Pitch Technical Change like a Software Architect – The Easy Way

It’s happened to just about every engineer I know.

You’re working on one of your millions of unfinished weekend side projects (or maybe just mine are unfinished) and the long sought-after AHA moment strikes! If you just change some things around, swap out tech X with the new Z, and voila, we have a solution to that one problem that’s been haunting us all month. You hit the keyboard, throw together a proof of concept, and show up early Monday morning ready to dazzle anyone that will listen. First up are the business decision makers. You expect this to be a no brainer and can’t wait for all the high fives.

And then it happens…

You ramble on for the whole hour you had scheduled. Something about blinking lights, flipping switches, and AWS will save us all. Microservices do things, AI for sure, and the backend won’t frontend unless you Agile. And if that’s not clear enough then you can always check out this diagram with a hundred different shapes and symbols available to you in the software you free trialed at 2am.

Yup. You’ve just lost them. Don’t worry, we can help your next idea get the traction it deserves.

Technical change that anyone can follow

Solving a meaty technical problem is already plenty hard on its own. Add in the pressure of explaining every nuanced detail and it can seem like a nearly impossible task. You don’t want to lose your audience to the complexity of the solution, but you can’t cut everything out either or it will seem hand-wavy. If you find yourself in a situation like the one above, you’re not alone.

Over the past decade I have given and seen crafted architectural pitches of all shapes and sizes. One truth I’ve come to learn is that nobody will ever really know your research better than you do. The good news is that they don’t really need to. Instead of trying to make your decision makers an expert on what you already know best we can better focus on communicating our main points effectively to earn their support.

To borrow from a classic, the Pragmatic Programmer:

It’s Both What You Say and the Way You Say It. There’s no point in having great ideas if you don’t communicate them effectively.

So how can we take the hard work out of communicating our technical ideas effectively to decision makers? Let’s dive in.

Use the business language

The easiest way to communicate the changes you want to make is by using the language people already know. If your business refers to something as X, it usually won’t help to start calling it Y (at least not at first). Words make the world we know. If your explanation requires everyone to change their vocabulary upfront then you are already asking for a lot from them. If you do need to introduce a new term or repurpose an existing one then clearly define that for them first. They will be able to follow along much better without getting completely lost first. You might be surprised by how often the same word will mean very different things to people in the same business.

It’s all about the benefits

Now that we’re speaking the same language, we need to make the what clear. In this case, I’m talking about the what are they getting out of it?

The key here is to know your audience, state the problem, and emphasize the top benefits your solution provides to them. Emphasizing the benefits does a few things:

1. It captures your audience’s attention because those benefits are important to them
2. It increases your chances of success because they want those benefits

Note that I said the top benefits. It’s often the case that your solution significantly helps A, B, and C, but only kind of handles D, E, and F. Be confident in the top benefits and sell those. It may take some repeating, but when it clicks it will be well worth it. Another advantage of selling less benefits is that if you find the discussion going sideways you can quickly filter out the noise and get everyone back on track.

It’s really important to not water down your pitch with less valuable arguments. While it may be true that your idea can help more than a handful of things, it is likely not the main discussion you want to have. At best you may distract from your main points and at worst you end up defending your solution against an impossible surface area that you never actually considered.

If the auxiliary benefits are too good to let go, then it’s best to take a note and come back to them later. Whatever you ultimately decide, don’t dangle benefits in front of decision makers that you won’t be building for. This will create misalignment between you and them right away. The next thing you know you will be upside down in a project you never wanted.

Map the path between here and there

Now that we have our decision makers attention we need to show them how we’re going to make it happen. But don’t dive into all the details just yet. Do you remember my earlier point that not everyone will know your research as well as you do? Now is your chance to bridge that gap for them.

Start with where you are today. Even if they already know, don’t assume they do. Ensure that everyones understands the state of what is about to be discussed. It’s very possible that by simply giving people a second to remember the state of things and think it over for themselves that you will gain a helpful ally. Don’t be surprised if someone chimes in recalling how much better this thing can actually be, but no one has brought it up before.

