Successfully creating and delivering on a long-term technical strategy often requires buy-in from senior leadership. Without it, ideas can quickly become undermined before they even start, or initiatives can become defunded if the business benefit is not demonstrated.

Using an example from my previous company, where I was part of a group of engineers that designed and built a company-wide analytics event platform for internal and customer-facing analytics use cases, I’ll demonstrate how to get leadership buy-in. 

Clear framing of the problem

Effective technical strategy is often in service of some broader business or customer problem. When opening up a conversation with leadership on a technical plan of action it’s important to communicate your understanding of this. You should outline: 

1. The issue or situation that the business is currently facing;
2. How the issue is creating problems for the business/customers; and
3. Why this problem needs addressing now.

Not spending enough time exploring and analyzing the problem space can lead to a strategy that may be expansive and exciting, but doesn’t quite address the real business/customer problems at hand.

You must be explicit in outlining how the issue is impacting the business – not every problem brought to a leader’s plate is one that will be dubbed as worth solving. What might be a problem to you, could have been the accepted tradeoff of a previous decision that, overall, had a wider positive influence on the organization. 

Leverage metrics to ensure the conversation with leadership stays as objective and honest as possible. If software build times are slow, use a time series graph that shows how they have degraded over time. If users are complaining on social media about a product feature, take advantage of metrics from customer support to plot how the number of complaints for that feature tracks against other big product changes.

Sometimes, situations can also be framed as opportunities rather than problems. A strategy to solve a problem can feel reactive: the problem is already hurting the business/customers. A strategy to capture an opportunity can feel proactive: you’re looking to capitalize on an event that can add value to the business and/or prevent a class of problems from even occurring. 

Case study: identifying problem areas 

For the analytics platform strategy at my previous company, we were fortunate to identify three related problems that spanned across different functions.

• There were a number of bespoke solutions for recording, processing, and analyzing analytics events (e.g., a user creating a new newsletter issue, a recipient opening the newsletter) that yielded data discrepancies across different analyst teams;
• Each solution used on-premise technologies that had high operational toil and low scalability ceilings relative to options available in the cloud;
• Each solution offered inconsistent granularity of data, data formats, and access patterns which made analysis that cut across the systems extremely difficult.

We built a coherent narrative around these issues, their relation, and how the combination ultimately impacted the company’s ability to innovate in the analytics and reporting space both internally and for external customers.

How does leadership know your strategy is the best one?

It’s all well and good to highlight a problem area with leadership, but why is your strategy the one that they should go for? You need to showcase how your approach makes the most business sense as leadership will likely be accountable for resourcing initiatives supporting your strategy. 

Because of this, they need sufficient evidence that your strategy is better than the alternatives. You can do this by painting a picture of what the business will be able to do once your strategy is executed. 

Anticipate their questions and have your answers ready; not only will this inspire confidence in you, but it will help leadership explain to others what is going on.

Case study: showing how a strategy helps the wider business 

For the analytics platform strategy, we had to paint a picture of how this initiative would affect four different teams of people.

• Product engineers – we demonstrated how easy it would be to define events using a published common schema, develop code to publish those events, and start analyzing them within minutes in the data warehouse. 
• Data engineers – we showed how all the added work that data transformation engineers do to make the data ready for analysis can be eliminated. 
• Analysts – we demonstrated how easy it would be to track existing business metrics using the new analytics events. We also showcased how it would become simpler to analyze different cohorts of accounts, audit different pricing models for usage-based product features, and assess data within minutes and hours as opposed to days. 
• Senior leadership – we demonstrated how optimizing the workflows of many cross-functional personas in this ecosystem unlocked new internal and external innovation opportunities (including ML-powered product features).

Showing concrete progress

Leaders that take a bet on your technical strategy expect to see a return on this bet. They likely have a vested interest in its success, are accountable for setting budget and staffing to execute against this strategy, and/or are accountable for its overall success.

You should use that understanding to be intentional about structuring initiatives so that impact is delivered incrementally. Work to have metrics in place that affirm your solution is solving the problem. Tangible, measurable deliverables build momentum for the team and assure leadership that it’s a worthwhile investment.

Your first few deliverables should be able to be accomplished by two-to-three engineers max. In my experience, this number is the sweet spot for prototyping various meaningful designs and implementations of a new technology/architecture. Additionally, the fewer resources you need to start implementing your strategy, the better the opportunity cost discussion will go with leadership.

Milestones

Sometimes leadership will expect a linear set of milestones to better understand the significant points of progress. It’ll help them start understanding how many engineers are needed and for how long.  

Outlining a set of milestones can be straightforward for some initiatives. But, other times, it can be a little more difficult. If you’re experimenting with state-of-the-art ML when your company doesn’t have any prior experience with it, you may know what the final destination looks like, but it could be a little difficult to fully map out how you’ll get there.

In these scenarios, a slight shift in the framing of the work ahead is useful. Instead of milestones, i.e., arbitrary checkpoints in a roadmap, consider “stepping stones”.  

Stepping stones are a vantage point where you can pause, get a better view of the solution space left to explore, and course correct as needed. It’s a subtle shift from milestones in that you're not charting your full course from start to end; instead, you're taking one step at a time and evaluating the next steps from there.

The Stepping stones, not milestones blog post by James Cowling delves deeper into this idea.

Case study: managing expectations on milestones

For the analytics platform strategy, our first deliverable was an end-to-end system. This included a dev experience for publishing analytics events with an architecture that was stress tested against our highest traffic period of the year: Black Friday to Cyber Monday.

The end-to-end dev experience, complete with a user guide, was easy to demo to engineers and leaders across all levels. And because the system we were trialing performed well under the Black Friday load, leadership became more confident that the novel architecture was viable and that the team had the skills to operate it effectively.

Once the initial system was in place and vetted, leadership was excited and started asking about the roadmap ahead, how much staff we needed, and if there’d be enough work to sustain that staffing. But, we weren’t done with our exploration. We still needed to vet the architecture for a secondary, downstream system. We didn’t know if we’d need to implement a drastic shift in the architecture and/or the dev experience we envisioned for it.

In conversations with senior leadership, we used the “stepping stone” framing to help them understand that (1) we knew what the end goal was, (2) we didn’t know exactly what all of the steps forward were to reach that end goal, but (3) we had a specific arc of work that, once completed, would reveal if our architecture was viable or not and if the development experience for our users would be tenable.

Although senior leadership wasn’t fully comfortable without a full plan of milestones to refer to, they understood the fact that the next phase of work would answer a lot of unknowns.

The learning never stops 

We didn’t really dig into any technical details in this article, as, though they’re important and interesting to senior leadership, they aren’t going to be what leadership anchors themselves to when making business decisions. 

Though it may seem evident, helping leadership understand the “big picture” can quickly be achieved through clear framing and transparency.