Why SDE to TPM is Mostly a One-Way Street!

This is a long blog, but here is the summary:

1. If you cannot get into one of the top (FALGUN) companies as a Software Development Manager, getting in as a Technical Program Manager (TPM) can work, but it is difficult to then shift back into the SDM role at the same company.
2. If you do get in as as an SDM at these or at other companies, having some project or program management skills can give you an edge in your role over your counterparts because of fragmentation of complex functional areas.
3. If you want to go from software development to product management, read this blog and learn why that is a hard road. However, software development to TPM and then to Product Management can be a good route in some of these companies.

In my coaching practice I often deal with mid-career individual-contributor (IC) professionals at crossroads when they realize that they are not moving up in their role to become a functional manager. SDE is an acronym for Software Development Engineer. Although SDE in my coaching practice is one of the more frequently encountered functional roles, where my clients face some headwinds interviewing at top companies (notably, Facebook, Amazon, LinkedIn, Google, Uber, and Netflix—what I call the FALGUN cluster and other such companies in that club) for a manager role (SDM), there are other functional IC roles that also encounter a similar experience. This difficulty often persists even when a client, who is already an SDM in their current role interviews for a manager role at these FALGUN targets. These headwinds typically emerge from the deep technical interview questions in system design, team leadership, algorithms, and even coding, where many are ill- prepared to ace the grueling in-depth technical vetting at these FALGUN companies and their ilk. 

Beyond SDEs, this experience extends to many other functional areas such as circuit design, mechanical engineering, system design, reliability, testing, automation, and many other technical areas. By “technical” I do not merely mean technology areas, but also any area of specialty, which can include law, medicine, marketing, and other fields.  

The reasons some SDEs and other ICs are unable to ace “tough” job interviews at these companies are many; notable among them are the emphasis their current employer places on the level of functional excellence they expect from these ICs and even from their managers vis-à-vis their ability to manage teams and resources, toeing the company line (a’ la politics), and personal favoritism. It is these latter aspects of emphasis in their roles that erode the functional ICs’ and managers’ edge as a technically competent professional capable of leading world-class teams that these coveted FALGUN companies take pride in hiring and nurturing. This is how they keep their edge and image.  

After a series of defeats in getting through job interviews for functional manager roles at these top-tier companies candidates’ focus shifts to finding promising proxies for these roles, while they continue their interest in these same companies. The most obvious alternative is to become a Technical Program Manager (TPM). Although TPMs require some technical expertise, the real emphasis in this role is on getting things done on a project across different functional areas and on the TPM’s ability to influence stakeholders on a project to keep the timelines on track and to deliver on milestones. 

A concomitant responsibility they share involves keeping all the major stakeholders happy, while they continue to seek their support without any direct authority over them; something a person who brings a line-experience DNA often has to struggle with. In this role their “impaired” functional expertise does not diminish their ability to drive a project, since the technical burden now devolves on to the respective functional managers, who provide the expert resources to TPMs; in effect, their stakeholder community. 

Something interesting happens when an erstwhile IC or a functional manager now takes on the TPM role. When their project gets impeded by technical challenges in the area of their previous expertise, they quickly forget that their TPM role requires them to stay away from sticking their nose in such matters. Yet, they offer their insights or advise gratuitously to the functional leads and managers, only to get ignored by them, regardless of their insights’ merits. 

If this keep happening—and it does due to its inevitability—these TPMs are seen as unfit in their roles and continue to get ignored—even ostracized—in how their project gets supported and managed. This can soon doom their new career as a TPM scuttling any hopes for them to navigate through the new company in their brand-new role.

The other rationale with which these candidates pursue the TPM avenue to get into these coveted companies is that they hope that once they establish themselves as TPMs they can migrate to their area of original functional expertise they left behind and reclaim their SDM role. 

As the TPMs align well and age in their new roles this possibility become increasingly remote, since a TPM worth their salt has now strayed away from their technical area of expertise by becoming mere observers—not leaders, as they previously were—of how a technology they thought that they had once mastered is now deployed on their projects. 

Thus, taking on the TPM path becomes a one-way street to career management, even when they do well as TPMs by disciplining themselves to stay within their role’s ambit. Although this path offers some career progression it is quite limited compared to what is available to a typical functional manager (SDM); they can go on to become director, VP, and follow the available career ladder, open to most functional managers, which can offer greater growth possibilities. 

Dealing with Fragmentation: These days many companies are fragmenting functional areas that were once kept unified. 

 For example, in the networking space the entire stack with its seven layers, each requiring specific expertise, were kept under one leadership to keep that stack optimized when developing a new solution (see figure-1).

Figure-1: The Networking Stack

However, not all companies now follow that org. design: Different areas within this stack are spread across adjacent functional areas at many companies because of technologies becoming increasingly more complex. As a result, the final design does not get the treatment of an optimized solution that it once did when it was under one roof in the early days of this technology. 

