Hamilton Ulmer

Tools for Data Analysis

How to build a proposal culture
Feb 2, 2022

The Zoom Monolith

It’s hard to say for sure, but more than likely, some amount of “remote work” is here to stay for those of us who can sit in front of a computer to earn a living. Which means that most of those in-person meetings and moments that enabled us to build rapport, trust, and candor with our teammates will continue to be swapped with the monolitic Zoom call.

We’ve all had this experience, especially early on in the pandemic: someone schedules one of these video meetings with a bunch of people, and there’s no agenda other than to “get to a decision on thing X”. The meeting becomes chaos due to the the caucus rule (“the first person to utter something gets the floor”), making hard-to-impossible for our teams to align and communicate effectively.

It’s hard to get stuff done over Zoom. And let’s be real; even when our Zoom interactions are structured, they’re still absolutely exhausting, and we just have way too many of them. Tone and intent easily gets lost; the signal lost in our collective fatigue and the god-awful form factor. We are desperate for a bit of IRL discussions but we simply can’t get them over video.

So how can we deliberate about what solutions we’re going to build if we can’t hash out the hard details together in person like we used to?

The Mozilla data engineering team has a solution to this problem that they call Proposal Culture, a methodology that enables effective distributed technical decision making via writing and collecting feedback on a written document in an inclusive, async-friendly way. I had the chance to be immersed in this workplace writing culture for a few years as a data scientist building data tools with them, working with developers distributed across continents and circumstances.

Proposal Culture offers a few antidotes to the Zoom remote decision-paralysis problem:

Sounds great, right? Proposal culture boils down to a simple process:

  1. Someone writes the technical proposal in a Google doc & shares it with their team.
  2. They give the writer feedback and critique in the proposal itself, which gets actively incorporated into or addressed in the proposal, mostly asynchronously & when it is convenient for the feedback givers.
  3. Once the feedback process is done, it gets “approved” (whatever that means for the team), and then resourced & implemented.

“Wow, put your proposal in a Google Doc? Groundbreaking” you jest. You and your team are 100% already doing parts of this process. Maybe all of it! Heck, you’re probably reading this note to procrastinate on writing up that one memo. We can all agree that technical writing is simply part of the job.

But in practice, there’s more than meets the the eye to this simple design. What follows is a curation of two years of field notes and observations on Mozilla data engineering’s Proposal Culture as I’ve experienced it, both good and bad. It’s a reflection of my own particular experience reading and writing proposals; I’m sure others on the data engineering team have other insights & probably other takes. I’ve also seen Proposal Culture work in a variety of other situations outside of data engineering. Mozilla has been, after all, a remote-friendly company for as long as I’ve worked here. Proposal Culture can be useful for engineering teams, product teams, or any team, really, especially ones that can’t easily be co-located (which is almost all of us).

Like any decision making approach, it’s certainly not without its tradeoffs. But even if your team doesn’t agree to follow this approach, you might still enjoy insights from this async-friendly mental model.

A product team I am currently embedded on discovers the power of Proposal Culture. Here is the Retrium post-mortem grouping. The proposal and demo alluded to was the work of a whole team, but especially three engineers who efficiently aligned through the proposal-writing proceess – two in California and one in Italy.

Cultures have norms

All workplace writing cultures are more than just a document template everyone forks; they have processes & norms embedded in them. This distinction does not go without saying; when we talk about technical writing, it’s easy to focus on the document structure without talking about the conditions a team must create to make a proposal successfully map to the right work, especially when people cannot be physically co-located. The truth is, without team norms and habits that encourage a productive feedback process, you’re just writing a doc in a vacuum of indifference. And that vacuum is so much wider when everyone is remote.

So what are the norms that make Proposal Culture work?

The three features of a successful proposal

So let’s get down to the proposal itself. My colleague Mark Reid, who manages our data engineering team, says that a good proposal has these three features:

  1. a clear, written statement of the problem you hope to solve
  2. a clear, written statement of the solution
  3. an inclusive process for collecting feedback on these written statements

When you frame the problem clearly, you set the field of vision for everyone and invite others to align on the problem space. When you provide a clear statement of the solution, you make space for alternative viewpoints that improve it. And when your feedback process is inclusive, you ensure that everyone can have a say in the outcome of the proposal, and that the outcome is much better.

