This is a really good description of a natural tension any engineering team has to deal with. I specially liked the framing of pair programming as a powerful hybrid.<p>A challenge the OP doesn't touch on is the need for individual focus _during_ coordination events. For example, someone is presenting their design ideas to an audience who's seeing them for the first time. In order for the coordination to be productive, the audience needs to be good at focusing in realtime to grok the ideas presented to them. It'd be unfortunate to rely on your team's ability to pull off a burst of focus on demand. Some can do this well, some can't, and you only water down your coordination if you rely on it too much.<p>I've read about and quite like writing-heavy workflows, e.g. presenter writes and shares a 4-6 pager, or meeting starts with people silently reading a memo. The async-ness and the reliance on written word pulls a lot of weight when there's too much depth/breadth involved; the kind of thing that happens a handful of times a quarter.<p>But this is hard to pull off consistently every week for small iterations that nonetheless need coordination on cognitively demanding topics.<p>How do folks deal with this?
There are some interesting analogies and truths here, but also dogmatic statements about focus and coordination being mutually incompatible. I tend to think that there is no conflict between those two - focus is always possible. However, as you move to higher levels of abstraction, you share your focus with more people to architect a solution, then you all split off to go down to the detailed abstraction levels for individual tasks/work.<p>One of my former co-workers used to be adamant that what makes a good developer is someone who is comfortable sliding up and down abstraction layers. It resolves so many problems, and lets you aim your focus where it is needed most.
Nicely captured and well thought out. As an engineering manager with 30 engineers in a 120-people company working on a social marketplace, our company requires an extraordinary amount of coordination, while engineers also need to focus.<p>I do feel like the post speaks quite a bit about extremes - focus, coordination, perfect, unproductive etc etc, while most of the teams sit somewhere in between trying to find that balance the author is referring to.<p>Also, the position of where they are changes on a daily basis depending on what work is being done and who is joining and who is leaving.<p>Wearing my engineer hat on, I'd love to, just get the requirements and tell everyone to go away while I focus on my work, but I also understand the whole coordination part. It's absolutely critical to making the team efficient & productive, which often go unnoticed and unappreciated.
I'm not sure if these are opposite ends of the spectrum.<p>I think the article says it best, focus results in actions. But coordinating, is an action in itself. The act of attending an all hands meeting, or even meeting with a group of people requires focus(e.g. to be fully present in a meeting). Or to prepare for an all-hands meeting a manager has to focus and think of an agenda.<p>I feel like focus is a supporting act for almost everything and we have a problem with balancing among too many things.
I’ve found one good way to manage this tension is doing coordination by “pair programming” on a shared markdown file in a collaborative text editor. Dropbox paper is good for this.