I spent years blaming management for micromanaging me. Turns out I was begging for it.
Not consciously. Nobody walks into a meeting thinking “please, take this decision away from me.” But that’s what I was doing. That’s what my team was doing. That’s what most teams do.
It took me three companies to see the pattern. And to realize I was part of it.
Nobody designed it. But once it exists, people with authority decide whether it continues.
The Accidental Education
My first real engineering job was in a startup. Tiny. No process. No handbook. No one to ask.
When something needed deciding, I decided. Not because I was competent—I was a mass of anxiety and Stack Overflow tabs—but because there was nobody else. The alternative to deciding was not shipping.
I made mistakes. Plenty. But I learned something I didn’t know was rare: when there’s no safety net, you build judgment. You learn to estimate consequences. You ship, you watch what breaks, you fix it, you remember.
I thought this was just how software worked. It wasn’t.
The Institution
A few years later, I joined a large public organization. Big digitalization project. Agile transformation. I thought I’d finally learn how “real” engineering worked.
We had sprints. Ceremonies. Retros. I had latitude on my UI and implementation details. It felt like ownership.
Then I hit authentication.
We were building a suite of internal applications. Users needed to move between them seamlessly. Basic requirement: log into App A, and App B knows who you are. That requires a central identity provider.
We didn’t have one.
I raised the issue. The response was polite and absolute: the infrastructure had been decided years earlier. In meetings. By people unreachable by the integration team. The architecture was politically frozen.
Reversing it would have meant admitting those meetings got it wrong. That had a cost. So the decision lived on.
I hacked together a workaround. Shared cookies under the same subdomain. It mostly worked. I documented the edge cases where it didn’t. Then I quit.
What I learned later is this: decisions made in rooms full of people tend to fossilize. Not because they’re good, but because undoing them has political cost. Seniority becomes a shield against revisiting them.
The Title Comes With Authority (On Paper)
Later, I joined a large organization as a tech lead. This time, I had real authority—at least formally.
The onboarding was full of modern language: lean product thinking, agile principles, outcome-driven development. I was optimistic.
It took time to understand how decisions actually flowed. Who influenced what. Where power really sat.
And then the frustration crept in.
Product decisions felt locked before the problems were even discussed. I blamed leadership. All of it. People preaching agility while it quietly failed underneath.
That story was comforting. It was also incomplete.
The Mirror
I started watching a very specific kind of meeting: decision meetings.
Here’s the pattern. A developer faces a technical choice—a library, a pattern, an approach. Instead of deciding, they book a meeting. Five or six people. An hour. At least one senior person present.
The stakes are usually low. A recoverable mistake. Something a well-paid senior engineer could decide alone.
The developer presents options. Discussion follows. Some engage, others stay silent. Forty-five minutes pass.
Then the most senior person says: “OK. Let’s go with option B.”
Meeting over. Decision made. Everyone was in the room. Nobody owns the outcome.
The manager didn’t want to be there. But by staying and breaking the tie, they become the decision mechanism. Every time.
They decide. They get invited again. The team notices. It confirms the belief they already had: decisions need approval from above.
The cycle feeds itself because authority intervenes at the wrong level: deciding outcomes instead of defining decision boundaries.
And who calls these meetings? Not management.
Developers. Tech leads. Us.
We ask to be micromanaged — and management rarely refuses.
We just don’t call it that. We call it “alignment.” We call it “collaboration.”
Agile without ownership is theater.
The Word We Don’t Use
Agile assumes ownership. Teams own decisions. Teams own outcomes.
But “ownership” isn’t a word we actually use. We talk about tasks and responsibilities. Ownership implies something harder: when something fails, it’s yours. Not the committee’s. Yours.
That’s terrifying in most corporate cultures.
“Fail fast” assumes failure is survivable. That a wrong call doesn’t follow you for years. That the market is liquid enough to absorb mistakes—you fail here, you learn, you get hired there.
In Switzerland—and across much of Europe—failure is expensive. I’ve seen it in my own career, and I’ve heard the same pattern from engineers at other companies across industries: a bad decision becomes a story. It resurfaces in calibrations. It colors perception for years. It accumulates as reputation debt.
The rational move isn’t to decide fast. It’s to make sure you’re never wrong alone.
The fear is rational. But rational fear is not a design constraint — it's a signal the organization has failed to make ownership safe.
So people optimize for shared responsibility. Meetings aren’t decision tools. They’re insurance policies. If this blows up, at least six people approved it. Including someone senior. Nobody’s career dies alone.
What Ownership Actually Requires
Across multiple organizations, in Swiss tech, healthcare, and finance, I’ve seen the same pattern. When I stopped blaming individuals, the real gaps became visible.
Vocabulary. We avoid “ownership” because we don’t mean it. Accountability happens after something breaks. Ownership happens before—the decision, the risk, the bet. Most organizations have rich language for blame and almost none for intent.
Data. You can’t own decisions about users you don’t know. Many developers can’t describe their users beyond job titles. Not “pharmacists”—which ones? The rural ones juggling three legacy systems? The hospital ones with workflows imposed from above?
If you’ve never watched a user struggle with your product, you don’t have insight. You have assumptions.
Domain boundaries. Every domain has red lines—legal, financial, safety, reputational. If you don’t know where they are, you can’t evaluate whether a decision crosses them.
This isn’t an excuse to escalate everything. It’s a reason to learn.
Method. People aren’t taught how to evaluate impact, reversibility, or blast radius. We assume judgment is absorbed through experience. It isn’t. It’s built by deciding, observing consequences, and adjusting.
Most organizations never allow that loop to run.
These aren’t nice-to-haves. They’re prerequisites. Everything else is process theater without them.
A Simple Way to Sort Decisions
Once those prerequisites exist, most decisions can be sorted quickly using two axes: reversibility and impact.
| Low impact | High impact | |
|---|---|---|
| Reversible | Decide alone, document | Propose async, validate |
| Irreversible | Tech lead decides | Meeting justified |
Three boxes out of four don’t require a meeting.
The hard part isn’t the matrix. It’s honesty about which box you’re actually in.
Fear upgrades everything to “irreversible, high-impact.” That’s the reflex to fight.
A gut check: if the worst-case cost of being wrong is less than roughly 10% of your annual salary, you can probably decide alone. That covers most library choices, most refactors, most architectural micro-decisions.
If you’re unsure, ask one peer. Just one. Dialogue sharpens thinking; committees dilute it.
If you’re escalating below that threshold, you’re not being careful. You’re being afraid.
Making It Stick
Frameworks don’t change culture. Habits do.
Ownership doesn’t have to be granted globally to exist locally.
It can be created inside a team, within explicit boundaries, even when the wider organization isn’t ready for it — and without waiting for permission.
The decision log. Decisions made alone still need visibility—not for approval, but for learning. Date, decision, context, alternatives rejected, owner. Public to the team.
When something breaks, you don’t hunt for blame. You trace thinking.
Normalize recovered mistakes. When a decision goes wrong and someone fixes it, say it out loud. Celebrate the loop, not just the outcome.
Protection from above. None of this works if the first mistake gets punished.
Tech leads: when someone on your team makes a call within their authority and it’s wrong, you own it upward.
Managers: same principle, higher leverage.
Break the cycle actively. If you’re in a position of authority, stop attending the theater.
Every time you show up and decide something that didn’t need you, you train the system to need you.
The Uncomfortable Truth
Ownership is uncomfortable by design. The real test isn't letting your team decide; it's letting them decide differently.
Most organizations don't actually want that. Ownership means mistakes. It means managers letting go. This is why it rarely survives contact with hierarchy.
If you can't watch your team make a call you disagree with without stepping in, you don't want ownership. You want compliance with extra steps.
Ceremonies are easier. But stagnating safely has a cost too—it's just not on any dashboard.
We're all training the system. But not all roles train it equally. We can also untrain it.
Views and experiments described here are my own and don’t represent my employer.
Top comments (0)