The 90% Problem · deegeevince

Irfana shared something that should have stopped the room: 80% of engineer time is spent in meetings, not coding. Winston, four weeks into his internship, put it more starkly: 10% of his time here is spent coding, versus 90% at his previous internships.

These are symptoms. The responses throughout the day stayed at the surface: AI would help, governance is the problem, skill gaps. But we're not asking the right question: why are these meetings happening in the first place?

An engineer fundamentally writes code. A system, a platform, a customer experience: all of it is code. If 90% of an engineer's time is not spent writing code, that's not a performance issue. That's a structural failure.

To be clear: we built shared platforms and centralised teams to gain efficiency and consistency. That was the right logic at the time. But at our current scale, that centralisation has become a bottleneck. And the usual explanations don't cut it.

It's not primarily about skill. Yes, there are experience gaps. But even if every engineer suddenly became expert-level, the meetings would persist. The meetings aren't happening because engineers don't know what to do. They're happening because engineers aren't empowered to decide.

It's not primarily about governance. We talk about governance as if it's an external force imposed upon us. But the meeting schedule, who attends, how long it runs: that's all within our control. Nobody is mandating 90% meeting time. We're creating it ourselves because we haven't solved the underlying problem.

So what's the root cause?

Meetings occur for one of two reasons:

I need information from someone else, or
Someone needs information from me

Both trace back to the same structural problem: I don't have the context, the authority, or the confidence to just act. So I need to talk to someone. And because ownership is unclear, I often don't even know who that someone is, so I pull in multiple people to figure it out. That five-minute question becomes a thirty-minute call with eight people.

There's another layer to this. When there's no single person accountable for a domain, you need collective validation before making any change. If something goes wrong, you need to be able to say "these people all knew about this change." So for every architecture change, every platform change, you pull in multiple engineering leads to validate: "am I good to make this change?" Not because you need their expertise on every detail, but because there's no one person up the chain who can actually own the decision. The meeting becomes a way to distribute accountability that should have been clear from the start.

A concrete example

A product team in Australia wants to ship a customer-facing change. To do this, they need to modify the platform codebase. But they don't own that code. They're not familiar with it. They don't have the historical context. They don't know what will break.

They have two options:

Option A: Just do it. Push the change, hope for the best. But this introduces defects. The platform team has to clean it up. An incident gets raised. MTTR goes up. Everyone firefights. Nobody wants this.

Option B: Talk to someone. But who? The platform team? Which person on the platform team? The principal engineer? The solution architect? Which solution architect? Does every country's changes flow through the same people? What's their actual decision authority? Can they approve, or do they need to consult someone else?

This is how a single code change becomes a meeting. And then another meeting. And then a sync to align on the outcome of those meetings.

This is why AI adoption is not going to help. First of all, who has the time to work on AI when 90% of your day is in meetings? And even if you did, AI can't tell you which solution architect to call. It can't decide whether your change needs cross-country alignment. It can generate code in seconds, but if you still need three meetings to figure out which file to change, or why the code has certain business logic in the first place because there's no tests, no documentation, and it was poorly copy-pasted from somewhere else, you haven't solved anything. Worse, if engineers blindly trust AI output without the experience to validate it, you compound the problem. More code, less understanding, more defects, more meetings to clean up the mess.

The result is structural coupling

Every change requires:

Cross-team consultation
Cross-country alignment
Cross-platform coordination
Escalation when there's conflict

There's no place where a team can just decide and act, because:

They don't own the code end-to-end
They don't control the funding for what they depend on
They don't have clear decision rights
The platforms serve multiple countries with competing priorities, so there's no single direction to align to

The problem compounds because our funding model doesn't match our operating model. Countries fund their own priorities. But they share regional platforms. Regional platforms serve multiple countries with competing needs. Country A wants X, Country B wants Y, both require the same platform change. Who decides priority? Who decides the pattern? Who decides the timeline?

There's no clear answer. So we have meetings to figure it out. And then more meetings when those meetings don't resolve it. And then escalations. And then alignment sessions.

This isn't a skill problem. It isn't a governance problem. It isn't an AI adoption problem. It's an ownership problem. We don't have clear owners at a manageable team size with defined decision authority and accountability for outcomes.

What would need to change

I don't have the full answer. But I know the direction.

Code ownership at team level. Small enough that one person can hold the full context. Small enough that communication stays manageable. A team of eight can coordinate. A team of fifty fragments into silos that need meetings to reconnect. The unit of ownership needs to be small enough that someone is actually accountable and actually knows what's happening.

Platform and product owners who actually own. This means understanding the technical reality of what they own, at least at a surface level. It means being able to make priority decisions without needing to consult five other people first. It means being accountable for outcomes, not just for facilitating conversations.

Decision rights that match accountability. If you're accountable for an outcome, you need the authority to decide. If you can't decide, you're not really accountable. You're just a messenger shuttling between meetings.

Funding alignment with operating model. If platforms serve multiple countries, the funding and prioritisation model needs to reflect that. Otherwise every platform decision becomes a negotiation between competing interests with no clear tiebreaker.

Boundaries that enable autonomy. Clear ownership, clear APIs, separation of concerns. When your change doesn't ripple into someone else's domain, you don't need their permission to ship.

None of this happens overnight. But we need to start by agreeing on the problem before we jump to solutions.

There's also a trade-off we need to be honest about. If we give teams more autonomy, we will get some duplication. Teams will build similar things in parallel. We'll lose some consistency. Is that acceptable? I think it might be, if the alternative is what we have now: perfect consistency in theory, paralysis in practice, and 90% of engineering time spent in meetings. But that's a decision we need to make together.

You can't fix this by telling people to have fewer meetings. You fix it by building a structure where meetings become unnecessary. Where an engineer can look at a piece of code, understand it, change it, test it, and ship it without needing consensus from three countries and five platform teams.

The 90% problem won't change until we address the structural coupling that creates it. That's the conversation we need to have.