I Wish I Knew THESE Before Becoming A Manager
Dev Leader Weekly 69
TL; DR:
People, people, people!
It’s an extremely fulfilling role!
Join me for a live stream on Monday, November 11th, at 7:00 PM Pacific
Join me for a live coding stream on Tuesday, November 12th at 7:00 AM Pacific
What’s In This Issue
Exclusive Article: I Wish I Knew THESE Before Becoming A Manager
People, People, People
Nearly every single software engineering manager (yes, there are exceptions) started out as a software developer. We started with a passion for solving problems using code, building cool sh*t, and totally nerding out on technical problems.
If you’re reading this, I can almost guarantee that describes you at least a little bit.
Many software developers envision spending most of their careers not focused on people. Instead, they can get their heads into the code and come up for air only when they need to sync with their team.
Fortunately, more people are talking about how this *isn’t* the case — working effectively is a big part of your job.
But as an engineering manager, it’s not part of your job, it is your job.
I define my role as an engineering manager as:
Empowering my team to deliver their best work possible
Helping my team members grow in their career
To do that effectively, two key ingredients are needed:
Trust
Respect
Neither of those come for free. Both of those require consistent work. Both of those take time.
That means spending a TON of time working with people. It means actively taking the time to learn about people, understand their challenges, understand their motivations, etc…
As an introverted person, this is very taxing on me. And I don’t mean that I don’t enjoy it — it just takes a lot of energy for me to do. On some days when I have many one-on-one calls with my team, I’ll need a nap as soon as the day is over! Conversely, if I put my head down to write code, I wouldn’t have to come up for air for hours and I’d feel energized.
But… that’s got to change too. Oh, I should mention that you can watch a video version of this newsletter here:
It’s Not Your Impact Anymore
As software developers, we often have key moments where we can REALLY feel the impact we’re delivering:
You’ve solved that seemingly impossible problem from debugging
You landed that feature you worked on for weeks
You merged your first PR on your new team
You mitigated that issue in production
… the list goes on. And these are all very tangible examples of you having your hands in something and getting sh*t done.
When it comes time for performance reviews and career conversations with your manager, you’re able to reflect on the work you did. You might be mentioning things like:
Improved performance of our service by 20% by leading project ABC
Redesigned X legacy part of the codebase
Fixed several key bugs
These awesome highlighters that YOU did. But as a software engineering manager, what exactly are OUR highlights? What impact are WE responsible for?
This can become tricky to navigate for two reasons:
Just like any employee, you’re going to want to discuss your impact when it comes time for career conversations. It’s important that you can communicate your contributions and value.
You might feel completely demotivated if you’re unsure how you’re deriving value in your role as an engineering manager — because it probably isn’t from landing awesome pull requests!
The reality is, your impact is the impact of your team. Some people think about impact as mutually exclusive: two people working on something but only one person an take credit. However, as engineering managers, our impact is based on our ability for our team to deliver successfully.
Earlier in my career, I was coding while managing teams — it took me around 6 years to TRULY start to feel like I was having an impact through my team. It’s not an easy mindset shift!
But that brings us to one more critical point to consider.
Hands Off That Keyboard
The truth is, you don’t have time to be coding as an engineering manager. That doesn’t mean that you shouldn’t be technical or can’t benefit from having a solid foundation in code, but it’s not your role anymore.
There are exceptions to this — like when a team is forming and things need to get built. It’s more common in startups or newly forming teams. Another exception is when your team is truly just small, up to around 5 direct reports or so. (Disclaimer: I know there are exceptions to this, always, so I am trying to generalize)
Beyond that: you don’t have time for it as part of your regular job. If you feel that you can easily fit coding in with your managerial responsibilities, and you’re NOT in the situation I just described, it’s probably one of two things:
You’re working extra hours
OR… you’re not actually spending enough time with your team and on the managerial aspects of your role.
Working with your team members takes a significant amount of time. Between one on ones, resolving conflicts, navigating personal situations, career conversations, and everything in between — you’ll find that your day is filling up rapidly.
But these are the valuable things to be focusing on.
Many new managers have a hard time transitioning into this frame of mind but remember: Writing code isn’t how a manager’s impact is measured. How are you enabling your team to do their best work possible?
There are other things outside of pure people activities that require attention:
Architectural input
Project planning
Strategy and vision
Stakeholder updates
Partner team collaborations
The list goes on — and all of these things will be pulling for your attention. Just remember: your team gets priority.
Is It For You?
I’ve learned a lot on my journey as an engineering manager, but there’s of course so much more to learn. Along the way, I’m happy to share what’s working and what’s not — that’s how Dev Leader came to be!
If you have an interest in pursuing a career in management, I recommend you consider the following:
If you love to code, when will you make time for it?
Do you enjoy mentoring others?
Do you avoid conflict or difficult conversations?
Do you enjoy working with others? For others?
You need to be ready to work with people — it’s your job! I’ve found it to be one of the most fulfilling things that I could pursue, so I’m thankful every day to be doing this work.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
Weekly Recap
Answering Your Questions: Technical AND People Centric Roles in Tech
In this vlog, I discuss some different options for tech careers that involve people.
And a big surprise — most of them involve people. Even software engineering is a field HEAVILY focused on working with people.
Working directly with customers is a different story though. What’s that look like?
Fixing Bugs In Production – Principal Software Engineering Manager AMA
Why do so many of us keep saying build software to become a better developer?
You’re going to learn a LOT more about REAL types of situations.
Using a tutorial can be helpful, but when you’re only used to following the happy path…
You’ll be in for a ride!
In this livestream, I’ll discuss a recent experience in BrandGhost where a simple fix became a LOT more complicated because of real constraints.
As with all livestreams, I’m looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
LIVE CODING – WordPress Migration to Blazor – PART 3
It’s time! WordPress on AWS LightSail has been non-stop problems for nearly 2 years now.
Time for a change.
I’ll be looking into using LinkDotNet.Blog by Steven Giesel as my blog engine of choice. But migrations are never easy, so this will be the first of many sessions trying to figure out how I can get my blog setup before going live.
Remember — I need to keep as many links active as possible so I don’t ruin my SEO!
Intro To Yield In C# – Beginner Examples In Action
The yield keyword is a spicy one in C#.
That’s because when we use it within a method that returns IEnumerable, we get this fancy thing called an “iterator”.
Yeah. It’s fancy as heck.
But it can also be really confusing to understand, which is exactly why I made this video to help you out.
Let’s step through some code so you can see the behavior of the yield keyword and how it works inside of iterators!
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!