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.
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.