Leading Tech People or Remaining a Software Engineer: What to Choose? Panel Discussion

Introduction

Sooner or later, software engineers come to a point in their careers where they can make their move into management positions. It could be a tech lead position, team leader, development manager, (senior) architect, staff plus engineer, or another position where they become responsible for managing tech people. One question senior tech people ask themselves is:shall I go into management, or do I want to stay in a tech position?

Going into a management position feels like leaving tech, where you have to stop doing what you're good at and happy doing it. It can feel uncomfortable making a move to management. It will impact the relationship that you have with your colleagues, both with other engineers and with the managers in your company. This can make you question as an engineer, shall I do it, or would I prefer to stay in my tech role?

In this virtual panel, we'll discuss what made people decide to become a leader and how they did it. And we'll find out if we really have to leave tech forever or if there's a way back into engineering.

The panelists:

• Shawna Martell, Senior Staff Engineer @Carta
• Peter Gillard-Moss, Senior Engineering Manager @DeepL
• Brittany Woods, Senior Engineering Manager @ The LEGO Group

InfoQ: What made you decide to become a tech leader, was there anything when you were still an engineer that made you aspire to become a leader or made you feel ready for it?

Shawna Martell: When I first started in tech almost twenty years ago, I only knew of one type of leadership role, and that was people management. I didn’t hear about an "individual contributor (IC) career track" until I’d been working for more than ten years, and by then, I’d been a people manager twice. If I’d known there were other options, I might have taken a different path.

Management is an important and valuable form of leadership. I won’t pretend I’ve ever felt "ready" for management or leadership. That’s imposter syndrome for you. When I was offered my first management role, I was very hesitant. What finally convinced me was my manager’s encouragement. Further proof of how important good managers are for any organization.

But management and leadership aren’t synonyms. I’m a leader now, as a Senior Staff Engineer, but I’m not a manager. I didn’t feel ready to take on the leadership role of Senior Staff Engineer either, but again I was fortunate to be surrounded by people who encouraged me and offered to support me.

I’ve taken every leadership role because people I trusted encouraged me to do it. I’ve stayed in leadership because it turns out to be work I really love.

Leaders are organizers and cheerleaders and visionaries. They use their influence to make the people around them better.

Peter Gillard-Moss: There wasn't one reason. Early on it was a combination of seeing this as career progression and feeling I would do a good job (so you could say ego?). The third time I was reluctant and it was because someone saw my potential and encouraged me to do it. 

My first two changes in leadership weren't successful. I was about to give up the third time when I got a good coach who turned things around for me.

Brittany Woods: One of the most fulfilling parts of being a lead engineer, for me, was building others up around me and thinking about problems not from a technical lens, but from the lens of how does this fit into the bigger picture. At this stage, I was also already developing roadmaps and presenting and coordinating projects to senior leadership so I felt ready for the next step at least in that regard as well.

InfoQ: What skills or qualities that you already had as an engineer helped you to become a manager or tech leader, and what was missing that you developed along the way?

Shawna Martell: My first role where leadership was part of my job description was a "hybrid role", what a lot of places call a Tech Lead Manager. I was still responsible for engineering tasks, but I had a handful of direct reports, too. I’ve known these types of roles can be controversial, and I can understand why. It was easy for me to spend lots of time doing the technical work I’d been doing up until the change in title. There was a familiarity in the day-to-day of tickets and pull requests that I just didn’t have with the people management work.

My only prior management experience was... being managed by one. I hadn’t taken any management courses in school. I think my path is how a lot of people end up in management: I was a high performing engineer and a management position was available. I was already leading my team’s day-to-day work and assigning tasks, so adding the additional people management responsibilities was a logical next step.

What I lacked was an understanding of how to deal with the personnel challenges of leadership. How do you help solve interpersonal issues, not just technical problems? I sought a lot of support from my manager, and I read so many books. These days I recommend Creating Magic: 10 Common Sense Leadership Strategies from a Life at Disney and The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change for new or aspiring managers.

