Inheriting an Engineering Team You Did Not Hire

Last updated: August 29, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

When you inherit an engineering team you did not hire, diagnose the system before you judge the people. Most of what reads as individual underperformance is your predecessor’s operating model still running, and it will produce the same results with anyone sitting in those seats.

The first thing they handed me was a list of names.

Three of them, ranked. The outgoing VP had put it together on his last Friday, and my new boss slid it across the table in week one with the relieved expression people get when they think they are handing you a gift. Here are your problems. Fix these and the rest sorts itself out.

Second name on the list was a backend engineer who had shipped almost nothing in two quarters. Low output. Skipped most of the demos. Textbook.

He was also the only person in the building who understood the rate-lock service.

That fact was written down nowhere. Every time pricing broke, which was roughly weekly, someone would quietly pull him off roadmap work to go fix it, and because incident work got logged against a different project, none of it ever showed up next to his name. Two quarters of firefighting rendered as two quarters of nothing. The list was not wrong about the output. It was wrong about the cause, and those are very different problems carrying very different price tags.

The List Was Not Wrong About the Output

KORE1 publishes this one because the same pattern keeps surfacing in their engineering staffing work, usually as a client convinced they need three more engineers when what they actually inherited was a measurement problem.

I want to be careful here, because there is a version of this argument that turns into an excuse for never holding anyone to anything. That is not the argument. The output was real. The chart was accurate. Nobody fabricated the two quarters.

What was missing was the denominator.

Every inherited team arrives with a performance record attached, and that record was generated inside a system you did not design, under priorities you did not set, measured by instruments you did not choose. You are reading the output of an experiment where somebody else controlled all the variables. Then you are being asked to draw conclusions about the people.

Most new leaders take the record at face value for about six weeks, which is roughly how long it takes to make a decision you cannot walk back. I have done it. The engineer I moved off a team in month two at a previous company turned out to be the only one raising a schema concern that later cost us eleven days of rework, and I have thought about that one more than I would like.

You Inherited a Result, Not a Baseline

Gallup’s research on managers is the number I keep coming back to on this. Their finding is that managers account for at least 70% of the variance in team engagement. Seventy percent. Whatever you think of engagement as a construct, sit with the implication for a second.

If the manager explains most of the variance, then the team you just inherited is, statistically speaking, largely a portrait of the person who left.

Their standards. Their tolerance for ambiguity. Their habit of making calls in the hallway. The eight people in front of you adapted to all of it, some of them for years, and adaptation starts looking a lot like personality after a while. The engineer who never pushes back may not be passive. He may have learned, correctly, that pushing back cost him something under the last regime. It usually did.

This is where the mainstream advice and I part company slightly. The standard guidance, and Harvard Business Review has a well-known piece on inheriting a team that is not working hard enough, is to move quickly on resetting norms. I agree on norms. I disagree on people. Reset the system in week one. Reserve judgment on individuals until the system has been different long enough for their behavior to mean something.

Sixty days is my number. Sometimes ninety.

Run the Clarity Stack Backwards

I have written before about the Clarity Stack, the three-layer diagnosis for why engineering orgs stall. Nobody agrees on what done means. Priorities live in hallway conversations. Decisions get made and never written down. On a team you built yourself, you run that diagnostic forward, looking for which layer is broken.

In an inherited org you run it backwards. The question is not what is broken. The question is who built it and whether that person still works here.

That third question is the one I would run first if you only get to run one. Ask three engineers why a given service is structured the way it is. If what comes back is three different origin stories, or worse, three shrugs and the name of somebody who left in 2024, you have found your actual inheritance, and it was never the code. What evaporated was the decision layer, and it went when its authors went.

A good portion of what looks like technical debt in a freshly inherited org is authorship debt instead. The code usually runs fine. Nobody will touch it because nobody can reconstruct why it exists in that shape, which is the thing I have called load-bearing spaghetti elsewhere and will not relitigate here.

One caution before you run any of this. A team that is simply out of gas will fail all three layer tests for reasons that have nothing to do with clarity, and the fixes will make an exhausted team worse. Rule that out first. The separate diagnostic for whether your org is actually slow or just tired takes about a week, and it is the highest-value week you will spend.

The Clean-Room Test for a Person You Cannot Read

So you have someone whose record is bad and whose cause is unclear. The record says one thing. Two colleagues say another. You have no baseline of your own, and every week you wait is a week the rest of the team watches you not decide.

What I do at that point is hand over a single decision, cleanly.

With the engineer from the rate-lock story it was a caching change on the pricing service. Small, real, reversible. I wrote down what done meant, put a date on it, and said in front of his manager that the call was his and I would not be taking it back at the halfway mark. Then I stayed out of it, which was harder than it sounds. I have wrecked a couple of these by hovering.

