Leading Through Trust, Not Authority

Why Leadership Fails

Some of the worst engineering leaders in the industry are technically brilliant. They can design systems that scale to millions of users. They can debug race conditions in their sleep. Yet they struggle to retain a team for more than a year.

Technical excellence alone does not make someone a good leader. It may earn respect initially, but it does not build trust. The difference between leaders who build lasting teams and those who constantly replace engineers lies in how they treat people, not how well they write code.

Not every poor people manager is technically brilliant either. Some are driven by insecurity rather than expertise. Control gets mistaken for leadership. Micromanagement gets sold as "maintaining standards." And criticism slowly replaces any real coaching. Over time, teams disengage and eventually leave.

There are leaders who lose multiple direct reports within a short period while insisting the problem is the talent market or that "this generation doesn't want to work hard." But persistent attrition is rarely a coincidence. More often than not, the problem is leadership itself.

Technical skill is table stakes. Leadership is measured by the environment you create and whether capable people choose to stay and grow under your guidance. Systems scale through architecture. Teams scale through trust.

Respect Creates Ownership, Submission Creates Compliance

When someone disagrees with you in a meeting and you shut it down, you did not win an argument. You lost the next ten ideas that person would have shared. Worse, you taught everyone else in the room to stay quiet.

Some leaders routinely override well-reasoned arguments with positional authority. The logic does not matter if the person presenting it has less seniority. Decisions get made by rank, not by reasoning. Teams learn this quickly. They stop preparing thoughtful proposals and start guessing what leadership wants to hear. That is not decision-making. That is obedience with extra steps.

Some leaders block innovation because they are unwilling to learn. They default to tools and approaches from years ago, not because those are the right choices, but because those are the ones they understand. Teams cannot pick the right tool for the problem. Everything gets forced through whatever the leader is comfortable with. New ideas get dismissed as unnecessary risk or over-engineering when the real barrier is the leader's own knowledge gap. Teams stuck in this cycle stagnate. The engineers who care about growth leave for environments that let them evolve. The ones who stay stop proposing anything new.

Google's Project Aristotle studied 180 teams over two years. The #1 factor in team effectiveness was not technical skill, seniority, or process. It was psychological safety. People on high-performing teams felt safe to take risks and be vulnerable in front of each other. That finding surprised Google's own leadership, who had assumed raw talent was the biggest lever.

Amazon's "disagree and commit" principle gets cited constantly, but it only works when the "disagree" part is genuinely safe. If people learn that pushing back means getting labeled "not a team player" or getting passed over for the next project, they stop pushing back. They also stop caring. You end up with a room full of people nodding along to a plan they know has holes, because pointing out those holes has a personal cost. That is not alignment. That is compliance dressed up as consensus.

Empathy Is a Practice, Not a Personality Trait

Empathy is not something you either have or you do not. It is something you practice, and you get better at it over time.

With your team: notice burnout before it becomes a resignation letter. When someone who normally speaks up in meetings goes quiet for two weeks, that is a signal. Do not wait for a one-on-one to ask about it. Walk over, send a message, check in. And never schedule a difficult conversation on a Friday afternoon. That person will spend their entire weekend in their own head.

With stakeholders: understand the pressure they are under from their own leadership. The product manager who keeps changing requirements is probably getting squeezed by senior leadership that changes priorities every board meeting. That does not make the churn acceptable, but it changes how you address it. You stop fighting the symptom and start addressing the cause.

With candidates: they remember how you treated them whether you hire them or not. Asking someone how they are feeling during a stressful system design interview takes five seconds and fundamentally changes the dynamic.

Feedback Is a Skill, Not a Scheduled Event

Saving feedback for performance review cycles does more damage than most leaders realize. By the time you bring up a pattern you noticed months ago, the engineer has spent all that time thinking everything was fine. The conversation feels like an ambush, not a development opportunity.

Good feedback is timely and specific. "The way you handled that production incident yesterday was strong, especially how you communicated status updates to stakeholders" is useful. "You're doing great" is not. Equally, "The approach you took in that design review dismissed input from the rest of the team" is actionable. "You need to be more collaborative" is vague enough to ignore.

Separate observation from judgment. Talk about what you actually observed, why it mattered, and hear their side before jumping to a fix. Most people already know when something went wrong. They need a leader who helps them understand why it happened and how to adjust, not one who delivers a verdict.

Make feedback a regular habit, not a dreaded event. When it only happens during formal reviews or after something goes wrong, people associate feedback with punishment. When it happens consistently, in both directions, it becomes part of how the team operates. On the best teams, feedback goes in every direction. Peers give it to each other. The team gives it back to the leader. Nobody waits for a formal process.

Giving Credit Is Not Optional

Not giving credit is a leadership failure. Full stop. It destroys trust faster than any technical mistake you can make.

Name people when you give credit. "This problem was solved by the engineer who designed the caching layer" lands completely differently than "we solved this." One builds loyalty. The other breeds resentment, because the person who did the work knows it, and so does everyone on the team.

When your team ships something great, resist the urge to present it yourself. Let the engineer who built it present in leadership reviews. Your job is to create opportunities for your people to be visible, not to be the funnel through which all visibility flows. When someone on your team gets promoted, celebrate it publicly and loudly. When they leave for a better offer, ask yourself what you missed. Not what is wrong with them.

