Building Trust With a Team You Just Inherited

The first team I inherited had already lost two managers in eighteen months, and they told me so in the first meeting. Not as a complaint, exactly. More as a warning: we have watched people like you come and go, so forgive us if we don't repaint the walls for you. Six engineers, one payments gateway that processed real money for real merchants, and a wall of quiet skepticism I could have leaned against.

I have inherited four teams since then, twice through reorgs and twice through acquisitions. Every time, the technical problems were the easy part. The hard part is that a team you inherit did not choose you, and trust is not transferable from the person who hired you. You start at zero, sometimes below it, and no amount of enthusiasm in your first all-hands will move that number.

You Start Below Zero, Not at Zero

New managers love to believe they walk in neutral. You don't. An inherited team has a history you weren't part of, and that history is usually the reason there's an opening for you at all. Someone left, someone was pushed, a reorg swallowed a whole org chart. Whatever the story, the team lived it and you didn't, and they are watching to see whether you're the sixth version of a pattern they already know how to survive.

On that payments team, the previous lead had promised a rewrite of the settlement service for three quarters running and delivered nothing but slide decks. So when I mentioned, casually, that the settlement code looked like it needed attention, I watched two people physically lean back. I had accidentally said the exact sentence that meant "here we go again." I didn't know the landmine was there. That's the point. The landmines are invisible to you and load-bearing for them.

So I stopped treating the first month as a chance to impress anyone. Below zero means the first job is not to add value. It's to stop subtracting it.

Listen Before You Touch Anything

I run the same thing every time now: a round of 30-minute one-on-ones with each person in the first two weeks, and I ask roughly the same four questions. What's working that I should be careful not to break. What's broken that everyone knows about and nobody has fixed. What do you want to be doing in a year. And the one that gets the best answers: if you were me, what would you be worried about that you're not telling me yet.

That last question does real work. People will tell you the org chart is fine and then, thirty seconds later, explain that the on-call rotation is quietly destroying one specific engineer who has covered 60 percent of pages for a year because everyone trusts her and nobody wants the 3 a.m. calls. That's not in any document. You only get it by asking a human being directly and then shutting up long enough for the answer.

The fastest way to lose an inherited team is to diagnose out loud in week one. You haven't earned a diagnosis yet. You've earned a notebook.

The First Real Decision Is a Test

There is always a first decision that the team actually cares about, and they will remember how you made it far longer than what you decided. It might be a promotion case that stalled, a piece of tech debt someone has been begging to fix, or whether to keep the Friday deploy freeze that half of them find pointless and half consider sacred.

On one team, the pending question was whether to kill an internal tool that one senior engineer had built and clearly loved, and that almost nobody else used. Killing it was obviously correct on the numbers. But I made a point of talking to him first, privately, explaining the reasoning, letting him argue the other side, and giving him the job of writing the migration plan rather than just announcing the tool's death in standup. We still killed it. He still ran the migration. And the message the rest of the team took was that decisions here come with reasons and dignity attached. That reputation was worth more than the tool ever was.

Make the first hard call cleanly, transparently, and with the affected person in the room before it's final. People are not really evaluating your judgment yet. They're evaluating whether you're safe to be honest around.

Fix One Small Thing They Openly Hate

Grand strategy earns you nothing in month one because nobody believes it will survive contact with reality. But there is always a small, stupid, daily irritation that the team has stopped even complaining about because complaining never worked. Find it and kill it fast.

Concrete examples of what I mean, because "quick win" is a phrase that has been drained of all meaning:

• A CI pipeline that took 40 minutes because nobody had been given time to parallelize the test suite. Two days of work I authorized in week one; it dropped to 11 minutes.
• A staging environment that had been broken for months, so every engineer tested in ways they weren't supposed to admit to.
• An access-request process that routed through a manager who had left the company, meaning new hires waited a week for database credentials.
• A recurring meeting that four people attended out of habit and nobody needed, which I simply cancelled.

None of these are strategic. All of them signal something strategic: that you listen, that you can move, and that "someone finally fixed that" is a sentence people will now say about you. That sentence is currency.

Don't Trash the Person Before You

This one is a discipline, because the easiest way to look competent is to imply your predecessor wasn't. It is also poison. Half the team probably liked that person, some of them made the decisions you're now criticizing, and every time you disparage the old regime you teach the room exactly what you'll say about them the day you leave.

I inherited a codebase once that was, by any honest measure, a mess. Circular dependencies, a database schema that told the story of five different abandoned architectures, tests that asserted almost nothing. It would have been easy, and satisfying, to say so. Instead I said something closer to the truth: this was built under deadline pressure by people who were solving the problem in front of them with the time they had. That's not a lie you tell to be nice. It's usually just what happened. And it lets the people who wrote that code help you fix it instead of defending it.

You can be honest about the state of things without being contemptuous about the people who produced it. The team is doing the math on which one you are.

Learn the System With Your Own Hands

Trust with engineers has a technical component you cannot fake and cannot delegate. At some point you have to show that you understand what they actually do all day, and the way you do that is by getting into the system yourself, not by nodding along in architecture reviews.

I don't mean you need to be the best coder on an inherited team. You won't be, and pretending otherwise is embarrassing. I mean pick something small and real and ship it through the actual pipeline. On the payments team I fixed a genuinely annoying bug in the reconciliation report and pushed it through the same review, the same deploy, the same on-call handoff that everyone else used. It took me the better part of three days for something a senior engineer would have done in an afternoon. Worth every hour. I now knew, from the inside, that our deploy process required manual approval from a Slack channel that was muted by default. You cannot learn that from a diagram, and the team saw that I'd chosen to learn it the hard way.

Spend Your Credibility Protecting Them

The moment that turned the payments team was not a technical decision. It was an incident review where a senior VP wanted a name attached to an outage. The outage was real, a bad config push had taken down settlement for 90 minutes, and the pressure to produce a scapegoat was intense.

I took it. Not in a martyred, theatrical way, just flatly: the process allowed a single unreviewed config change to reach production, that's a system failure I own, and here is what we're changing so it can't happen again. The engineer who pushed the config was in the room. So was the rest of the team. Nothing I said in any one-on-one over the previous two months did as much as that ten minutes of taking the hit in public. Managers who feed their teams to leadership to save themselves get found out immediately, and the team had clearly seen it before.

Give It a Quarter Before You Judge Anyone

You will form opinions about individuals in the first week. You will be wrong about at least one of them. The quiet person who seems disengaged is often the one holding three critical systems together and has simply learned that speaking up gets them more work. The loud confident one is sometimes loud and confident about things they don't actually understand.

I try to hold my personnel judgments loosely for a full quarter, because inherited context distorts everything. Someone labeled "difficult" by the previous manager is frequently just someone who asked inconvenient questions. I'd rather re-earn my own read on each person than inherit a verdict I didn't witness the evidence for. Ninety days is roughly how long it takes for the performance people put on for a new boss to wear off and the real working rhythm to show up.

Conclusion

Here's the thing nobody tells you: the goal is not for the team to like you. Plenty of well-liked managers get quietly worked around. The goal is for them to believe that when you say something, it's true, and that when it costs you something to protect them, you'll pay it. Likeability is optional. Reliability under pressure is the whole game. Get that right with a team you inherited, and one day you'll say something looks like it needs attention, and instead of leaning back, they'll lean in and tell you they've been waiting for someone to say so.