Join · £699 £1,199
Expert Interview Jun 11, 2026 · 10 min read

Your First 90 Days as an Engineering Manager

You get promoted for doing the work. Then the work stops being the job. Most of what goes wrong in a new engineering manager's first 90 days comes back to that one shift, and sitting with it is harder than it sounds.

Ryan Murphy
Ryan Murphy / Founder, EM Accelerator
Field Notes

New essays for engineering managers, delivered when they drop. No spam, unsubscribe in one click.

Every promotion you have ever earned came from doing the thing. You shipped the feature, you fixed the bug, you reviewed the PR, and someone noticed. Then you become a manager and the doing quietly stops being your job. Nobody warns you on day one, and it is the thing that catches out most new engineering managers in their first 90 days.

This is hard for almost everyone who makes the jump, however good an engineer they were. Dr Claire Knight has watched it from both sides. She is a Director of Engineering at n8n, has led engineering teams at GitHub and was a senior director at Netlify, has been through acquisitions, and has hired and mentored a long line of managers and ICs through exactly this transition. Most of what follows came out of a conversation with her.

What gets you hired as a manager now

The role that used to be mostly project management does not exist anymore. The breadth expected of a manager has expanded to the point where you need the people side, the delivery side, and enough technical depth to steer the team and push back on product when product is wrong. All three, not one.

That breadth now includes playing with the AI tools yourself, even if that is not on work time. It can sound gatekeepery. It is not meant to be. Execs, the C suite and the people writing cheques in venture capital already expect it, and pretending the bar has not moved helps no one who is trying to clear it.

You do not have to be the smartest person in the room. A good manager wants the people reporting to them to be stronger engineers than they are, and treats it as a failure when they are not. What you need is enough technical judgement to hold a sensible conversation, steer the work, and recognise when product is asking for the wrong thing.

The technical interview has changed

For years the sensible bar for a manager was system design over pure code. If you have not written code daily for a while you lose some fluidity, and a timed coding test mostly measures rust. That has shifted. Even senior director and VP candidates are being handed code tests again, after years where plenty never were.

If you only managed during the ZIRP era, when a lot of companies never grilled managers on anything technical, this part is going to hurt. At n8n the format has moved on again. Candidates are asked to use AI tools on a coding task, then answer questions about what they did. The point is not whether you can write the code cold. It is whether you can steer the tools and explain the result, which is a fair reflection of the actual day job. LeetCode tells you nothing useful, only whether someone memorised the problem.

The GitHub interview that told her everything. Long before Microsoft bought GitHub, Claire interviewed there with a code review. They handed her a deliberately flawed pull request, asked her to review it the way she would review any PR, then to make a small change to fix something. It was a Rails shop, so understanding a Rails N plus one helped, and communicating like a human being helped more. It was never built to trip you up. When she later ran it as a hiring manager, it turned out to be one of the cleanest signals she had on how a candidate communicated and shared technical knowledge under a bit of pressure.

The instinct you have to break

The hardest thing in the first 90 days is not learning a new skill. It is unlearning the one that got you here. Your whole career so far has rewarded shipping. At the manager level the outcomes you own take weeks to show up, sometimes months, sometimes years. Give in to the pressure to do, and you will do the wrong things quickly.

Do too much too fast and you destroy trust rather than build it. You make changes you then have to undo, and the undoing costs more trust than the change ever bought. The useful question in week three is not what you can fix. It is whether you are trying to change the whole system, or making smaller changes inside the influence you have actually earned so far. Plenty of new managers, and plenty of experienced ones joining somewhere new, arrive ready to rip things up because it worked at the last place. Taking it slower than feels comfortable is the counterintuitive move, and it is almost always the right one.

Sitting on her hands. When Claire joined n8n, her manager and the team were welcoming and kept asking what she thought. She made herself wait. Sometimes that meant literally not replying to a message, sitting on her hands while she built context, because the fastest way to get something wrong is to weigh in before you understand why things are the way they are. Months in, she is still learning the context.

You serve the business, not your team

Servant leadership has trained a generation of engineers to believe their job is to serve the team, and that is the line most new managers do not want to hear. You actually serve the business, and the business comes first. The managers who make the transition well internalise that quickly, even when they have to learn to accept it. The ones who do not slide into being everyone’s best friend, usually with the team they were promoted out of, and lose the ability to make a hard call.

