SDE or Manager? Things To Know Before Making The Switch

Are you a Software Development Engineer (SDE) thinking about transitioning to a management role? This is the article for you. Learn about my experience moving from an SDE to manager, then back to SDE.

Many SDEs (sometimes called ICs or Independent Contributors) at some point in their career contemplate management. This usually happens 5 years or so into your career where you have to decide between doubling down on learning tech, or switching to a new career path.

As an SDE 3 at Amazon, I recently faced this decision and dove into the Management role. It was a challenging decision, but the experience was rewarding in multiple ways. Eventually, I found that the role wasn’t for me and moved back into the SDE/IC path.

Not surprisingly, I’ve had many SDEs approach me recently asking for advice on switching to management. Many are looking for understanding what the role looks like, what I enjoyed and didn’t enjoy, and what the average manager day comprises of. For this reason, I decided to write this article to articulate my thoughts and pass on some insight to folks facing the difficult decision: SDE or Manager? I’m going to share what the Manager’s day to day looks like and tips on how to make this career change decision.

Much of this article is going to be about my experience itself. However there is much to draw from and I’m sure you’ll be able to relate. We’re going to cover the following areas:

  1. Backstory – My Career Path and Skillset
  2. The Big Question – Do You Want To Be a Manager?
  3. Fully Submerging Myself Into the Manager Role
  4. Do I Really Like Being a Manager? Pros and Cons
  5. The Inflection Point
  6. Transition Back to SDE/IC
  7. Retrospective and Closing Thoughts

So that’s what we’re in for. Lets get into it.

Backstory – My Career and Skill-set

Before becoming a Manager, I was a newly promoted Senior SDE at Amazon. I’ve always had a deep appreciation for technology including software. My personal satisfaction came from learning about tech, implementation, and sharing my knowledge with others.

Naturally, my love for teaching led to the development of communication and people skills. This is typically a less common skillset for SDEs. In my experience, most SDEs I’ve met have been on the quieter side. After all, most of us came from a science/math/engineering background which tend to attract a more nerdy, quieter audience.

I on the other hand had a good mix of technical and communication skills. This made my future transition into a management role much smoother.

My Original Reasons For Wanting to Become a Manager

Since around 2018 I had always expressed an interest in becoming a manager, or atleast trying out the role. I felt there was a sense of prestige and power that Managers, Directors, and VPs had. It seemed like a good future career path for me. I just felt it was more desirable to be a VP over a Distinguished Engineer.

The Big Question – Do You Want To Be a Manager?

About a year and a half ago I was asked to change teams temporarily to help out another team in need. They had lost a bunch of SDEs and were left with just two SDEs managing half a dozen Tier-1 services. Myself and another SDE jumped on board and I immediately started putting in the work to rebuild. This included establishing standard processes like sprint planning, SDE mentorship, knowledge transfer sessions, tech talks, and more. The team didn’t have a manager at the time so all these processes were basically non-existent.

Concurrently, I was digging deep into the tech and the team’s function in the org and uncovering a different set of problems. I quickly realized the team simply didn’t have the right resources to efficiently support customers and develop new features/systems. Bandwidth was already stretched and assisting customers with inquiries was eating into dev time. Features got delayed.

I moved quickly to change things up a bit. We put together external facing documentation. We established office hours. I organized our roadmap to ensure we were working on the right things at the right time. I raised concerns with leadership. I started meeting with and mentoring the team’s SDEs. I naturally slipped into kind of a leader role for the team.

And then my manager herself noticed and approached me. She had asked me if I was interested in becoming a Software Development Manager (SDM) for the team. I knew I had thoughts on becoming a manager in the past. I had kind of walked into the role and started acting as the team’s lead to help stabilize things. A side affect was building all these processes a manager typically would, right?

But was I capable? Could I handle talking regularly to VPs, SVPs and possibly higher up in the future? Did I have the right business judgement? Was I good enough of a writer? I thought about all these things.

Eventually, I decided to take the plunge and go for it. I realized it was a safe opportunity to fail. If I didn’t like the role, I could easily transition back into the SDE role with minimal career impact.

The Transition Process

