Is your collaboration good or evil?
Signals, self-assessment, and three levers to reduce collaboration tax
I went for a lunch break. One hour later, when I returned my Slack was on fire. Fifteen unread messages in public channels, some unread threads where I participated, and a few direct messages.
I've learned to read moments like this as a diagnostic. The types of messages hitting your Slack, the meetings filling your calendar, and how long work takes to ship — they all tell you whether your collaboration is good or evil.
Signal #1: Message types
FYI — something good to know for people who follow a certain project or area. Alice started working on a stakeholder presentation. Bob found a bug, created a ticket, and is fixing it.
These messages might or might not require a reaction from you.
Asynchronous input request — somebody needs your input but not urgently. An RFC review, a new design review, a presentation to review before next week. These requests have a deadline but can be satisfied on your own terms. You don’t need to stop doing what you are doing.
Synchronous input request — someone needs your decision or answer now. Otherwise they cannot continue. You hold a critical piece of information, or you are a decision maker. Others cannot continue without you.
You can read more about modes of asynchronous communication here.
Think of those three message types as a spectrum: FYI on the left, async requests in the middle, synchronous requests on the right. Our goal is to shift the collaboration left — toward a world where most communication is FYI, some is async, and synchronous requests are rare.
The amount of synchronous requests is a signal that tells us about the health of communication in the organization.
Signal #2: Meetings
Another signal is your meetings. These can be roughly split into the following groups:
Connecting. Team-building activities. Connecting on a human level, often outside of the work matter at hand.
Innovating. Getting together to create something new together. The process produces something better than any individual solution.
Deciding. A meeting to make a decision as a group. Gathering the opinion of the group and making a decision.
Informing. All kinds of status updates, information sharing, syncs etc.
If your meetings are primarily about informing and deciding, it usually means that information is not effectively circulated within the organization. It can also signal overly hierarchical decision-making and lack of ownership.
Signal #3: Cycle time
There is a third signal — how long does it take from a developer picking up a task to it being released? If a two-day task takes two weeks to release, the difference might be your collaboration overhead.
Do we have a problem?
An organization with centralized decisions, lacking documentation and weak ownership generates sync requests. The message types and meetings are symptoms. The organizational culture and its structure are the cause.
This is when collaboration turns evil — when it stops being a choice and becomes a tax on every piece of work.
Like water, the right amount is essential for life. Too much — and the roots rot.
Collaboration Overhead Self-Assessment
I created a self-assessment questionnaire you can use to gauge where your team stands on cross-team and internal team autonomy.
For each question, answer yes (1 point) or no (0 points). Score based on your default, not your best day.
Cross-team (Max 5):
Can the team and their PM/PO decide what to build without further approval?
Can the team decide how to build it without external sign-off?
Can the team release to production without external approval?
Can the team ship a feature end-to-end without other technical teams?
Does the team learn about business priority changes directly from the source?
4-5: Your team has strong autonomy. Protect it. 2-3: Some external dependencies are slowing you down. 0-1: Your team can’t move without permission. This is your biggest leverage point.
Inside the team (Max 4):
Can an urgent bugfix be released with only a code review and no other approval gates?
Is the default first step for technical proposals and design reviews to write it down?
Can someone understand a system through documentation and code alone?
If a team member is on vacation for two weeks, does their work continue?
3-4: Strong async culture and low internal dependencies. Your team has space to focus. 2: Some internal friction. Look at your defaults — meetings or documents? 0-1: Knowledge and decisions are trapped in individuals. Start with documentation.
Solving the problem: three levers
To reduce dependency-driven collaboration, we can pull on three levers.
Localize decision-making — push decisions down to the team that does the implementation. Every time a decision has to travel up a chain or sideways to another team, that’s deep work interrupted — not just for the person asking, but for the person being asked.
Default to asynchronous collaboration — choose writing over meetings as your first instinct. A design shared as a document that people review on their own time costs one person an hour of writing. A meeting to walk through that same design costs everyone an hour simultaneously.
Make information available — when someone needs context — why a decision was made, how a system works, what the business priorities are — they can find it without tapping someone on the shoulder. The goal is to turn tribal knowledge into accessible knowledge.
Word of caution
Autonomy without alignment is dangerous. A team that ships fast but builds the wrong thing creates more damage than a slow team building the right one. Pushing decisions down only works when the team understands the business context and the goals (you can read about how to expose your team to the business context here).
Final thoughts
Ineffective collaboration is the most persistent problem I have encountered. Teams lacking autonomy and asking for permissions. Teams isolated from the business that create products nobody wants. Teams where every question requires a meeting. Teams where developers are continuously bombarded by direct messages.
Balancing autonomy and alignment is difficult. But this small space between two extremes is the place where high-impact product teams live.
Thank you for reading and see you next week,
Roman
P.S. Scaling an engineering org is hard — especially without a sounding board who’s been through it. I’ve spent 20 years building software and then scaled a startup’s engineering department into a top leadership role. I learned management in the trenches, made the mistakes, and figured out what actually works. Today, I help engineering leaders and startup founders stress-test their strategy and scale their teams without repeating those same mistakes.
If you’re facing a challenge — whether it’s org design, technical leadership, or figuring out how to grow from here — drop a message on LinkedIn.