The most common path to engineering management is accidental: you were the best engineer on the team, so when a management gap opened, you were handed it. Nobody explicitly trained you for it. The skills that got you promoted — writing tight code, debugging complex systems, making fast technical decisions — are exactly the skills that will cause problems in your first year as a manager.
This is not a warning. It is a description of a predictable transition, and once you see the mechanism clearly, you can navigate it.
What Actually Changes
Your leverage shifts from doing to enabling. As an IC (individual contributor), your impact is your own output. As a manager, your impact is the team’s output. A great IC who becomes a manager and keeps solving problems themselves is a manager who is doing the wrong job.
The most common failure mode: a senior engineer becomes an EM and is the best person in the room at every technical decision. So they make them all. The team executes rather than thinks. Technical growth stops. The manager is busy, the team is bored, and within 18 months two good engineers have left.
Feedback becomes your primary tool. As an IC, you rarely need to give structured feedback — code review is feedback, and it is about the code, not the person. As a manager, the 1-on-1 is the main instrument. How you run it, what you say in it, and what you do not say in it determines whether your engineers grow.
Ambiguity is now your input, not your enemy. Engineers solve well-defined problems. Managers operate in permanent ambiguity: unclear business goals, changing priorities, team dynamics that resist debugging. Getting comfortable in this state is a skill that takes years.
The First 90 Days
The two most common first-90-days mistakes:
-
Making changes before you understand the system. You see things to fix. You know the codebase better than anyone. Resist. Spend the first 30 days listening. Your credibility with the team is built on understanding their reality, not demonstrating your technical superiority.
-
Skipping 1-on-1s when things get busy. 1-on-1s are not a nice-to-have. They are how you learn that the quiet engineer who looks fine is updating their LinkedIn. Cancel them when things are on fire; reschedule within the same week. Never cancel twice in a row.
A framework that works for the first 90 days:
- Days 1-30: Listen. Talk to every team member, skip-level up, and the engineering managers you collaborate with. Map the informal dynamics, not just the org chart.
- Days 31-60: Identify the one or two things that are genuinely broken. Not the ten things you see — the one or two that if fixed would unlock everything else.
- Days 61-90: Make the changes with full transparency. Announce what you are changing and why. Track the result.
1-on-1 Structure That Works
The 1-on-1 belongs to the report, not to the manager. Their agenda, their concerns, their career. A structure that prevents it from becoming a status update:
Opening question (not “how are you?”):
- “What is in your way right now?”
- “What is going well that we should do more of?”
- “Is there anything you want to flag that you would not raise in a team meeting?”
Middle (career, not tasks):
- Once a month: where do you want to be in 2 years? What are you learning? What are you trying to get better at?
Close (your input):
- Give one piece of specific, recent, behavioural feedback — positive or developmental.
- Flag blockers you are working on for them.
The common mistake is turning this into a sprint review: which tickets are done, which are blocked. That information exists in Jira. Use the 1-on-1 for what Jira cannot tell you.
Technical Involvement After the Transition
You do not stop being technical. You stop being the technical decision-maker. The shift is subtle:
- Before: “We should use Redis for this caching layer, here is why.”
- After: “What are the options here? What are the trade-offs? Who on the team has experience with each?”
Your value is asking the questions that expose the trade-offs, not providing the answers. The team learns to make better decisions. You learn the team’s reasoning. Both are better outcomes than you being right every time.
Stay close enough to the code to detect when an architectural decision will cause problems in 12 months. Stay far enough away that engineers do not wait for your approval before making decisions.
Training
The Technical Management training at Sphinx-Digital covers this transition in depth: 1-on-1 frameworks, feedback models, handling underperformance, and running engineering processes (estimation, incident response, hiring) for technical team leads.