Imagine you live in a city like Lisbon.
It’s gorgeous with a long history. But it takes a second to realize the infrastructure was built for people, not cars. In other words, there aren’t enough parking spots.
So, if you have an appointment with a dentist who lives in the city center, you might not find a spot nearby. And if you don’t plan properly, you might need to walk at least fifteen or twenty minutes from your car to the office, which sometimes means you end up late.
Thankfully, there are a lot of public scooters in the city. You can hop on one and get to the dentist in just a few minutes. It allows you to do more, like owning a car or being fluent in more than one language.
Wanting to do more was one of the main reasons I decided to become an engineering manager (EM). I wanted to work faster and build more things, but there was only so much I could do alone. I needed to scale up, which meant learning to coordinate teams of people to work towards the same goal.
But this journey didn’t happen automatically. And I believe it’s important that we tell our stories, so I want to share mine and what I learned from it.
I wanted to stand out
Scott Adams, creator of the Dilbert comics, once said being in the top 1% of a field means being nearly perfect and sacrificing a lot, sometimes too much.
But being in the top 10% doesn’t demand perfection. What it requires is being very good, as well as bringing undeniable value to the table. This is a much more achievable goal for most of us.
Part of this comes down to what he calls “talent stack,” which means pairing skills. If you try to be the best at a particular skill, you’ll have a lot of competition. There is no shortage of brilliant pianists out there, for instance. But if you can play and sing at the same time, you’re going to get noticed much more easily.
There aren’t a lot of managers out there with deep technical experience. So, when you combine that background with managerial know-how, like seeing the big picture and understanding how things work on the business end, you become a major asset to the teams you work with.
I thought about this a lot when I was considering the switch to management. My initial problem was not having this managerial experience and not knowing many things when it came to delegation and project management. So, I had to find a way to gain that experience.
I took a risk
I saw my opportunity while working as a contractor on Upwork (oDesk at the time). I found a client whose vision for the project was too large for one person alone, so I made him an offer. I suggested taking the money he would pay me and letting me invest it in a small team of engineers who I would manage for free.
I was able to do this because, by this point, I was an experienced engineer with many skills. I worked as a:
- Frontend engineer
- Backend engineer
- And QA engineer
- As well as a designer and business analyst
So, I’d made good money and could afford to divide this project’s pay among a small team. As a result, I ended up not being paid for a while because it took time for me to feel comfortable enough as a manager to ask for a full salary.
This also worked for me because I knew what I was getting into. Not everyone can forgo their salary like me, but leveling up always demands something from you.
At the very least, you’ll give up your comfort zone. I gave up a clear, predictable path as an engineer and stepped into a world with more responsibility and less certainty. But this was the space where I learned what I needed to know.
I learned surprising things during the transition
The shift into management tested me in ways I wasn’t expecting. But this allowed me to learn things that I would never have understood without throwing myself into the deep end.
You never know as much as others think you do
Managing teams under deadlines with limited resources can feel like driving down a foggy highway without high beams. Your visibility is reduced, but you still have to drive fast to get where you need to go on time. This means:
- Being on high alert
- Focusing on the bit of road just in front of you
- And praying nothing unexpected appears out of the dark
Surprisingly, your worry about all of this doesn’t show on the outside as much as you think it does.
Your team members usually think you have everything under control. I quickly realized I was the only one who understood how precarious things felt sometimes. Which is a good thing since you want your team working in as calm and confident of a state as possible.
You have to lean on yourself now
As an engineer, you have others to report to. This includes, for example, a project manager (PM) who:
- Assigns you tasks
- Gives you deadlines
- And tells you what you should be working towards
This creates a predictable rhythm, allowing us to focus on our work without needing to think about the bigger picture.
When you become a manager, this changes. When I started managing a team, I was the one who had to decide who did what and how long it should take. I had to translate our long-term goals into steps my team members could act on. I didn’t have anyone else in the company to lean on, and so learned by trial and error.
But you also need to get out of your team’s way
It was easy to think that effective management meant micromanagement. This came from my belief that my team’s output was dependent on the energy I put in. So I tried to:
- Be everywhere at once
- Check in on everyone
- And step in to finish tasks when someone fell short
This was just a quick path to burnout and frustration, though. Eventually, I realized I had to get out of people’s way. After all, I’d hired them for what they brought to the table, so I needed to trust them to use it!
Once I set up a system where team members knew their tasks and responsibilities and could work independently, everything started running like clockwork. The first time I saw this happen, it gave me a rush I hadn’t felt before, and I never went back to my old way of doing things.
So much depends on who you hire
By the time I was ready to request a full management salary, I had built a team from the ground up. But more than that, I understood how to work through a team to do more than I could ever have done alone.
Looking back at it now, I had two major realizations from the process.
The first is that so much depends on the people you hire.
Even if you’re new to management and don’t feel entirely comfortable yet, you’re going to do fine if you have a good team. If your team members can learn quickly and work independently, you’ll find they can pick up the slack. I can’t affirm enough how important good onboarding is.
And whether or not you actually manage well
The second sounds paradoxically like the reverse of the first realization: even if you don’t have the best team, you can make up for it by being a great manager.
I think about the book “Extreme Ownership” by Jocko Willink. He described navy SEALs and the training they undergo. This included a competition where teams of six, each with a leader, carried heavy boats uphill. They did an experiment where they took the best and worst performing teams and switched their leaders.
They found that the losing team, accompanied by the best-performing leader, improved so much that they finished right after the winning team. It’s a fantastic illustration of how leadership can turn things around, and I’ve seen examples of this time and time again.
The short version: I hope my story guides yours
I believe it’s important for EMs to share the story of how they transitioned from engineering into management. After all, everyone has a slightly different one. And understanding how some have walked that path can help others decide if it’s right for them.
My own story looked like this:
- I wanted to stand out: combining management with deep technical experience helps us stay relevant in a changing marketplace
- I created the opportunity for myself by taking a risk: I temporarily gave up my salary to pay a small team and gain management experience
- I was surprised by some things I learned: I soon learned that managers have to make decisions with limited certainty, don’t have someone to fall back on, and are aided by having good systems in place, among other things
None of this was easy, but when I came out the other side, I was able to do far more at work than I did as an engineer. This happened when I realized I didn’t have to do everything on my own but could instead leverage my team’s abilities so that we could build something great together.
It’s been amazing ever since.
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com
Content in this blog post by Alex Ponomarev is licensed under CC BY 4.0.
