You have been made the manager of people who are better engineers than you. That gap is not closing. Most of what goes wrong in your first year comes from trying to pretend otherwise. The urge is to prove you deserve the job, and every way of doing that backfires.
You try to out-engineer them
New managers try to out-argue their senior engineers on the technical detail. It does not work. They know more than you, and they can tell when someone is arguing to win rather than to get it right. A few rounds of that and your technical opinion stops counting for anything.
By then they have stopped bringing their real objections to you, because it is not worth the argument. The same urge makes you grab the hardest task and do it yourself, which is its own way of sinking a new team.
You manage them like juniors
When out-engineering them does not work, you reach for the rulebook. You ask a principal engineer to justify an estimate. You leave notes on a design by someone who was shipping production code while you were still learning to write tests.
They will not argue. They will clock that you do not trust them and start saving their best work for somewhere it is wanted. Six months later you call them a flight risk, like it came out of nowhere.
You defer to them on everything
The opposite mistake looks like humility. You are intimidated, so you go along with whatever they say and call it respecting their experience. You stop having opinions in front of them.
They notice fast. Deferring on everything does not make a senior engineer’s life easier. It hands them every hard decision on top of their own work, without the authority to make those decisions stick. That is not trust. It is you deciding not to do your job.
The one who wanted your job
Sometimes the senior engineer under you wanted your job. They applied for it, or assumed it was theirs, and got you instead. That does not go away because you ignore it.
It rarely looks like hostility. It looks like being right. They raise the objection you cannot answer, at the worst possible moment, in front of the team. They let a bad decision play out instead of stopping it, because you being wrong helps them. None of it is ever bad enough to name in a review.
Giving them more influence to win them over makes it worse. It tells them they were right that the job should have been theirs. The only thing that works is slower. You give them something real to own, you hold them to it, and it counts when they deliver. That resentment does not go away on its own. It goes when they do good work on something you handed them, and not before.
When you have to overrule them
Sometimes you have to make a call they disagree with. You will not win that on the technical argument, because they have the better technical argument. Do not try.
The call is usually not technical anyway. You are shipping the good-enough version because the business needs it this quarter. That is a trade-off you own, not a design they got wrong. Say that. Tell them you might be wrong and that you are deciding anyway, because the decision is yours and so is the fallout.
Senior engineers can take being overruled by someone who is straight about the trade and about who carries the risk. They cannot take being overruled by someone pretending to know better than them on the thing they are best at.
You still need to clear the technical floor
This does not mean the technical side stops mattering. There is a floor, and you have to clear it. You need to follow an architecture discussion well enough to know what is being given up. You need to notice when an estimate is padded, or when someone is steering you off a decision because it suits them. A manager who cannot tell a real constraint from an excuse gets managed by their own team.
That is a floor, not a contest. You clear it and stop. Trying to be the strongest engineer on the team is the out-engineering mistake again, and you will lose it every time. Know enough that nobody can snow you. The depth beyond that is theirs to bring.
Start by fixing something they hate
In your first few weeks the useful move is not to prove anything. It is to find one thing that has annoyed the senior engineers for months and get rid of it. The flaky test suite nobody owns. The release that needs three people awake at midnight. The standing meeting that outlived its point.
Pick one, take the boring work of fixing it off their plate, and see it through. It does more for your standing than any opinion you could offer in a review, because it shows them what you are actually there for. They do not need another engineer. They need the friction gone, and you are the only one now whose job is to remove it.
The 1:1 is not a status check
Do not use your one-to-ones with senior engineers to check up on their work. They notice at once, and it confirms you do not know what else a manager is for. Their status is in the tracker. You do not need half an hour of their time to hear it read aloud.
Use the time to find out what is slowing them down, and what they are worried about that has not surfaced yet. Ask what they would change if it were their call. A senior engineer usually knows exactly what is wrong with the team and has stopped saying it, because the last few managers did nothing with it. Being the one who asks and then acts is worth more than any credibility you could fake.
What they actually want from you
A senior engineer does not want you to be a better engineer than them. They want you to take the work off their plate that stops them doing the job: the meeting they should not be in, the stakeholder chasing them, the triage eating their mornings. They want you to have the argument with the people above you so they do not have to. They want bad news early enough to do something about it.
Most of it is managing up for them. When their promotion is due, you make the case in a room they are not in, with evidence they cannot present themselves. When a reorg threatens the work they care about, you are the one who argues to keep it. They can see whether you do that or whether you fold, and it decides how much of themselves they put in.
None of that needs you to write better code than them. That is the job, and it always was. Do it long enough and the engineer who worked around you starts coming to you instead, because you make the week easier instead of harder. That is the respect you were chasing, and it never had anything to do with who writes better code.
Final Thoughts
You are not going to be the best engineer on your team. Stop trying to be. The people who already are can see you doing it.
Respect from someone more experienced than you will not come from the title, and you cannot argue your way to it. It comes from being the one who clears the problems they had stopped expecting anyone to fix. That has nothing to do with who is the better engineer, which is just as well, because you are not.
If you want to make one of these calls before you have to make it for real, the New Manager Simulator starts with an engineer you used to sit next to, testing in front of everyone whether your decision still stands.
Managing someone more experienced than you is one part of a larger adjustment, and it usually arrives in the same months as several others. The new engineering manager guide covers the rest of that ground.
