On Friday you were one of six engineers arguing about the deploy pipeline over lunch. On Monday you're the manager of the other five. They know your habits, your opinions and the time you broke production. Some of them wanted the job. Many new managers start this way, and they're rarely told how to handle this part. This post covers the first month: the conversations to have, what to change, what to leave alone, and how to give the first piece of hard feedback to someone who used to be your peer.
The authority you think you have, and the authority you actually have
Linda Hill, a Harvard Business School professor who has long studied first-time managers, describes a set of myths new managers bring to the job in her Harvard Business Review article Becoming the Boss. Two of them matter most here. The first is that the role gives you formal authority, so people will do what you decide. In reality, Hill argues, your power has to be earned, through credibility with your team, your peers and your own manager. The second is that the job is about control and getting compliance. Compliance isn't commitment, and a team that only complies will do exactly what it's told and nothing more.
This is harder when you're promoted from within, not easier. Your former peers already have a settled view of you as an engineer. They don't yet have any view of you as a manager, and the title doesn't give you one. You earn it the same way you earned their technical respect: by being consistently useful over months.
Practically, that means your first month is for listening and small, visible follow-through, not for announcing changes.
Say the awkward thing out loud
Everyone on the team knows the situation is a bit strange. Pretending otherwise makes it stranger. Address it directly, once, with the whole team, then again individually.
A team-level script, short enough to say in a regular meeting:
"You all know I've moved into the manager role. It's new for me and probably a bit odd for you too. For the next few weeks I'm mostly going to be listening, not changing things. I'll be setting up one-on-ones with each of you this week. If I start doing something that bugs you, tell me; I'd rather hear it early."
Then hold a first one-on-one with each person within the first two weeks. With former peers, these questions work better than the generic ones:
- What should I keep doing that you liked when we were working side by side?
- What did you wish our previous manager had done differently?
- What do you think I'll find hardest about this?
- Is there anything about me moving into this role that you'd like to talk about?
- How do you want to hear feedback from me?
The last question is practical: you'll need the answer soon. The fourth question gives anyone who's unhappy about it an opening. They may not take it the first time, and that's fine. They know the door is open.
For the mechanics of running one-on-ones once they're going, see One-on-ones that engineers don't dread.
If someone else wanted the job
Say a colleague, call her Ana, also applied for the role and didn't get it. This is the relationship most likely to go wrong, and avoiding it makes it worse.
Talk to her privately, early, and without making it about you:
"I know you went for this role too. I'm not going to pretend that isn't awkward. I'd like to understand what you were hoping the role would give you, because some of that may be things I can help with anyway."
Often the answer is something like more influence over technical direction, more visibility with leadership, or a clearer path to the next level. Many of those don't require the manager title. You can give Ana ownership of a technical area, put her in front of stakeholders, or work out a growth plan with her. What you shouldn't do is overcompensate by deferring to her on every decision. That undermines you with the rest of the team and doesn't actually help her.
If after a few months she's still disengaged, that's a performance conversation like any other. Don't let the history make you avoid it.
Friendships change, and that's not a failure
You probably have one or two people on the team you're genuinely close to. You don't have to end those friendships. You do have to accept that they're now different, because you hold information and make decisions that affect your friends.
Some rules that keep it workable:
- No private information flows through friendship. Salaries, other people's performance, upcoming reorganizations: none of it goes to your friend first, at the pub or anywhere else.
- Equal access. If you get lunch with two people every week, the other four notice. Spread informal time around, or make the lunch open.
- Stop complaining sideways. Venting about leadership or about another team member with a former peer was normal last month. Now it's the manager complaining to a report, and it spreads.
- Name it with the friend. "I want us to stay friends. There'll be things I can't tell you, and sometimes I'll have to give you feedback I'd rather not. I'd rather say that now than have it come as a surprise."
Most friends handle this better than you expect, especially when you say it out loud.
What to change, and what to leave alone
Former peers are watching for two things: whether the job has gone to your head, and whether you'll actually do anything with it. Both overreaching and doing nothing cost you credibility.
A rough rule for the first month:
| Change early | Leave alone for now |
|---|---|
| Things everyone already complained about and you all agreed on | Technical decisions you lost the argument on as an engineer |
| Things that are clearly broken and cheap to fix (a meeting nobody needs, a missing on-call runbook) | Team rituals that work, even if you'd run them differently |
| How decisions get communicated, so people stop guessing | Who owns which area, unless it's actively causing problems |
The middle row is the trap. If you lost the argument about the database migration three months ago, using your new title to reverse it tells everyone that the role is about getting your way. If it genuinely needs revisiting, reopen it the way anyone else would, with the team, and accept the result.
Keep a list of the things you want to change. Revisit it after a month of listening. Usually a third of it no longer looks important, and the rest is better informed.
Your first hard piece of feedback
Sooner or later you'll need to tell a former peer that something isn't working. The pull is to soften it until it disappears ("Just a tiny thing, no big deal...") or to avoid it entirely because "they know me, they'll figure it out".
Kim Scott's Radical Candor gives a useful frame for this. She describes good feedback as combining two things: caring personally and challenging directly. Caring without challenging is what she calls "ruinous empathy", and it's the most common failure for new managers promoted from within, because the caring part is already there. You like these people. That's exactly why the feedback needs to happen.
A worked example. Say Ben, a former peer, has been merging his pull requests without waiting for review, and twice that's caused a broken build for everyone. You might say:
"Ben, I need to raise something, and it's a bit strange coming from me rather than as a teammate. Twice this week you merged without a review, on Tuesday and Thursday, and both times the build broke for everyone for about an hour. I need reviews to happen before merge. What's getting in the way?"
What makes that work:
- One sentence acknowledging the change, then straight to the point. Don't spend five minutes apologizing for being the manager.
- Specific situation and behavior, not "you're careless". This is the Situation–Behavior–Impact structure from the Center for Creative Leadership.
- A clear expectation, stated as yours. Not "the team feels", not "people have mentioned". You own it now.
- A real question at the end. Maybe reviews are taking two days and he's been trying to keep things moving. That's a problem you can fix, and you wouldn't have learned it by lecturing.
Do it privately, soon after the event, and in person or on a call rather than in a message. Then follow up a week later, including saying so if things improved.
The mistakes to watch for
- Staying "one of the team". Avoiding decisions so nobody's annoyed. The team needs someone to decide; if you won't, someone else will, informally.
- Overcorrecting into distance. Suddenly formal, closed door, no more lunch. People read it as "the job changed them".
- Keeping your old work. You still own the hardest technical area because it's yours. Now the team's most critical work waits on the person with the least time. Hand it over deliberately; Engineer to manager: what actually changes in your week covers why.
- Asking your former peers for permission. Asking for input is good. Waiting for everyone to agree before you act is abdication.
Your first-month checklist
- Address the change with the whole team in your first week, in a sentence or two.
- Hold a first one-on-one with everyone within two weeks, using the questions above.
- If someone else applied for the role, talk to them privately before the end of week two.
- Have the friendship conversation with anyone you're close to.
- Start a "things to change" list. Don't act on most of it until the month is out.
- Make one small, visible fix the team already agreed on, and follow through on every promise, however small.
- Give the first piece of corrective feedback when it's due, not when it's comfortable.
The question to ask yourself at the end of the month: if one of your former peers described you to a new hire, would they say you're fair? Not "nice", not "still one of us". Fair. That's the foundation the rest of the job is built on, and the PTMF study guide covers the other basics, like trust, feedback and clear communication.