How to Drive Meaningful Change - Delivering your proposal
Having a great idea is unfortunately not enough to get it approved. The delivery of your proposal highly impacts the odds that proposal is approved.
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.
Delivering your proposal
After you craft a proposal, you need to effectively deliver it to the decision-makers and stakeholders. Knowing how to effectively tell your story and manage details can determine how successful your proposal is.
Concisely summarize
It’s really important to know how to summarize your proposal concisely. Leaders and executives typically don’t have a lot of time, and your item is likely on a long list of asks and problems they have to address.
Think about what your proposal - a summary structure will likely follow these patterns:
“I’ve looked at this situation, and we should do this for these reasons.”
“There’s a big problem here, and I have a path forward - here it is.”
“Here’s a quick description of what’s happening. here’s what we’re doing next.”
“Here’s what I need to achieve this result.”
“I have additional information - I need guidance on directives based on this information.”
You need to be able to quickly:
Make your ask clear
Establish context of the problem
Establish context of the ask
Remember: the value of the planning is in the plan. While you may not ever show anyone your proposal summary, crafting it allows you to think through it in a way that the major points are clearly laid out and addressed.
Make your ask clear
Most of the time, you are asking for something: a decision, a resource, information, etc. If you can’t articulate your ask and why you are asking in a single sentence, you aren’t being clear enough.
It’s not that you'll always present it in that short a format. It’s just that the skill of boiling it down is valuable for distilling the essence of whatever you want out of your proposal and drives attention to exactly what you need.
Once you understand what you’re trying to ask/recommend/conclude, start with that.
An example of a proposal summary to give raises:
I need to redirect $1,000,000 previously earmarked for additional hires into increasing compensation for existing team members.
Due to our rapid growth and lagging compensation strategy adjustments, we currently have new junior developers making more than tenured senior high-performing contributors.
The recent accidental leakage of the company salary spreadsheet has caused significant morale issues in all of our high performers, with churn expected for over 30% of our team as a result of this issue. Losing our top performers will ensure we will not meet our funding goals for this year.
We must ensure we balance and achieve equitable compensation for our team to be able to move forward. Losing all of our top performers is not an option.
Establish context of the problem
You can’t just ask for something and expect to get it. You need to have a reason or “why” behind your ask. That’s the context you need to summarize and deliver.
Context requires:
Explanation of a problem
Explanation of the cost of the problem
Explanation of the value of solving the problem
Explanation of the stakeholders of the problem
Most importantly - you need to establish the magnitude of the problem. Revenue terms are often the most impactful, but other framing like reputation, risk, retention, etc. can all be effective depending on your audience.
An example of a proposal summary to change an incident response:
We’ve experienced a quarter-million dollar incident, folks, and we are on the verge of making it worse with our recovery plan - I need alignment on a different plan.
Due to our earlier decision of releasing our fund management dashboard before testing was fully completed, a severe defect was identified in our refund logic. The defect, now fixed, temporarily allowed users to issue repeated refunds for the same transaction, which pulled money directly from our bank accounts. Operations has identified our system automatically issued $230,000 in duplicative refunds that we are unable to claw back automatically. Their recovery plan involves pursuing legal action against our top customers to claw back the money.
This will greatly damage our reputation with customers far beyond the cost of the incident. I recommend instead that we eat the cost as the reputation damage will out-weigh the funds recovered.
Establish context of the ask
Chances are if you are making an ask or proposing something, you already have a solution or direction you’d prefer in mind.
This is your intent or recommended solution. Be sure this is extremely clear and show evidence you’ve done the thinking.
I’ve seen many a proposal sink because the proposer didn’t make it clear what they were specifically asking for and why, or that they didn’t prove they did the thinking to provide confidence in their proposal.
Context requires:
Explanation of your ask/intent/solution/recommendation
Explanation of why of this approach
Explanation of tradeoffs and factors
An example of a proposal summary to change a technology:
I intend to transition our company from UJS and onto Vue.js.
We’ve experienced dozens of critical defects in just the past month and extremely delays in even simple front-end changes as a result of complicated UJS and lack of front-end or Javascript knowledge in our organization. If we wish to achieve our company’s development outcomes, we must address the root cause of the issue - our company’s increasing struggle using an outdated technology to achieve outcomes it wasn’t built to support. This requires a new front-end technology.
Vue.js, while new to me, is an extremely similar technology to Angular 1 that I am a deep expert in and can effectively train and educate a team around. I can, within three weeks, rapidly set up a front-end component and infrastructure system and conduct trainings to educate the team. I expect that even our back-end engineers can effectively make front-end changes within 2 weeks.
I evaluated other technologies like React and Angular 2 and found them quite difficult to use relative to the simplicity of Vue.js. The lack of in-house expertise also makes these challenging to build expertise for across the team.
Transitioning to Vue.js will greatly accelerate our product development efforts by a factor of 3x with higher quality, design fidelity, and lower defect rates.
Use the right proposal medium
One you have your proposal locked, you need to use the right proposal medium to communicate your proposal.
Presentations
Written documents
Group discussions
1:1s
Instant messaging
Presentation
A slide-deck presentation can be effective for asks to groups where the high-level details are enough to make a decision.
Some things to keep in mind:
Presentations aren’t great at diving into things or explaining a narrative.
If it requires deep thinking, it’s likely not the appropriate medium.
Keep it short. Less than 10 slides should be plenty. If you need more, you may benefit from another medium.
You’ll still likely need to prepare supplemental materials that dive into details.
Written document
A written document detailing your proposal can be extremely effective. You have tons of space to add details, explain thought processes, and dive deep.
Keep in mind:
It has to be extremely well organized. Without an effective narrative structure people will get lost.
Use the “newspaper approach”. Start with the headline, then summary, then go into details. Ensure you don’t start at the details or else people will get lost. Your conclusion should always be clear.
People may not have time. If you’re talking with your leaders, you want to be cognizant of their time and effectively leverage their attention span. A dense, multi-page document may just not be read.
Group discussions
If you need decisions from multiple people at once, or there’s a lot of stakeholders that might have thoughts, it’s useful to have a group breakout discussion.
Keep in mind:
It can easily derail. Try to redirect people back to the subject or topic at hand.
Objections are highly visible. It can drag down decision-making or confidene in the proposal if people get stuck on the fact objections exist. It’s always useful to frame the objections and remind people of the magnitude or relevance to the decision at hand.
Discussions may get uncomfortable. Handling public objection is a learned skill, especially on a proposal you may have crafted and have a vested interest in. Learn how to not take it personally or get nervous when conversations get deep and questions get extremely pointed.
Ensure enough time on the agenda. Some people think a decision is going to be made quickly so they only reschedule a few minutes. When discussions run long, the context-setting or decision gets deferred for other matters, which causes decision-makers to sit with incomplete information. The incomplete information can bake for days or weeks into an uninformed perspective or decision, derailing hopes of proposal acceptance.
Know where people stand. You can use 1:1s to shop around a proposal and get thoughts before presenting to a larger group. This helps you incorporate new perspectives, address objections, and find weaknesses in the proposal early. Just don’t ask for a decision - make it clear it is a work in progress.
1:1s
1:1s are a great avenue for shopping a proposal around. People typically are more open about their thoughts than they are in group settings, and you can really dive deeply and openly into the thoughts around the proposal.
Keep in mind:
At executive leadership levels, some 1:1s don’t stay 1:1.
At individual contributor and manager levels, people can generally correctly assume 1:1s are 1:1s - nobody else will ever know. At leadership levels, things discussed in 1:1s are not automatically restricted to just those two people.
It may surprise those not used to it, but it makes sense if you take a step back and think about it. When you’re talking to an executive and proposing an idea that impacts the company, you’re talking to a representative of the company and other leaders. If you propose something related to the company or is relevant to other executives, it’ll naturally get discussed with other executives. Decisions don’t happen in isolation - if you bring up something affecting a function, it’ll likely get brought up to that functional leader to address.
This is pretty easy to deal with - be explicit if you want something to remain private. The strength of your interpersonal relationship with that person helps keep things private when you want them to be.What people say in a 1:1 may differ from a group.
I once secured “buy-in” on a proposal to change the organization structure from every individual decision-maker, only to have all the individual decision-makers disagree with the proposal when I presented it to them in a group - despite them all individually agreeing to it!
It wasn’t that they were lying - it’s just that the dynamics of group decision-making can’t be avoided. There’s external pressure, perception management, personal factors all interplaying in real-time during a group discussion. How one person personally feels and thinks may be completely different when in a group.
In the case above, I pointed out that they all actually agreed with the proposal individually, which helped reset the decision in the group.Interpersonal relationships really matter to the honesty of thoughts.
Honesty requires trust from both parties. Trust is a sensitive thing where history, competency, integrity, perception all play a key role in determining how open, truthful, and direct you can expect a relationship to be.
It’s key to maintain good relationships with people you work with, and to not let ego, personal disagreements, or pettiness disrupt your working relationship. Work is work, and it really shouldn’t impact your perspective on someone as a person and human being. My advice? Always keep the other person’s best interests in mind, and support them when you can.
Instant messaging
Sometimes you don’t need a formal touchpoint to submit a proposal or get a decision.
You can just send an instant message, either directly to a single person or or in a group.
Some advice:
Try not to write a wall of text. Your shortened summary statement actually help here an comprise the bulk of the message. You can link to additional details in another written document at the end of your message.
Be cognizant of message visibility. It’s easy to accidentally include more people than needed in a decision, or to forget a key decision-maker when making a group chat. Always double check your list and adopt a ”just enough” approach to decision makers to avoid an awkward situation where you need to remove someone or include someone after a decision was made.
Expect it to go into overtime. Some decisions may end up being larger an require deeper discussion. These tend to experience a medium change, such as being deferred to a breakout discussion or put on the schedule for the next committee meeting. Try not to push too hard after this point and wait for the time if you can.
Tone gets lost. If you find that the conversation is going nowhere, it might be a matter of talking past each other. Defer to a breakout or other conversation where people can align and get a better sense of where they stand than what instant messaging provides.
Keep a separate decision log if you’re dealing with a long-lived complex chain of decisions. Decisions tend to get lost amidst message an channels. If your proposal or decision involves a long-lived topic, it’s helpful to keep a decision log to track them over time, particularly if people forget what decisions were made in the past.
The amount of thinking that goes into a proposal does not need to be reflected in the actual delivery of the proposal itself.
I once wrote up a 10-page document on an organizational change. I articulated trade-offs, discussed alternate options, discussed failure modes, success criteria, and all manner of thinking into an extremely detailed, cohesive plan, complete with charts and data.
Once I did that thinking, I sent my CTO a two sentence instant message letting him know that I had a plan to adjust the organizational structure, and that we would not need more money. The CTO, satisfied, approved it.
Other advice for delivering your proposal
Be ready for a lot of questions.
Leaders, especially executives, will hone in on the stuff they care about. Some proposals might have zero questions, but others might have dozens.
Some questions might be very surface-level, others might drive extremely deeply even into areas you wish they didn’t go into. While you should do your best to preemptively think of and answer questions, it’s unlikely you’ll be able to address every single question before they are asked. Some questions are intended to poke holes, others are to help the leader build context. Some might just be intellectual curiosities for the asker. Some might be because there’s strong disagreement. Others might be because there’s strong agreement. You can’t assume the intent from the question alone.
Answer them factually and don’t get anxious or take offense. It doesn’t mean the leader is against the proposal - they just want to better understand it. I often see people answering questions with “justification” answers - trying to make themselves and their proposal look good vs. answering truthfully. Some end up blabbering in an effort to avoid answering the question. Neither builds confidence in the proposal.
An IT professional once gave me his proposal for securing our physical office network infrastructure to achieve compliance with PCI regulation. I asked a lot of questions. Questions about the tradeoffs, the cost, the firewall capabilities, the hardware maintenance costs, the setup and management time, personnel requirements, and more.
By the end of it, I was extremely convinced that the person had done their research and kept our company’s best interests aligned, and had considered the risks, benefits, and constraints thoroughly. While we had minor disagreements in approach, they were personal preferences or unimportant quibbles.
I approved his proposal in its entirety.In a conversation afterwards, his boss said that I had scared him during my questioning. Because I was asking so many questions, the IT professional had believed that I was fully against the proposal and was trying to sink it. My questioning came across as intimidating.
Know when to stop talking
Whether it’s nerves presenting to an executive or just personality differences - some people just keep talking far beyond when their point has been effectively made and the proposal is ready to be decisioned.
Sometimes, this causes other areas of concern to open up, derailing a conversation or causing other factors to take precedence that change the decision.
It’s important to read the room and know when your point has been made. A useful mental model is to view your role in the delivery of a proposal as setting the stage for a show about making a decision. You’re not there to act in the show, so get off the stage before the show starts.
Useful phrases in your toolbox
Adapting to objections and changes in real-time can be difficult for some people, but it’s useful to have some phrases you can fall back on to help direct your thoughts.
Some of these phrases include:
“I don’t recommend that, and here’s why...”
“We did analyze that option and do not recommend it because…”
“We can make that work, but our belief is that the more effective option is…”
“I think that’s a great idea, and we can get started on it immediately/as soon as you want, provided…”
“I defer to you all, but my personal opinion is…”
“That’s a fair point, where does it fall in the set of tradeoffs we need to make?”
and so on.
When you adapt or address an objection, counter-proposal, or other statement during delivery of your proposal, make sure you:
Make it clear you understand the objection or counter-proposal
Make it clear you’ll commit to any decision that does get made
Make your own position / recommendation clear
Make it clear you are flexible when you are, and not flexible when you aren’t
Don’t worry about the credit.
You might not get credit or recognition.
Proposals can sometimes change form in tiny or large ways. This may muddy the waters as to who is responsible for a brilliant idea. Sometimes it’s the last person who spoke and had their idea incorporated. Other times it’s the most authoritative person in the room. I’ve had reports take full credit for something I explicitly prepared and directed them to do as if they came up with the idea themselves.
At the end of the day - it doesn’t matter. Trying to get credit might mean you reject otherwise good improvements to your idea, or lose someone who could’ve successfully drove it forward. It might mean you focus too much on optics instead of substance.
Remember - your goal is to affect organizational change, not get credit. Don’t worry about recognition - it doesn’t matter.
Focus on the goal: improving the company.
Having a great idea is unfortunately not enough to get it approved. The delivery of your proposal highly impacts the odds that proposal is approved. Stack the deck in your favor by avoiding common mistakes and making it as easy as possible for decision-makers to decide.