How I knew that going from engineering was right for me (and quick tips to figure it out)
Tags: leadership, career, engineering, management
Published: 2022-07-28 08:55:08

At some point, when engineers reach a level of seniority, they become curious about management. I am convinced that every individual contributor arrives at the point of getting larger-than-oneself ideas and wanting to use the insight they accumulated through technical work to lead teams. 

For years, management seemed a logical next step for a developer’s career, up to the point of a strongly-held belief that getting a manager’s title is a “promotion”. Only after having made an engineer-manager transition myself, I am confident this is false.

When you are a manager, you stop being an active contributor or have to cut your workload and give up challenging tasks. Over time, you might discover your coding skills have deteriorated and realize you are behind on tech trends and best practices. 

At the same time, I believe that transitioning into management is the right move for a fair share of developers - this was definitely the case for me. It’s been over a year since I accepted a management position at [oVice](https://ovice.in/) - a remote-first company that supports remote and hybrid teams with collaborative virtual office spaces. 

In this post, I’d like to share a few pointers that will help you understand whether a career path in management is the right one for you. 

## Dip your toes before you dive in 

In my career as a developer and a manager, I’ve seen several reasons why people make the transition from an individual contributor (IC) to an engineering manager (EM): 

- Team leaders present the new opportunity as a raise and offer a higher paycheck (a huge organizational mistake since skilled engineers are as important as managers). 
- Working as a contributor isn’t stimulated enough and engineers want to try something new. 
- ICs start questioning their managers and feel like they can (and should) do a better job. 
- An urgent position opens and an engineer decides to fill it in as a favor. 
- The opportunity to switch the business side (for people who were not too passionate about coding). 
- Being a manager and having a team report to you stroke an engineer’s ego.

Then, once they made the decision, engineers often discover the not-so-glamorous side of management: constant stress, interruptions, back-to-back meeting, and no feeling of control (the opposite of what you could’ve expected). Before they know it, they hate the job and regret their decision. 

If you want to get rid of the weight of regret, I recommend testing the waters first - take up a few manager-like responsibilities within your IC role or get a position on the edge between coding and management.

Here are a few low-effort ways to try management without committing to an EM role right away: 

- **Mentor junior developers and oversee their career growth**. This way, you will discover if constant communication, teaching, and the need to answer questions are not putting too much stress on you. 
- **Work as a tech lead**. While tech leads and EMs have somewhat similar responsibilities - communicating strategies to the team, helping developers prioritize tasks, and contributing to developer training, tech leads are more involved in the nitty-gritty of development. They oversee code reviews, introduce development practices, even code themselves. By getting into management as a tech lead, you will see which between the two (hands-on programming and dealing with people) you gravitate to and make an informed decision. 
- **Shadow an engineering manager**. It’s a simple but effective way to see if are ready to commit to an EM role. Shadowing a manager at your organization for a few weeks should give you an idea of the workload, amount of stress, and typical responsibilities. 

Let’s suppose you tried all of the above and are still not sure which way to go. What I did in this situation was a round of introspection - understanding what I like about engineering and management and the challenges I might face both ways. 

## Pros and cons of staying an IC

These are the things I took into consideration when making my decision. They might not be universally applicable so I recommend doing the same analysis with the specifics of your job and company in mind. 

I assigned a score to the benefits benefit of working both as a manager and as an individual contributor so that I can see which way the pendulum swings. 

## Benefits of staying an engineer

**Broader job market**
The numbers speak for themselves - there are 68,382 “senior software engineer” job openings on Indeed compared to 32,875 open engineering management positions. If I stayed as an IC, I would’ve had higher job security. 

_Personal relevance: 2/5_
I am not highly driven by job security - in my opinion, as a skilled EM I should still be able to find a job even in a smaller pool of opportunities. 

**Following technical trends and improving coding skills** 
I like to think of engineering management vs individual contribution as an intersection - at one time, you can either go one way or another. Eventually, you can come back and go the other way, but it will be too stressful to do both jobs well at the same time. 

I knew that, if I flip a switch and transition to management, I will have to focus on improving in leadership, communication, and strategy - much less on technical problem solving or architecture design. Thus, it was obvious I wouldn’t be top of the market in programming like my colleagues who committed to coding. 

_Personal relevance: 4/5_ 
Deciding to slow my progress in software development down was not easy. I found solace in the fact that understanding the bigger picture will make me a better professional even if I come back to an IC role. 

I still see the work my colleagues are doing and absorb some knowledge by passive diffusion. I still do my best to follow the latest industry trends. At the same time, I understand that alone is not enough. 

I understand I will be behind if I decide to come back but I am confident that having a backbone in leadership and a 360-degree view of a project will help me focus on the “why”, not only the “how” of coding if I am back to engineering. 

**Sense of accomplishment**
Working directly with the codebase gave me a lot of fulfillment. It is satisfying to finally ship a feature, solve a difficult problem, or fix an error no one else could figure out. That thrill is the backbone of software engineering but it is not as applicable in management. 

Engineering management is a team sport, which means you are responsible for everyone’s success. There’s no way to remove yourself from organizational issues by telling yourself “Well, I’ve done my job”. There’s no sense of short-term accomplishment either - you can oversee plans and strategies that will pay off in months or years. Everything in between will be uncertainty and trying to convince your and other teams that your strategy will work - even though you are never 100% sure. 

_Personal relevance: 3/5_
Even as an engineer, I got little satisfaction from just doing my part of the job well. I would get invested in what happens to my code, the part it plays in the product, and the way it benefits the end-user. I didn’t feel a ton of joy from shipping a feature if I didn’t understand how it benefits the project in the long run. That’s why, when I switched to management, I enjoy the ability to see things through and no longer be restricted by my scope. 

**Total: 9/15**

## Benefits of transitioning to management 

**Working with the “why” of technical work** 
As an engineer, I often felt restricted in my focus. There were a lot of technical details to keep in mind whereas what actually interested me was how to work more efficiently and meaningfully. When I was given a task, I would often find faster or cheaper ways to arrive at the same outcome - but making these decisions wasn’t always up to me. 

Now that I am in the management role, I am involved in important conversations and strategic decisions on budgeting, product development, marketing, and sales. My view of the project became broader and I got to talk to end-users, experience their struggles and receive feedback on the product face-to-face. 

_Personal relevance: 5/5_
The ability to clearly see how the project impacts the market and helps companies is the most fulfilling part of my work. I am grateful when [clients share testimonials](https://resources.ovice.in/use-cases/) about how a virtual office platform improved their approach to remote and hybrid work, and being in management gave me access to this proximity. 

**Connecting with more people**
Constant [synchronous and asynchronous communication](https://resources.ovice.in/blog/remote-synchronous-asynchronous-communication/) with colleagues is the key to successful management. Although I chose a technical path, I always liked connecting with people and kept doing this through a range of part-time jobs - I worked as a barista, a secondary school PE teacher, and so on. 

Engineering has a strong communication component (a good developer is a team player) but it still revolves around focusing on the task at hand. Meanwhile, management is communication. You get to connect with your team and other teams, other department leaders, clients, partners, and investors - you name it. 

In my career in management, I’ve met dozens of people from all over the world. Connecting with them on a daily or weekly basis is a highly rewarding part of my work. 

_Personal relevance: 4/5_ 
Developing communication and leadership skills, as well as defining and communicating the company’s strategic vision was always interesting to me. 

At the same time, management comes with a lot of responsibility, especially that of handling my teammates’ careers and making sure they have a work-life balance, feel appreciated, and fulfilled at work. That’s why I believe that, in management, mistakes come at a higher cost than in coding, because teammates are the variables you are working with. 

Committing to that responsibility was (and is) stressful but the ability to connect with people from different cultures and backgrounds tipped the scale in favor of management. 

**Learning new skills and becoming an all-rounder** 
As a developer, I was mainly concerned about making progress in my field, rarely taking the time to see what marketers, salespeople, or HR professionals are doing. I knew, that once I switch to management, I will have to understand all the processes within the organization, and was excited to step up to the challenge. 

As a manager, I have to work closely with HR to communicate hiring needs and participate in candidate selection. I am highly connected with the marketing team, helping them streamline operations, set up processes, and address concerns. I am involved in the activities of the product team, as well as those of the sales department. I also represent the company externally, attending events, and connecting with investors or prospective clients. 

_Personal relevance 3/5_
A part of me is worried about not picking up new coding skills when working in management. Also, I have to accept the challenges I haven’t worked with before - that is stressful. At the same time, I realize I would never have learned as much about communication, marketing, product design, talent management, or budgeting had it not been for the transition. That’s why I am happy with the choice and wouldn’t take it back. 

**Total: 12/15**

After analyzing the benefits of both approaches, I realized I would get more from working in management. That’s why I decided to accept the offer to transition and committed to my current position: Global Operations Manager. 

## Fast-forward: my observations after working as a manager for almost 2 years

I took the Operations Manager position in 2020. Since then, I’ve firsthand experienced the positives and negatives of management and have a rough idea of what can make an engineer fit for the transition. 

**Switching to management will be good for you if you:** 

- Have a strong vision and feel restricted by having to focus on coding alone
- Enjoy communication and don’t mind having a day full of meetings 
- Don’t require a quiet focused environment for work and are okay with interruptions and controlled chaos 
- Want to dive deeper into the business side of product design. 
- Always look for ways to improve processes for yourself and the team, love trying different [collaboration tools](https://resources.ovice.in/blog/collaboration-tools-to-try/) and methodologies. 

**Staying an individual contributor is a better fit if you:** 

- Enjoy the accomplishment that comes with accomplishing personal tasks
- Love the technical aspect of engineering more than the business side 
- Are uncomfortable with “information processing tasks”: documentation, reports, presentations 
- Feel pressured by long-term planning and having to make large-scale decisions and would rather focus on practical tasks 

I’ll finish this by saying that, if it looks like a manager in your company is doing nothing, they might actually be excellent at their work. I’ve discovered that the ability to filter the background noise and help teams focus on their tasks is what separates excellent leaders from mediocre ones - that’s the point I am trying to reach in my career. 

So, if it feels like working in management is not a big deal, chances are your team leader is making it look easy. On the other hand, if you feel drawn to the field despite the constant stress, incessant impostor syndrome, and never-ending flow of tasks, going into management might be an excellent step in your career.