This is an interesting follow-up to the original example. I quite like the proposals he makes (although with some reservations about the extreme one —- some level of contact with end users is always valuable in my experience)
However, relevant to contemporary software (where nearly every project, regardless of scale, seems to need a team...):
The exception, of course, is that makers working in teams have ways to communicate within their team.
My experience is that “the team” seems to be a disproportionate source of interruptions. If anything, I wonder about a system where a manager acts as a form of message-queue within the team. Pretty much the direct opposite of a lot if contemporary approaches (...scrum...) but perhaps a bigger increase in maker-schedule time than focusing on external interruptions.
However, relevant to contemporary software (where nearly every project, regardless of scale, seems to need a team...):
The exception, of course, is that makers working in teams have ways to communicate within their team.
My experience is that “the team” seems to be a disproportionate source of interruptions. If anything, I wonder about a system where a manager acts as a form of message-queue within the team. Pretty much the direct opposite of a lot if contemporary approaches (...scrum...) but perhaps a bigger increase in maker-schedule time than focusing on external interruptions.