The Work Outside the Code

A tech lead told me about a moment she knew something was wrong. Her team had been building systems that generated data for other teams to act on. They’d crushed their goals. Improved their metrics far beyond what anyone expected. The team was proud of the work.

But almost no one was using the data.

She raised it with her manager. The metric, she explained, measured what her team could achieve, not what the business actually needed. The work that would have made a difference required alignment across teams, decisions above her authority, and expertise her team didn’t have. Her manager heard her. Nothing changed. The organization had other priorities.

So the team kept delivering. Good work. A lot of it, but it was disconnected from what actually mattered.

She was leading her team and raising issues. That’s what stuck with me. She was doing everything right inside her team’s boundaries. The problem was the boundaries were wrong, and no one was willing to redraw them.

I’ve been interviewing engineering and product leaders from startups to large organizations for a book about what unlocks teams. Different scale, different companies, but the same patterns.

Here is what I’m hearing. The hard problems never sit neatly inside one team. They cross boundaries, functions, sometimes entire organizations. But most teams stay focused on the slice in front of them. They solve their part well, but they don’t always connect.

One leader described a team where everyone had their own lane. Ten people. Twelve workstreams. Nobody was working together. When something changed, they couldn’t adapt. No one had enough context to see what was coming or where the opportunity was.

Another leader told me some of the happiest, best-functioning teams they’d seen weren’t actually doing anything useful. People liked each other. Work shipped steadily. Nothing looked broken, so no one stepped in. That’s not a team problem. It’s a leadership problem. And it can go on for a long time.

And now there's a new pressure making it harder to ignore. Every engineering leader I talk to is getting some version of the same question: how is your team using AI to ship faster? It’s a fair question. Over ninety percent of developers now use AI coding tools at least monthly. At some companies, more than a quarter of production code is AI-generated. Code speed was a bottleneck, and that bottleneck is dissolving.

The average developer spends less than 20% of their time writing code. AI is helping there. The rest of the work: deciding what to build, getting the right people on it, making sure it all connects, hasn’t improved in the same way. Producing more code faster may actually be making this worse.

That tech lead already knew what mattered. She told her manager exactly what the real problem was. It didn’t move anything, because the team wasn’t shaped to solve it.

But some of the leaders I talked to are doing something different.

Form a temporary team around the problem itself. Instead of pushing work into the org structure, assemble a small group with one job. Own the problem, solve it, move on.

Before that can work, someone has to make the problem visible across the teams that each hold a piece of it. Talk to the teams. Learn their vocabulary. Write it down in plain language and ask: did I get this right? Once everyone agrees on what they’re actually solving, a team can form around something real.

Harvard researcher Richard Hackman studied what determines whether teams succeed or fail. Team design turned out to be almost forty times more powerful than coaching. A leader’s most important decisions happen before the team starts working, defining the right task, assembling the right people, setting up the structure.

Make the stakes clear. Not the company mission. What happens if this team fails? What’s at risk, right now, for real customers or users?

When stakes are abstract, every direction sounds reasonable and nobody asks what to stop doing. When stakes are concrete, the team feels pulled toward the work rather than pushed.

One leader turned an abstract company mission into a concrete challenge their team could feel. Another set a technical target so ambitious it forced the team to completely rethink their approach. They achieved a 100x improvement on a metric most people thought couldn’t move 2x. In both cases, the mission didn’t change. The stakes got real. And a team that had been going through the motions started running.

But the leaders I interviewed didn’t treat this as a one-time exercise. Problems shift. The team that was right six months ago may not be right now. The leaders who kept teams moving kept reshaping: narrowing the problem, pulling in the right people, reforming around what mattered next.

This is what makes AI actually useful.

AI doesn’t fix scattered ownership and it doesn’t resolve misalignment across teams. What it does is accelerate iteration once a team is clear on what it owns and what success looks like.

A small, focused team can use AI to move faster because the feedback loop is tight. They know what good looks like. They can iterate quickly and see if it worked.

AI is solving the code bottleneck, and it’s surfacing the one that was always underneath. What AI can’t do is look at a problem that crosses three organizations, figure out that nobody owns it, and reshape a team to solve it. That’s the work outside the code. It’s always been leadership work. And it’s about to matter a lot more.

What’s the biggest mismatch you’re seeing right now between your team’s shape and the problem they need to solve?

I write a weekly newsletter on what actually makes engineering and product teams move: http://melodyolson.com/newsletter.