How to Drive Meaningful Change - Crafting your proposal
If you’re trying to drive a meaningful change, you’ll need to be formulate your idea and get buy-in from many stakeholders across an organization.
Everyone can benefit from understanding and knowing how to build influence, implement change, and shape the organization and culture.
Much of it relies on learning and understanding the soft skill of navigating organizational politics.
This article is part of my series How to Drive Meaningful Change.
Crafting a proposal
Crafting your proposal
An idea isn’t useful in and of itself. It requires execution and delivery. If you’re trying to drive a meaningful change, you’ll need to be able to formualte your idea and get buy-in from many stakeholders across an organization.
This requires you to create a compelling argument to convince others of the merits of your idea. Your proposal needs to be able to tell a story or narrative that relates to your stakeholders and decision-makers: the people who ultimately in charge of approving or rejecting your idea.
Your proposal should be well-researched, with data, sound arguments and clear, concise summary of the problem, the solutions, and the recommendation.
Do your research
The first rule of proposing something: know what you’re talking about. This obviously means doing your research.
What exists today?
What has been attempted or tried in the past?
How aware are people of the problem/change/solution you are proposing?
What are the risks?
What are the important tradeoffs?
Every aspect a proposal where you are not aware of existing efforts, possible problems, or other issues undermines the credibility of your proposal.
Stakeholders expect you have done your homework. If you have too many unknown unknowns because you didn’t do your research, you harm your credibility. Unknown unknowns that should be known knowns is a signal to deciders that you didn’t really think that deeply about what you are suggesting. At some threshold, your proposal will be rejected outright on the grounds it was not as well thought out as it should.
The importance of knowing current state
I once worked with a senior engineer who proposed a scaling plan to avoid an outage during our busy season that he spent several weeks writing. In it, he proposed a massive re-architecture.
I read it and rejected it outright.
He didn’t match the desired risk profile. His proposal was a big-bang change of a massive amount of infrastructure components and a complete rethinking of the data lifecycle. This would have taken on so much risk and required so many changes across the entire application that it was likely we would have broken our system ourselves a hundred different critical ways. At that point, I would have preferred to have an outage instead of the many data issues, defects, and other problems his approach would have caused.
He proposed things we already had. It was clear he didn’t do his homework on what we were already using. He proposed large different implementations for capabilities we already had, such as asynchronous message passing or reading from replicas. His proposal was framed as if these did not already exist to strength his argument, when in reality much of what he was proposing was a re-creation of capabilities we already had. There would have been little to no benefit to change our implementation for the significantly added cost and risk.
He proposed things we already had smaller, easier plans to do. It was clear he didn’t look at any of our existing documentation on our scaling plans or talked to any of the stakeholders. His proposal contained complex plans for things we already had simpler plans to do, such as vertically scaling or distributing load or leveraging caching. His plan increased the complexity of the effort and ignored many of the low-hanging opportunities that would have negated the need for many of his ideas.
It wasn’t that his plan was bad - it was, in theory, good. His issue was that he failed to account for existing work and the current context of our organization. This meant his proposal was, in practice bad, especially relative to our existing plans which were much simpler and more efficient with lower risk.
Form the right narrative
If you did your research and you have a great idea - it’s not enough. Unfortunately, convincing people requires more than facts. It requires a compelling story that helps people connect the dots to why you are proposing what you are proposing.
This is the big flaw I see with many people proposing changes and getting them rejected. They fail to clearly create a narrative structure. Instead, they dump a bunch of random statements and numbers on a page or deck, making it hard to follow. Or, they immediately jump into a solution without identifying why they’re even proposing it. By the end of it, the decision-maker doesn’t know what the problem is, let alone what the solution is, why it’s being asked for, or even what was being asked for.
They reject it out of sheer confusion.
Be structured
When you craft your proposal, you need to form a narrative that is well-structured an flows as expected. You’re telling a (hopefully true) story to decision-makers, taking them along on the journey.
You need to quickly orient them, answer their questions, and highlight the primary areas of importance, such as:
Why is this being proposed?
What is being proposed?
What are the pros?
What are the cons?
What are other options?
Who is involved?
What’s the value of doing it the way it is proposed?
There are many narrative structures that can support you here:
Pain point and solution. There’s a pain here. It’s causing <X> issues. Here’s a proposal to resolve that pain.
Problem → Solution → Value. This problem exists. This is the proposal to solve it. Here’s the value of solving it.
Simple math. This opportunity to capture or save <X> value exists. This is the <Y> cost to do it. <X> is greater than <Y>, so we should do it.
Bets. Here is our goal. We have information that indicates this approach will lead to <Y> value. We are going to size a bet that costs <X> to capture this improvement.
Intent. Here’s what I intend to do to solve this problem. Do you have any objections?
What narrative resonates depends on what you are proposing and to who, and the context.
Know what is important to the decision-makers
If you don’t know what is important to the decision-maker, you won’t be able to provide them with it. If you can’t provide what is important to the other person, they’ll either not care about your proposal, or they’ll reject it because you didn’t sell it from their perspective.
What does the person care about? The subjects are limitless: Cost? Risk? Impact? Numbers and data? Alignment with strategy? Impact to another project or effort? User benefit? Predictability? Impact to the team?
Ask yourself what the stakeholder cares about. Suppose you’re presenting an idea that has finance as a stakeholder, you’ll want to ask yourself:
Does finance care about the cost of an initiative?
Does finance care about the value of an initiative?
Does finance care about predictability of expenses?
Does finance care about the reliability of estimated expenses?
Of these, does finance care about one in particular more?
If you can’t explain possible ways how or reasons why the stakeholder will reject your proposal, you don’t fully understand their perspective.
Once you do understand, bake that into your proposal. Show numbers to people who care about numbers. Talk about user benefit to people who care about user benefit. Show resource utilization to people who care about resource utilization.
The opposite of this is also true - don’t focus on something they don’t care about. If you know that a decision-maker doesn’t care about numbers an data, then don’t spend your whole proposal discussing numbers and data - it won’t resonate.
The importance of knowing your audience
Engineers often propose technology and practice changes in technology organizations that I lead. Proposals range from things as granular as new linting standards to as monumental as organization-wide technology stack.
Many engineers trying to introduce a new technology emphasize the positive resume/career impact on them personally, and the adoption of the technology by larger enterprise companies. They focus on things that they think are valuable, and not what I actually consider during a decision.
The problem is that whether there’s an impact on their career or that massive companies are using it aren’t factors in my decision. Instead, I care about things like:
How long will it take to migrate?
Do we have enough of “critical mass” of people in the organization that can sustain our usage and adoption of it?
Across all of our innovation portfolio and organization, is this the most important technology to implement currently to slow down to learn?
What are the benefits to speed, throughput, and quality?
What classes of problems does this address, and are we experiencing these problems at the rate that I want to invest in resolving them?
What do the next 3, 5, 7 years look like for this technology and its upgrades?
Does the technology’s upgrade cycle match our ability to invest in upgrading?
Does the technology’s market-wide trend enable effective hiring or training?
Does the technology still provide benefits at the scale and size we operate at?
These questions matter significantly more than whether it’ll look good on a particular engineer’s resume or whether a big-name company that operates in a completely different context uses it.
I’ve often rejected weak proposals that didn’t factor in these interests. Engineers were ill-prepared for the kinds of questions I sought answers for, and the narrative and arguments they made up weren’t compelling.
Don’t hide from the weaknesses in your proposal
In an effort to get their point across, a lot of people hide the weak points of their argument or proposal. They do this because they aren’t confident in their proposal enough to overcome objections. By hiding it, they believe they’ll be able to hand-wave or gloss over it, skipping a potentially difficult discussion.
Don’t do this. When the proposal gets discussed under scrutiny, you will get caught off-guard and be unable to answer important questions, which undermines your credibility, or even worse, results in fatally flawed proposals being accepted, which isn’t good for the company.
It’s a mistake to ignore or hide the weaknesses of your proposal. Instead, be explicit about the drawbacks and try to figure out:
Are they valid?
Are they high impact?
What is the risk of this weakness being encountered?
Can this weakness be compensated?
Is this an acceptable risk?
Once you identify the weaknesses, address it explicitly. Be up front about possible mitigations, or even solicit ideas for addressing the risk.
The more thoroughly researched, the better. Document potential objections, gauge their validity, and find counterarguments for them.
Remember - the point of a proposal is to swiss-cheese it and poke as many holes in it as possible. If it’s still standing after that, it’s more likely a good proposal.
The more you yourself poke holes in your proposal, the more prepared you will be to answer objections when decision-makers do it.
Be clear with you recommendation
When you’re proposing something, there are likely other alternatives to your approach to solve the same problem. When crafting your proposal and including possible solutions, you have to be careful to know what you don’t want.
Many people fail in this for some strange reason by leading with an option that’s the opposite of what they want actually want to do. Sometimes they’ll present multiple approaches as equivalent even when they have a strong recommendation - they fail to highlight what they are actually looking for. When decision-makers inevitably decide to do a thing they didn’t want, they are shocked.
It’s their fault, really. They didn’t make their desired outcome clear, instead providing the entire palette of options as equivalent.
Lead with your desired direction. Always make it clear what your recommendation actually is, and the strength of your recommendations.
You rarely want to give options you don’t want people to take. If you want to be comprehensive with the options, you can list them as rejected options due to various considerations, but you should always mark when an option is recommended or not recommended.
Polish your proposal up
Once you have created a proposal, take a step back and examine it. Be detail-oriented.
Use the right medium
There’s many ways a proposal can be articulated - verbal, a presentation, a short memo, a message.
You need to make sure you choose the right medium and approach.
Some of this depends on your audience - do they want to or have the time to read a giant document? Will a slack message be more effective? Do they need guidance through a presentation or an in-person discussion?
Whatever the case - match your proposal with the person and context. If you write a 10-page document for a simple, minor budget ask, you may just get rejected because of the length. If you put an ask to do a company-changing direction in a two-sentence direct-message, you’ll likely receive an immediate rejection followed by setting off a lot of alarms.
Ensure your story is cohesive
Cohesion is about removing unnecessary or irrelevant details and information.
Your proposal is about the believability of the story, not the comprehensiveness. That’s not to say you should hide or lie or remove important information. But you should be cognizant that not all details are relevant to the decision to approve or reject a proposal, and therefore these details should be removed to achieve a coherent flow.
You can save extraneous details for a deeper dive for actual implementation or as supplementary material for those interested.
The importance of removing the unnecessary
I once received a proposal to change our build pack technology from one of my engineers. Much of the document in particular was filled with code-level concerns and various line-by-line package changes, comparison points, and other examples.
I skipped almost the entire proposal because it wasn’t relevant to deciding whether we wanted to switch or not. Instead, I did my own research and approved the proposal. If I hadn’t had the time, I likely would have rejected it outright.
A single sentence that had said “Build definition files are 30% shorter and 3 minutes faster” would have been perfectly fine to illustrate the point, and saved me time.
Make it professional
I’ve seen many proposals littered with typos, work-in-progress sections, run-on sentences, incorrect data, or irrelevant fluff. These are all diminished my confidence in the actual thinking and preparation behind the proposal. It made me think the idea was half-baked, and I put less effort into trying to figure it out.
If you’re going to present something, make what you are presenting is polished. It doesn’t have to be aesthetically pretty, but put care into it.
Use headings and paragraph breaks. Use tables. Form complete sentences. Run auto-correct. Pay attention to the details.
Your proposal is your chance
You need to do your research, think through your proposal, carefully consider your audience, and be sure your ask is clear. When you put your thoughts in a structured format appropriate for the ask, it helps prepare the decision-makers to make a decision. The easier you make it to make the decision, the more likely it is the decision lands in your favor. Without the ability to craft effective proposals, you’ll be unable to drive organizational changes outside of your sphere of authority.