The transition process was a relatively smooth one. At one point I was concerned that after working with these people as peers, it might become weird to starting acting as their official manager. I got over this really quickly and I think my peers did to.

At Amazon, you have excellent access to learning resources during role changes. Since the SDE to SDM path was a fairly common one, I was lucky to have access to over 40 hours of video training content for aspiring managers. Some may find this stuff boring but I was legitimately interested. I started thinking explicitly about things such as team culture building and what it takes to build a great team. I never directly thought of these things before… the results just kind of… happened.

At some point I started looking for training material again. I found one of the most useful management resources books that I know of. Its called Managing the Unmanageable by Ron Lichty and Micky Mantle. I swear this book is by a former Amazonian. It was critical in me understanding what it means to be a manager and how to approach the manager role.

Managing the Unmanageable – an excellent resource for aspiring and current managers in software organizations.

You can pick it up on Amazon here.

Do I Really Like Being a Manager? Pros and Cons

There are a great number of both positives and negatives to being a manager. One key thing I quickly realized is that management is an entirely different career path. Sure you’re around tech, but you’re not necessarily the tech expert on your team anymore-you must defer to others.

You don’t have time to devote long sessions pouring over a code base. You need to embrace interruptions and learn to drop everything on a whim if you need to. One other big adjustment is getting used to meetings – lots of meetings. These can range from personal mentorship, to priority planning, organization, stakeholder management, and many many more. You’re not really flexing your tech skills in these meetings either – its more about communication and working with people. This alone took some time to adjust to.

At the same time, you are responsible for everything about your system but have limited power in making tech decisions. For this, you need to defer to your SDEs to scope, suggest, and implement features. You have to learn to achieve through others and enable productivity while tearing down roadblocks.

You as the leader set the culture. This can be an easy-going culture where folks build strong relationships, or a more professional looking working culture. You get to decide. In my own experience, I found it was best to build a relaxed but technically focused engineering culture devoted to group think and improvement. Even for small projects, I’d ask the team to create mini-design documents. This has multiple benefits including spreading knowledge and preventing silos, getting group feedback, and encouraging the growth of SDE communication/writing skills. Smaller things such as regular team lunches, or giving someone a half day off if they got paged in the middle of the night set the team up for success. Little things like these examples helped create bonding and establish a good working culture.

The above are some of my most notable responsibilities of being a manager. Below are some concise Pros and Cons of the role.

Pros of Being a Manager – In My Opinion

  • Mentoring and Developing the career of others – Much of your time is spent in 1:1 meetings with your SDEs. I found it was best to mix this time with getting to know eachother and technical talk. Its typical to meet your SDEs 1:1 once every two weeks. You provide feedback on how they’re doing, how they can improve, and what they’re doing well. This is all constructive criticism and should be communicated not as an attack on the person, but as a suggestion for personal growth.
  • Control Over the Tech Roadmap – You get to decide what your team works on. This is important since defining priorities is critical for team’s success. Neglect Operational Tasks too long and get burned by an outage. Focus too much on OE and hamstring your delivery. Its a critical balance of features and maintenance while also giving your SDEs project to grow and develop. It was nice being the final decision maker in this process.
  • Develop the Team Culture – Things like requiring collaboration, frequent design reviews, code reviews, sprint planning and others practices are the result of team culture. As a manager, you get to influence what that culture looks like.
  • Watching the Team Deliver – This is the most rewarding part about being a manager – seeing your team successfully deliver. Although you’re not doing the low level work yourself, you still get a great sense of team accomplishment. A big part of this is also celebrating your teams successes, and learning from failures.

