While I write a lot about management, I actually spent the majority of my career focused in non-management roles on writing software and designing products. In fact, I actively resisted moving into management.

For people in the software engineering field, one common topic is should I focus my career on a purely technical track or should I focus on a management track. Let me share a bit of my career journey. It will illustrate that the decision isn’t really a binary one. But can actually look a bit messy.

I got my start in computer science taking a programming class in 1976. It was a bit like programming in assembly language. I fell in love with the idea of writing beautiful code with the right algorithms to solve really hard problems. It led me to be one of the earliest game developers for the Macintosh (1985), build war game graphics systems for NATO & the Naval War College (1989-1992) as well as building Development Environments for Java(1999-2000), and writing one of the earliest JavaScript libraries (2004). I never got into this field to be a manager. I fell in love with coding and I generally felt sorry for my managers as I had the “keys to the kingdom”. I could solve the problems they presented. Sure they presented the problems, but without me and those who worked with me there could be no solution. So in those early years, there was absolutely no way that I wanted to be a manager. It was really anathema to me.

The first management role I took just sort of happened to me (1999; about 15 years after developing my first commercial product). We had some key projects that we needed to deliver and since I was seen as the technical leader, I was also given management responsibility for our small team of 4-5 engineers. The additional management responsibilities included hiring, career development and dealing with people issues. While there were some aspects of the new role I enjoyed, the chief concern I had was I was spending less and less time on the purely technical challenges that the project presented. I had entered the field because of the enchantment of coding, not the desire to be a manager. A few months in, my director of engineering made the statement that I should really consider the management track for my career as the feedback was very positive about my leadership with the team. This was a really pivotal moment in my career. Do I embrace the management career ladder? Or do I continue going deeper and deeper into my technical career? Fortunately there was enough of a technical architectural challenge to the projects that I was able to still spend most of my time there. But I knew at that time I didn’t want to make management my full-time career.

I left that company shortly thereafter and in the next few jobs (1999-2005) I would focus primarily writing the software to build our products. However, invariably I would always end up managing a small team again. Then after a few months of that I would begin to get the itch to solve problems with code. So I would shift back to primarily coding and once my skills were sharp again I would feel a huge sense of relief. I still had the technical mojo.

What was going on? Why couldn’t I make up my mind?

There were several factors at play

• I loved the craft of coding. Being able to create solutions with just my mind and code was deeply satisfying. Management didn’t have the same appeal.
• My passion for being the best I could at software development had been financially rewarding enough. Jumping to a different track was actually a bit scary. Would I have the same “edge” or just become a boring middle manager and become irrelevant over time? I couldn’t imagine ever being a director or a VP. So I wasn’t even sure what career it would lead to if I became “just a manager.”
• The feedback loop for writing code is really quick. Frustration and reward come daily. Crafting a solution and seeing the reaction of the team & the customer was addicting. Management has a much slower feedback loop. It takes a lot longer to see results. That just didn’t feel as rewarding.
• The problems solved by code are much more straightforward. The problems presented by people are a whole lot messier and not straightforward at all.

I continued on this path of being primarily a software engineer and from time to time being a manager of small teams. When I changed companies, I would go in as a software engineer and not a manager. The first slight change to this happened in 2002. I joined Sabre Airline Solutions with the understanding I would be the manager of the team. However, the agreement was I would spend at least the first few months as a peer and totally focused on software engineering. This worked well because when I did take the management role, I already had the technical respect of the team. This team was a bit larger with close to one dozen team members. So it was a growing experience. However, even in that role, after I got the team operating smoothly, I occasionally took on some very challenging software platform initiatives and spent the bulk of my time coding.

Leaving Sabre, I went to Yahoo (2005) as their “Ajax Evangelist”. Basically I was a JavaScript technology evangelist with a blend of product, design & engineering. The role had both an internal technical leadership angle as well as an external focus giving technical talks all around the world. One reason I had been hired was I had co-written one of the first Ajax JavaScript libraries (OpenRico) and had written a lot about good user experience design with these new technologies. Besides evangelism, I wrote a lot of code at Yahoo. And sometimes I would lock myself away for 7 straight days in a manic coding frenzy to build out an idea I had. Eventually at Yahoo I did become an engineering manager for the Yahoo for Teachers product. It was a small team and I still spent half my time coding. 