Serving the business is not the same as driving people, and the difference does not get said often enough on LinkedIn. If you have to poke your senior engineer every single day to get them to do their job, the engineer is the one failing, not you. A senior engineer is paid to care and to self motivate. The founders telling managers they should be relentlessly driving their people have the diagnosis backwards. If you are driving someone who ought to care at that level, something else is wrong.

The relationships you will forget to build

Most new managers spend the first 90 days on their team and their boss. That is correct, and it is also incomplete. The relationships they skip are the peer ones. Other managers are allies. They solve problems with you, they tell you what is actually happening before the formal channels do, and they are the people you call when you have a hard conversation coming and no idea how your company handles it.

Higher up, the relationships become most of the job. A director’s week fills with customer success, sales and partnerships. New managers rarely picture any of that. They picture shipping. Building a few of these relationships in the first 90 days is worth more than another week heads down in delivery.

Throw away the 30/60/90 plan

Process for its own sake is worth little here. A 30/60/90 plan is useful right up until it gets in the way of real work, and once you are deep in the actual job you can bin it. Sometimes it goes early for the opposite reason, because a new manager is already grasping the role and running with it, and the more useful conversation is telling them to slow down and that a particular fight can wait six months.

What matters more is a genuine early win, not a manufactured one. A project the new manager can deliver well, where they show they can run the team as a team rather than as a senior IC who happens to have reports. Have some real impact, without burning every bridge to get it.

How to tell whether a team trusts their manager

You will not find this out by asking the manager how the team feels. You find it in the signals. Company-wide surveys give you aggregate trust numbers. Retention tells you something too, though not the thing people assume. Ninety-nine percent retention is not the goal, and keeping the wrong people is a win for nobody. If more than one person leaves saying some version of “I cannot work with this person,” that is your signal.

Skip levels matter, as do AMAs and simply making yourself available, even if it takes about ten attempts before a skip level believes you genuinely want them to ping you. None of this is purely a numbers game, and the moment a trust score becomes a target, someone will manage the score instead of the trust. If you want the longer version of how good measurement turns toxic, how to measure engineering teams without breaking them is the detour worth taking.

Your first hard conversation

Nobody is naturally good at these. I have never met an engineering leader who came out of the gate good at hard conversations. They take practice, both in how you say the thing and in living with how it feels afterwards.

A few habits help. Your peer group can tell you how a conversation like this tends to land at your specific company, with its specific culture. Writing a short script of the key points, not to read out, keeps your brain on track when emotion tries to derail it. Preempting the likely pushback means you are not caught flat when the other person reacts. And blocking out time straight after to take a breath is not soft. Even after years of running them, the hard ones, layoffs especially, still need a moment afterwards. Hard conversations are called hard for a reason, and you are allowed to give yourself some grace.

It is a role change, not a title change

The title changes on day one. The role takes a lot longer to grow into. There will be hard days. For some people the hard days are the sign that management is not for them, which is a legitimate answer. For everyone else they are the speed bumps, the same ones you hit when you first became an engineer. The discomfort is real, and for most people it fades once they stop fighting it. Sit with it and you get through it.

The other thing worth doing early is finding a support group, whether that is internal, external, or paid coaching if you can afford it. There is far more of it out there now than there used to be, courses and books that cost a fraction of a coach. The real skill is learning to pick and choose what fits you and your management style.

Knowing your own style is the part most people skip. There is no single correct way to manage, and the approach that works for you depends on the kind of manager you already are. If you are not sure what that is yet, the engineering manager archetype quiz is a fast way to see where your instincts pull you, and where your blind spots probably sit.

Final thoughts

The first 90 days are not about proving you can do the job. They are about giving up the version of the job you already know how to do. Stop shipping. Watch before you change anything. Build the peer relationships you are tempted to skip. Accept that you answer to the business now, not to your team’s comfort.

None of that will feel like progress, because real progress at this level takes weeks or months to surface. The waiting is the hardest part, and the part that matters most. It is a role change, not a title change. Plan the first 90 days around that.

Ryan Murphy

Ryan Murphy

Nearly 20 years of building and leading engineering teams. Founder of EM Accelerator - the premium training platform for software engineering managers.

Keep reading

Stay sharp

Get the latest issues
in your inbox

Scripts, frameworks, and field notes for engineering managers who want to lead well. Not just survive.

We will never share your email. Unsubscribe in one click.