Cons of Being a Manager – In My Opinion

  • Meetings Meetings and More Meetings! – Being so involved and participating in meetings was one of the reasons I didn’t enjoy staying a manager. Since the manager role is about people management, it makes sense most of your time is spent listening or talking to others. This may not sound bad, but sitting in meetings all day while actively listening exhausts you by 5pm. I enjoyed the big blocks of time I would get as an SDE to work on my projects. Sadly, blocks of free time was relatively rare for me to stumble upon. I had to resort to deliberately blocking off chunks of time in my calendar to avoid meeting ovelroad.
  • Lose Touch of Tech – Since you’re no longer in the weeds implementing features, you tend to lose touch of the tech. For me, this was really sad. As you can tell by my blog and youtube, tech is a big part of my life. The idea of not having enough time to actively learn while on the job really sucked. This con played a big role in transitioning back to SDE path.
  • Responsible but Powerless – A manager is as only as good as their team. As the manager, you are responsible for the teams delivery, but can’t do the work yourself. Since you’re achieving through others, it can be frustrating seeing a project get delayed due to things out of your control.
  • Lack of Feelings of Accomplishment – This is a big one for me. You know those euphoric moments you feel when you’re debugging a problem for hours and finally crack it open? I missed that a lot being a manager. You do accomplish things as a manager – but they honestly feel less significant and rewarding. Maybe its just me, but having a successful review of a planning document pales in comparison to small and large successes during development.

So that’s overall what I think of the manager role. Things were going well for me during my entire time as a manager. However I had this itching desire to get back into the tech side of things. Eventually this hit a tipping point as I describe in the next section.

The Inflection Point

One of the many roles of being a manager is to facilitate conversations with the SDEs under you and other teams. It was what followed after attending one of these meetings that changed my career trajectory forever.

This meeting had to do with a rearchitecture project. My team was leading a move to eliminate a inflexible and narrow feature in favour of one that was used throughout the company. As one of our most business critical clients that used our legacy systems, adoption was crucial. My SDE and their SDE chatted during these means explaining and understanding the major changes. Next steps being clearly understood.

It quickly became apparent that things weren’t understood by the client. There were follow up meetings–many follow up meetings. Sometimes clarifying a key concept, other times making sure their config was setup properly. It felt endless. As a manager, I had a good understanding of how the solution flow would look, but the devil was in the details. And as a manager, discussing low level implementation details were beyond my job description.

I kept asking to myself during these meetings. Why does this keep happening? Why do they not get it? Is it me? Do I not understand it well enough? Are we not explaining the concepts right? Whats going on here?

And so I did something I hadn’t done in a long time. I pulled out a sheet of paper and started drawing a flow diagram. I laid out the systems at play – the legacy system, and the new system to replace it. I connected services between services with APIs and documented the data flow. I …. was right back into it.

And at a certain point something happened. Something clicked. A sheer feeling of enjoyment that is difficult to describe. If I can best describe it, it’s the feeling you get after facing a frustrating problem and grinding through it for hours and hours before finally discovering the solution. Pure satisfaction – like you’re the king of the world.

I found that I had more mental stimulation and exhilaration in that 30 minute exercise than I had in the past week combined. I thought more and realized how much I missed getting your hands dirty in the tech and problem solving complicated problems. This was the inflection point that made me realize the manager path maybe wasn’t for me.

I dwelled on this thought for a while weighing the pros and cons of each role. I eventually realized that I receive more personal satisfaction solving problems in the tech space than in the management role. And if we don’t enjoy what we work on, what’s this all for?

Transition Back to SDE/IC

Since my foray into the Manager role was just a trial period, transitioning back to the SDE 3 role was pretty seamless. I ended up staying on the same team I was managing, but now as an IC. I had originally worried if things would be awkward between my peers but it never turned out that way. Lucky me.

If you’re afraid of the potential awkwardness you may want to consider transitioning to a different team. This would give you a fresh slate without any team baggage.

Retrospective and Closing Thoughts

I don’t regret for a moment my decision to try out the manager role. I learned a lot about what the role entails and the business of the job. My communication and people skills also greatly improved during this time (I guess all the meetings had some benefit, after all).

I also started to anticipate questions as an SDE from my Manager and understand why he was it. A manager is approaching things from an organizational and resource mindset, so sometimes it helps to cater your answers with that in mind.

The most valuable part of becoming a manager was learning that it wasn’t for me. I’m a firm believer that if you don’t try something, you’ll never know if you’ll enjoy it. Now atleast, I can cross off being a manager from my TODO list.

Total
0
Shares
Leave a Reply

Your email address will not be published.