BONUS The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First With Roman Nikolaev

BONUS: The Communication Tax — Why Your Team Collaborates Too Much and What to Cut First

In this BONUS episode, Roman Nikolaev challenges one of the most deeply held beliefs in the agile world: that more collaboration is always better. As Head of Technology at Cambri, Roman has watched teams burn their best hours in meetings and handoffs that create the feeling of productivity without the outcomes. He shares practical tools — from the vacation test to RFC processes — that help teams find the minimum viable level of collaboration.

From Senior Engineer to Accidental Manager

"I kind of accidentally ended up in management. I didn't want to lead anyone, I wanted to be just a senior engineer doing my stuff. But somehow, four months in the job, I was already leading a team, and then one year after, I was head of technology."

Roman's career in engineering goes back to the early 2000s. When he changed jobs during COVID, he specifically didn't want a management role — he wanted to code. But within months he was leading a team, and within a year he was running the entire technical organization at Cambri. That unexpected shift from hands-on engineering to leading teams gave him a front-row seat to how collaboration actually works — and how often it doesn't. What he noticed was that the most important differentiator for technical teams isn't technical knowledge — it's communication, and the tax you pay when communication goes wrong.

The Communication Tax Is Real

"The communication tax is real. The less we need to pay for communication, the more we can concentrate and own things end to end."

Roman describes a pattern most teams will recognize: stakeholders inside and outside the team — product managers, QA, scrum masters, product owners — and at some point, it becomes a game of telephone. The people doing the actual work don't have the context they need. The result? Unnecessary features, wrong implementations, suboptimal technical solutions that don't scale. His argument isn't that collaboration is bad. It's that every handoff, every meeting, every "quick sync" has a cost — and most teams aren't honest about how much they're paying.

Handoffs Aren't Collaboration

"If you look at a typical software development lifecycle — a ticket created by a product owner, refinement with the team, development, code review, QA, acceptance — there are quite many handoffs. If we can reduce some of this, we get a more effective workflow."

Roman walks through the standard ticket lifecycle and counts the handoffs: PO creates ticket, team refines, developer picks it up, code review with other developers, QA phase, acceptance phase. Each transition is a potential information loss. His provocation: instead of involving more people when someone struggles with a task, give the person working on it the tools and knowledge to complete it independently. The trigger for his thinking was a real team conversation where someone suggested everyone should "jump on the ticket" to help. Roman's response: wouldn't it be better to equip the individual rather than create more dependencies?

Async Tools That Actually Work

"Instead of gathering a meeting where people come unprepared or with some raw ideas, we have ownership for a task. Someone takes their time, writes down their thoughts, options in a document, and then we assign people to review it."

Roman shares two async practices his teams use at Cambri. First, the RFC (Request for Comments) process on Confluence — one person owns a decision, writes it up with options, and assigned reviewers sign off asynchronously. It turns out to be more effective at finding better technical solutions while spreading knowledge without requiring synchronous deep-dives. Second, his Monday written updates: every week, he spends about 90 minutes writing a detailed post covering all project statuses, what happened last week, what's coming, and business context. The team feedback in skip-level meetings is consistently positive, and he fields far fewer questions about business context and priorities than before the practice started.

The Vacation Test

"One heuristic would be that if one of the team members goes on vacation, the rest of the team can continue working on their task."

Roman learned this the hard way. He went on a typical Finnish one-month vacation. Before leaving, he explained the architecture and intent for a key task to his team. He came back to discover they'd built the completely wrong thing — wasting one month of a two-month project. He spent the remaining time working weekends, on planes, on trains, just to hit the deadline. The lesson wasn't that he needed more collaboration or synchronous communication before leaving. It was that he needed better communication — and a way to test whether shared context actually exists. His heuristic: if Alice goes on vacation, can Bob continue from where she stopped? If not, you don't need more meetings. You need better async context-sharing.

Where to Start: Ownership First, Then Cut Meetings

"I would probably first look into if a particular initiative, a feature, or some kind of process has an owner and well-defined roles. Usually, if there is no clear owner, that leads to a lot of synchronous meetings."

For Scrum Masters and team leads looking for a practical starting point, Roman offers a two-step approach. First, ensure every initiative, feature, and process has a clear owner with well-defined roles. Without clear ownership, meetings multiply because nobody is sure who's responsible, so everyone attends everything. Second, look at the team calendar starting with the biggest meetings and ask: can this be an RFC? A message? An email? Then experiment — cancel a meeting, replace it with an async channel, and see what happens. You can always bring it back. In the agile world, Roman argues, we should embrace experimentation with our own processes, not just our products.

Recommended Resources

Roman recommends Team Topologies by Matthew Skelton and Manuel Pais. The book gave him a clear mental model for independent teams that own their area end to end — teams aligned to value streams that own the customer problem completely. For more of Roman's thinking on collaboration, check out his Substack newsletter: Is Your Collaboration Good or Evil? on High Impact Engineering.

About Roman Nikolaev

Roman Nikolaev is Head of Technology at Cambri. He's spent his career thinking about how teams actually get work done — and his contrarian view that most teams collaborate too much has sparked real debate in the agile community.

You can link with Roman Nikolaev on LinkedIn.