A few years into my second stint as a manager, I was an aspiring Director, and I knew that there were going to be business and finance concepts in a director role that my MS in Computer Science wasn’t going to help me understand. So I decided to go back to school for my MBA. I don’t think everyone in leadership needs to go to business school, but I’m very glad I did. Even now that I have moved back into an individual contributor role, the marketing, branding, and finance concepts I learned doing my MBA have proven very valuable.

Peter Gillard-Moss: Great engineers and leaders have three things in common: they are good communicators, know how to design things to make them simple and are great at diagnosing problems. This is what engineers do every single day in code. How do I make the intent of this code clear? How do I make sure that the value this method brings can operate independently from the value this other method brings? How do I rapidly zoom in and out from an incorrect behavior at a system level to the check-in which caused it?

When you become a manager these are your strengths and give you a real advantage. You just have to apply them through a different lens. Are we communicating our intent as well as we communicate our code? Have we removed ambiguity? Does this team have a clear purpose? Is this delivery problem a one-off or part of a pattern?

What is usually missing is how to adapt those skills with humans. Once you have a good answer you don’t need to convince the computers you just give the instructions. The same is not true with humans.

Brittany Woods: I've always been a strong communicator with an ability to build relationships across the business. As a leader, this has been incredibly helpful as a portion of my day to day is building relationships with other teams or stakeholders. 

I mentioned before that I really enjoyed building others up. While I was an engineer, I found myself pretty consistently teaching others how to do things or taking on more mentorship roles in relationships with other engineers. This too is a great skill to have when moving into leadership because, in my opinion, it's no longer about you. It's about how you can help grow the people around you and your team.
 

InfoQ: What challenges did you face as a tech leader and how did you deal with them?

Shawna Martell: Imposter syndrome has been the biggest hurdle for me throughout my career. It makes me second-guess myself and that lack of confidence can be hard to mask. I’ve dealt with it by being very honest with others about it, and I’ve been amazed at how often I’ve encountered others with the same struggle.
 
Some of the people I hugely admire turn out to have imposter syndrome, too! Knowing you aren’t alone is a tremendous resource and tapping into that community when you need support can make all the difference.

Peter Gillard-Moss: As a tech leader you will need to work with people in other disciplines and get tech concerns included in decisions outside of engineering. A lot of organizations put tech in a box at the end of the process marked "delivery". Combine this with the fact that hanging around with engineers is in your comfort zone …

Yet, as the tech leader, you have accountability for things like quality and speed of change and scalability, which you have no direct control over because they are heavily affected by decisions made elsewhere by your colleagues in other disciplines (marketing, product, finance, design etc.). And we can get into the trap of blindly assuming that we have to work with those constraints and compromising in engineering alone. 

The only way to solve this is by bringing visibility into engineering so other people can collaborate with you to make better decisions. This doesn't mean talking about tech-debt, clean code, refactoring, etc. It means understanding what's important to them and helping them understand the trade-offs needed to meet their goals. This means starting with what you see as right and then negotiating compromises on both sides.

Alfred P Sloan's advice to a young Peter Drucker is relevant here: "My only instruction to you is to put down what you think is right as you see it. Don’t you worry about our reaction. Don’t you worry about whether we will like this or dislike that. And don’t you, above all, concern yourself with the compromises that might be needed to make your conclusions acceptable. There is not one executive in this company who does not know how to make every single conceivable compromise without any help from you. But he can’t make the right compromise unless you first tell him what right is."

Brittany Woods: As a woman in tech, and even more so as a woman leader in tech there's always challenges. I think one of the challenges that I've faced most commonly so far in my career is in ensuring I'm heard. 

I absolutely don't want to speak for every woman in tech as everyone has their own experience. But for me, I've noticed a tendency for others to try to speak over or dominate conversations - particularly when there are women trying to push a solution or idea. 

My remedy to that is to continuously remind myself that not only can I assert myself in conversations where needed and take up space as any other would, but I can also be mindful of keeping space for others. If anyone on my team is struggling to get a word in or has remained relatively quiet on a topic I know they want to have an opinion on, the simple act of asking them and making space for them to answer without others speaking over them has worked great. 

