Last updated: July 15, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
New engineering leaders get the same three decisions wrong in their first 90 days: they chase speed before the team agrees what “done” means, they become the human router for every priority, and they make themselves the approval gate for every decision. Each one feels like leadership. Each one is the opposite. And each one is reversible if you catch it before day 90.
Ninety days is not a lot of runway. It feels like plenty on your first Monday. You have the title, a team, a mandate, and a list of things everyone politely mentioned needed fixing on your way in. Then the calendar fills. The first fire starts. And somewhere around week six you notice the clock has been running the entire time, and you have spent most of it reacting.
I coach new VPs of Engineering and freshly promoted managers through this window a lot. The pattern barely changes. They walk in wanting to prove they earned the seat, and that instinct, as human as it is, quietly sets up all three of the mistakes I am about to walk through. KORE1 keeps seeing the same thing across their engineering staffing placements at growth-stage and mid-market companies. The leaders who stall in their first quarter are almost never the ones who lacked technical range. They are the ones who spent 90 days answering the wrong question.
None of these three are technology problems. They are clarity problems, which is the whole reason I built the Clarity Stack. This piece is that framework pointed at one specific and unforgiving moment. Your first 90 days.
What the First 90 Days Are Actually For
Your first 90 days are not for shipping. They are for building the operating system the team runs on: what “done” means, where priorities live, and who owns which decision. Ship hard too early and you are just tuning an engine you have not opened yet.
Michael Watkins wrote a whole book about this window. The line from The First 90 Days that stuck with me is that missteps made in the first three months can jeopardize everything that comes after. He is right, and it is worse than it sounds, because the missteps rarely look like mistakes while you are making them. They look like progress. That is the trap.
Here is the reframe I give every new leader. You were not hired to be the fastest person on the team. You were hired to make the team faster without you standing in the middle of it. Those are different jobs. Most new leaders spend their first quarter doing the first one and calling it the second. Do not be that leader. The entire point of the seat you just took is that the org needs the team to keep shipping on the days you are unreachable, and that only happens if you spend these 90 days building something that runs without you instead of proving how much runs through you.
Decision 1: Chasing Speed Before Anyone Agrees What “Done” Means
The pressure to prove yourself is real, and it shows up fast. You want a visible win by day 30. So you pick something. A stalled feature to push over the line. A reorg to signal you are serious. A rewrite of the service everyone complains about. Something the org can point at and say the new leader is making things happen.
It feels great. For about a month.
Then the win lands and nobody is quite as happy as you expected, because you optimized for motion before you checked what the business actually counted as a finish line. I watched a new director at a mortgage-tech shop spend his first six weeks driving a loan-pricing refactor to completion. Clean work. Shipped on time. The problem was that the CEO’s definition of a good first quarter was a compliance-reporting gap that had been open since the last audit, and the director had never asked. He optimized the thing he could see. He missed the thing that mattered. It happens constantly, and it happens precisely because the visible work feels like the responsible move while the invisible work of asking what the business actually counts as success feels like stalling, right up until the quarter closes and the scoreboard says otherwise.
The right first-90-days move is slower and less satisfying. Before you push the team to go faster, get three or four people who should already agree on the quarter’s goal to write it down separately. Read the answers side by side. If they do not match, you do not have a speed problem to solve yet. You have a definition problem, and shipping into it just gets you to the wrong place sooner. Fix the target first. Then let the team run at it. Not before.
Decision 2: Becoming the Human Router
This one creeps in because it feels like the job. Requests come at a new leader from every direction in the first month. A product manager wants a date. A staff engineer wants an architecture call. The VP of Sales wants a favor for a customer. You, being new and eager and wanting to be seen as responsive, catch every one of these and hand it to the right engineer yourself.
Congratulations. You are now the routing layer. Nothing reaches the team without passing through your head first, and your head does not have an API. It does not scale. It sleeps.
The team adapts to this faster than you do. They stop reading the board because the board is not where priorities actually live anymore. You are. They learn to wait for you to hand them the next thing, which means the moment you are in a meeting, on a flight, or out sick, the work quietly stops. I have written before about why priorities have to live in writing, and it matters triple in your first quarter, because the routing habits you set in the first 30 days are the ones the team will still be running in month nine.
There is a hard number under this. HBR, citing Gartner research on why managers fail, found that managers today carry 51 percent more responsibility than they can effectively handle. You are already overloaded on day one. Volunteering to be the router is how you guarantee you stay that way.
The fix is not glamorous and you can start it in week two. Pick one place. Linear, Jira, a shared Notion doc, a list on a whiteboard. The tool does not matter. What matters is that every request you catch gets written there, in front of whoever asked, before they leave. Ugly and visible beats elegant and living in your inbox. The goal is simple to say and hard to hold: any engineer on the team should be able to open one place, read for thirty seconds, and know what matters this week without booking time with you to find out. Get there by day 60 and you have bought yourself back the hours the router job was quietly eating.
Decision 3: Making Yourself the Approval Gate
The third one wears a disguise. It looks like standards.
A new leader wants to establish that quality matters now that they are in charge, so they put themselves in the path of every decision. Every pull request gets their review. Every design gets their sign-off. Every technical call waits for their opinion. For a few weeks it even works, because you are sharp and your judgment is good and the team is happy to have air cover while they figure you out.
Then it calcifies. The queue for your attention gets longer than the work itself. Your best engineers, the ones with the judgment you actually hired the team around, learn to stop deciding things and start waiting for you. You have taught your strongest people to be less than they are, and you did it while working harder than anyone. That is the cruel part. The gate is almost always the diligent leader, not the lazy one.
I have said a version of this to more than one very good manager, and it never lands softly. If the team cannot move without your approval, you are not the leader of the team. You are its slowest dependency. I wrote the full version of this in the piece on when you are the bottleneck, because it deserves more room than a single section. The short form for your first 90 days is this. Write two lists. One holds the decisions that are genuinely yours, the calls where you personally carry the risk if they go sideways, and that list is shorter than your ego wants it to be. The other holds everything else. Give the second list away. Mean it. When someone makes a call you would not have made, ask why before you overrule it. Nine times out of ten the reasoning holds and you learn something. The tenth time is a coaching conversation, not a takeover.
A 30-60-90 That Measures Clarity, Not Activity
Most 30-60-90 plans are activity checklists. Meet the team. Read the codebase. Ship a thing. They measure motion, which is exactly the trap. Here is the version I hand new leaders instead. It measures whether the operating system is getting clearer, because that is the only thing that compounds after you leave the room.
| Window | The wrong instinct | The clarity move | How you know it worked |
|---|---|---|---|
| Days 1 to 30 | Ship a visible win to prove yourself | Find the real definition of done from the people who set it | You can say the quarter’s goal in one sentence and so can they |
| Days 31 to 60 | Route every request through yourself | Move priorities into one place the whole team can read | Work keeps moving on a day you are completely out of reach |
| Days 61 to 90 | Approve every decision to hold the quality bar | Write down who owns which decision, then hand the list away | Your best engineers stop asking permission for calls that are theirs |
Notice what is not on that list. Lines of code. Tickets closed. A dashboard trending up and to the right. Those are outputs, and outputs in your first quarter mostly measure how busy you made yourself look. Clarity is the input. Even the delivery numbers worth trusting, the DORA four, are lagging indicators this early, because they report how the operating system you inherited performed, not whether the one you are building underneath it is any clearer than what you walked into. If you want to check your own progress, do not count what you shipped. Pop the hood on one question instead. Can the team run for a week without you? In month one the honest answer is usually no. By day 90 it had better be yes.
The Decision Underneath the Other Three
All three mistakes grow from one root. You try to prove your value through activity instead of clarity, because activity is visible and clarity is not. Nobody claps when you delete four prioritization systems and keep one. They clap when you ship something big in week three. The incentives point exactly the wrong way. Resist them anyway. The leaders who do are the ones still standing at the one-year mark, still trusted by their strongest engineers, still holding the seat when the operating system they quietly built in their first quarter finally starts compounding into the kind of delivery a board actually notices.
There is a harder version of this problem, and it is worth naming because it shows up constantly. Sometimes the new leader in the seat is a recently promoted individual contributor who was never given a real transition. Best engineer on the team, handed a title and a calendar, told to sink or swim. They miss the craft. They resent the meetings. They fall into all three traps at once because nobody taught them the job is different now. Most of the leaders I have watched in that spot either find their footing or wash out inside the first year, and the ones who wash out usually take a strong engineer or two out the door with them.
That is a build vs buy decision, and companies get it wrong by default. The build path is to take your strongest senior engineer and develop them into the role over many months, with a coach and a real safety net and the freedom to step back into engineering if the seat does not fit. The buy path is to hire an experienced engineering leader who has done the job before, paired with enough internal context that they do not spend their first quarter flailing. Both work. The lazy default, promote and pray, works least often of the three.
KORE1 places engineering leaders into both paths through their direct hire staffing practice, and they hold a 92 percent twelve-month retention rate on those placements. That number is the whole ballgame. It is the difference between a leader who lands and one who gives notice at month nine and takes your best people with them. If your leadership bench or your senior software engineering talent is thin enough that the wrong person is about to inherit a 90-day window they are not ready for, fix that before the clock starts, not after.
The 90-Day Scorecard That Actually Matters
Forget the win you shipped. Ask three questions at day 90. Can everyone on the team say the goal without looking it up? Do priorities live somewhere other than your head? Do your best engineers make the calls that are theirs to make without waiting for you? Three yeses and you built something that outlasts you. Three noes and you spent a quarter being busy. Busy is not the job.
The first 90 days are not a performance. They are a foundation, and foundations are boring to pour and expensive to skip. If you want to talk through where your own first quarter is heading, or where an org you just walked into sits, connect with me on LinkedIn. If you want to talk to KORE1’s engineering hiring team about getting the right leader into the seat, you can reach out to their recruiters here.
Questions New Engineering Leaders Ask Me
What should I actually do in my first week?
Mostly listen and write. Ask the people around the team what “done” looks like this quarter, and write down every answer verbatim. You are not gathering opinions to be polite. You are hunting for the gaps between them, because those gaps are your real job.
Resist the urge to reorganize anything in week one. You do not have enough signal yet, and a reorg is the loudest possible way to announce that you value motion over understanding. Book the one-on-ones, read the last two quarters of retros, and find the one decision everyone quietly disagrees about. That decision is usually where the clarity is broken.
I was promoted from inside the team. Is my first 90 days different?
Harder, honestly. You know the code and the people, which is an advantage, but you also carry the habits of the job you just left. The pull to keep doing your old work is the strongest force acting on a promoted IC, and it is the exact thing that turns you into the bottleneck.
The trap for internal promotions is staying the best engineer instead of becoming the leader. You will want to grab the hard tickets because you can do them faster than anyone. Do not. Every time you take the interesting work, you signal to the person who should have grown into it that their ceiling is you. Give the work away and coach through the discomfort. That transition has enough failure modes that I mapped the whole timeline separately.
How do I show an early win without falling into the prove-it trap?
Make your early win a clarity win, not a shipping win. Kill four of the five overlapping priority docs and leave one that everyone actually uses. Get the quarter’s goal down to a single sentence the CEO and a junior engineer would both recognize. Those are wins. They are quieter than a launch, and they compound instead of fading.
If you genuinely need a shipped thing for political cover, pick the smallest change that removes a daily annoyance the team keeps complaining about. Fast, real, and low risk. Then get back to the foundation work that nobody will applaud but everybody will feel by month six.
Is 90 days really enough to tell whether a new leader is working?
Enough to see the trajectory, not the outcome. By day 90 you cannot judge a leader on what shipped. You can judge them on whether the team is clearer than it was, which is the leading indicator for everything that comes later.
Watch for the tells. Can the team articulate its goal? Did the leader build a system or become one? A leader who is clearly the smartest, busiest, most indispensable person in the room at day 90 has usually failed. They just have not felt it yet. The bill for that arrives in months four through nine, when the org discovers it cannot function without them.
The org I inherited is a mess. Where do I even start?
Start with the layer you can fix in a sprint. Get six engineers, alone, to tell you what success looks like this quarter. If you get six different answers, do not touch the architecture yet. You have a definition problem, and it is upstream of everything else that looks broken.
The instinct with a messy org is to fix the loudest thing, which is almost always some piece of gnarly code somebody keeps cursing. Leave it. Half of what reads as technical debt in a stalled org turns out to be priority debt wearing a costume, code nobody wanted to write because nobody was sure it was the right thing to build. Get the clarity layer solid first. A surprising amount of the mess sorts itself out once people know what they are actually building toward.