In 2007 (22 years after developing the game), I joined Netflix as a Director of Engineering. This was the first time I took a full management role going into a company. Yet even there I saw a need for fixing performance issues and wrote an open source Firebug (a developer extension for Firefox) plugin that visually graphed the performance of a web page. I just really had a hard time letting go of coding. Yet, at Netflix I began to see the incredible leverage that management afforded. I could hire a great team, I could make the hard decision to let someone go to make the team more effective, I could create an environment where a team could thrive, I could literally multiply the outcomes of the team by being a good & thoughtful leader. It was here that I began to spend 100% of my time on managing and leading teams.

It is important to note however, that I didn’t check my technical brain at the door. I used my deep expertise in software to understand where the Netflix code base was suffering, how that impacted the team and what engineering processes we needed to create better software. I co-wrote a technical book on design during that time. I spent more and more time on the technical challenges of blending product, design & engineering to produce great consumer products. I began to see a much larger set of problems that executive leadership could solve.

After a few years, I left Netflix for a period of about a year. During that time I consulted for numerous companies. Once again, I took a detour back into the technical side of things. While I did some product strategy consulting, I also was writing code for startups. When I returned to Netflix, I was better for it since I was put into an environment where I had explored numerous technologies as well as ways of working. 

When I finally came to PayPal (2011), it was to be a Sr. Director and later a VP of engineering. This was the time I fully embraced executive leadership. I ended up leading complex organizations as large as 750 employees. But I still occasionally would do deep dive into a portion of the code and form an architectural opinion and rally my teams in some needed architectural direction. 

So, what career path did I take? If I count 1985 as the real beginning of my career (It was several years after writing my first lines of code that I began to pursue computer science as a career. 1985 was when co-wrote GATO for the Macintosh), then the first 22 years was primarily a technical track. The last 13 years were in true executive leadership. 

If you are evaluating whether to stay on a technical track vs heading down the management track, here are a few things I learned along the way:

• You can be a leader without being a manager. In fact people misunderstand leadership and think it has to have an organizational hierarchy with it. The best leaders lead by influence & inspiration and not by control. In technical leadership roles you have to influence. You don’t have the organizational mandate often. So these skills will serve you well later if you do choose to go into management.
• The decision doesn’t have to be binary. You can move between the two.
• You can experiment with management while still staying technical.
• The two are really different. The technical side of your job requires intense narrow focus. The management side of the job requires the bigger picture view. The technical challenges lead to more immediate results and feedback. People challenges take much longer to solve and you might find the longer feedback cycles to be deeply dissatisfying. 
• Ask yourself why you want to switch to management? Is it to have more control? Is it to make more money? Understanding your motivation can lead to solving the desire in a different way. Or to challenge your motivation.
• Is it because there isn’t a clear path in your company to move up a technical ladder?  This is a good time to have discussions with your manager about the company supporting engineers who want to stay 100% technical and yet be rewarded in a similar manner to managers.
• Do you still find the challenge of writing code & solving technical architectural problems highly rewarding? It can be a bit disconcerting if you come to a place in your career where the rewards of a purely technical track begin to diminish. But this is understandable. The brain needs new challenges. This is really what pushed me over to the other track. I needed whole new sets of problems and challenges. I found the problems presented in executive & business leadership to be at a whole new level. It made the decision easier to make because it became my passion.

Hopefully my messy journey can be illustrative that the decision between the two career tracks can be a bit challenging. As I look back over my career, I am extremely happy that I waited a long time before switching to a full management track. Your mileage may vary of course. But what really guided me? My passion. Pure and simple. I kept at the purely technical side even if it might have been more financially rewarding to switch because I followed my passion. I only switched to a pure management leadership track when it became an all consuming passion.

In a separate article, I write about how companies should think about creating a technical track and enable their best engineers to stay in this track as long as they want.