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.
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.
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.
But this is hard to pull off consistently every week for small iterations that nonetheless need coordination on cognitively demanding topics.
I'm one of those folks who can't focus on my own thoughts during a presentation. I can understand the ideas being presented, but cannot critically evaluate them until later.
All I can muster is to write down questions. It's just a bulleted list of "Slide number/title. Question." I can ask them in real time if the presenter consents to interruptions. Otherwise, I'll ponder over them later when I can focus, and follow up if necessary.
I pretty much never approve any decision in a presentation without later analysis. That is, unless there is somebody else in the room that I can delegate that analysis to post-approval.
There's a strong relationship between writing and focus. The more writing done beforehand, the more productive a meeting can be.
But writing is harder to coordinate over. Just think of all those multi-day hundred-message chat arguments that happen from time to time. Going completely async means things fall through the cracks by default, so we need to write more and more to compensate. But meetings are great for synchronizing information and coming to decisions quickly. Meetings have high information bandwidth and we're much more adapted to face to face conversation than back and forth writing.
So on top of the Focus-Coordination spectrum, there's the Sync-Async spectrum, where focus and async are on one side, and coordination and synchronous communication are on the other. We can use sync and asynchronous communication to achieve that balance between focus and coordination across time.
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.
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.
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.
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.
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.
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.
I feel like focus is a supporting act for almost everything and we have a problem with balancing among too many things.
Focus (as I tried to define it) is not just "paying attention", but more like "a flow state that moves things forward".
The problem is that coordinating forces us to break from that flow state in order to spread, organize, and mediate information across teammates. We can either pay attention to solving problems, or to communicating/informing/negotiating with people, but not both. The manager needs to shut off Slack in order to prep for the meeting, for example.
But you're right. Focus is required to coordinate properly and coordination is required to focus properly. It's an intricate dance. The tricky part is moving between the two states in a harmonious way.
Focus vs Coordination aims to be a bit less verbose, but what I really mean is "doing stuff well" vs "aligning on the stuff we should do".
It's also important to emphasize that doing stuff well is much harder than doing stuff, and thus less compatible with talking and alignment. And same for the other side. We can talk all we want, but actually aligning requires intention and attention. And that coordination-attention draws energy from our execution-attention.
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.
Readit News
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.
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.
But this is hard to pull off consistently every week for small iterations that nonetheless need coordination on cognitively demanding topics.
How do folks deal with this?
All I can muster is to write down questions. It's just a bulleted list of "Slide number/title. Question." I can ask them in real time if the presenter consents to interruptions. Otherwise, I'll ponder over them later when I can focus, and follow up if necessary.
I pretty much never approve any decision in a presentation without later analysis. That is, unless there is somebody else in the room that I can delegate that analysis to post-approval.
But writing is harder to coordinate over. Just think of all those multi-day hundred-message chat arguments that happen from time to time. Going completely async means things fall through the cracks by default, so we need to write more and more to compensate. But meetings are great for synchronizing information and coming to decisions quickly. Meetings have high information bandwidth and we're much more adapted to face to face conversation than back and forth writing.
So on top of the Focus-Coordination spectrum, there's the Sync-Async spectrum, where focus and async are on one side, and coordination and synchronous communication are on the other. We can use sync and asynchronous communication to achieve that balance between focus and coordination across time.
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.
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.
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.
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 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.
I feel like focus is a supporting act for almost everything and we have a problem with balancing among too many things.
The problem is that coordinating forces us to break from that flow state in order to spread, organize, and mediate information across teammates. We can either pay attention to solving problems, or to communicating/informing/negotiating with people, but not both. The manager needs to shut off Slack in order to prep for the meeting, for example.
But you're right. Focus is required to coordinate properly and coordination is required to focus properly. It's an intricate dance. The tricky part is moving between the two states in a harmonious way.
Focus vs Coordination aims to be a bit less verbose, but what I really mean is "doing stuff well" vs "aligning on the stuff we should do".
It's also important to emphasize that doing stuff well is much harder than doing stuff, and thus less compatible with talking and alignment. And same for the other side. We can talk all we want, but actually aligning requires intention and attention. And that coordination-attention draws energy from our execution-attention.