The Problem

The first, singularly most important, and often most-overlooked part of a good proposal is the problem statement. Getting this right is vital because without it, others will implicitly bring their own secret version of the problem to the proposal. It is also vital because understanding the problem is often as difficult as figuring out a solution. Solutions to non-problems are probably the most expensive type of mistakes that companies make.

Getting everyone on the same page about the problem shifts the nature of the feedback process from “me vs. everyone else’s opinions” to “us vs. the problem statement”.

The problem statement usually doesn’t need pages and pages of exposition. A few paragraphs is usually enough to set the frame of reference for your readers.

Because the problem statement is so important, I almost always write it out first and share it with a few colleagues before I invest too much in the solution. If they agree with the problem, then it feels safer to proceed with the solution.

The Solution

The next component of a proposal is the solution. A good solution should be explicit, it should be well-scoped and achievable, and it should be structured so different types of feedback have a home in the proposal itself. We’ll go into more detail about how to achieve these goals in future sections.

An inclusive process for collecting feedback

Writing a proposal is difficult; getting people to interact with it is maybe even harder. You can be an effective writer and still have your proposal fall flat.

Building a proposal-writing culture comes down to getting the process and the form factor right with your particular group of people. Who is responsible for what? Here is what the data engineering team landed on:

Little-i inclusive

The “inclusive” part of “an inclusive process for providing feedback” deserves both more explanation and caveats, because it’s often taken for granted, especially in tech companies. I’ve already talked about how the asynchronous nature of our proposal process removes some of the downsides of diverse timezones & mismatched schedules. Proposals do not replace face-to-face deliberation, but they do help keep everyone on the same page, contributing to the same end.

A process that is designed to be more inclusive can, in theory, level the playing field by mitigating, addressing, or removing communication advantages others might have, such as “natural loudness.” This is to say, moving some forms of feedback and deliberation to the comments section reduces the possibility that the caucus rule dominates the discourse on the technical decision. This is especially more important in remote settings, but even in IRL offices, these dynamics still obviously exist.

The reality is, even when everyone is in the same time zone, not everyone feels comfortable talking in meetings anyway. An inclusive proposal process makes a written document the source of truth and the primary feedback surface, which reduces the importance of meetings where certain personalities can dominate. It doesn’t mean discussions aren’t had in meetings; it just means meetings simply can’t be the only place to contribute.

An async proposal process is, however, necessary but by no means sufficient to ensure capital-I inclusion in this – that is, it won’t ensure that everyone feels that their voice is valued outside of this context, or even within it. Async culture is probably no more inherently inclusive than an IRL workplace. If you’ve spent time asking a question on IRC, you know what I mean.

The necessity of inclusiveness is bigger than this Proposal Culture. that said, when you are designing a proposal process for your team, you have the room to encourage feedback mechanisms and behaviors that encourage better inclusion. And that really makes all the difference. Otherwise it’s still possible for loud people with strong opinions to dominate a Google Doc as easily as they can a meeting, and many other problematic dynamics will still keep people from contributing. Throughout these field notes I’ll suggest some solutions to mitigate rudeness, feedback-ignoring, bullying, and caucus-rule-style loudness.

Caucus rule:
“the first person to utter something gets the floor”. See Chelsea Troy, “Why Do Remote Meetings Suck So Much?”

Creating an inclusive process is more than just the right thing to do – it’ll make the proposal substantially better and easier to execute if everyone believes they are contributing to the same mission.

A typical proposal process

Proposal Culture really is the summation of big and small agreed-upon norms and habits that make the process work. The more visible we make these invisible things, the clearer Proposal Culture becomes. With all of the above said, here is a more concrete example of the proposal-writing process that the Data Engineering team has been using:

  1. Write the first draft – I open a new Google Doc and begin writing. An hour is enough to form a problem and solution statement, as well as some of the important details. Once I feel I have those, I begin sharing with one or two colleagues who might provide a good gut check to see if I’m heading in the right direction. These colleagues are usually familiar with the problem space, willing and able to challenge assumptions and feedback, and are people I feel comfortable discussing one-on-one.
  2. share with the team – Once I feel the proposal is ready for the broader team, I share it. The Data Engineering team has a project meeting every Monday morning. We have a “proposals” section where I link the proposal and give a deadline in the meeting notes. I get a few minutes to talk about it at a high level. At this point, the engineers who are not procrastinators tend to jump right in after the meeting and provide feedback.
  3. send the reminder ping – a few days before the feedback deadline, I ping @here on Slack reminding people to get their feedback in. This causes a rush of overly-busy and procrastinating engineers to jump into the proposal and add their feedback (I fall into this category). In my experience, there is a pretty weak correlation between the quality of the feedback and how early it comes in the process, so I make sure to have time to consider what I get at the eleventh hour. Feedback that comes after the deadline is of course still considered. But we have an understanding that it’s much better for everyone if people abide by the deadline, so most of it comes beforehand.
  4. get the thumbs-up – between the initial share-out and this end-point, I’m incorporating feedback, having one-on-one’s with engineers to talk through bigger concerns if needed, and getting the proposal into its final shape. There is usually some decision point where the relevant parties agree “this proposal is done”. In the Monday Data Engineering meeting, I will then let everyone know the proposal is finished, and thank everyone for the feedback. If I’m working on a team or project where there is no explicit meeting, I’ll make one, either in a pre-existing meeting with enough attendance, or as a brand new one (if this is big enough of a proposal). Last resort, I’ll just mention it in Slack that the proposal is baked. The whole process ends up taking about 1-2 weeks for a big-lift proposal. For smaller scopes, sometimes it only takes a few days.

This is just one possible example. It would probably vary if a team is more product or business-unit focused. Regardless, the theme throughout the above process is the writer is responsible for driving the entire lifecycle of the proposal. The rest of the team must fulfill their own roles.

Qualities of an effectively-written proposal

The three requirements – a problem, a solution, and an inclusive feedback process – are the bare-minimum you need to begin collecting feedback. You still have to write the thing, though, and pitfalls abound because writing is incredibly hard. So let’s talk about what makes an effective proposal:

it’s tailored for your audience(s)

There is almost always more than one audience for a proposal. For instance, a proposal that is largely about deciding on a technical architecture will understandably be written to align engineers. But your PM and designer still need to understand the consequences of the approach. In other cases, your boss (or boss’s boss) might be reading the doc to get a gist of the solution, the timeline, and the level of investment.

Think carefully about who needs to be informed about the outcome of your proposal. For internal projects, there are often stakeholders in the proposal that are not just on your team. When you share your proposal with them, it’s best to explain your expectation on what kind of feedback you’re looking for and when you want it by. Doing so makes it much easier for them to contribute meaningfully,

the problem and solution statement is focused and easily understood

Make sure the first page of a proposal is a succinct, clear framing of the problem and solution, so that the person with the least amount of time (or is the least technical) can understand what the point is. The short version lets readers decide whether the proposal is relevant and if they should engage with it. Making it easy for folks is a good way to be respectful of their time.

The reality is, everyone benefits from a simply-written problem statement, including the engineers. If others are confused about what you’re trying to accomplish, then they can’t buy into the solution. Or worse – confusion can lead to mismatched expectations or unexpected technical or organizational problems that could compromise your objective.

the tone, structure, and medium accommodates inclusive discussion

Your first goal is to define the field of vision to make the problem and solution tractable; your second is to make it easy for everyone to contribute. A good proposal is made better when it efficiently and proactively encourages and incorporates feedback and deliberation. It’ll also make it easier to execute the proposal if others are bought-in on the solution.

It’s your job to make your proposal easy to read. Write in clear, simple language, have a clear and understandable structure, and make sure your proposal is commentable in some form. If you’re unsure about how to make it commentable, just use a Google Doc with liberal suggesting privileges for anyone with a link

It’s best to maintain a dispassionate tone throughout the written document, since the proposal will be successful because of its merits, not because of flowery, creative, or polemic language that might confuse or alienate readers. The writing style should be in simple, approachable language, as free from unnecessary jargon and idioms as makes sense for the proposal.

Whatever form your proposal takes, make sure it is easy to comment on it. We use Google Docs for that reason. Google Docs are also easily commentable by non-technical stakeholders, so it’s really the ideal medium for collecting feedback. In other cases, sometimes an email thread, a GitHub issue or PR, a Slack channel, or something like HackMD is sufficient.

It is explicit about all the relevant details

It’s unlikely that you will have thought about every detail and edge case on your own. Discussions that are had in-person or on calls might bring up new critiques of a proposal. If so, these points should be directed explicitly to the proposal document itself.

A finished proposal becomes a reference doc for future versions of your team. “Why was X chosen?” can be answered with a link to the section of the proposal that details “Why X?”

At the very least, a good proposal defines terms that may be a source of confusion for others.

It has a sensible scope

Your first draft should outline something the team can implement in a reasonable amount of time. The complexity of the proposal should probably reflect the complexity of the problem and the engineering effort involved. As such, you should be explicit about the scope of the work.

It is not likely that your manager wants you to solve a huge, multi-year process upfront. Other people have written about defining scope. I don’t have any tips here. Most technical proposals outline a timeframe of a couple weeks to a few months of work, and are usually tied to other frameworks like OKRs. Make it clear how big of a lift you’re proposing.

If you’ve done the job of defining a reasonable scope, you may need to shift gears and spend time defending it once you start getting feedback. Ideally, a team of experienced engineers will be mindful of the scope you’ve laid out already. But be prepared to handle any proposed scope creep thoughtfully. Out-of-scope ideas can find a home in a “future work” section, so everyone knows the idea has been considered.

Alternatively, others might find your proposal scope to be too wide. Listen to these arguments carefully.

A well-defined scope shows an explicit end goal. It rules out things that don’t need to be deliberated today. All this said, you will also need to spend time suggesting what the first steps look like too. This will help others see what’s in front of them. It also ensures that your proposal has momentum after everyone agrees. A common first step is “let’s prototype something”. Sometimes, you’re doing the prototyping already. Include links to prior art.

Everyone agrees to the process

Everyone has to be invested in the proposal process, from the ICs through the PMs to leadership. This is really what the “culture” part of Proposal Culture means. If a team is not bought in, then people won’t comment on the doc, and you’re stuck in a strange middle-ground of having written down your ideas (wonderful!) but having not gotten anyone onboard (sad). You simply can’t have a Proposal Culture unless management makes it happen. I discuss pathologies around this in a section below.

Usually people who object to the idea of writing proposals simply don’t think it’s useful to write down what they want to do. They think they know the way forward, and they feel that the proposal is unnecessary stop-energy and a waste of time. The best way to convince them is to ask them to try it for a sufficiently complex problem, especially one that will affect others. When they do it, most ICs realize that it’s a lot easier and more efficient to get everyone to agree to their ideas if they just write them down.

A proposal skeptic will feel validated in their negativity, however, if they end up spending too much time on the first draft. It can be difficult to know just when to share. When in doubt, share a few colleagues earlier rather than later for a gut-check. With this in mind, don’t spend more than an hour writing something up before demoing it with a few others. Keep in mind that if you don’t have at least a clear and concise problem and solution statement, then it’ll be hard for your colleagues to contribute.

the proposal writer takes responsibility for the proposal’s outcome

It’s your team’s leadership – managers, directors, whoever is responsible for your team’s direction – that needs to get everyone to agree to build a Proposal Culture. But I find it helpful to talk about who owns the outcome of a written proposal, assuming everyone agrees to the process. The reality is, it has to be the writer.

Say you want to pitch some new engineering thing that’ll save everyone a lot of time. Your job is to write the document; your job is to make sure it is understandable; your job is to explicitly share it with your colleagues; your job is to explicitly push them to give feedback; your job is to incorporate that feedback and iterate on the proposal until it’s good; and your job is to get signoff from the right parties on the finished product. If you drop the ball on any of these things, your proposal is liable to fail. No one else is going to get it done.

This puts a lot of responsibility on the proposal writer, who is often an IC. In practice, Data Engineering has found it to be a great moment of career development for more junior engineers to propose something with a reasonable scope. Strong professional skills are a force-multiplier on technical chops. All of this said, if the team is bought-in to the proposal-writing culture, they tend to offer their support and suggestions about how to drive the process efficiently and equitably.

Ways a written proposal can be “bad”

A bad proposal tends to leave out some of these good qualities. I know this is an unsatisfying answer, but it’s the truth. They usually have a similar root cause: the team doesn’t understand their specific duty and agency in the process, and thus the ball gets dropped somewhere.

For the rest of this section, let’s assume that leadership supports some kind of proposal process as outlined above, and that ICs are encouraged to follow the process. This will allow us to rule out some issues with team dynamics that might make a proposal fail.

Let’s walk through some common proposal pathologies I’ve seen over the years:

use of flowery language, business-speak, memes

I have read proposals that include extended metaphors, weird business filler words, funny anecdotes, and reaction gifs. Almost always, someone will leave comments asking for these to be removed or simplified. Why? Because proposals that aren’t written in plain language reduce confidence and increase confusion. It also excludes those who are not native speakers of the language your proposal is written in. I’m not saying your writing has to be stuffy. But there is a time and place for a well-executed meme or literary flair, and it’s not really in a proposal.

sections that come out of left field

When you add sections (and section headers) that come out of nowhere or have no explanation, you’re asking readers to do extra work to understand the context. A clear structure creates context. Don’t throw together a bunch of asides into a proposal and expect people to understand how they fit into the bigger picture.

burying the lede

A good proposal is focused on explaining the problem and solution, starting with the first page. If your problem statement doesn’t appear almost from the first sentence, then people are going to be confused about what you’re trying to do.

low coverage of pertinent points

A lot of magic and understanding happens during one-on-ones and meetings, which makes meetings the biggest risk to a good proposal. If the proposal does not capture all the pertinent questions and concerns brought up in those moments, then you’re relying on shared team knowledge to fill in blanks. This will lead to failure, especially with a remote team. Your colleagues will have different mental models of the solution, which will lead to wasted time. So be diligent about redirecting your colleagues’ questions to the proposal document itself.

semantic tar pit

If disputed technical nomenclature finds its way into a proposal without any glossary, expect engineers to deliberate about semantics. In some cases, this might be worthwhile, especially if you’re breaking new ground. But to the extent that your proposal relies on terminology that is already well-defined, provide links and save everyone time.

boiling the ocean

A proposal may be well-written, but if it leaves your team unsure how to even proceed and doesn’t constrain the field of possibilities, you run the risk of people implicitly abandoning the direction. An unrealistic scope will ruin you. At a bare minimum, describe a feasible end state and outline the first steps.

no explicit feedback mechanism

Proposals that take the form of blog posts or other writing-without-direct-comments can be difficult to comment on directly. This is one of the reasons why data engineering encourages the use of Google Docs or other similar commentable writing software. Without a feedback mechanism that is easy to use for just about everyone, you’re less likely to get the feedback you need.

There is another half of a feedback mechanism that is invaluable – the people reading need to understand the expectations around feedback. If you don’t tell someone that feedback is very welcome or what kind of feedback you’re looking for, they’re less likely to comment. It’s all about making it easier for them.

oops, ya missed an audience

Often, proposals will have more than one audience, especially if the consequences of the proposal extend beyond the team that will implement it. It can be easy, however, to miss a world of needs if other stakeholders never get a chance to read and comment on the proposal.

Another common problem – a proposal requires sign-off from someone higher up the chain. It’s very hard for a busy director or exec to say “yes” to something if your first page (where the problem and solution statement should be) is not clear and concise. So do yourself a favor and always assume that someone with very little time has to understand the consequences of your proposal quickly. The first page is for your boss.

“I’m open to just about any solution here!”

I once saw someone share a proposal that was unfinished & full of open questions for the solution statement itself. The writer had slapped it together in about thirty minutes, and it showed. No one knew how to respond to “I’m open to just about any solution here!” on page one. Your peers should not be completely defining the field for you at feedback time. Your goal is to provide them a field of vision and a potential path on the field. Don’t make them do the work you were supposed to do.

