Your output is now the team's output
As a developer you are measured by what you build. As a manager you are measured by what your team delivers, and by whether the people in it are getting better. A week in which you wrote no code but removed two blockers and settled one disagreement can be your most productive week.
- Building
- Reviews and design
- Planning and meetings
- People: one-to-ones, hiring, feedback
This is the hardest adjustment, because the old measure was visible every evening and the new one is not. Expect to feel unproductive for the first few months. That feeling is normal and it is not evidence that you are failing.
What to stop doing
- Taking the hardest ticket. When you keep the difficult work, your team stays dependent on you and nobody else grows.
- Rewriting other people's code. Review it, explain your reasoning, and let them fix it. It is slower this week and faster every week after.
- Answering every question yourself. Ask what they would do first. Often they already know.
- Protecting your team from all bad news. People do better work when they understand the real constraints.
What to start in the first three months
- Regular one-to-ones. Thirty minutes with each person, on a fixed schedule, and their agenda before yours.
- Learn what each person wants. One wants promotion, another wants stability, a third wants to change domain. You cannot motivate people you have not asked.
- Make delivery predictable. Stakeholders forgive a late date they were warned about. They do not forgive surprises.
- Give feedback early. A small correction this week is kinder than a poor review at year end.
- Stay technical enough. You need to follow the design discussion and spot a risky estimate, without being the one who writes the design.
Five interview questions to prepare for
Manager interviews are mostly about your past behaviour. Prepare one real story for each of these, with the situation, what you did, and what changed as a result.
Tell me about someone on your team who was underperforming.
Interviewers listen for whether you found the cause before judging, whether you were direct with the person, and whether you can say plainly how it ended.
Describe a project that was going to miss its date.
They want to hear when you raised it, what options you offered, and what you changed afterwards. Blaming another team is the weakest answer.
How do you balance technical debt against new features?
A good answer describes the debt in business terms, such as slower releases or more incidents, and shows how you negotiated time for it.
How have you helped a senior engineer grow?
Senior people need scope and visibility more than instruction. Talk about what you handed over and how you stepped back.
Tell me about a time you disagreed with your own manager.
They are checking that you can argue your case with facts, and then commit fully to the decision once it is made.
If you have never held the title, use the times you led without it: mentoring a new joiner, running a release, coordinating across teams. Most first-time managers are hired on exactly that evidence.
Prakash Nayak
Software architect and engineering leader with 25+ years in software, nearly ten of them leading payments architecture at Fiserv. Book a mentoring session or write to me.