Once you are on the same page, you can now walk them along the path of changes you want to make. Be sure to finish at the state you want to end up in. The trick is to highlight the difference between where you are today and where you’ll end up tomorrow. High level diagrams are a great way to share this information.

It might be hard, but avoid excitedly trailing off into all the future possibilities. You might end up signing up for more work than you actually want and it’s more important that everyone understands the immediate benefits of where you are headed first.

Help them see the finish line

Finally, we want those supporting us to know that the work will not continue on forever. It’s important to know that the thing that sounds super complicated won’t blow the entire years budget or roadmap.

Technical projects have a bad rap for dragging on. We don’t want our changes to snowball into more technical projects and leave us with a big ball of mud that accomplishes nothing. I would guess that if you work in software that you can dredge up a few horror stories of changes that didn’t go quite as planned. While we can’t guarantee that won’t happen, what we can do is help the decision makers supporting our work feel good about what they’re committing to.

We can instill confidence in our decision makers by showing them that we are approaching this problem with a definite end goal in mind. Make it clear that the end goal you have in mind is motivated by the same benefits they want. Ideally the end goal we share is measurable and any progress or milestones should be demonstrable. Whether the results are good or bad is less important than taking responsibility for the changes you’re pitching and following through.

Some things you definitely want to avoid:

• Binary end goals. Things like “It’s done when it’s done” simply won’t give others a ton of confidence. Binary goals also offer very little flexibility to adjust or retro along the way.
• Don’t give an estimate you aren’t comfortable with to get the approval you want. This can hurt the overall success of your project and ultimately be bad for business.

Pulling it all together

Now that you have some communication strategies you can start influencing technical change in your company. However, we also want to maximize our time spent on the idea that brought us here in the first place. This is where a template can really help save time. We can take anxiety out of the pitch by reducing the above into a simple reusable template. Even though some pitches may require significantly more effort an elevator version to get a conversation started can go a long way. I find myself using this template often for medium to large size architectural changes:

We want to change how do we refer to this in the business
From what do we have today
To what are we implementing
In order to benefits we gain as a business
We know we’re done when tangible results or quantitative metrics of success

A quick example

Let’s say your company has an ongoing survey that is collecting open ended product feedback. To keep it simple we’ll pretend that this data is being collected in a spreadsheet. Each week someone manually reads this data and categorizes it as positive, negative, or neutral for a later discussion.

If you only have a few clients this might not be a problem. However, what if you need to handle thousands of responses? Also, who will be reading this feedback and how can we account for their potential bias? Is this the best use of that person’s time?

Let’s put together a quick tech pitch for that work:

We want to change how we analyze our customer product survey responses

From a manual process of reading and labeling the feedback responses based on a limited set of working knowledge that a person can fit in their head

To an automated sentiment analysis tool that runs the same data through a Cloud Providers NLP API and compares against the entire set of feedback

In order to help manage the volume of feedback we get, reduce reader bias, and more quickly and accurately alert us to important trends in our data at lower cost

We know we’re done when we have successfully analyzed, labeled, and automatically delivered a weeks worth of results to our happy stakeholders email group for further discussion.

…would you like to know more?…

Wrapping up

There are many ways to pitch technical changes across your business. I have found the strategies above and having a few templates on hand to be a real time saver. Be sure to have fun blending these ideas across different mediums to keep it fresh and find what works best for you. I encourage you to incorporate these ideas into your next tech pitch or try them out in a roadmap planning. We’re always looking for great ways to communicate our ideas effectively and would love to hear from you!

Carlos Avila

Carlos Avila is an Engineering Manager at FloQast focused on developing top talent and a world class AutoRec product. Previously a Technical Leader on FQ Close, Flux, and Analyze, Carlos considers himself a recovering full-stack-aholic and craftsman of all things product engineering.