Leaders who present their team's work at every leadership review without ever bringing the engineers into the room lose people. One leader lost three of their best engineers in six months this way. The justification was "shielding them from politics." The engineers believed their work was being stolen. Intent does not matter when the impact is this clear.

Favoritism is another form of credit failure. When the same few people consistently get the high-visibility projects, the conference talks, and the shout-outs in all-hands meetings, the rest of the team notices. An inner circle forms. Those outside it stop volunteering for stretch work because they have learned it will not be recognized. Over time, you end up with a two-tier team where half the people are engaged and the other half are coasting toward their next opportunity. Spreading visibility around is not being generous. It is your job.

Shared Ownership Over Individual Achievement

Treating outcomes as individual achievement is how you build a team of territory guarders. Everyone protects their service, their feature, their domain. Nobody helps with anything outside their lane because there is no incentive to do so.

Shared ownership looks different. The backend engineer helps debug the frontend issue because it blocks the release, not because someone assigned them a ticket. The senior engineer reviews the junior's PR thoroughly instead of rubber-stamping it, because the team ships together or fails together. Teams that celebrate wins together and run postmortems together build a fundamentally different culture than teams where one person gets the credit and everyone else gets the action items.

Stripe built a culture where engineers routinely fix bugs in services they do not own. That did not happen by accident. It happened because leadership consistently recognized cross-team contributions in performance reviews and promotions. What you reward is what you get.

Ethics Under Pressure

You will face moments where pressure to ship overrides the right call. Pushing a security fix you know is incomplete because the deadline is tomorrow. Letting a toxic high-performer stay because their output looks good on the quarterly slide. Hiding context from your team because "they do not need to know." These moments define you more than any architecture decision.

One engineer's output can look exceptional on paper while the surrounding team quietly falls apart. People stop collaborating with them. Knowledge sharing dries up. The best engineers on the team start interviewing elsewhere, not because of the work, but because they can see that leadership cares more about output than culture. Every month the situation continues, it sends a clear message: this behavior is acceptable here. By the time the toxic engineer is finally addressed, the damage to the team is already done. The people you most wanted to keep have already left.

Be transparent about trade-offs. If you are shipping with known technical debt, tell the team why and commit to a timeline for fixing it. If you are making a decision they will not like, explain your reasoning. People can handle bad news. They cannot handle discovering that you hid it from them.

Some leaders go further. They actively control what their team can say to people above them or across teams. The product has known problems, but the team is told not to surface them. Cross-team transparency disappears because honest communication would expose poor decisions the leader does not know how to fix. This is not protecting the team. This is protecting the leader at the team's expense. Problems get worse when nobody outside the team knows about them. By the time they finally surface, they are much harder to fix, and the team's credibility takes the hit right alongside the leader's.

Admit when you got it wrong. This is terrifyingly hard for leaders who built their career on being right. But the moment your team sees you say "I made the wrong call on that migration timeline, here is what I learned," you give everyone else permission to be honest about their own mistakes. That single act does more for psychological safety than any workshop or offsite.

Making It Safe to Fail

Psychological safety is not about being nice or lowering the bar. It means people can take risks, own their mistakes, and push back on ideas without worrying about getting punished for it.

When a junior engineer proposes something that will not work, do not say "that won't work." Say "let's walk through what would happen if we tried that." The first response kills curiosity. The second teaches critical thinking. The difference in those two sentences is enormous, and junior engineers remember which kind of leader you were for years.

Praise publicly. Correct privately. This is old advice because it works. Run blameless postmortems and actually follow through on the "blameless" part. If every postmortem ends with action items assigned to the person closest to the failure, people will learn to avoid being near failures. They will avoid taking risks. They will avoid owning hard problems. Your org will calcify.

Accountability and Safety Are Not Opposites

You can hold people to high standards while making it safe to fall short. Most managers think they have to choose. They do not.

Separate the person from the outcome. "This deployment process needs to improve" is accountability. "You keep messing up deployments" is blame. The first invites problem-solving. The second invites defensiveness.

Kim Scott's Radical Candor framework gets this right: care personally AND challenge directly. Most managers only do one. Caring without challenging creates what Scott calls "ruinous empathy," where you are so worried about someone's feelings that you never tell them the truth. Challenging without caring creates fear, and fear kills every behavior you actually want from your team: risk-taking, honesty, collaboration, ownership.

The goal is a team where people hold each other accountable because they trust each other, not because they fear consequences. That takes years to build and one bad quarter to destroy. Protect it like the asset it is.

The Long Game

None of this is quick. Building a team where people trust each other, challenge each other, and hold each other accountable takes real effort, consistently, over years. There are no shortcuts, no frameworks you can install in a quarter, no offsites that fix a broken culture in two days.

But the compounding effect is real. Keeping your commitments, owning your mistakes, passing credit to the people who earned it. All of that adds up. And it pays back when things get hard. And things always get hard. The leaders who survive those moments are not the ones with the best technical instincts. They are the ones whose teams choose to stay and fight alongside them.

Systems scale through architecture. Teams scale through trust. Build accordingly.