Hamilton Ulmer

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:

• Async feedback is circumstance-friendly, which is vital for remote work. Asynchronous feedback is a core feature, which means the proposal process is just much kinder to people who can’t for whatever reason be on that big important Zoom call. That’s a lot of us these days, not just engineers in Finland who can’t make a San Francisco-time meeting.
• Because it is a more designed & deliberate process, there is more room for building inclusive norms. By removing the Zoom format as the primary way to deliberate, there is more of a possibility for everyone can contribute to the shared solution without the downsides of speaking up on a call full of strong-opinions-weakly-held types. This is not true by default, however – there is still work to make everyone’s voices heard, since anyone can be as loud in a document as they can be over Zoom or in a conference room. It’s just easier when you’re explicitly designing a process and interaction pattern. The norms and expectations are laid out for everyone to follow.
• And naturally, if the process is done well, the outcome is usually way better because everyone can contribute to it more equitably.

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.

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?

• Everyone agrees that the proposal is the primary artifact of decision making, because it is a codification of everyone’s collective expertise, not just the writer’s. It defines the problem & solution – and then aligns everyone on it – before expensive work is done, reducing the risk of building the wrong thing. The written artifact is invaluable later on when everyone forgets why something was done a certain way.
• Everyone agrees to follow the process & they understand their own role in it. This alignment around the process itself ensures that the proposal reaches its ideal state efficiently. If team members don’t take their roles seriously, the process (and thus the culture) fails.
• Everyone biases conversation toward adding feedback to the proposal. There may be meetings where people talk about the decision the proposal is for, but the action item around these conversations is always “please add this as a comment to the proposal”. In fact, all institutional knowledge and feedback must make its way back into the proposal, if it is relevant to the decision being made.
• The proposal feedback process has to be asynchronous by default. This enables everyone to have a say, no matter their time zone, life circumstance, or propensity to talk in a Zoom meeting, making everyone feel like they can contribute and have a stake in the outcome.
• For decisions requiring multiple people, writing a proposal and collecting feedback is always the best practice – not only encouraged, but required. Proposals don’t have to be massive, involved documents; they just have to have all the features that enable the idea to be vetted async by peers.

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:

• Everyone has to know what the process looks like – a successful proposal process is an explicit one, preferably written down and accessible to everyone on the team. The explicitness reduces the emotional cost of getting started and moving to each phase. I outline a typical process in the next section.
• The writer is responsible for the proposal’s outcome – someone has to drive the proposal process itself. And it has to be the writer. They are responsible for the first draft & for refereeing the feedback process, supported by the team leadership.
• The team’s leadership is responsible for supporting the proposal process, encouraging inclusive conversation, and removing friction – Without leadership supporting the proposal writer, others won’t buy into the process, and the whole thing becomes a waste of time for everyone. The team’s leadership should be encouraging the other team members to give feedback on written proposals; they should be making sure the writer is not blocked by anything; they should be helping the writer consider the audience & make sure the right stakeholders read it and sign off; they should be making sure everyone’s voices are heard; and they should be pushing for an outcome & resourcing to implement the proposal after it’s been approved; and most importantly, they are responsible for making sure the proposal outlines a solution to an actual strategic problem to be solved for the organization.
• The team is responsible for providing actionable feedback – the team’s job is to provide constructive, actionable feedback in a way that is easy to incorporate back into the proposal itself.

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.

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:

