Finding Signal in the Noise: Communication Patterns for Platform Teams
Two identical projects, two radically different outcomes. What made the difference? The answer lies in how we schedule our communication. In one, we were constantly in meetings, checking status, discussing progress. In the other, we just met every other week. The results? The first one was a classic death march - frequent meetings, missed deadlines, frustrated developers. The other one? Delivered everything on time, with minimal fuss. Not something you see every day in software development.
Here's the thing though - having lots of meetings isn't always wrong. Sometimes we genuinely need them, like when requirements are fuzzy or we're venturing into unknown territory. The problem starts when we treat every project like it needs maximum oversight.
The Trade-Off
This gets at something fundamental in software development: the trade-off between efficiency and flexibility. Organizational scholars O'Reilly and Tushman (2013) call it the exploitation-exploration dilemma. Teams need to balance efficiency using productive processes (exploitation), while staying flexible enough to handle new challenges (exploration). The tricky part? These modes require different communication patterns, and mixing them up can be catastrophic.
Take our struggling project. The project manager treated an implementation task as if we were exploring uncharted territory. All those extra meetings didn't make us more flexible - we didn't need flexibility. They just kept developers from getting into that precious flow state where the real work happens.
Maker's Schedule, Manager's Schedule
This problem with flow actually points to something deeper about how we work in software teams. Paul Graham, in his influential essay "Maker's Schedule, Manager's Schedule", identifies a fundamental disconnect: Managers think in hour-long blocks, whereas developers need half-day chunks of uninterrupted time to get anything done.
It's not just about preference. As Graham notes, "You can't write or program well in units of an hour. That's barely enough time to get started." A developer needs sustained concentration to solve complex problems. When someone drops a quick meeting from 11am to 11:15am , they are not just taking fifteen minutes - they are potentially destroying half a day of productive work. The developer loses focus before the meeting (because who starts something complex when they know they'll be interrupted?), and afterwards, it takes ages to get back into the zone. And by then, it's probably lunch time.
This scheduling conflict explains why our successful project, with its bi-weekly meetings, worked well. By moving all communication into predictable slots, we protected those crucial half-day blocks where real development happens. The struggling project, with its scattered meetings, effectively prevented any deep work from taking place.
Let's look at three basic patterns now.
Anti-Pattern
The first pattern is one we've all encountered - the one that kills productivity. It usually starts when project managers get nervous about progress, and default to what we can call "control overkill".
The warning signs are clear:
This was exactly what happened in our struggling project. We had good requirements, but somehow still ended up in daily progress checks that did nothing except make some people feel like they were in control. The irony? The more we met to talk about progress, the less progress we actually made. Engineers were constantly switching context, never reaching that crucial flow, and delivered less, while appearing to communicate more.
领英推荐
Flow-Optimised Pattern
Now let me share what worked in the successful project. The foundation is simple: get clear on requirements upfront, then protect the team's ability to execute.
Here's what it looks like in practice:
We used this approach in the Easy Tickets project. Engineers stayed in their flow, and when they did hit a blocker, they never stayed stuck for long. The key? We treated interruptions like what they are - exceptions, not the rule.
Intentional Pattern
Of course, not every project starts with perfect clarity. Sometimes requirements are still evolving, or we're exploring new territory. In these cases, we use a more flexible pattern - but one that still protects developer productivity.
It looks something like this:
The big difference from the anti-pattern is intentionality. We know we need more communication, and we still protect those valuable half-day blocks where real development happens. The goal remains clear: get enough certainty to shift into our more efficient pattern as quickly as possible.
Conclusion
I can't stress enough how much difference the right communication pattern makes. Once you really get the disconnect between maker's and manager's schedules, once you start treating flow state like the precious resource it is, and once you match your communication to what the project actually needs - that's when teams really shine.
It's actually pretty simple when you break it down: Start with clarity. Default to the flow-optimised pattern whenever you can. Use the balanced approach when you genuinely need flexibility. And please, resist that urge to over-control through excessive status updates.
I've seen this approach transform multiple teams and projects. Engineers rediscover their productivity, project managers get actual control (not just the illusion of it), and suddenly projects start hitting deadlines. And here's the best part: You don't need budget approval, new tools, or a reorganisation to happen. You just need to accept one simple truth: in software development, thoughtful silence often beats constant chatter.
References: