🤝 How to get traction on your proposals as a software engineer
Strategize your communication to get support
You had an idea. You worked hard on a proposal. You made it to the public and got some feedback. You brought it to the person who handles the engineering resources and can make it happen… but they rejected the idea.
You may think there is some critical aspect that invalidates the proposal. But you can't find it. It may not exist. Getting traction is much more than the technical proposal itself.
I remember reading "What does it look like to be a senior+ / staff software engineer?" from
and I wanted to dive deeper into getting the buy-in for your idea. Here are my conclusions.🏆 Takeaways
How to build the idea with a visibility-first mindset.
How to execute your written communication.
How to drive your review and decision-making meetings.
👀 Adopt the visibility mindset
Everything starts with an idea. First, the idea has to make sense. I have written about aligning your actions with your company's goals. We'll assume here that your idea is aligned.
If you don’t have any idea, start exploring and create a list. Now you may have 10 ideas. Rank them in priority, pick the first 2, and drop the rest until you finalize them. If you were constantly context-switching between 10 ideas you would be snacking instead of doing meaningful progress.
Nobody will support this idea if they don’t know why it’s good. You need to create visibility.
Start by giving your idea a name. Don’t write in the title of a document “proposal to migrate from a monolithic architecture to serverless leveraging x technology”. Instead, write things like “Project Merlin”. Once it has a name, people can talk about it. This gets psychological traction.
🖋️ Document decisions in writing along the way
In today’s world, ideas are not told. Ideas are read. You write and socialize a document.
After a brainstorming session with your coworkers, you may think everyone is aligned. Wrong. You may be super smart, but other people’s monkey mind is already into some TikTok video and forgot about the meeting outcome.
You have to do some tactical writing. After every meeting, you email the participants with the meeting notes and add them to your document. Highlight when there are disagreements and people end up agreeing to proceed even if not fully convinced.
This is especially important with external stakeholders. They are likely to change their minds. It’s not that they lied to you the first time. You may talk every day to your coworkers, but not to external people. They just forget. Their next read on your proposal may start from a negative point. To prevent this, remind them of their previous take on the proposal, and change their starting point.
Every single meeting goes with its meeting notes, highlighting the hotly debated topics, conclusions, and action items with owners. This is not a nice to have, it’s the leverage of your idea.
👯 Know your audience
You don’t just write your idea for anyone to read it. You start with the target audience first and prepare your message for them.
In general, decision-makers are not tech people. Prioritize business instead of technology preference. Solve a real problem, don’t give a solution to something nobody cares about.
A single proposal is communicated very differently according to the intended audience:
When the audience is an engineer, you communicate improvement in developer experience and technology choice benefits.
When the audience is a manager, you communicate a reduction in future delivery effort and additional engineering capacity in the year for new projects.
When the audience is finance, you communicate savings in money required for a project thanks to the savings in engineering capacity.
When the audience is business, you communicate revenue opportunities thanks to taking on more projects in a single year.
Understand the context of your organization. Some organizations want information shared only as needed while others prefer information open to everyone. Organizational politics will change who are your stakeholders and who to pitch the idea to first.
Do some tactical meeting preparation. Before scheduling any meeting, understand its purpose: brainstorming, validation, or decision-making. Communicate the intent in the meeting agenda.
When involving different parties, ensure the same levels and roles for each. Avoid unbalanced meetings.
Never present a problem without a solution. Prepare for the follow-up questions. The SCQA framework comes in handy: Situation, Complication, Questions and Answers. Whenever a question is asked more than once in a review, write it in the FAQ section.
🏋️ Do upfront work to reduce friction
Find data to back up your proposal, but don’t overload. The same thing with your words, use simple words and keep your writing concise.
Approach your documents as 2-step reviews.
In the first one, you expose a high-level idea and alternatives. Socialize this document with relevant people: Your team, your senior engineers, senior engineers from impacted teams, etc. You want to get their buy-in on the proposal. There’s nothing worse than having a split team and disagreements after multiple weeks of work. A pre-agreement saves time.
In the second step, you dive deep into the pre-agreed proposal to make it solid. You can still change after new findings. But most of the time, changes occur in the first review.
Usually start by creating traction inside. Your manager is the first person to get aligned. If you think it’s about having bad managers, then run away from that team. you are not going to get support. Don’t intend to get traction on an idea without alignment with your closest people. This breaks people's trust, you are skipping them.
When changing the status quo, your words in a document won’t be enough. People are reluctant to change. Don’t try to impose it. Give a talk, start applying it to yourself, create tooling around it… make it easier to switch.
This is where you want to prototype fast. It’s easier to understand a prototype than an idea in a doc. It also attaches your name to the idea. No matter how many people work on it, it will be Mike’s script or Tom’s template.
💬 Prepare the review meeting
Read the room before making strong moves.
Your goal is not consensus, but getting people not to disagree blocking you from proceeding. This works for technical meetings and decision-making meetings.
I have found myself being more of a diplomat than an engineer in review meetings. When you don’t agree with something, disagree agreeably. People believe in their comments. Don’t dismiss them, but don’t let them hijack your meeting.
Acknowledge their proposal by writing down the comment in the design doc. People may be skeptical if you write in a private txt file and later ignore it. To solve this, in the next review or when you address their concern, make sure you give visibility to them about it. This builds trust that you are not ignoring their comment.
Everything starts with your mindset. Approach with genuine curiosity to learn what other people noticed that you didn’t.
Your purpose is not to defend your solution against comments. You are finding the best possible solution and helping people arrive at the same conclusion as you.
Be careful with your words. Instead of “I know my solution is better than yours”, use “I think this solution has benefits that we may want for this project.”
I have grown a lot since I joined a design review group in my org. We have zero stakes in the teams of the people bringing the designs. They don’t have to justify not following our advice. We can just provide recommendations and highlight risks as a way to help, not as a way to force. Approach reviews to build a better solution, not to destroy the proposal.
😭 When things go wrong
Understand your audience’s intention in their comments. An executive’s job is poking and pushing back on every idea to make it stronger. An engineer may kill the idea after flagging a critical unknown issue. Treat their pushbacks differently.
Also, it’s important to understand the roles of power. Some people want you to come back after the pushback and feel that they have taught you how to do it properly.
When I was in high school, the literature class had less than a 10% pass rate in the first quarter. Our lovely teacher wanted everyone to feel incompetent, so she didn't explain the proper way. Then after the bad results, she started explaining the correct method and people ended up the year passing the exams. Some people have a big ego and want to be your savior. Swallow your pride and ask questions. Make them feel it was their idea.
For promotion, nobody cares who participated in the discussion, only how well you drove and executed the project as lead. Don’t go into fights of “my idea vs your idea”. That’s just killing any traction on it.
The fastest you can go is not staying isolated in a cave and coming up with a finalized proposal. Move yourself, connect with the relevant people, take their feedback, and lead the initiative. Don’t give up on the idea on the first pushback, make it better thanks to it.
😋 When things go right
Congrats, you got your engineering resources to execute an idea and people seem aligned. But this is just starting.
How to execute a project could be its own full-length post. For now, make sure you have a realistic plan to deliver on your target date and a nice communication cadence of the progress and blockers.
🚧 A word of warning
Avoid false promises and committing to impossible deadlines with your leaders.
You may get approval from leaders to pursue the idea, but missing the promises gets you in a worse position. They dedicated resources to your idea and you failed.
You may get the project delivered at the expense of burning out the team. That creates a bigger problem of employee attrition for your leaders. They dedicated resources to your idea and you didn't give them back in good shape.
🎯 Conclusion - The traction strategy
Getting traction is not about the idea itself. It’s about the soft skills to socialize the idea and drive its discussions.
Written and verbal communication are key. Start with the audience and work backward. Document your proposal in writing and drive reviews with the appropriate stakeholders.
And communication is not only about words but about understanding organizational politics and roles of power.
🗞️ Some news
This week
added my recommendation blurb to the subscribe page of his newsletter. I’m so grateful to be next to two blogging referents that I admire! (Check newsletter)Thanks for reading until the end. This post was a bit longer and you showed your commitment. You are a real career strategist!
- Fran
👉Another way to help me is by clicking the ❤️ button at the bottom of this email
👉Connect with me on Linkedin or reply to this email
Super useful thoughts. Thank you for sharing, Fran!
I would add prototype testing or PoC to this list. What are your thoughts about that?
I have written an article about the benefits of prototype testing that you can check out here
https://open.substack.com/pub/basmataha199/p/making-informed-decisions-with-prototype?utm_source=share&utm_medium=android&r=2tl0x2