In this environment, if a functional manager leading a particular part of this stack knows how to work across this fragmented stack and to deliver an optimized solution, they stand out from their counterparts, who stay parochial to their own areas of trade within this stack. So, in such organizations, where a functional manager, who understands how to work across organizational boundaries to get their job done have better career growth prospects than their counterparts, who ply their trade within their narrow, fragmented area. 

What does this suggest when it comes to managing your career as an SDM? 

In simple terms, this means that those functional managers (SDMs), who bring the skill and the experience of collaborating across different boundaries—something what TPMs routinely do—have an edge over their counterparts running the functional adjacencies. This means that having some project management knowledge and even experience can help these functional managers become more successful in their roles if they stay true to their area of functional expertise and complement it with some project management skills as they continue to grow in their functional roles. They can do this by getting certification in project management and by being open to collaborating across organizational boundaries to fortify their overall contribution to the betterment of the stack, and not merely for optimizing their parochial solution.  

SDE to Product Management 

Yet another path many SDEs or SDMs consider—often as they reach mid-career—realizing that they cannot—or do not—want to go further up the chain of command in their current role, is to go onto a product management path. In this use case there are two categories of SDEs, who contemplate this transition: One, who are running away from their SDE path; and the other, running towards product management. 

The difference between these two categories is primarily that of motivation. Those in the former group—those running away—are looking for greener pastures and they mistakenly see that as an easy transition to product management to make by virtue of their misperceptions and misapprehensions (please read on) about what that role entails. Here, they are operating in a state of unconscious incompetence. 

 For the other category—those who have lifted and transitioned themselves into a state of conscious incompetence have come to appreciate how they can play the role as a future product manager by leveraging their deep experience in product development and technology management as SDEs and by learning all there is to learn about product management. These SDEs have worked closely with product managers, who have shaped their product roadmaps working in collaboration with these SDEs and in the process the SDEs have a deeper appreciation of what can be done in that role as they decide to become consciously competent by putting in their effort. They are now attracted to the product management role because of their conviction that this is a better career path for them, long term. 

For the former category, however, the allure of playing a customer-facing role and being in a position to tell their development teams what to develop, somehow, piques their curiosity, as they often mistakenly perceive their own SDE role as far more demanding than that of a product manager. From their vantage point they often see product managers they encounter as lacking deeper understanding of technology that SDEs are required to have, making mere guesses about what products the market and the customer really need. They’re often convinced that they could do that a lot better because of their superior technology expertise and the state of their unconscious incompetence about the product management role.

The latter category of SDEs—those who are running towards product management—come to realize that going further in their SDE career would not be as personally rewarding as it would be in a product management role because of their predilection for customer and business-focused roles, having watched star product managers up-close in their everyday work.  

So, many (from both categories) go on their own for an MBA and spend two years and their own fortune, as they continue to work through their SDE role only to come back, realizing that nothing much has changed for them in their immediate ability to move in the role to become a product manager. 

What some still fail to recognize is that product management is a business skill that requires not just a different skillset, but also a different mindset. Knowledge of technologies is useful, but how a product manager understands the available technologies and how to create compelling solutions to win customers and market require a different perspective, which now for them is a sine qua non. 

Often a deep understanding of particular technology—as what SDEs bring—can hamper a person’s ability to be an effective product manager. Nowhere is the saw, the grass is greener from afar, is more valid than a myopic SDE’s assessment of what it takes to be an effective product manager. Although this transition was easier to make about a decade back for some, with technologies getting more complex, customer expectations high, and more competition for product management roles, it is now a much more difficult transition. Those SDEs with their MBA and with their instinctive understanding of the product manager’s responsibilities and their business mindset find it easier to navigate their way into product management roles and they often succeed once they transition into the state of conscious incompetence (in product management).

Although a transition from SDE to product manager is more difficult for reasons mentioned here, a transition from Technical Program Manager (TPM) to a Product Manager is less daunting. So, if one can find a way to take this intermediate step of transitioning first into a TPM role in the right company that allows this next step to product management they will be well rewarded for their thoughtful career planning. Several of my clients have succeeded in going from SDE to TPM and then into product management at companies like Google, Salesforce, ServiceNow, and others. 

 Conclusion?

Going from a particular functional area as an individual contributor (IC) to a project or program manager (TPM) role is a one-way street in most technology companies. However, if you bring to your functional role some project management skill in companies where a functional area is organizationally fragmented you have a better chance of success, both getting in and then staying as a functional manager—once you get in—and leveraging your project management skills, however green, to get an edge over your counterparts. 

The second conclusion is that if you are running away from your IC role as an SDE to land a product management role one possible path is to take on a project or program management (TPM) role and explore the possibilities of later transitioning into product management. That may be possible in some limited number of high-tech companies as some of my clients have done successfully. 

Good luck!