As a maker-turn-manager I've become skeptical of this perspective. I think it's indulgent and misdirected. Yes, if I as a manager schedule your time, I'm prob

As a maker-turn-manager I've become skeptical of this perspective. I think it's indulgent and misdirected. Yes, if I as a manager schedule your time, I'm probably not going to schedule it for your best performance. But I don't think the problem that as a manager I don't leave you giant blocks of uninterrupted time. It's that as a manager I tend to interrupt your time with meetings that serve my role, and a manager's role tends to be focused on prediction, expectations, upward-directed planning, balancing work, status, risk... all things that aren't even intended to improve actual execution. In theory of course a manager is supposed to be focused on team performance and execution, but the heaviest pressure on a manager is about how the team fits into the larger organization, not how the team works. If a maker's days are interrupted by meetings that are genuinely structured to improve their execution, I don't think the interruption is very concerning, and may be beneficial. This theory about a Maker's Schedule, and these theories around attention, make these positive interruptions less likely to happen – the maker's become skittish about all meetings, become reclusive, sometimes causing a downward spiral because the maker actually needs those meetings and becomes more reclusive out of shame because the maker is confused and performing poorly. Defensively the maker reacts against the structure that remains – the structure of meetings created by the manager, meetings which aren't supportive, where the maker is not sufficiently engaged to feel confident in repurposing the meeting... but the dysfunction is that in the face of these meetings a better response would be more meetings, better meetings, meetings where the makers leave the meeting ahead of where they started instead of behind. But don't expect the managers to call those meetings – frankly as a manager I often can't make those meetings happen even when I want to. I'll also copy a post I wrote on the topic (https://plus.google.com/u/0/+IanBicking/posts/jgJCdMkzyBE https://plus.google.com/u/0/+IanBicking/posts/jgJCdMkzyBE): I'm somewhat pro-meeting, which maybe puts me at odds with the cultural norms of developers. I think I realize some of the problem. Meetings tend to be called by managers. Managers have management goals. Process, deadlines, coordination, etc. The developer sits around in case they provide some important input on one of those topics, or to give status, or to commit to a deadline. Nothing in that kind of meeting helps the developer's work. And the developer tries their best to withhold, to protect their own work, but also to protect the project which actually needs that output. In a developer-oriented meeting the topics would be decisions to make, architectural choices to consider, noting places of tension where a creative solution could be helpful. In a developer meeting it is reasonable to take some time to look at code. To do a bit of research – right in the meeting – to answer a question. To brainstorm ideas. If a problem is hard, it is reasonable that everyone go silent for a minute and ponder the problem. In The New Science of Building Great Teams (https://hbr.org/2012/04/the-new-science-of-building-great-teams https://hbr.org/2012/04/the-new-science-of-building-great-te...) they discuss some evidence-based observations about communication patterns. In it they suggest that high levels of communication lead to more productivity. By developer sensibilities, very high levels. But mostly peer interactions – developers interacting with developers. I'd really extend this to all the people engaged in making the product, design, user experience, user research, development, probably support and other roles. In an ideal model there would be dozens of meetings, as different sets of these people came together to talk about what is relevant to those groups of people. These meetings would not have clear and firm agendas, the product is the agenda, finding the agenda is some of the work of the meeting. It's easy to blame management for the unproductive meetings. We're calling these snooze-fest status meetings. But I'd turn it around: professionals shouldn't depend on management to initiate meetings. Sure management can try; I try to setup meetings I think will be productive for other people. The Standup is the quintessential example. But we know where those so often end up: as yet another management-led status meeting. And it's a form without a clear purpose. Who should be in the standup? What should we talk about? When those things are defined by management we get management-style answers. Even better than trying to fix the standup, keep it from being necessary: make the meetings that help everyone do their work, where the topic is always execution and not prediction or planning or status. With Project Managers and other professions focused on planning there is a danger that we defer to the specialists. But everything needs to be planned. The next line of code I write has to be planned. Developers have to be planners, every one of them.