In this blog post, I wanted to take the time to discuss my recent transition from a Software Engineering role to a Partner Technology Strategist (PTS) role here at Microsoft. I have been in this new role for roughly 1.5 years, so this is a perfect time to share my experiences as it might help others who may be considering a similar career move. This blog entry will primarily focus on some of the challenges I have faced while transitioning to the new role. I plan to create follow-up blogs that discuss how rewarding the role has been for me, how the role has allowed me to grow and some strategies that can be implemented to ease the transition.
Why the Role Change?
Since graduating in May 2001, I have primarily worked as a Software Engineer (LinkedIn profile here). As I progressed through my career, I would wear many hats, such as Software Engineer, SCRUM Master, Consultant, Lead Engineer, Software Architect etc. etc., however, my primary role was always a hands-on Software Engineer.
A big part of the culture here at Microsoft is having a Learn It All mindset and allowing individuals to move to different roles, to grow their career. At Microsoft, I started out as a Software Engineer in the Commercial Software Engineering (CSE) organization. As I increasingly worked with large Microsoft Partners/Customers, I started to feel that after over two decades of being a Software Engineer, I could provide more value by combining my EQ and technical skills to help shape an organization’s overall technical strategy.
When a friend, mentor and someone who has been extremely influential in my career at Microsoft left CSE, to become CTO of Microsoft’s Global Partner Solutions organization, he encouraged me to interview for a role in the organization he was building (The Global ISV Tech Team), as he felt I would be a good fit and the rest is history.
What is a Partner Technology Strategist?
A Partner Technology Strategist (PTS) focuses on three major areas, and these areas just happen to be the three words in the role name. The PTS works with Partners to understand how both Microsoft and the Partner’s Technology can be integrated to be mutually beneficial to both organizations. As The PTS develops this deeper understanding, the expertise will be used to develop a Strategy to realize the goals of both Microsoft and the Partner. The PTS owns the entire technical relationship with the Microsoft Partner and a major goal is to be viewed as a Trusted Advisor (TA), and eventually, a CTO.
Challenges?
Making the transition from Software Engineer to Technology Strategist has been rewarding (which I will discuss in a later blog entry) but it has certainly come with its many challenges.
Perceived Effectiveness!: In the role of Software Engineer, how effective I was at doing my job was objective and easy to identify. My manager and peers can perform code reviews on my work, they can see the features that I was working on and through consistent interaction, such as architecture design reviews and backlog grooming, the engineering team could observe my competency level.
In the PTS role, the goals can often take months (maybe even years) to be realized due to the complexity of the working environment. The PTS must build trust with the Partner, have a solid understanding of both Microsoft and the Partner’s goals and technology. Also, because the PTS is focusing on the overall technical roadmap for a Partner, the PTS must work with several decision makers, both within Microsoft and the Partner to move the needle. Due to this type of complexity, it is a lot more difficult to measure the effectiveness of a PTS.
Time Management!: As a Software Engineer, I spent most of my time writing code or pondering how I would design and implement a solution. I did attend meetings but most of the meetings were planned i.e., SCRUM, Sprint Planning, Design Reviews etc etc and with a regular cadence. Also, in most cases, if a decision needed to be made, it was typically a Lead Engineer (in some cases, that was me) or the Product Owner (in some cases, a Business Analyst serving as a proxy), which were very accessible.
In the PTS role, I often view things at an organizational level, and I must meet the needs of at least two organizations, Microsoft, and the Partner. As a PTS, I spend a lot of time having to meet with several decision makers, who themselves have limited time, influencing without authority and bringing different resources together to help drive technical strategy and solve problems. All the above takes time and because of this, I have had to develop strong time management skills, avoid being randomized and learn which items to prioritize and dedicate most of my time.
Learning to Say No!: As a Software Engineer, I had to tell people no a few times but for the most part, that was the job of the Product Owner. The Product Owner worked with the engineering team to groom and prioritize the Product Backlog and indirectly, the Product Backlog would be used to determine when a feature was going to be implemented.
As a PTS, I am constantly pulled in several directions and there are constant attempts to randomize my day (not on purprose of course). Co-workers that are working with the customers of my Partner will ask me for my time, my Partner will ask me for my time and my manager, and my teammates will ask me for my time. I found out very quickly that if I did not learn to say no, I would burn out in the PTS role very quickly. I had to learn that No was not necessarily a bad word because there just is not enough time in a day to accomplish everything and in the words of a mentor, “In the PTS role, you will absolutely drop something, you just have to figure out the items that cannot be dropped.”
Influence Without Authority!: As a Software Engineer, I typically worked with the same 10-15 people every day, even when I was a consultant. In Software Engineering, I did not spend a lot of time trying to influence people and when I did, it was typically the same small group of people i.e. what framework to use, design patterns etc. etc. In Software Engineering, you typically know what feature to implement, however, discussions tend to focus on how the feature is implemented.
As a PTS, I easily meet 2-3 new people every single week. I must scale both Microsoft and my Partner’s organization, to find decision makers and resources that can answer specific questions (you will never have all the answers). Also, as stated already, co-workers that are working with the customers of my Partner will seek me out because I may have the answers they are looking for. I am an individual contributor, which means I have no direct reports, so I must influence without authority and manage the different personalities and objectives of the people I work with.
I had to understand very quickly that it was imperative to understand the roles of the people I meet and most importantly, how they are measured by their leadership. Understanding the answers to these questions helps to influence without authority because I gain insight into what motivates them, which in turn, helps to align common objectives.
Learning How to Depend on Others!: As a Software Engineer, I certainly had to depend on other people from time to time, to be effective at my job. However, the number of people that I needed to depend on was small and the areas where I depended upon others were very narrow. I depended upon teammates to review code, provide expertise around a certain technology stack or concept in which another engineer might be more knowledgeable (i.e. design patterns, frameworks, DevOps etc. etc.).
As a PTS, my scope is at the Microsoft and Partner level. My Partner could ask me anything from Azure Blob Storage, Azure Purview, OpenAI or why they are not able to deploy their SaaS solution into a certain Azure Region. And on the Microsoft-side, my co-workers could ask me random questions such as what industry my Partner is targeting, would the Partner be interested in integrating with a new Microsoft product or how redundancy is implemented in my Partner’s product.
Due to this complexity and the fact that I cannot possibly know everything, I tend to have to depend more on others than I did in Software Engineering. I have had to learn that sometimes; it is okay if my only contribution to solving a problem is that I found the right person who did have the answers to a particular problem.
Conclusion
The decision to switch from a Software Engineering role to the role of a Partner Technology Strategist has presented new challenges. With any new role change, I have had to adapt, grow, and learn new skills. I have learned to play the long game, better time management, understand that I will not be able to say yes to everyone, become better equipped to influence others without authority and understand that it is okay to lean on others to solve complex problems.
In this blog entry, I focused on the challenges that I have faced as I transitioned to the new role. In my next blog, I want to spend time discussing how rewarding the role of a Technology Strategist has been for my personal growth and my overall career.