Software Engineering to Management: What got you here won't get you there

Years ago, I joined a solo founder of a software startup. I was the first engineer. It was an exciting time. We had no team and no product to sell. My job was to learn the domain (capital markets) and build the software. That’s it. No extra meetings or distractions. We worked out of the mailroom of our first client. I was learning a lot about FinTech and building new things all the time. 

Months later, we launched our product, got our first customers on it, hired engineers, and my job was different. Little by little, my job changed from an engineer building software to an engineering manager building a software team, a customer success manager working with customers, and a product manager figuring out what to build. Throughout all this, there wasn’t much time left to code anymore; and I learned to live with it. My transition was slow and organic. It was what I wanted. 

Many engineers don’t have that luxury. One day, you’re an engineer, and the next day, you are promoted and are a Team Lead or a Manager. After the initial excitement subsides, there are several key differences that you’ll need to be aware of and ready for:

1. You are a people manager: Many managers don't truly appreciate their "management" title is not a "project manager", or a "product manager" or "program manager" but a "people manager". That's usually the first time they need to get things done through people instead of doing it themselves. This reality usually "clicks" much later than it should, which can lead to months or years of stress, dissatisfaction, lost engagement and productivity for themselves and their team.

1. You are responsible to your team and responsible for your team: You were likely promoted because you were one of the best individual contributors (IC) on your team. It’s fair to think that you could probably build things faster and better and it may be true. (It would be harder if you were not a great IC because your team would not give you the respect you may need). But as a manager, your main job is not to build software anymore. Your job is to enable your team to build better.

   Good managers take the time to coach, empower, and educate their team even if it takes longer to build that way. This is a skill that most engineers aren’t trained for. I certainly wasn’t. When one of our key projects was delayed, I took over the coding and delivered the project in a week. I was very proud of my accomplishment. About a month later, we lost the team member who was working on the project. In hindsight, I wouldn’t want a manager who diminishes me either!

2. Your team’s success is your success: You need to be comfortable with having built much less at the end of the day. As a manager, you design, attend meetings, manage projects, coach team members, handle personnel issues, interview candidates, review code, and a lot more. It’s not just coding anymore. When I was an engineer building code every day, I used to take pride in having built new features regularly. As a manager, I’d be lucky if I find half a day during work hours to create something new. My first responsibility is to get things done and the best (long-term) way to do it is to enable our engineers to build and pave their path. Personally, I have nothing to show anymore except for what our team has done. Their success is my success.

3. You unlearn old lessons: The role you play as a manager is very different from the role you play as an engineer. Your responsibilities and performance metrics change greatly, especially if you skipped the Team Lead step in your career. The same thing that would have made out an excellent team member may now hurt the team and your relationships (see my example above). You need to change gears. So you need to unlearn as much as you need to learn. This transition is extremely hard and doesn’t come easily to most people. Adam Grant’s “Think Again” and  Marshal Goldsmith’s “What got you here, won’t get you there” are great reads that dive deeper into this.

   We still see many engineers become managers without any training, mindset adjustment, or any proper prep for this new role, especially if it's an internal promotion. One day, they come to work, and they have direct reports, 1-1s, performance conversations, etc. Engineers are smart. They can learn on the job. The only problem is that learning on the job means that they will be a bad manager for their team for a while. Their engineers will suffer.

   Thankfully, “manager training” has become highly in demand, and many managers are offered coaching by their companies to adjust to the changes. First-time managers are a large number of thousands of people we coach at Sayge and it has been growing.

4. You negotiate for your team: You are now "middle-management". Congratulations! You sit between the executives and your team. Don’t let the executives set the timeline, especially if they have an engineering background. This gets worse if they coded sometime in the early days. Executives drastically underestimate the work, which is understandable; they probably haven’t considered builds, automated tests, refactoring, debt payback, edge cases, interplay with other modules, dependencies, and many other factors.

   Executives and product managers can set priorities. The only authority who can estimate the work is the development team (and they’ll be wrong; But that’s a whole other article). Your job is to enable the team to get the most important things done as fast as possible (but not too fast. Otherwise, you’ll be spending a good amount of your time replacing your engineers who burn out or quit).

5. You accommodate your team: There’s a good chance that people who opt for management roles want more people interactions in their roles. I’m an extrovert. I enjoy interacting with others. Many engineers don’t. Also, building major features needs attention and focus. If you haven’t read Maker’s Schedule Manager’s Schedule, read it now. Establish your communication preferences, frequency, and channel early on. This one is a difficult balance to find.

6. Your challenges are different. They don’t disappear: Many senior engineers face more and more challenges as they work on more important projects. From a distance, a manager’s job may seem easier. After all, they don’t build much. How hard can that be?

   Management can be very challenging and potentially less fulfilling and rewarding. But the challenges can be different. The question is if you prefer the kinds of challenges managers deal with. If there were no challenges, the job wouldn’t exist in the first place. 

7. You only become a manager if you want to manage people: Many young engineers think management is the only way to increase their compensation or impact. It was true probably a decade ago. Thanks to many leading companies, most engineers can grow in individual contributor capacity or management. There are many changes when going from engineer to manager. Compensation doesn’t have to be one. Many companies allow you to go up the ranks as an IC. See below for a sample “leveling” used for compensation at GitLab. Most other tech companies today are similar.

Lastly, you can go back to engineering: After some time in management, if you realize you don’t enjoy it as much as you enjoyed engineering, you can go back. It may lead to a better work-life for you and better results for everyone involved. It happens a lot. The choice between individual contributors or management is a completely personal choice. 

If you are a people manager in tech, I’d love to learn about your journey. What did I get wrong? What would you add or change?