I think people tend to share vague proposals with their whole team because they don’t really know how to proceed. If you don’t know how to frame the problem or solution, then have discussions with others about it until you can. Some engineers will share early forms of their proposals with individual teammates before showing the group, just to see if they’re on the right track. Do whatever it takes to sharpen the problem and solution statement without diffusely passing the burden onto everyone else.

falling in love with your solution instead of the shared outcome

Be careful about becoming emotionally attached to your proposed solution. The point of sharing your proposal with others is to see what is missing, inefficient, or inaccurate. You could simply be off-base. It doesn’t really feel good to have someone suggest something in your proposal isn’t quite right, especially if you’re not used to candid feedback, but it’s much better for your team and your career to learn how to gracefully be wrong, especially when it is in service of the bigger goal – doing a big difficult thing well.

Another antidote is sharing early (but not too early as above) before you’ve invested too much. Sometimes, having another pair of eyes from an engineer with domain expertise or someone you trust is a great way to see if you’re on the right track. Keep in mind that people may also have suggestions to tweak the problem statement too.

debate hell

Proposals sometimes have a tendency to become a hellscape of debate. This usually happens when two or more engineers find themselves arguing at length in the comments about something.

Your job as a proposal writer is to make sure the proposal gets finished and people feel heard. It is not a place for people to feel they have to win an argument. Steer debate toward something that benefits the proposal wherever possible. (More thoughts on this below.) Whenever possible, it is helpful to remind the feedback debaters that there is a deadline for feedback, which in some cases can help move them out of the thought bubble into something actionable.

Sometimes this is difficult to do on your own. If you need a hand in moderating, ask for it! Your manager is a good starting point.

comment graveyard

When comments linger unaddressed in a proposal, it gives the impression that you didn’t do the work of building consensus. This creates real risk, because it keeps people from being bought-in to the solution, and honestly – the comments may be pertinent to the proposal, so you should spend time with them.

Always strive to address comments somehow. Engage with the comments, talk to your colleagues about their disagreements, and find a solution. In some cases, you might have to simply agree to disagree. More on this below as well.

Tips for structuring a proposal

Proposals end up taking many forms because they need to accommodate the needs of the team you’re on and the realities of your work. It’s far more valuable to learn the principles of writing a good proposal and just work from there. As long as you have those three requirements – a problem statement, a proposed solution, and an inclusive feedback mechanism – everything else is optional and meant to encourage feedback, add details, reduce risk, and bring others onboard.

Before we go through our tips, I want to dispel a common criticism of proposals – it just feels too heavy to write a long proposal and collect feedback. Writing is hard! But no where in these field notes is there mention of a minimum page count for proposals. The length is less important than the content and the process. My favorite proposals I’ve written have been 1-2 pages. Technical proposals sometimes grow longer because of the necessity to cover important bases. But it’s not a requirement that a proposal has to be long or heavy. That’s not one of our three essential features. It just has to be long enough to communicate with your team the problem and solution.

With this in mind, here are various sections & features that make their way into the written data engineering proposals I’ve seen:

Team, Management, and Strategic Pitfalls

You might write a perfect proposal – perfectly tailored to your audience, well-scoped, written in clearly expressed language, and accessible. The reality is, a productive proposal-writing process can only exist in a circumstance where you have some influence over a team’s practices, or you’re on a team that is not completely dysfunctional.

One of the biggest risks to an effective proposal process, outside of the team not knowing how to effectively give feedback on the proposal itself, is management not understanding its agency in the process. Here are a few common pathologies:

Your team is a mess

We’ve all been there; your team is dysfunctional, dominated by weird / secret politics, or just kind of aimless. Writing a proposal won’t get your team out of the mess. In fact, it is liable to become either a battleground where the dysfunctions are fought out (a comment graveyard, debate hell) or it will remain devoid of any feedback. Candidly, attempting to follow Proposal Culture here isn’t going to fix your team’s problems. It may help you formulate your thoughts.

The leadership on a team does not support the proposal-writing process

Your team might be functional, but if the leadership on your team does not proactively encourage both writing and giving feedback on proposals, it is less likely to be successful. They might not see the value of it or think decisions are being made just fine as-is.

