Welcome to the deep dive. You are listener, and today we're thinking specifically about the learner you've given us your sources. Our job simple, we extract the key knowledge you need fast.
Yeah. Think of it as your shortcut getting you up the speed without drowning you in info exactly.
And today we're plunging into a really common but often tricky shift in the tech world.
Right moving from software engineer you know, an individual contributor or IC, to becoming an engineering manager and EM.
Yep. So, whether you're maybe thinking about this move or just curious what it actually involves, or you're already in the thick of it, we're going to try and break it down.
And our guide for this is the book Think Like a Software Engineering Manager dot pdf.
Our aim here isn't just to like read the book to you, Oh definitely not.
We want to really get into the EM role itself, the subtleties of that IC to EM jump clear up some you know, common myths.
And highlight those key skills you need to build. We're hoping for some a ha moments.
For you, Yeah, moments that just make the whole thing clearer.
Okay, let's jump right in one of The first things that really stood out for me in the book is that it feels very authentic, like it comes from someone who's actually done this.
Oh. Absolutely. The author kicks off talking about their own struggles finding good resources when they made that leap from senior engineer to EM.
Which is so relatable I think totally.
It grounds the whole thing. This isn't just theory, right, It's built on their own journey, the obstacles they hit, how they worked through them.
And they emphasize that it's packed with real workplace stories, actual examples.
Yeah. And for structure, the book sorts things into three main pillars for an EM, people, projects, and products, and the process is holding it all together.
That sounds like a really practical way to frame it, based on actual experience. It is.
So let's get down to basics. What is an engineering manager according to the book, Well, it.
Offers a pretty clear definition. Basically, someone who manages other engineers, could be direct reports or even managing other managers.
Right, and it points out that in really early stage startups you might not even have a specific EM role.
Oh interesting, So who does that job? Then?
Often it's the CTO, the chief technology officer. They kind of wear the em hat initially handling both the tech vision and the people side. Huh.
That really shows you, doesn't it. Even in a tiny team, those leadership functions are essential.
Exactly, which brings us to a really key distinction. The book makes the difference between management and leadership.
Okay, yeah, this is important. The author argues that whatever your title em engineering lead, the real focus ought to be on engineering leadership. What's the nuance there?
Well, the interesting part is the idea that you can absolutely be a leader without being a manager, and maybe more surprisingly, you can be a manager without truly leading. But the best ems they manage and they lead, They blend both. It's not just about doling out tasks. It's about setting direction, inspiring people, fostering growth.
That makes a lot of sense. It's about enabling the team, not just directing them. And a massive part of that, the book stresses, is genuinely caring for the people.
Oh hugely. The book lists out so many responsibilities tied to that, having meaningful one on ones, talking about careers, doing fair performance.
Reviews, navigating uncertainty, giving emotional support.
Sometimes team building, really listening, being fair, thinking about diversity and inclusion, giving constructive feedback. It's a lot. It really highlights the human side of the role.
It really does. It shifts the focus, doesn't it, from just technical output to cultivating a healthy, productive team.
And to show the impact, the book uses these two examples, Alice and Bob.
Ah Yes, the contrasting managers tell us about them, okay.
So Alice is shown as an em who sets a clear vision right, she guides her team effectively towards success. Bob, though he's very hands off lessay fair leaves him to it me much and the result, Bob's team starts to drift. They lose sight of the bigger picture how their work fits in.
So Alice provides that direction and motivation that Bob's team is missing. But the book also says Alice wasn't perfect either. Right, even with a vision the way she led head.
Issues precisely, Alice had direction, Yeah, but her approach was quite rigid. She wasn't really open to feedback, didn't create an environment where people felt safe to speak up.
That sounds stifling.
It was. It dampened creativity and her inflexibility, like demanding everyone be in the office on certain days no matter what. That hurt morale and trust.
So leadership isn't just what you achieve, but how you get there. It needs that psychological safety, that autonomy.
Absolutely, and the book then gets into different leadership styles like transactional and transformational. Can you break those down?
Sure? Transactional is more about rewards and punishments, right, very goal focused, maybe involves closer monitoring.
Sometimes boring on micromanagement. Yeah, and often morale can suffer.
Right. Then transformational is more about the big vision inspiration, company goals first, strategic.
Bold, but the potential downside there is maybe missing the details the day to day needs of the team.
So one's very much about the now and external drivers, the others about the future and internal motivation. It seems like neither extreme is perfect.
And the book agrees. It really stresses that the best leadership is situational. You adapt based on the person, the team, the company.
Context, hybrid approach usually.
Generally Yeah, drawing bits from different styles works best. The book even gives an example of book a team having to quickly change its style because a competitor dropped a big new feature. Shows you need to be adaptable, right.
It then quickly covers a few others Autocratic democratic, delegative, servant leadership, highlighting the pros and cons of each, but always coming back to that idea of a flexible hybrid style.
Yeah, like autocratic might be needed in a real crisis. You know, fast decisions, but.
Use it all the time. Terrible for morale kills initiative exactly.
People need to feel heard.
Okay, let's switch gears slightly. Let's talk about how people see this move from IC to EM. The book tackles that idea that it's always a step up of.
Promotion, and it makes a really crucial point. It's better to think of it as a lateral career move. It requires a totally different set of skills.
It's not necessarily better than being in IC.
Just yeah, different exactly, And reframing it like that is so important, isn't it. It helps manage expectations for you, for your team.
Yeah. Absolutely. The book also adds reassuringly, I think that these career changes aren't like a one way street. You can always learn, always adjust.
Your path, which is good to remember. Now, a question that always comes up, should an EM still code? Ah?
The coding question. What's the book's stance, Well.
It's nuanced. It says, Look, it's possible to code as an EM, but it strongly advises focusing on the EM skills firsts. Trying to do both well often leads to burnout and you might end up doing neither job effectively.
Okay, so hang up the keyboard entirely.
Not necessarily, The book says, staying connected to the tech is really valuable, things like code reviews, design discussions, being in the agile ceremonies.
That makes sense. It keeps you grounded in what the team's actually doing, helps with mentoring, builds credibility right.
And it's just other ways too, like hackathon's or writing some automation scripts for your own reports, things that keep you technical but don't put you on the clinical path for features.
So you're not becoming a bottleneck exactly.
And hey, coding for fun once you're settled in the role, totally fine.
It's a balanced view. Stay connected, but let the team own the codebase precisely.
Now, let's hit another big misconception the rock star engineer.
Myth ah Yeah, the idea that your best coder will automatically be your best manager. The book pushes back on that right hard.
It states very clearly being a brilliant engineer does not automatic mean you have the people skills to be a great.
Em Technical skills are important, maybe a prerequisite for.
Sure, you need that foundation. Yeah, but empathy, communication, delegation, handling, conflict. Those are different muscles. Some you might have, many you need to build.
And the risk if you ignore that you could.
Lose a fantastic ICEE and gain a pretty mediocre manager who struggles to support their team. The book warns against that. Don't sacrifice great engineers for subparer management.
It really hammers home that these are separate tracks needing different talent. Okay, so how do you actually make the transition? The book talks about phases, starting before you're officially an em.
Right this phase I, it's all about being proactive, having that growth mindset, and step one align with your manager.
Talk to them. Why is that so crucial upfront because it.
Sets the foundation for everything. You need to state your interests clearly, talk about expectations, get their support.
Makes sense.
The book suggests maybe creating a thirty sixty to ninety day plan. Think of it like a learning period, a trial run, almost.
A chance for you both to see if it's the right fit.
Exactly, and it's a perfect time to spot your own skill gaps maybe communication, maybe delegation, and start working on them. The author even shares a story about timing their own move and talking about it early.
What about that idea of considering the worst case scenario, like what if your manager says no?
Thinking that through helps you plan strategically anyway. It forces you to understand their perspective, maybe look at other paths. It's valuable planning.
Okay, And the book also says start taking on leadership tasks now right gradually?
Yes, definitely start small, mentor and intern, maybe lead a small part of a project, be an onboarding buddy.
Get a feel for the people's stuff exactly.
See if you actually enjoy growing others, and look for projects that involve working across teams, dealing with different stakeholders. Practice those communication skills.
Another tip for this pre em phase document your achievements, but specifically against management expectations. Why do that now?
It builds your case. It's concrete proof you're developing leadership skills, especially if your company's career guide for managers isn't super clear, so you.
Can say, look, I've already been doing X Y, and Z, which aligned with the EM role precisely.
It tracks your progress and shows you're ready.
Okay, so you've done the prep work. Now the actual move into the EM role. The book mentions different ways as can happen.
Yeah. It outlines three main scenarios. First, joining a new company.
As an EM that sounds tough.
The book suggests it is probably the riskiest new company, new team, new role all at once, may be best to avoid for your first EM gig if possible.
Okay, scenario too.
Transitioning within your current team where you used to be an IC peer.
Ooh, tricky dynamics.
There can be very delicate. Yeah, you need patients. You need to actively build trust in your new capacity, manage perceptions, avoid any hint of bias or favoritism, maybe even deal with some resentment.
How do you handle that?
The book implies things like being really clear on expectations, seeking feedback constantly consciously building those new manager report relationships.
Got it. And the third scenario.
Moving to manage a different team within the same company.
That sounds potentially easier.
The book suggests it often is you already know the company culture, the processes. That gives you a head start. Even with a new team.
Okay, So whichever way you transition, the book stresses reflection afterwards, a retrospective.
Yeah, looking back after that initial period, ask yourself things like what parts were frustrating? What was satisfying?
Do I still feel more connected to the code? Or am I enjoying enabling people?
Am I finding joy in my team's success? How do my former peers see me now? Am I actually helping this team? Really honest questions?
And how do you measure success beyond just you know how you feel?
The book gives both subjective and objective measures. Subjective your comfort level, are you challenged but fulfilled? Do you have a clear mission? And objective things like are you multiplying the team's impact? Are projects getting delivered successfully? What's the feedback from others? Team velocity and attrition rate? Are people staying?
The goal isn't just to survive the transition.
No, it's to thrive, And the book adds remember to actually celebrate making this big career change.
Good point. So once you're settling in the book talks about identifying your management style. Why is that an ongoing thing?
Because who you thought you'd be as a manager might be different from reality after you've shadowed, been mentored, actually done the job for a bit. That's a golden opportunity for self assessment.
So revisit those styles Autocratic, democratic, servant, et cetera.
Yeah, see which ones feel most natural. Now, maybe you thought you were democratic, but you're actually leaning more towards coaching.
And it's okay if it's not just one style.
Totally identify one or two as a starting point. But the key is flexibility, adapt as you learn as the team needs change. Constant learning is the name of the game for managers.
It sounds like it's a continuous journey of refinement.
Absolutely no fixed endpoint. You're always learning, always adapting.
Okay, So, as we wrap up this part of our deep dive on moving from IC to EM, what are the absolute core takeaways for the learner?
Well, the book's summary really hits the nail on the head.
First.
IC and EM are different jobs, different skills.
Remember that separate tracks.
Know the definitions, and remember IC to EM isn't automatically a promotion, it's a lateral move.
EMS can stay close to the code, just maybe not by writing a day to day exactly.
Technical skill is still important, but it's not enough on its own, and the big.
One, Great engineers don't automatically make great managers. You need those people skills summinate some learned.
So bottom line from this chapter really evaluate your own skills, your own motivations. Is this EM path truly the right fit for you.
That's a fantastic summary of a really dense and useful chapter. Lots for anyone thinking about this or going through it to chew on.
Definitely, it really sets the stage well for understanding the role's complexities and its rewards too, So.
The learner, to bring this deep dive toward a close. For now, we've really unpacked the why behind the book, what an em actually does, busted some myths about the iced.
EM move, and stressed how vital self awareness, planning ahead, and always learning are for this kind of career shift.
We hope this gave you that shortcut, highlighted some maybe surprising things, and definitely some practical steps mmmmmm.
Which leads us to a final thought for you, the learner, Based on everything we've talked through today, what's maybe the very first smallest step you could take if you're considering a move into engineering management.
Something to think about, is you continue exploring,