There’s a particular kind of meeting I’ve come to dread. Everyone’s in the room. The problem is on the table. Ideas are flowing. And an hour later, you walk out with nothing — no decision, no owner, just a vague agreement to “keep discussing.” Everyone feels heard. Nobody feels led.
I’ve run that meeting more times than I’d like to admit.
Early in my leadership career, I believed collaboration was almost always the right answer. If I involved the team in every decision, I’d get better outcomes and higher morale. Two birds, one stone. What I actually got was decision paralysis, frustrated senior engineers, and a team that was polite but quietly losing confidence in my leadership. It took me a while — and some direct feedback from a team lead who told me, bluntly, “We need you to just make the call sometimes” — to understand what I was getting wrong.
The problem wasn’t collaboration itself. The problem was that I’d turned it into a default mode instead of a deliberate tool.
The Collaboration Myth
There’s an unspoken orthodoxy in modern engineering leadership: collaboration is inherently good, directive leadership is inherently risky. It shows up in management training, leadership books, and conference talks. “Empower your teams.” “Seek diverse perspectives.” “Create psychological safety.” All good advice — until it becomes dogma.
Here’s what nobody tells you: collaboration has a cost. Every person you include in a decision adds latency. Every brainstorming session you run instead of making a call delays execution. Every “let’s get alignment” meeting is time not spent building. And past a certain point, the returns diminish sharply.
I manage multiple teams across Germany and Canada at AutoScout24 and Trader Inc. At that scale, the cost of unnecessary collaboration is not abstract — it’s measurable in weeks of delayed delivery, in engineers sitting in meetings instead of writing code, in decisions that get relitigated because the last discussion didn’t produce a clear outcome.
The uncomfortable truth is that overcollaboration is at least as common a failure mode as micromanagement. It’s just less visible, because nobody complains about being asked for their opinion. They just quietly disengage when they realize their input doesn’t actually change anything — that the meeting was performative, a ritual of inclusion rather than a genuine decision-making process.
When Collaboration Actively Hurts
Not all decisions benefit from group input. Recognizing which ones do — and which ones don’t — is one of the most important judgment calls an engineering leader makes.
Decisions with clear ownership shouldn’t be collaborative. If someone owns a system, a domain, or a deliverable, they should make the calls within it. Asking the whole team to weigh in on a database schema that one engineer owns isn’t empowerment — it’s diffusion of responsibility. The owner loses agency, the team loses time, and the decision often gets worse because it becomes a compromise between people with unequal context.
Urgent decisions shouldn’t be collaborative. During a production incident, a critical escalation, or a hard deadline, the team needs direction, not a brainstorming session. I’ve seen leaders try to run democratic processes during crises — “What does everyone think we should do?” — and the result is always the same: slower response, confused teams, and escalating damage. In those moments, the team is looking for someone to say, “Here’s what we’re doing. Here’s your role. Go.”
Reversible decisions shouldn’t be collaborative. Jeff Bezos called these “two-way doors” — decisions you can easily undo. If the cost of being wrong is low and the cost of deliberation is high, just decide. Pick the monitoring tool. Choose the sprint cadence. Name the service. Move on. You can always change it later.
Where collaboration genuinely adds value is in decisions that are irreversible, high-stakes, and require expertise you don’t have. Architecture decisions that will shape the system for years. Organizational changes that affect people’s careers. Strategic bets that commit significant resources. These deserve real input from people with relevant context — but even here, “collaboration” doesn’t mean “consensus.”
The Consensus Problem
Consensus is collaboration’s most dangerous byproduct. It feels democratic and fair, but it optimizes for the wrong thing: agreement rather than quality.
When a group of smart people tries to reach consensus, the result is usually a lowest-common-denominator solution — something everyone can live with but nobody is excited about. The boldest ideas get sanded down. The strongest opinions get diluted. And the person with the most conviction often stays quiet because pushing too hard feels socially risky.
At AutoScout24, we ran into this during a planning session for a major platform initiative. We had strong engineers with legitimate but conflicting perspectives on the architecture. After two hours of discussion, we’d converged on an approach that was… fine. Safe. And, I realized later, worse than any of the individual proposals it was trying to synthesize.
What we do now is different. When we can’t reach agreement — and this happens regularly with a large engineering organization — we use a simple rule: we vote, the majority wins, and we document the minority’s concerns. Not to dismiss them, but to acknowledge the trade-off explicitly. If the minority turns out to be right, we have a record of what they were worried about and can course-correct faster.
This approach does something important: it makes disagreement productive rather than something to be smoothed over. Engineers learn that it’s safe to advocate strongly for their position, because even if they lose the vote, their reasoning is captured and respected. That’s a healthier dynamic than the false harmony of consensus, where disagreement gets buried and resurfaces later as passive resistance or disengagement.
The leader’s job in these moments isn’t to build consensus. It’s to ensure the best arguments get heard, make a decision (or delegate the decision to someone with the right context), and then commit fully — including supporting the outcome publicly, even if it wasn’t your preferred option.
Direction Without Micromanagement
The opposite failure mode — too much direction — is well-documented and easier to spot. Micromanagement kills initiative, erodes trust, and drives your best people to update their LinkedIn profiles. But there’s a subtler version of over-direction that often goes unrecognized: being directive about the how when you should only be directive about the what.
I once worked with a leader who had a strong software engineering background and couldn’t resist making suggestions on database table structure, optimization strategies, and testing approaches. Their intentions were good — they genuinely had relevant expertise. But the effect on the team was corrosive. Engineers stopped proposing their own solutions because they knew the leader would override them anyway. Innovation dried up. The team’s senior engineers, the ones you most want to retain, were the first to lose motivation.
The framework I use now — and the one I enforce with my own engineering managers — comes from how we structure OKRs at AutoScout24. I own the what and the why: the objectives we’re pursuing, the key results that define success, and the reasoning behind them. The teams own the how: the initiatives, the technical approach, the implementation details. Initiative owners identify milestones and are free to pivot whenever they see their approach isn’t moving us toward a Key Result.
This isn’t a loose “figure it out” delegation. It’s structured autonomy. The boundaries are clear. The expectations are measurable. And within those boundaries, teams have genuine freedom — including the freedom to make choices I wouldn’t have made myself.
The hardest part of this, honestly, is shutting up. When a team chooses an approach I think is suboptimal, my instinct is to intervene. But I’ve learned that the cost of occasionally letting a team take a longer path is far lower than the cost of teaching them that their technical judgment doesn’t matter. People learn by doing — including by making mistakes that their boss could have prevented but wisely didn’t.
There are exceptions. If a decision creates significant technical debt that other teams will inherit, or if it violates a security or compliance constraint, I intervene. But I do it by explaining the constraint, not by dictating the solution. “This approach doesn’t align with our platform vision” is direction. “Use Fargate instead of ECS” is micromanagement — even if Fargate is the right answer.
Reading the Room
Knowing when to switch between collaborative and directive modes is the real skill. And it’s mostly pattern recognition built over years of getting it wrong.
There are reliable signals for each mode.
Your team needs more direction when:
- Discussions keep circling without converging — the same arguments repeat across meetings.
- The team is new, either to the domain or to each other, and hasn’t built the shared context needed for autonomous decision-making.
- Delivery has stalled despite everyone being busy — a classic sign that effort isn’t aligned with priorities.
- The team explicitly asks for it. This happens more often than leadership literature suggests. Good engineers don’t want to be told what to do, but they do want clarity about what matters.
Your team needs more collaboration when:
- You’re facing a problem outside your own expertise — and you’re honest enough to admit it.
- A decision will significantly affect people who aren’t in the room. Bringing them in isn’t just considerate; it surfaces constraints you’d otherwise miss.
- Trust is low, often after a reorganization or acquisition. Directive leadership in low-trust environments reads as authoritarian. Collaborative leadership builds the relational capital you need before you can be effectively directive.
- The team has deep domain expertise that you don’t. This is increasingly common as organizations scale — no leader can maintain deep technical context across every system their teams own.
The transitions between modes matter as much as the modes themselves. When I shift from a collaborative phase to a directive one — say, when a brainstorming discussion needs to become a decision — I make the shift explicit. “We’ve heard the options. Here’s what we’re going with, and here’s why.” No ambiguity. No pretending it’s still collaborative when it isn’t.
Similarly, when I deliberately step back and ask for input, I clarify what kind of input I’m looking for. “I want to hear alternatives” is different from “I want to hear concerns about this plan,” which is different from “I want the team to decide this.” Vague invitations to collaborate produce vague results.
What Scale Changes
Everything I’ve described gets harder as organizations grow. With five engineers, you can operate almost entirely on informal collaboration and gut-feel direction. With forty, you can’t.
At scale, the collaboration-direction balance gets encoded into process whether you design it deliberately or not. Undesigned process is worse — it means the loudest voices drive collaboration, the most senior person’s opinion becomes direction, and the rest of the team oscillates between the two without a clear framework.
What works at AutoScout24 is an explicit structure at multiple levels. Strategic direction — OKRs, platform vision, organizational priorities — flows from leadership. Tactical collaboration — how to solve a specific problem, which approach to take, what trade-offs to accept — lives within teams. And in between, there are mechanisms for cross-team alignment: shared backlogs, regular demo sessions where teams show what they’ve built, and Slack channels where platform decisions get discussed openly before they’re finalized.
The critical insight is that collaboration and direction aren’t opposing forces you balance on a scale. They operate at different levels of abstraction. You can be highly directive about outcomes and highly collaborative about implementation at the same time. In fact, that combination is what the best engineering organizations do — clear alignment on where we’re going, genuine autonomy on how we get there.
When we recently communicated a 54% reduction in high-severity incidents, the outcome was the result of clear direction — this was a priority, these were the metrics, this was the timeline — combined with deep collaboration on the technical solutions. I didn’t tell teams how to reduce incidents. I told them it mattered, gave them the tools and platform support, and got out of the way.
The Leader’s Real Job
The balance between collaboration and direction isn’t something you solve once. It shifts with every new team, every new project, every phase of organizational growth. What worked when you managed eight engineers won’t work when you manage forty. What works for a team that’s been together for two years won’t work for a team formed last month from an acquisition.
The job isn’t to find the perfect ratio and lock it in. It’s to develop the judgment to read each situation accurately and the flexibility to adjust — sometimes within the same meeting. To be the person who says, “Let’s discuss this” and also the person who says, “I’ve heard enough, here’s what we’re doing.” And to know which moment calls for which.
That judgment comes from experience, from failure, and from paying attention. It comes from the team lead who told me to stop asking and start deciding. It comes from watching a brilliant engineer disengage because their leader never let them own anything. It comes from seeing a team deliver their best work because their leader gave them a clear objective and then genuinely trusted them to figure it out.
Collaboration and direction aren’t competing values. They’re complementary tools. The skill is knowing which one to pick up — and when to put it down.