Four things tend to come back.

• They ship it. That fast.
• It lands late, and there were four check-ins along the way, and not one of them was necessary. Somebody trained that into them over a period of years. It tends to unlearn inside a quarter.
• Nothing happens at all. The reason, when I ask, is another team or a dependency or a person who never replied, so I ask twice more across the month and watch which direction the finger points each time. Consistently outward is the only result on this list I would call a people answer.
• Something technically clean arrives on time, solving a problem nobody had.

That last one is the expensive case, and it gets filed as a success far more often than it deserves. The gap there is business judgment rather than raw skill. Coachable, certainly, but slow, and it wants somebody senior sitting beside them for two quarters, which is a real cost worth pricing honestly before anyone commits to paying it.

One variable moved in that whole exercise. Clarity. When performance moves along with it, the problem was never sitting in the person, and I was perhaps six weeks away from removing somebody over an artifact of my predecessor’s operating model.

Nobody enjoys hearing that. I did not enjoy learning it.

The Promises You Did Not Make and Now Own

This one blindsides more new leaders than anything else on the list, and almost nobody writes about it.

Somewhere in that team are commitments your predecessor made out loud and never recorded anywhere. Somebody was promised a promotion at the next cycle. Somebody else has believed for a year that the architect role is his the moment it opens. There is a remote arrangement that exists because a man nodded at it in a hallway in March. And at least one person took a title instead of a raise to stay through a migration everybody now refers to in the past tense.

None of that lives in Workday. All of it is entirely real to the person carrying it around.

You find out one at a time, usually in a one-on-one, usually in a tone suggesting they assume you already know. What you do in the following thirty seconds sets your credibility with that engineer for the rest of your tenure, and they will tell the others either way.

My rule here has never cost me anything. Do not honor the promise in the room, and do not kill it in the room either. Say you did not know about it. Say you will find out what is possible by a specific date. Then come back on that date, including when the answer is no.

The date does more work than the answer. People absorb a no without much trouble. What they cannot absorb is a new leader taking his place in the long line of people who told them something and then went quiet, which is the exact pattern they were already braced for on the day you walked in.

I inherited one of these at a lender in 2019. A senior engineer had been promised a staff title eighteen months earlier, in a hallway, by somebody who was by then two companies away. I could not deliver it that cycle. I told her so in week three with the reasoning attached, gave her the actual criteria in writing, and she hit them in nine months. She stayed four more years.

Change Two Things in Week One

Restraint is the hardest part of taking over an org and I am not naturally good at it, so read this section as partly a note to myself.

Everything visible is going to look fixable, which is the trap. The standup runs long. Somebody has 340 open tickets in a backlog nobody has groomed since spring, and the branching strategy appears to have been designed by three people who were not speaking. Fixing things is what got you promoted. There is a list sitting in your desk drawer. The pull toward doing something, anything, in week one is enormous and you should treat it as a symptom rather than an instinct. I have felt it.

Two changes. That is the budget.

The first one is a sentence. Write down what the quarter is for, put it in one place, and then say it out loud at the top of every leadership meeting until people start finishing it for you. Week three is the test. If you cannot recite it from memory by then the sentence was wrong. Rewrite it, and do not make a ceremony out of having been wrong.

Second thing is the decision-rights map I have gone deeper on in the piece about the diagram that stops hallway decisions. One page. Not a reorg, and say that part out loud too, because the word map makes people think reorg and then they spend a week worrying instead of answering.

In an inherited org that exercise does something it does not do anywhere else. The blanks are the point. Every decision type nobody claims is a piece of your predecessor that left with him, and the pattern in those gaps is a more accurate portrait of the man than anything HR will tell you.

First time I ran it, eleven decision types came back. Four unassigned. All four touched deployment.

Everything past those two is a preference. Sprint length, standup format, whether retro happens Thursday. A team that just watched a leader walk out is trying to work out whether you are worth investing in, and preferences imposed in week one get read as ego, correctly. Under the hood they are scoring you constantly. Uncomfortable, and entirely fair, since it is precisely what you are doing to them.

What Coaching Cannot Reach

Sometimes you run all of it and the answer really is a missing seat.

Clarity fixes land. The decision map goes up. The team can recite the quarter back to you. And there is still a capability that does not exist anywhere on the roster, which happens most often in one particular shape. Your predecessor was the capability. He was the staff-level architect, or he was the only one who could hold a room with the CFO, or he was the person who knew the payment rails end to end. Nobody got developed underneath him because he was busy and doing it himself was faster, and the hole he left behind is exactly the shape of him.

You cannot coach your way out of an absence. Not on a two-quarter timeline.

Build it or buy it, and building takes longer than your runway once the board has started asking questions in that particular tone. I have watched a director try to grow the missing architect internally while simultaneously covering the gap himself. Eight months. It half worked, and it cost him the thing he was actually hired to do.

