Leading Engineering Teams | Why Ownership Beats Talk

The fastest way to ground an overconfident engineer is to hand them a module and make it theirs: their bugs, their on-call, their failures, no shared blame to hide behind. I have led engineering teams for more than fifteen years, some grown past twenty engineers, and between 2018 and 2025 I watched this one move work where every pep talk, code review, and seniority argument failed. This post is the rule and the case that taught it to me, with no names and nothing softened.

Talk is cheap; shipping is the teacher

A team is mostly an argument about who is right. Junior and mid engineers walk in with strong opinions, which is fine, opinions are cheap to hold and free to defend. The problem is the gap between holding an opinion and shipping the thing the opinion is about. You can tell someone you have spent a decade keeping production apps alive through traffic surges that would flatten a tutorial project, and it changes nothing, because words do not transfer competence. The person across the table heard words too, in a course, on a podcast, from a senior they half-remember.

So I stopped trying to win the argument. The argument is not winnable with more talking, and trying to win it is how a lead becomes the most resented person in the room. What is winnable is the demonstration. Put the work in front of everyone and let the work say what no amount of seniority can say.

The 30-day project that would not boot

Here is the case I come back to. I handed a greenfield React Native app to a developer who debated me constantly, on architecture, on tooling, on things a single search would have settled. I gave him the project and, honestly, forgot about it for a month while I was buried elsewhere. When I checked back thirty days later, he had not built the first screen. He had not built the first layout. He could not get the app to boot at all. Thirty days, and the bootstrap itself was still broken.

React Native is a fair place for this to happen, to be clear. Its environment setup is genuinely fragile: Node versions, the native toolchain, Metro, simulator and SDK mismatches, any one of them will stop you cold. It is not a trivial first day. But it is also not a thirty-day wall for someone who reads the errors instead of arguing with them.

I sat down with him. The app was running in about a minute. The core of it was done that day. Nothing about that is me being fast; it is me having hit every one of those errors before and knowing they are not opinions, they are checklists. What changed was not his respect for my speed. What changed was that he stopped debating and started delivering. I call this the ownership flip: the moment a developer who was all argument becomes someone who actually ships, and it happens the day the thing becomes truly theirs. Respect followed the proof. It never once followed the title on my email signature.

Why a good interview predicts almost nothing

I hired across roughly 2018 to 2025, and the pattern held the entire window. The people who interviewed best, humble, curious, openly listing what they did not yet know and eager to learn it, were very often the exact opposite a few weeks in. The humility was a performance for the room, and a startup growing fast and hiring fast is a very forgiving room. Once the offer was signed, the same person who said "I would love to learn that" was debating settled facts and treating a decade of production scars as someone else's outdated baggage.

This is not a generational complaint and I want to be careful here, because the lazy version of this story is an older engineer grumbling about younger ones, and that version is both boring and wrong. Plenty of the sharpest people I have worked with had two years of experience. The real variable was never age or where someone learned to code. It was whether they had ever owned something in production long enough to be wrong in public and have to fix it themselves. People who had that were calm. People who had only ever learned in a sandbox, where every problem has a clean answer and nothing pages you at 3am, mistook fluency for competence. An interview measures fluency beautifully and ownership not at all.

Give them the module, not the task

The fix is structural, not motivational. A task is rented; a module is owned. If I assign you a ticket, the ticket is mine and you are renting your time to it, so when it breaks the failure routes back to me and you learn nothing except that someone will catch you. If I give you a subsystem, the bugs are yours, the on-call is yours, the design decision that looked clever in the pull request and turned ugly in production is yours to live with. That is the whole mechanism. Werner Vogels put the principle in one line back in 2006: "you build it, you run it". Running what you built is the part that teaches.

Ownership is also the only thing that ends the debating, because you cannot argue with your own production incident. The feedback stops coming from me, which is contestable, and starts coming from reality, which is not. The same logic runs through how I make records: a session musician or a co-producer who owns a part plays it like it is theirs, and I have written about that crossover in going from musician to lean SaaS team. Different craft, identical principle.

How ownership scales past twenty engineers

The obvious worry is that ownership does not scale, that if everyone owns their own thing you get twenty silos and a lead who is now the single point of integration for all of it. The opposite is true, and it is the only reason a team can grow past twenty engineers without the lead becoming the bottleneck for every decision. Each owner is a node that absorbs decisions instead of escalating them. My job stops being to have the answer and becomes to set the boundaries of each module cleanly enough that the owners can resolve most things between themselves.

This changes what the lead actually does all day. My job stops being to answer questions and becomes to draw the seams: name the modules, define the contracts between them, set the on-call rotation, and then get out of the way. Most of my time at twenty-plus engineers went into boundary design, not code review. When two owners disagreed at a seam I had drawn badly, that was my bug to fix, not theirs to escalate forever. Good boundaries are what let ownership scale; bad ones turn every module into a dependency on me.

This is exactly why I lead small, deliberate teams chosen for compounding skill over raw headcount, the same posture behind the stack I run my own ventures on. Ten engineers who each own their surface and ship will out-build thirty who are all waiting on the lead to adjudicate. Headcount adds coordination cost; ownership subtracts it. The grounded engineer, the one who has been wrong in production and fixed it, is worth several who have only ever been right in a sandbox.

The only lever that worked

After years of trying, ownership is the only lever I have found that reliably turns a confident talker into a dependable engineer, and it works precisely because it takes me out of the equation. I am no longer the authority to be argued with; the production system is. Respect, when it came, was a side effect of that, never the goal, and never something I could have demanded into existence. You can read more about how the engineering practice fits the rest of what I do on my about page. But the operating rule compresses to one sentence: stop telling people you are right, and give them something they cannot get wrong without owning the fix.