It's a small act that I wish someone had done for me, particularly when I was earlier in my career, that I make sure to do for my team now. So as a leader, I make sure to do this and would encourage any other leader to be mindful of others getting heard in conversation.

InfoQ: How do you lead high-performing tech teams, what specifically have you learned that works and doesn't work with teams in particular?

Shawna Martell: Thinking about this question with a management lens, high-performing teams need two things from their managers:

• Protection of their time to ensure they’re working on the right problems
• For others to get out of the way so they can solve those problems

There’s a great thing about high-performing teams - they’ll generally make just about any situation better. This is also one of the hardest things for high-performing teams, because you can’t have them work on everything.

High-performing teams are also usually staffed with helpful people. They want to make the people and situations around them better! It’s really great! It can also be a challenge, because everyone knows how helpful they are. They are likely to get pulled into lots of things, but just because they can help doesn’t mean they should. How do you decide what gets their time and attention?

Solving this is an art and not a science. As a manager, you can’t micromanage your teams hour by hour to ensure every minute is spent "correctly." You also shouldn’t just assume they’ll know which requests they can ignore or that other teams will value their time correctly.

What I’ve found works best is keeping up with their time in whatever way works best for everyone on the team. Whether that’s a weekly bullet list of the stuff getting their attention or updates in a weekly 1:1 meeting or maintaining a ticket board that shows their current and upcoming work. Inevitably something will come up that should be solved by someone else. Help them get those things off their lists as quickly as possible.

There’s not a lot of difference if you’re an IC leader on a high-performing team. You’ll likely have a better understanding of the day-to-day than the manager will, and guarding your team’s time is still going to be a top priority.

High-performing teams are also candidates for burnout. If their time isn’t well guarded, they may run themselves ragged trying to keep up with too many things. 

Your high-performing teams will be set up for success when they are deployed effectively and their time is guarded.

Peter Gillard-Moss: The most important thing is building trust. Once teams trust your intent, trust your judgment, and trust that you have their interests at heart, then you can build a high-performing team.

Without trust, you pull a lever and you think you are seeing results. So you pull that lever harder expecting even better results. Then, 6 months later, you realize that everytime you pull that level the team is actually going "hey, stop doing that, it really hurts". And because you are their leader and they don't want to upset you and they don't quite trust you, they resort to "managing up". Which basically means they'll start telling you what you want to hear to get you off their back. Because you are causing them pain and they worry if they tell you that you might do something to make it worse. Once that happens it's hard to come back from.

Brittany Woods: I have two things that I consider "the most important" when it comes to leading high performing tech teams. These two things are trust and transparency. 

I always make sure my team knows that I trust in their expertise, I trust in their knowledge of the business, and I trust that they will help get us to the right solution for the company. We hire engineers because we believe in their skills. To bring them in and dictate the steps they should follow for a solution, or worse to give them an already solved problem to check boxes, is an insult to their knowledge and experience. 

On transparency, I make sure I share everything that I can share with my team. This builds their trust in me, certainly, and it makes sure they have all the required details to make the best decision. From my position, I know there are things that cannot be shared, but if it's not sensitive and it's pertinent to the team's work, I share it.

InfoQ: Some engineers aspire a staff+ position where they can keep their technical edge and take on leadership responsibilities. What's your view on and experience with staff+ roles?

Shawna Martell: I’ve been a Staff+ Engineer now for almost three years. When an IC comes to talk to me and says they’re thinking about taking a Staff role, it’s an exciting conversation. In my experience, Staff roles are a paradigm shift in your career that’s different from moving from the "IC track" to the "management track".

My role as Senior Staff is a blend of what are often considered "people management" responsibilities and "engineering" responsibilities. I am involved in planning and strategy and product vision, things I did when I was a manager, as well as architecture and design and implementation (though I don’t do as much implementation as I did in previous IC roles).

I still do a lot of mentoring and work to grow engineers and managers, but I don’t write performance reviews or make headcount budgets or have direct reports.