One tactic I have used when I parachute onto other teams; get someone else to write the proposal (with your eye), and serve as the hype-person for it. When two people are pushing a process on a team that doesn’t have the proposal-writing instinct, it makes all the difference. People usually need to see it successfully work before buying into the process.

If you are a manager or project lead interested in creating a proposal-writing culture, then your job is to explicitly push for it and support it. Exhort your reports to provide feedback; have the back of the proposal writer; push for and encourage explicit feedback due dates, signoffs, and the like. Having leadership tactically support some of the people-issues that get in the way of a proposal being successful is vital.

One special version of this lack of support – it’s not clear what the next step should be after the proposal is done. It could be that a proposal process goes great. But once we get to the critical moment – what’s next? – the manager & team forgets it ever happened.

The cases that have to be guarded against:

  1. No explicit thumbs-up from relevant parties – if the team’s leadership doesn’t realize they are the blockers to the proposal being accepted, they’re never going to give it the thumbs up. One easy guard against this is to include a signoff matrix on your proposal, and ask the decision makers if they should be on it (and if so, to please sign off). One reason why someone may delay signing off is because they might think the proposal will take forever to read, so they procrastinate. It can be helpful, in this case, to have the first page of the proposal be a tl;dr of the problem and solution. You can communicate lower, concrete expectations about how much they need to be informed on the proposal. I have found in practice that this makes all the difference.
  2. The proposal gets the thumbs-up, but the manager promptly forgets the proposal ever existed and doesn’t resource it. This is a sign that the manager didn’t really buy into the process in the first place, or that they’re not communicating that intervening factors have gotten in the way of resourcing the next step.

The process leaves out stakeholders

You may have a strong team, leadership that supports a proposal-writing process, and a concrete plan to collect feedback. But it’s very common that you have external stakeholders who need to chime in on the proposal, and it’s also common for the proposal writer & the team to leave these people out. It’s often inadvertent. But without your stakeholders’ input, your problem and solution statement won’t probably match up well, and bruised feelings might get in the way.

The process is not explicit enough for outsiders to contribute meaningfully

If you work in a larger company and your proposal needs feedback from people outside of your immediate team, they will need to be made aware of and reminded of your expectations about feedback. If they’re not in the same meetings you’re in they might not be reminded, for instance, that feedback is due at the end of the week. Alternatively, some people outside of the process may feel intimidated or unsure if they should comment on your proposal.

The proposal & process isn’t on the critical path for your team

A proposal may feel like it is well-scoped and a good idea, but proposals cannot exist in a strategic vacuum. The team leadership is responsible for making sure ICs don’t waste time figuring out solutions to non-problems.

Ways to mitigate conflicts and disagreements

Handling feedback from your colleagues can be challenging in any environment, but especially in a written one. After all, the proposal you’ve written is largely about communicating to them what the field in front of them looks like. Egos can flare up, including your own. But for your proposal to be truly inclusive, you have to do the work of making sure everyone has a voice and everyone feels heard. In most cases, your colleagues will have useful feedback or criticism that, if addressed, makes your proposal better. In other cases, they might comment in ways that are simply off-base or out of scope, or motivated by something other than the merits. Or – and this is familiar to all – they won’t comment at all. Let’s talk about these:

There is a delicate balance between merely hearing out your colleagues’ feedback and incorporating it. If someone feels strongly about a small detail, ask yourself if you feel as strongly. A good proposal sees the forest for the trees. Sometimes, graciously accommodating feedback will soften a more cantankerous colleague’s issues with what you’ve written. People want to be heard and feel like they’re a part of the conversation. Again, it’s your job to make sure the proposal gets finished and accepted. It’s not your job to win every argument.

All this said, you might end up in a situation where a disagreement can’t be resolved. “Agree to disagree” comes in handy here. If you can’t bring around a colleague, make sure to incorporate their misgivings in the “questions” section. If you’ve successfully shifted everyone’s framing from “my solution vs. your solution” to “us vs. the problem”, then people are more likely to sit with their disagreement.


These days I crave an IRL workplace. But I know I’ll be bringing these lessons with me to just about every other work environment I’m in, in-person or otherwise. Once you see a strong proposal-writing culture in action, it’s hard to unsee it.