Every knowledge worker will face burnout, or have coworkers who do. Here I share what I’ve learned about it as an engineering manager.
A blog by Emmanuel Goossaert
Code Capsule Posts
Peter Drucker—the founder of modern management—said in his 1999 article “Managing Oneself” that knowledge workers should plan their second career well ahead of time.
That’s admirable advice.
Except that for the rest of us, planning our first career is already a major life struggle.
And I can talk at length from my own experience. A little more than ten years ago, back when I was still a naive junior engineer, career progression was a very nebulous concept.
Now that I’m at a point where I’m managing other tech managers, I’ve gained enough perspective on the topic that I can share valuable insights that my younger self would have loved to hear and learn.
In a previous article, I covered why soft skills matter and how they can make your career stagnate if you don’t address them. I also shared what the next job roles are from the senior developer role.
I wanted to create a simple representation to enable anyone with a career in tech to grasp how career progression looks like and what it requires.
In the rest of this article, I’m presenting a skills map of career progression, starting all the way from the senior developer role. This map covers both the individual contributor and managerial career paths.
Have you ever received feedback from your manager that you should improve your communication skills? Or that you should create more visibility for your work? And another one, that you should work on your influencing skills? These are all related to soft skills, and it can be confusing what they mean and how to improve on them.
As a tech manager, I find myself giving that feedback regularly to engineers. About 50% of them get it, however, the other 50% roll their eyes and reply “Soft skills? Pffft, I’m an engineer, I don’t need that. All I gotta do is code harder and learn technologies A and B and I’ll keep on going.”
And that’s where they’re wrong, as sadly, I’ve seen such neglecting of soft skills ending up costing many of them years of stagnation for their tech career. The same could happen to you, or might already be happening to you without you realizing.
I wanted to follow up on my article about career progression for senior developers, by addressing the topic of how to map and learn the skills needed for tech jobs.
Soft skills and teamwork
skills are what’s gluing
hard skills together.
So in this series of three articles, I’ll first be covering what is the difference between hard skills and soft skills, and why soft skills matter even if a great part of your job is purely technical.
Another difficult problem is how to prioritize those skills so you can improve predictably. To address that, in the second article I’ll share a map that I’ve created and which shows how different types of skills relate to different career paths.
Finally, in the third and last article, I’ll cover the top skills you should focus on as a senior engineer or as an engineering manager if you want to see fast progress in your personal growth.
Let’s get started with defining the types of skills and why they matter.
I’ve been thinking a lot about my personal remote work setup lately, and also about the organizational setup that my tech teams are using to work together.
When most of us still worked in collocated office spaces, there were many organizational features that we didn’t even realize were there and that we took for granted.
And it doesn’t matter that the pandemic started more than a year ago. It’s never too late to reflect on what can still be improved, and apply changes for the better.
I distilled it down to the following features.
After I shared my article about the next career moves as a senior developer, someone asked me the following question over the weekend:
“I’m a senior engineer who recently switched to leading a team of engineers. How do I grow in the managerial career path and become a manager of managers?”
It’s a great question, and not a trivial one. Becoming an engineering manager is often straightforward, but the next step, becoming a manager of managers, ends up being a career blocker for many.
If you’ve been wondering the same thing, then the first step is to look at your current workplace by addressing the following questions:
- Did you see any colleagues becoming a manager of managers via an internal process over the past year?
- What type of projects did these colleagues work on, with who, and in which department? Can this be reproduced?
- Is your department or a nearby department growing, and will a position of manager of managers open soon?
- Do you see yourself staying at your current company for the coming two to three years?
If you could answer YES to all of the above, it means there is a chance you could grow internally. From there, you have to start planning to position yourself so you get the job when it opens.
If you answered NO to any of the above, then you’re in the wrong company, and it’s time to plan a move. Selecting the right next job and company, so it’s aligned with your career aspirations, is going to be a crucial step.
In this article, I’ll be diving into both cases by providing a guide on how you can plan this career move, and if you’re lucky enough to get a shot at it, how to handle your transition into your new role.
In addition, as I’ve run dozens of leadership interviews and selection processes, and as a manager of managers myself, I’ll be sharing insider information on how managers will evaluate you and will decide whether you get the job or not.
“I don’t know what’s next in my career” is a sentence I hear frequently from senior engineers.
In fact, I hear this question so frequently that I decided to write this series of articles to address it.
When I ask those senior engineers how they have approached their career planning until now, what I hear is “I thought if I just worked harder and wrote more code, eventually someone would notice and I’d get promoted to staff engineer.”
Unfortunately for so many senior developers, this type of thinking is a major misconception on so many levels. Just writing more code isn’t going to get anyone promoted. Just waiting to be noticed isn’t going to get anyone promoted. Also, there is more than just the individual contributor or managerial path as possible career paths for engineers. And finally, getting promoted—like other forms of external validation—shouldn’t be the ultimate goal in anyone’s career, because it’s not fulfilling.
In this article, I am making a recap of the most realistic career moves from the senior engineer position. I’m dividing the possible moves into the four categories from the diagram. For each category, I will cover what it’s all about what it would require to get there.
Many engineers have great tech skills but see their careers hit a roadblock when they’re unable to pull the self-awareness necessary to grow further.
I’ve encountered many such engineers in my career and tried to help as best I could. I wish I could say I was successful at it, but generally, the effects of my feedback would last for a few weeks, and then those people would surely fall back into their usual bad habits and triggers.
Last week, I found an interview with Esther Perel, and it’s been a real game-changer for me. Perel is a psychotherapist and shared advice on the topic, which for once was practical and directly applicable.
A short recap on the world or Bitcoin, cryptocurrencies, and non-fungible tokens (NFTs).
“Of course,” said my coach, “that’s because you’re not listening.”
I leaned back in my chair and stayed there, quiet and confused. Trying to grasp what he said, I asked “What do you mean I’m not listening?”
“I’m not saying you’re not hearing,” he replied, “but that you’re not paying attention.” He paused for a few seconds to let that sink in me, as he knew like no one else how to use silence. Then, he continued “You’re not looking to uncover the facts about what really happened. You have to look for the facts.”
That was a total “aha” moment for me. It felt like my brain had expanded right inside my skull and turned upside down. And this is just one example among many that happened during our calls.
and on which I added text in an attempt at being funny.
As an engineering manager, I’ve been thinking how much sharing my opinion of someone’s performance and skills can influence others around me to think the same.
For example during the weekly meetings I have with my peers at work, if I praise or complain about a person in my area having some behavior, I will shift the perception my peers have of that person.
When you have to manage people, staying objective when assessing a person’s performance is always a challenge, no matter the experience or seniority. There are several traps to avoid, one of them is to rely on reputations too much because although reputations offer convenient mental shortcuts, they also bring their load of subjectivity.
So how exactly are reputations formed, how to verify if someone’s reputation is fair, and how to help bring someone’s reputation closer to what it is in reality?