Driving a technical strategy at scale

A good technical strategy provides a map for the journey towards your North Star goal.

Are you responsible for a horizontal program like optimizing your cloud infrastructure costs, or improving the overall security, reliability, or data quality posture? Are you evaluating a greenfield, broad, ambiguous problem space and wondering where to start? Or, are you building infrastructure or leading a multi-year effort, with significant error margins due to unknown unknowns?

For all such situations, when dealing with ambiguity over a long time horizon (at least 12-18 months); when the stakes are high, as is the investment and the impact; when you need to make decisions with measurable confidence, spanning multiple teams, and drive influence without direct authority, you need a technical strategy.

A good technical strategy provides a map for the journey that’ll help you focus on your North Star goal. It is a framework to help drive alignment from your users, stakeholders, or leadership, solicit buy-in from your peers or dependencies, and provide clarity for your team. And most importantly, at an individual level, it helps define purpose, tapping into your team’s intrinsic motivation.

As a senior manager or a tech lead, here’s a playbook on how to drive impact at scale by creating change meaningfully and meticulously across multiple teams. We’ll cover when you need a technical strategy, and how to design and socialize one, highlighting all the things to consider at every stage.

What is a technical strategy, when do you need one and why?

‘If you don’t know where you’re going, any road will take you there’, paraphrasing the Cheshire Cat’s response to Alice. What Alice lacked was direction. And that’s where strategy comes in.

Highly productive, autonomous teams are like an orchestra performing in full rhythm and synchrony. They are a collective working in unison towards a higher-order vision and mission, which represents the North Star – the why. We’ll assume that you have solved the hiring problem and built an inclusive team that has at least five-to-eight highly-skilled, capable engineers with the right domain expertise and career goals. We’ll also assume that your management and leadership practices lean towards a healthy culture that provides the right blend of growth mindset, radical candor, and psychological safety for individuals to autonomously thrive – so competence and autonomy are more or less solved.

But when faced with ambiguity over a long time horizon, how do you know where to start, what or whom to optimize for, which route to best navigate, and what pitfalls to avoid? Some questions you could ask are:

• Do you want to build a broad platform or perfect a niche use case? How should you do product planning over a multi-year trajectory? 
• Are there different user cohorts who’d benefit from rolling out feature A versus feature B? For example, an engineer or a team trying to debug their monthly cloud costs might prefer a drill-down of specific areas that caused the highest variance, versus an org leader preferring to see a leaderboard of the fastest growing teams by spend. 
• Are there multiple different business metrics that you want to optimize for – do you want to increase the revenue of the company or decrease the operating costs? For example, you might want to increase the customer base or market share or drive the performance and efficiencies of existing systems.
• Are there multiple different internal metrics affected by embarking on road A versus road B? For example, you could either focus the team for the next six to twelve months on building tools to empower others, which improves the mean time to diagnose latency regressions, or you could optimize your database transactions to directly reduce the end-to-end latency. 
• How much should you invest in a legacy system that serves key business value, versus doubling down on net new, lift-and-shift efforts?

Designing a technical strategy

I first came across the need for a strategy about a decade ago when we were shipping a key VMware® Workstation release to our enterprise customers. We had to pick between early scale and performance testing data, and solving a key user complaint. I distinctly recall how I lacked the framework to articulate the tradeoffs between delaying the release to embark on a potentially unsolvable problem and continuing to build for the product management specifications.

Fast forward a few years, I came across Good Strategy, Bad Strategy by Richard Rumelt, which has since become my staple for framing relevant situations to drive large-scale impact. The framework comprises of formulating the problem and proposed steps forward in terms of:

• Diagnosis: an objective, quantitative or qualitative assessment of the current status quo, describing the challenge at hand, potential causes for the challenge, and the related perils of leaving it unaddressed. For example, current deploy success rates of our service are down from 80% last half, to 20%, and this translates to X engineering hours spent waiting on our tools, adversely impacting developer productivity.  
• Guiding policies: a set of constraints that you either plan to or need to optimize for, making certain trade-offs and assumptions along the way. These have to hurt! If they don’t collectively create healthy tension or facilitate lively debate, you’re either playing it too safe or not pushing the organization hard enough. For example: in 2021, we’ll drive accountability with the top 20 teams contributing to 85% of total infrastructure spend, and defer the long tail of teams until 2022.
• Actions: a set of coherent actions that you’ll take with the guiding policies as beacon, to identify measurable progress to mitigate the challenge at hand. For example, the home insurance innovation task force will survey a demographic of new, emerging, tech-savvy users. It will publish a white paper on related attrition numbers at various points of our onboarding funnel.

This thesis then forms a cohesive narrative for the ‘how’ and helps identify the ‘what’, in service of the North Star – the ‘why’.

Socializing the technical strategy

Once you’ve thought about the problem and the proposal, you need to seek alignment and solicit support from key leaders and stakeholders within your organization. This is extremely crucial to creating an environment for the team and the initiative to succeed in the long term.

It is highly likely that for big bets or outcomes where the stakes are high, the investment also needs to be big. You might need additional headcount, to reprioritize planned goals, more time, or require commitment from other parts of the organization to align with your proposed actions. Essentially, you need leadership clearance and support. For one of my teams, we needed to split a monolith to a more service-oriented paradigm, and drive higher ownership and accountability. This implied, however, that the service owners needed to possess the relevant skillset, tooling, and support in order to achieve sustainable success. Such systemic changes are only possible with at least a skip-level approval, depending on the size of your org. For such conversations or decisions to be effective:

• Craft the narrative to suit the audience. Highlight the reasoning behind the strategy. Talk about ‘Where do you want to get to? What’s the most measurable way to identify the destination?’ and set an aspirational target as the outcome at the end of the strategy.
• Seek a sponsor for this outcome. Secure an executive leader – vocal, strong, in good standing, who will go to bat when needed, in big and small ways. For example, one of our leaders at Stripe deeply cares about infrastructure efficiency and is constantly highlighting the impact of such work for long-term success, amplifying relevant ships, talking to other engineers during casual lunches about the value of designing performant and scalable systems. Such endorsement and advocacy from key leaders goes a long way in validating the value of such work.

With an approved strategy and an outcome that has buy-in from an executive sponsor, you’re now ready to embark on the next steps of your exciting journey.

Read part 2 of ‘Driving a technical strategy at scale’ by Smruti Patel here (Publication date: October 1st, 2021).