The mistake underneath most of this is confusing a hire with a diagnosis. They cost wildly different amounts and they get swapped constantly, usually in the direction of hiring first because a req feels like progress and an assessment feels like delay.

If you are not sure which one you are looking at, KORE1 staffs an engineering velocity diagnostic that reads those same three layers out of your repository and your calendar across two weeks, run by somebody with no stake in anyone’s reputation, ending in a written verdict that names the constraint. When it comes back structural rather than personal, their engineering org design and operating model advisory redraws the operating model instead of filling a chair.

And if it is a seat, hire slowly. Hire once.

KORE1 runs about a 92% twelve-month retention rate on placements. That number carries more weight in an inherited org than it does anywhere else, because these people have already watched somebody walk out and they are quietly keeping score on whether you are going to be the reason it happens again. A second departure inside a year costs you more credibility than the original vacancy ever did. That is usually the argument for making it a direct hire rather than a contract-to-hire trial, incidentally, since a trial framing is perfectly legible to the team and reads to them as one more temporary arrangement.

What New Leaders Ask Me in Month Two

How long before I am allowed to change someone?

Sixty days minimum, and only if the clarity layer has genuinely been different for most of that window. Judging somebody against a system you have already replaced is the only fair version of this test.

Conduct is the exception. That one I have always moved on in week one, and I have never regretted the speed.

The rest I sit on, which feels unbearable while your boss circles back to that list every second Tuesday. Give him a date. Hold it.

My predecessor already left. Is there any point in reaching out?

Yes, and I would ask one question rather than twenty. Ask what they would have done next, and why they never got to it. Then let the answer run.

They almost always say yes to the coffee. The one I did this with in 2019 talked for ninety minutes and the part I needed showed up around minute eighty, which is the argument for lunch over a half-hour call. What he told me about systems I took seriously. What he told me about two specific people I logged as one opinion from a man with a history.

Half the team is telling me the other half is the problem. What do I do with that?

Both halves are describing the same broken handoff from opposite sides. The useful move is measuring where work actually sits waiting, rather than collecting more opinions about people.

Platform says product changes requirements constantly. Product says platform will not commit to a date. I have sat in some version of that meeting maybe fifty times and neither side has ever been lying to me. There is a genuine gap between those groups, nobody owns it, and both have spent long enough experiencing a structural defect as the other side’s character flaw that it has hardened into something they now recite as history.

What has worked for me is putting one name on the handoff and a written turnaround expectation under it. Six weeks on, most of the animosity has quietly drained away. Whatever survives that is the genuinely interpersonal residue, and it is finally small enough to deal with as itself.

The team has no documentation at all. How high does that rank?

Lower than it feels. Missing documentation is a symptom of the decision layer, not a problem of its own, and a documentation sprint fixes nothing while decisions are still being made out loud in hallways.

I start the recording from the day I arrive and backfill only what is blocking somebody that month. Two separate orgs I have worked with burned a quarter each writing documentation nobody ever opened.

Do I tell the team I was handed a list?

Not the list. The criteria. Tell them exactly what you will be evaluating and by when, then apply it to everybody, including the people nobody flagged.

Naming names makes you the previous leader’s instrument on day one.

Silence is not neutral either, which I had wrong at first. Everyone assumes a list exists whether one does or not, and the people assuming hardest are usually the solid middle of the team, quietly certain their effort is decorative. Publishing the standard is what takes that from them. I have lost better engineers to that belief than to any decision I actually made.

You Did Not Inherit the People. You Inherited the Rules.

The engineer who was second on that list runs the platform group there now.

Nothing about him changed. Incident work started getting logged somewhere people could see it. The rate-lock service got a second owner inside a quarter. And somebody finally wrote down that keeping pricing alive was a job rather than an interruption between the real jobs. Three unglamorous fixes, not one of which required a hard conversation about him, every one of them sitting in the system rather than in the man.

I would like to tell you I spotted it in week one. I did not. That list sat in my desk drawer for five weeks and I took it out more than once.

So go find out what produced the record before you act on it. Ask three engineers why the architecture looks the way it does. Ask where they heard about the last priority change. Ask what done means this quarter and count the answers.

Then judge people with your own instrument, inside a system you actually control.

If you are in the middle of one of these and want to think out loud about which layer you are looking at, connect with me on LinkedIn. If the gap turns out to be a capability that walked out the door with your predecessor, talk to a recruiter at KORE1 about what that role has to cover now.

Related reading: The Three Decisions Engineering Leaders Get Wrong in Their First 90 Days, How to Tell If Your Engineering Org Is Actually Slow (vs. Just Tired), and The Clarity Stack: 3 Reasons Engineering Velocity Stalls.