Trust, Ownership, Feedback, and Excellence

The engineering teams I look back on as truly great share less than people assume. Smart people, of course. Doing this work well is hard, and the teams I'm thinking of were all made up of people who were good at it. But smart, capable people are also on plenty of teams that never come together. What separated the great ones was a way of working together that kept them improving. The teams got better at delivering, better at handling pressure, better at recovering when something went wrong. That continuous improvement is what always mattered more than any particular high point along the way.

Four things make that possible, and they're what I work on with every team: trust, ownership, feedback, and a relentless push for excellence. They reinforce each other. Trust enables ownership. Ownership creates the need for feedback. Feedback drives excellence. And excellence, over time, builds back more trust. When one of these is weak, the others tend to weaken with it.

Trust

The clearest way I've found to talk about trust on a team comes from a New York Times interview with Tobias Lütke, the CEO of Shopify, that I read about ten years ago. He described something he called the trust battery. The idea is that between every two people there's a battery, and every interaction either charges it or depletes it. It sounds silly, but it has stuck with me, and the more I've run software organizations, the more I've seen it hold up. The battery isn't just between individuals. It's between teams. Between engineering and product marketing. Between engineering and sales. Between a company and its customers. Every commitment kept charges it. Every missed expectation drains it.

This is why I care so much about ETAs. Software isn't perfectly predictable, and treating every estimate as a promise carved in stone is its own kind of dysfunction. What matters is the pattern. If an engineering team tells product marketing they're going to ship something on a particular day, and product marketing spends money on ad placements and podcast spots based on that date, and the team doesn't ship it, they've lost more than the project. They've lost the ability for product marketing to plan around them. The next time that team gives a date, why would product marketing believe it? They shouldn't. The team earned that. So when I push my teams to get better at estimates, I'm really pushing on the trust battery. Estimates are how a team keeps it charged with everyone who depends on it.

The same dynamic shows up between engineering teams, and even between engineers on the same team. A team waiting on another team's API to finalize and ship their work. An engineer planning their week around a teammate's PR landing. A project where three pieces all need to converge before anything ships. Every estimate is a promise someone else is already planning around. When dates start slipping without warning, the people downstream lose the ability to plan, and the trust between them and the team that gave them the date drains the same way.

Trust is also a resource the team accumulates and gets to use. The hardest thing for an engineering team to negotiate is time for the work that doesn't have immediate customer value. Better systems, better observability, better foundations. The team that delivers what it commits to gets that time. The team that misses dates and lets scope creep without saying so loudly doesn't. Trust is what gives engineering the room to push for the things engineering needs.

Ownership

Micromanagement doesn't scale. The manager who has to make every decision becomes the bottleneck, and the team learns to wait instead of think. I don't run teams that way, and I don't think most people should be on the receiving end of it either. The cost compounds quickly. People stop bringing ideas forward. They stop catching things they would have caught otherwise. They stop owning the work, because the work isn't really theirs to own.

What I want is for people to make decisions and feel empowered to make them. The goal is for the team to keep getting better at it, project by project.

Ownership includes a sense of where decisions should be made. Some sit cleanly with the individual, the person closest to the work. Others belong to the team, where the call affects more than one person's area or sets a pattern others will follow. A smaller number genuinely need to escalate, because they're really product decisions or company-level tradeoffs. The goal is for most decisions to land at one of the first two levels, with the team gradually getting better at handling more of them itself. The team is driving, not waiting for someone to put a ticket at the top of the backlog and bring it to standup as the next thing.

Driving the work still happens inside a structure. There are product owners setting direction, priority, and requirements. There's an architectural design process for the things that need it. There's a platform team building out golden paths so the team doesn't have to make every decision from scratch for work that fits the mold. The team's work is in how it gets built, how it operates in production, and how the implementation decisions add up over time.

Ownership also extends past the moment a change merges. Owning a service means staying close to it once it's in production, watching for issues, and actually knowing how it works. That last part has been weighing on me lately, especially with how much code is now generated. It's possible to ship a lot of code without really knowing how it works, and that's a problem for ownership. You can't own what you don't understand.

Owning a service also means welcoming contributions from outside, with a review and a conversation. The team's job is to stay close to the work, set the bar for how it should land, and welcome contributions that meet the bar. When ownership turns into gatekeeping, it becomes a wall, and walls slow everything down.

Feedback