Staff+ roles aren’t for everyone. It’s hard to find this type of position where you get to write lots of code all day. They exist, but they’re rare in my experience. For me, the type of leadership I get to do as a Senior Staff Engineer is my dream role. I am still involved in deep technical issues and problem-solving, but I also get to work to drive vision and strategy.

I encourage anyone who’s wondering if a Staff+ role is for them to check out Staff Engineer or staffeng.com by Will Larson. I read his book the week I started my job as Staff Engineer, and it made the transition much smoother for me.

Peter Gillard-Moss: Every single leader is going to be different. And people aren't static over their careers either.  We are not producing widgets with a list of features on a factory line. So we have to be cautious about creating processes that push people towards rigid roles and shapes.

Likewise the same is with teams. And the unit of performance is the team, not the individual. It's about building the right team and mix of talent where people can play to their strengths. One team might require a more technical leader. Other teams might need one who is better at stakeholder management. Another needs more product acumen.

On the individual level, when someone has real potential (whether as a leader or an IC), the goal is to find the right opportunity for them to increase their impact and learn faster. If that means, for them in their career right now, staying more technical is important, then how do you find a way to make it work? How do you work with their existing team or find a new opportunity elsewhere?

Brittany Woods: Personally, I think having a robust career progression framework for engineers is just as important as having a career progression framework for those that aspire to be people leaders. In fact, when more senior engineers express interest in progression, I always advise that they should take a look at the things that bring them fulfillment about their role. 

As I mentioned before, I find fulfillment building others up on the people side - and building the bigger picture on the tech side. So my question to engineers hoping to grow is do you find fulfillment in building up others, or is it in solving problems and getting your hands on the code? 

In many cases, the more you follow the people leadership path, the further you get away from getting your hands into the code and into the actual solutions to problems during your typical work day. For those that find fulfillment in that, I always recommend following the engineering progression path.

InfoQ: Have there been moments when the allure of returning to a technical role was particularly strong, and if so, how did you handle it?

Shawna Martell: I’ve made the swap from people management back to individual contributor twice in my career, most recently leaving a Director role to take my Staff role at Carta.
  
I used to think that I had to choose between a technical role and leadership, but it turns out I don’t. I didn’t fully internalize that until my job at Carta, where I found a role that lets me do both. I am incredibly fortunate to work for a company that gives me the autonomy to work on big projects like revamping our interview process or building out an engineering mentorship program while also architecting new systems. I know that’s not a privilege everyone enjoys, and I am grateful for it. 

What each of us finds joyful and fulfilling at work is different, and understanding what those things are for you is what’s important. You may try a few things that aren’t quite the right fit, like I did. I learned a lot in each career transition I’ve made, and each one was a step in the path to where I am today, doing a job I really love.

Peter Gillard-Moss: Yes, very often. I find alternative ways to get my fix. For example, I'm a big believer in practicing Genba, spending time with engineers observing what they do hands-on. It builds empathy and understanding and also gives me the thrill of working with tech hands-on.

Brittany Woods: For me I know I'm on the right path and I haven't felt the "itch" so to speak to go back into a more technical role. I think at this stage, I've been able to balance the need to remain technical with personal projects to keep my tech skills sharp while doing the things I enjoy. 

I can see how one would want to move back into a technical role, and I know many people who have gone from being a leader to an individual contributor and back again. I think it's all about balancing what is important to you and again, what brings you joy. It is okay for those things, the things that bring you joy, to change or transform over time.

Conclusions

Software engineers go into management positions when being asked or encouraged, or when the opportunity arises in their career and feel ready to take the step. They use skills that they already poses, like good communication abilities, experience in building relationships, knowing how to design something, and being able to solve problems.

The challenges encountered in the management position vary, from imposter syndrome, becoming accountable, to being heard as a woman leader in tech. 

Leaders can foster high-performing teams by giving them time and space to do their work, trust them, and be transparent by sharing what they have with them.

In a staff+ position you can keep your technical edge and take on leadership responsibilities. Staff+ might be a next step in your career as a senior software engineer, or a position to look out for when you want to move back to a technical role after having worked in a management position.