• a deadline for feedback – You might have a great proposal, but if you don’t give a deadline for feedback, people won’t prioritize it over their other work. So pick a date and tell everyone more than once. Usually a week after you introduce the proposal is enough time. Remind everyone when they have a day or two left. This is usually most helpful if your team has a lot of functional areas to deal with, vs. teams where everyone is pointed toward a single deliverable goal (like a product team). Sometimes it can help to have a discussion with your team once the proposal has incorporated feedback to get explicit sign-off on the approach.
• short objective statement on page one – Frame the problem and how you plan on solving it at a high level. Keep the length to about one page, as if you were writing for someone with only a single pages-worth of attention. Sometimes the first page is sufficient to start sharing with a small group for early high-level feedback. Regardless, this is the best way to ensure that the reader with the least amount of time or the least amount of technical understanding can understand the problem, solution, and consequences. To reiterate, the first page of your finished proposal is for the bosses. Don’t skip it, and make sure you’re using clear language.
• a set of milestones – Communicate the deliverables. The resolution will probably depend on the size of the solution, and the milestones really depend on how your team already does things. This section answers the question “when-ish?” This can be the last thing you write, and probably the most prone to change until the path forward is clearer.
• stakeholder signoff – Sometimes, a proposal will need explicit stakeholder signoff from someone up the chain. I have written proposals that require signoff all the way up to a C-level executive. If your proposal requires that, list those people explicitly and make sure you share it with them after you’ve gotten adequate feedback from everyone else. And because obnoxious repetition makes the point stick, make sure your problem and solution statements are clear, short, and on page one so those higher-ups can get the gist.
• cost estimates – data engineering often has to be mindful of the costs involved. If there are any, outline them here, or link to supporting materials.
• required definitions, framing, etc. – for people that need to care about the details. Your proposal becomes a working reference doc for others when you are explicit about all the nomenclature and details. Links that might provide better / more context would go here. For proposals that outline a large body of work, there may be other smaller proposals for tackling certain sub-problems that can be linked off of this one.
• the proposal itself – Honestly, I don’t have a strategy behind the meat of the proposal. “The proposal” is usually the topic of other frameworks. But each one is different.
• alternatives considered – there are usually other possible solutions to the problem. Listing alternatives you’ve considered and explaining what the tradeoffs are is a great way to build confidence in others that you’ve spent the time suggesting the right solution.
• how to prototype – any materials or thoughts about how to validate assumptions made in a proposal is useful. Many proposals have at least some prototyping done to assess technical feasibility either before or after the doc is finished. If you have something, link to it. At the very least, suggest how to prototype as a first step. A section like this answers the question “what’s the cheapest way to validate the idea?”
• future work – elements of the proposal or problem area that will be addressed later or in another doc. Use this section to divert questions and requests that are out-of-scope but might be in-scope down the line after you’ve achieved your proximate deliverables.
• questions – this section does a lot of heavy lifting. I put questions here that I don’t know the answer to. I also encourage others to put unaddressed questions and concerns here if there is no place to ask the question elsewhere in the doc. As the list of questions begins to pile up, you might start moving the answers directly into the proposal itself. The “questions” section tends to become the workspace for the whole proposal.

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:

• a colleague doesn’t end up reading the proposal until it’s too late – you may have colleagues who either don’t have the bandwidth or don’t have the discipline to read the proposal until after it’s done. Expect this to happen if you’re working with a team that is new to proposal writing, or a team that has a lot of junior people, or one that is kind of dysfunctional. This is why I recommend you make the feedback deadline explicit. Regardless, you should expect some late feedback anyway. It simply comes with the territory.
• a colleague is hesitant to contribute – some ICs are shy. Some are dealing with dynamics that exist outside of the proposal process that keep them from contributing. Maybe they feel intimidation or imposter syndrome, assuming “surely they don’t want my feedback.” It’s wise to be mindful of this, and create space for them to contribute their thoughts, if they have any. The nice thing about written proposals is that no one is required to speak up in a meeting where more senior ICs might otherwise dominate the discussion. I’m never afraid of DMing someone on Slack asking if they had any thoughts about something I’ve written. Sometimes light encouragement is all they need.
• a colleague loves to debate – sometimes, you’re working with someone who enjoys debating more than they enjoy finding solutions. Your role is to steer deliberation into an actionable or meaningful change to the proposal. If you happen to be someone who loves debating, I’m afraid it’s time to go against your instincts and do what is best for the proposal.
• A colleague’s feedback isn’t clear nor actionable - There is an art to giving good feedback. If you’re receiving feedback on your proposal that isn’t clear and actionable, ask for the feedback to be restated more clearly. I am a big fan of asking people to be more specific. It helps a lot. Sometimes, asking for clarification forces them to reconsider the feedback.
• a comment will never be in scope – in some cases, your colleagues will contribute ideas that will not ever be part of the plan. In the best case, put this feedback into a “questions” section at the end, where you can both restate the feedback as a question, and provide an answer. If others ask the same question later, you can refer them to the questions section. This preserves the question and makes the feedback giver feel heard.
• a comment will be in scope later, but not right now – I tend to put this feedback in a “future work” section. This signals that the feedback is worth addressing later, but it’s not pertinent to figure out the answers now.

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.

Conclusion

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.