LTC#10 - First-Time Management Opportunity
How can an IC successfully transition to an EM role? What are the risks and goals to consider, and what questions can help navigate areas of uncertainty?
Hi, this newsletter is a weekly challenge for engineers thinking about management.
I’m Péter Szász, writing about my engineering leadership experience on my blog, training aspiring and first-time Engineering Managers on this path. See more about what I might offer you at leadtime.tech.
In this newsletter, I pose a weekly EM challenge and leave it as a puzzle for you to think about before the next issue, where I share my thoughts on it.
Last Week's Challenge
Last week, we explored a situation in which a developer was offered their first management position through a surprise skip-level conversation. If you missed it, read the details here.
I'll approach this situation from the standpoint of that developer who’s being offered the Engineering Manager role, focusing on goals, risks, and 5 questions that can inform and guide towards the best decision.
Goals to Achieve
Career Development: This should be a conscious career choice, not a path-of-least-resistance move. I need clarity on whether this aligns with my long-term career aspirations. Even if I decide to refuse the offer, it should be about preferences in developing technical skills instead.
Support Structure: If I take this role, I'll need appropriate mentorship, training, and clear expectations during the transition.
Team Continuity: The team is losing their manager already; if I step in, I need to ensure stability during this transition.
Personal Fulfillment: I need to determine if I'd genuinely enjoy management, including leading people, rather than just taking it for status, compensation, or pleasing a leader.
Risks to Avoid
Rushing a major career pivot: Taking a management role without proper consideration could lead to poor performance, career regression, and burnout.
Overcommitting without support: Agreeing to step up without securing concrete mentorship and resources increases the risk of failure.
Damaging team relationships: Transitioning from peer to manager will fundamentally change workplace dynamics that I value.
Undermining technical credibility: Without a plan to maintain technical involvement, I could quickly lose the expertise that got me this opportunity.
Creating a no-return path: Making the switch without establishing how I could return to IC work if management isn't the right fit.
5 Questions
What does success look like? I should ask the VP for specific expectations for my first 30/60/90 days. This helps gauge if the expectations are realistic and if I'd be set up to succeed or fail. What specific metrics would be used to evaluate my performance? Understanding the real definition of success beyond vague statements like "lead the team well" is crucial. This can also give some insights into how leadership sees the performance of my team.
What insights can the departing EM share? The topic might be sensitive, so I need to ensure them first that I’m keeping their confidentiality, but since they're leaving anyway, they have little reason to withhold critical information. I'd ask about team dynamics that aren't obvious, recurring challenges they've faced, and their honest assessment of what the role actually entails versus what's officially described. What would they do differently if starting over? Who needs what kind of support on the team? Which stakeholder relationships require special attention? Their unfiltered perspective could reveal important context the VP might not mention — or even be aware of.
How does the organization support management transitions? I'd ask both the VP and other EMs about mentorship programs, training, and other support during the learning phase. Is there an onboarding plan specifically for the transition from developer to manager? Does the company have examples of people who have successfully moved back to IC roles after management? Are there EMs who maintain technical expertise while managing?
How can I handle the shifting team dynamics? I need to think about how my relationships with colleagues would change, while considering ways we might preserve the most valuable aspects. My familiarity with the team's strengths and challenges should be an asset during this transition for all of us, as the other option for the team is to get an EM starting from zero context. How can I have honest conversations with them about this change? What are the risks we see, and what support would we need from each other? The trust we've built could enable us to work through this transition more openly, acknowledging that we're all adapting to new dynamics together.
What are my true motivations for considering this role? This self-reflection is critical. Am I drawn to management because I genuinely enjoy developing people and solving organizational challenges? Or is it about status, compensation – or maybe pleasing others? When I've coordinated work in the past, did I find satisfaction in helping others succeed? Can I honestly see myself energized by one-on-ones, performance discussions, and conflict resolution – or do these sound draining? What would I miss about being an IC? How would I feel watching others solve technical problems while I focus on people and processes? Can I find fulfillment in the team's technical achievements rather than my own? If I chose management and looked back in a year, what parts of my current role would I wish I still had?
The answers to these questions would shape my next steps. If I see a supportive environment around me and genuine motivations within, I might accept, with clear agreements about support, evaluations, and options. If not, I might propose alternatives like a temporary leadership role or a trial period. Otherwise, I should be clear that the current circumstances both within the organization and myself are pushing me towards continuing to develop on the technical track.
What's most important is recognizing that the technical-to-management transition is not just a promotion (at some organizations, it’s not even a promotion) — it's a career change. It requires new skills, new measures of success, and a fundamental shift in how one creates value.
Did I miss critical considerations? How would you approach this pivotal career decision? Let me know in the comments!
This Week's Challenge
You're an Engineering Manager for a team of 8 developers. Your company is stable but has decided to "tighten the belt" given market conditions. Your director has asked you to develop a plan to reduce your team by two people within the next month. You need to choose who to let go, and how to handle the situation with the remaining team members.
The team is a mix of senior and mid-level developers with various specialties. Everyone is performing adequately, though some are stronger than others in different areas. You've never had to let anyone go before.
What do you do?
Think about what your goals would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those and similar weekly brain teasers in the future.
Until then, here's a small piece of inspiration to match last week's challenge:
See you next week,
Péter