As a technical leader, part of your role is to set the technical direction of your team and the product that you work on. Part of this includes proactively identifying technical constraints in your codebase and proposing investments to overcome them. Convincing stakeholders and your team to be on board, particularly if it’s a large undertaking or a shift in your current strategy comes with many moving parts. Instead, work to produce compelling strategies that focus on your audience’s motivations and goals to generate buy-in.

Getting the support of stakeholders

The stereotypical challenge engineers face is that stakeholders are often unaware or unaffected by the technical limitations you propose to resolve. Some may have a technical background, but that is very different from being knee-deep in a codebase on a daily basis.

For this reason, don’t focus purely on the technical benefits when pitching your ideas to an audience whose main concern is the product and/or the wider business success. I once prepared an hour-long presentation to executives about why a six-month migration was beneficial for the company. I focused entirely on the technical benefits and unsurprisingly that meeting ended without anyone really wanting to invest in my plan. There were two key mistakes I made that day:

1. Failing to connect the technical benefits to the company's overall benefits. We all know that if your team is able to implement features or resolve bugs more efficiently, that translates into business value and the ability to move quickly. However, I focused on my frustrations with the technical setup we had. And unfortunately, engineers being frustrated by legacy code is neither new nor a compelling reason to invest time into a proposal.
2. Disregarding people’s limited time to fully grasp every facet of the problem. These people are in countless meetings and their attention is pulled in infinite directions; they need the high-level, concise version to help them understand as efficiently as possible.

After some candid feedback and a few more successful attempts, I now have my list of strategies that help me present as effectively as I can.

1. Keep it succinct. Imagine everyone you’re addressing has just fifteen minutes to consider your plans (even if the meeting is longer). This compels you to strip superfluous content and focus on what really matters.
2. Focus on giving high-level summaries. Instead of getting bogged down in the details of the technical challenges your team faces say something like, “we are spending too much time fixing bugs because of the lack of good test coverage". You’ll only get approval for a strategy by advertising the benefits your new initiative will bring.
3. Show impact. Highlight recent issues and how your proposals could prevent or reduce the likelihood of them happening again. Using this approach I gained approval to rewrite a large part of an ecommerce site I once worked on. I demonstrated how a few recent bugs, which had prevented customers from purchasing items, would have likely been avoided if we had already implemented the change I was advocating for.
4. Pre-empt concerns that you’ll be asked about. For example, a justifiable concern that many have when discussing longer-running projects is the likelihood of the project overrunning. We all know that estimating software work is, at best, tricky. It’s always better to be realistic with stakeholders and accept this might happen. In this case, show you have thought about the problem by defining a series of milestones and break the project down into smaller, more manageable pieces. 

No two proposals are the same, so the approach differs each time. Following these steps helps my presentations stay concise and focused on the end result for our users/customers. Ultimately, this is more likely to motivate decision-makers to approve plans.

Getting the support of your engineers

Getting the engineering team’s support is often easier because they typically understand the context and motivating factors. However, they most likely have varying opinions on how best to solve the issue, so your challenge will lie in aligning the team behind one approach. 

This is a good problem to have! It's much better to have an opinionated, curious team over one that doesn't offer ideas. Here are a few methods I use to keep everyone happy:

1. Start early. Once you identify a problem area that needs to be changed, begin to gather opinions from your team. While you may have a preferred approach it's important to be open to other ideas. As a technical leader, your job isn’t dictating decisions, rather considering all perspectives and coming up with the best path forward.
2. Acknowledgment. Once you set the strategy in your proposal, make sure you acknowledge the ideas from the team that influenced it. This helps everyone feel included, prevents misunderstandings, and ensures team members feel valued and heard. I like to do this in the proposal document itself: call out when others have influenced you and make it clear where the ideas came from.
3. Provide context. Be thorough in explaining why you didn’t pursue alternative approaches. Discussing technical issues in detail may not be warranted when presenting to stakeholders, but it's very important when you’re dealing with your team. Explain all the options you considered, and why you ruled them out. Your goal is team alignment; for that reason, you need to have everyone understand why the chosen approach is better than others.
4. People growth. As the technical lead part of your role is to also give the team room to grow. Look for opportunities in larger projects to help develop people’s skill sets. Any large strategy will be made up of many parts and some of those will provide new experiences for developers on your team. 
5. Autonomy. Once the strategy is underway, empower team members to take ownership of their work. I've been on both sides of this and there's nothing more frustrating as an individual contributor on a project than feeling like your tech lead is too involved in the details. It can be a hard adjustment, but as a technical lead, your job is to set the direction and own the high-level architecture. Of course, sometimes you will need to get into the details to help unblock work, but make sure team members have the space to own their assigned areas.

Understand your audience

The key to creating compelling strategies is understanding the specific interests of each person who needs to be on board. If they are a product manager they will care about improving the team’s velocity. If they oversee company-wide staffing, they’ll prioritize project outcomes to justify resource allocation. If they are an engineer you'd like on the project, they need motivation and a clear grasp of technical and product-level goals. 

Tailoring your message to your audience and choosing the right delivery method ensures compelling, understandable, and motivating strategies are delivered.