In part 1 of my series about transitioning from Software Engineer to Partner Technology Strategist (PTS), I spoke about some of the challenges I have faced in the 1.5 years I have been in the new role.
In part 2 of this series, I want to get a little vulnerable and discuss how in 2023, I really struggled mentally in the Technology Strategist role and the strategies I implemented to find enjoyment and overcome the challenges of the role.
Caveat
The views that I discuss in this blog post are my own and they are based upon my own experiences. My hope in writing this blog is to share my experiences with others, in hopes that it will provide insight and guidance to those who plan too or are currently transitioning from Software Engineer to a Technology Strategist.
Getting Vulnerable!
In part 1, I discussed why the Partner Technology Strategist (PTS) role can be extremely challenging and how many aspects of the role are the opposite of what I had been doing as a Software Engineer. In 2023, the role really started to wear me down mentally and by the Summer of 2023, I had gotten to the point where I was completely burnt out. My sleep issues started to worsen, I had a few dizzy spells, and I was constantly fatigued, anxious, fearful and stressed out.
Surprisingly enough, a blessing in disguise came my way via an adult Tonsillectomy. I was diagnosed with Obstructive Sleep Apnea a few years ago and TMJD last year. Towards the end of the Summer, my Sleep Apnea and TMJ physician told me that I needed to have my tonsils removed before he would begin treatment. After getting numerous second opinions and ruminating over the surgery, I decided to get the Tonsillectomy, which forced me to take 3 weeks off work.
While recovering from the surgery, I discovered that many of the symptoms that I had suffered leading up to the surgery were virtually gone, despite only getting 1-2 hours of sleep a night the first few days after the surgery due to the pain.
It was at this point that I had an epiphany and realized that the PTS role was really diminishing my quality of life. The engineer in me immediately started to first contemplate “why” was the role having these effects on me and then implement a strategy to overcome these challenges.
After much contemplation, along with the issues I spoke about in part 1, I identified a few other reasons why the role was having such a negative effect on me:
I was constantly concerned with getting promoted to Principal. So, there was a constant focus on what others thought of me.
I was constantly concerned about being fired or laid off. I had a hard time figuring out what metrics I was being judged by and Microsoft was having layoffs.
I was constantly concerned with everyone else’s opinion on what I should be doing with my Partners.
During my 3 weeks off, after recognizing the above bullet points (whether real or imagined), I made a vow to immediately stop being concerned about all 3 of these issues. Furthermore, I decided to implement strategies to manage the stress and ambiguity that is inherent to the role. I no longer concern myself with promotions, I no longer worry constantly about losing my position and the way I handle unsolicited advice is completely different than I did in the past. Once I did this, a lot of the stress and anxiety diminished significantly and it was extremely “freeing” to not consistently worry about these things, some of which I freely admit in hindsight, were not grounded in reality.
Managing the Stress & Ambiguity
Next, I want to talk about the strategies I implemented to manage the stress and ambiguity that just comes along with the PTS role.
Understand the Microsoft Landscape!
Microsoft is a very big organization that is filled with seemingly endless organizations and roles. I started to spend a lot more time understanding the organizations that I worked with and what were the core priorities of the roles within those organizations. In part 1 of this series, I talked about how I interface with a lot of people inside of Microsoft and I have no direct reports. To continue, I spoke about having to constantly “influence without authority”. I started to understand that to influence the people around me, I had to understand their role and what motivated them. Once I was able to do this, I was able to view things from “their” perspective and this allows me to be in a better position to influence.
Recognize and Manage Patterns!
In Software Engineering, there are tons of documented design patterns that help solve difficult engineering problems. In the PTS role, I found out that there were anti-patterns of behavior that continually surfaced and recognizing them helps manage the behavior, which if it goes unchecked, can increase stress.
Dial-a-PM Pattern: The Dial-a-PM pattern is typically employed by the Microsoft Partner. Some Partners may take the view that they do not want to share roadmaps and they don’t want to engage in co-innovation with Microsoft. The partner that behaves in this manner will typically only care about support and access to the various Microsoft Product Groups. Typically, they will ask the Technology Strategist to be put in contact with various Program Managers inside of Microsoft, hence the term “Dial-a-PM”. This behavior is problematic because there isn’t a strategy, the Technology Strategist is “randomized”, it isn’t a real “partnership” and thus, greatly increases the stress level when interacting with the Partner.
Inbox Pattern: The Inbox pattern is typically employed by my colleagues within Microsoft and specifically, the ones that work with the customers of my Partner. What typically happens is that people will find out that the PTS works with a Partner, in my case, a Global Independent Software Vendors (GISV) and they will immediately start including the PTS in tons email (hence, the name Inbox Pattern) and Teams threads, of which, many of the topics are outside of the responsibilities of the PTS role.
Push-Push Pattern: The PTS is responsible for helping to craft the technical strategy for a Microsoft Partner. I believe that the PTS should spend time listening to what the Partner states is important and align these goals with those of Microsoft. The PTS should do this by consistently “pushing” to get the Partner to follow through on their stated goals. Also, I believe that Microsoft leadership should support the PTS by “pulling” in the Partner when there are serious technical or business challenges that are preventing business objectives from being realized. However, on many occasions, a PTS will observe not a “Push-Pull” pattern with regards to the PTS and Microsoft leadership but a “Push-Push” Pattern. What I mean by this is that many of the people who work for our Partners are ex-Microsoft employees who have established relationships with some in leadership positions at Microsoft. The Partner will sometimes go above the PTS and straight to leadership (to push) to get answers and/or advice, which can undermine the PTS and, in some cases, the advice received can be counter to what the PTS would have advised as the PTS is working with the Partner on a week-to-week basis and has better context.
Getting Ahead of Patterns, Stress & Ambiguity
Outside of the strategies already mentioned and recognizing typical patterns when working with Microsoft Partners, below are some of the other strategies that I am employ:
Set expectations upfront: When I start to work with a Partner and the internal Microsoft team, I set expectations upfront. I educate everyone about what a PTS does and what my core objectives are.
Focus on Strategy: I’ve been a PTS for about 2 years. When I changed roles, I spent a lot of time being “tactical” and “reactive” (I didn’t know any better), which gave me very little time to focus on technical strategy. I had a very hard time saying “no” to people and the result was burnout. Now, since I have a very keen understanding of everyone else’s role, I can point people to the right role to get answers that are outside of the scope of the PTS position. Furthermore, a consistent focus on strategy prevents “randomization” and allows more time to be spent focusing on Microsoft and the Partner’s core goals (stated verbally, in financial earnings reports etc. etc.) and this puts me in a better position to provide guidance on technical strategy.
Be ruthless with my time: When I first started in the PTS role, I would always accept meeting invites, regardless of the meeting topic. Many of the meetings were reactive and didn’t focus on core objectives. Now, when I get meeting invites, I either decline or select “maybe”, if it is unclear what is going to be discussed. Spending time in meetings that didn’t move the needle on core objectives resulted in randomization, stress and a feeling of “busy” work with no strategic outcomes. Furthermore, if it is a meeting that is crucial to core objectives, but I am not able to attend, I will politely ask the team to record the meeting and I will watch the recording later.
Accept that everyone has an opinion: One of the areas that I struggle with (in my personal life as well) is unsolicited and often uninformed opinions. The Partners that I work with are large and have global reach, so it isn’t a surprise that people are going to have very strong opinions about what “should” be happening with regards to working with the Partners. I observed in meetings that people would propose solutions that were already being solved or suggest things that weren’t appropriate due to not having the full context. Now, I accept that everyone is going to have an opinion, this is not going to change, and I must focus on how “I react” to these opinions. I found that if I am employing the “Push-Pull” pattern effectively with regards to me and leadership, and I am consistently focusing on technical strategy, I am in a strong position to educate and provide better context when opinions surface in meetings.
Embrace ambiguity: Historically, I have been the type of person who shuns ambiguity and is more comfortable with tangible and well-crafted goals. As stated already, the PTS role is the complete opposite. Impact, objectives and goals can be very ambiguous and change on a quarterly basis. I have had to step out of my comfort zone and accept that this just comes with any strategy role, and I had to learn to be flexible and develop the ability to context switch. Since I consistently focus on strategic goals, instead of being annoyed by the changing landscape, I can ask the Partner (or Microsoft) about priorities, to ensure alignment, which in turn, ensures that we are both working on stated goals, and this gives me the appropriate level of comfort to manage the ambiguity that comes with the role.
Opportunity Cost: When I left Software Engineering for a Strategy role, I was completely obsessed with losing my technical edge i.e. the cost of focusing on strategy at a cost of losing my Software Engineering acumen. I spent a lot of time trying to figure out how to maintain deep technical skills and grow as a strategist. Honestly, I had to just accept the fact that yes, I would lose my deep Software Engineering skills because I am not doing it every day and these skills were not as valuable to my Partners in a Technology Strategy role. I still create POCs, write code and upskill when I have time, but I now take the view of “I am not losing my technical edge, I am gaining new skills that is allowing me to grow and get out of my comfort zone.”
Furthermore, the Technology Strategist role is technical, however, it is a focus on other aspects of technology. For example, one of my first Microsoft Partners was Redis. I was explaining to a fellow Software Engineer that if I was back in Software Engineering, I would focus on Redis SDKs and best practices on implementing Redis Cache from a Software Engineering standpoint. However, as a strategist, I am more focused on what technical problems Redis solves, what differentiates Redis from competitors (pricing, region availability, performance, availability etc. Etc.) and what should Redis do next to provide better value to their customers and increase their market share. I must be technical, and my technical background helps me to better understand these problems and how to come up with a competent strategy to solve some of these issues.
Conclusion
In part 2 of this blog series, I wanted to shed some light on some of my struggles transitioning from Software Engineering to Technical Strategy. I also wanted to outline in detail some of the many strategies I am employing to help ease the transition. I have been in the Technical Strategy role for about 2 years, and I learn something new every single week. But because I have started to recognize “anti-patterns” and started to implement strategies to reduce the stress and ambiguity of the role, it has been very rewarding. I now have more time to be hands-on, focus on Microsoft and Partner products and the above has allowed me to be less anxious, fearful, worried and more confident. This has led to the ability to more easily develop technical strategies and to be able to articulate my ideas across Microsoft and the Partners that I work with.
I am no longer worried about promotions, being laid off and the constant stream of unsolicited opinions about what my Partner should be doing. Since I am technically (no pun intended) captaining my own ship, working with Partners weekly, and thus have a good contextual grasp at any given moment, I let these facts guide my work and I let my outcomes speak for themselves and cease to borrow problems from the future. The strategies that I have discussed in this blog post may not work for everyone because everyone is different. However, I hope that this blog post will be able provide some value for those who are moving from a 100% hands-on Software Engineering to a role focused on technical strategy.