Honest feedback, in my experience, is one of the things teams most often fail at. People are capable of it. The hard part is that feedback is uncomfortable, and the easiest path is to soften it until it disappears. The phrase I use with teams is "take the personal out of it." We're critiquing the work, not the person. If someone offers a critique of something I've built, the first thing I have to do is recognize that my coworker is here for a reason. They're smart. They have experience and lenses I don't. If they're saying something, there's a reason. Maybe I miscommunicated. Maybe they caught something real. Either way, the feedback is information, and my job is to hear it.

There's a real difference between being nice and being kind, and feedback is where it shows up most clearly. The kindest thing you can do for someone is give them honest feedback. Withholding it doesn't protect them. It deprives them of the information they'd need to grow. It pushes the problem downstream where it gets bigger, and where it eventually does feel personal because it festered. In practice, this is a team where someone can say, clearly, "I don't think this is going to work," and have it land as part of the work rather than an attack on the person doing it.

Feedback also has to flow in every direction. If I want my teams to receive feedback well, I need to be able to receive it without getting defensive. This is something senior people have to model, especially with younger engineers in the room. They learn what's acceptable from watching us, and if we treat critique as something to win or deflect, that's what they'll learn to do too.

The other piece of feedback that matters is what happens after. A team can vent forever and never get better. The thing that distinguishes a feedback culture from a complaint culture is that feedback turns into action. The team schedules a retro because something went sideways and they want to learn from it. The retro produces a few specific things to do differently. Then they actually do those things differently the next time. Without that loop, the conversations are just noise. Same with postmortems. They exist to make the next incident go better and prevent the ones that can be prevented. Feedback that doesn't lead anywhere isn't really feedback.

Excellence

Excellence on a team is the quiet, consistent practice of getting better, noticing where you fell short and adjusting.

Over time, this is a team that becomes the subject matter experts on the systems they own. They know their area inside and out. They can answer every question that comes their way. They develop the systems thinking to see how everything interacts, and how a change in one place will land in another. They document what they know so it can be found later. And the team holds together as people come and go, because new members can come up to speed without the team going sideways.

Getting there means running two tracks at the same time. One track is the product work, the things the company needs to ship. The other is engineering initiatives, the investments in systems, tooling, observability, and the delivery workflow itself. The team that only runs the product track ends up on a hamster wheel. The team that only runs the engineering track loses the trust of the rest of the company. Both tracks have to be on the table, with the team negotiating the mix as it goes.

Negotiation is the right word here. Everything is a negotiation. Product comes in with requirements. The team needs to meet those, and they need to give estimates they actually hit. They also need to push for the engineering initiatives that pay off later. Better tests, better observability, the cleanup that makes the next feature easier to build. When the team keeps the trust battery charged with the rest of the company, they have standing to push for that time. When they don't, they don't. Excellence in this sense depends on trust. Without it, there's no room to invest in anything beyond the next ticket.

The pressure on this is heavier now than it was even a year ago. The early framing of AI-assisted development was that engineers would finally get time back for the things teams usually skip: documentation, cleanup, better testing, the careful design work that pays off downstream. What's actually happened is the opposite. The expectation flipped. Now the assumption is that the same engineer ships ten times more, and the parts of the system that don't scale at the same rate (review quality, observability, the team's ability to maintain what just shipped) are getting left behind. We end up juggling more projects, burning out, and shipping things we don't fully understand. I don't think we need to be on either extreme: people refusing to use these tools at all on one end, people pushing three hundred PRs a week on the other. The right place is in the middle. Use these tools to ship more than we could a year ago, but reinvest some of that time into the quality of the system around the code. Nothing else holds up if we don't.

How They Reinforce Each Other

I think about these four together because each makes the others possible. A team that has trust can give people the room to own things. A team that owns its work needs honest feedback as part of how it operates. Feedback that turns into action creates excellence over time. And excellence, when it shows up consistently, builds trust with everyone outside the team that depends on it. The cycle gives the team more room, which gives ownership more space, and so on.

It takes consistency and hard work to get a team improving like this. One interaction at a time. A commitment kept. A piece of feedback delivered without ego. A retro that actually changes how the next project runs. A small problem flagged before it grows into a big one. Over time, if the team keeps doing the work, they build resilience. As people come and go, as the company changes, as the work changes around them, the team stays great and keeps handling whatever comes next. Getting better is something a team has to keep choosing.