Drive change by writing structured proposal documents

In any collaborative environment, opportunities for change often arise. When such an opportunity presents itself, write up a structured proposal document describing how to tackle this opportunity. With this document, a decision on whether or not to implement the proposal can be made quickly and confidently.

Fix me: This document uses the words choice, opportunity (opportunity for change), proposal (proposal for change, change proposal), and decision. Verify that these words all make sense.

Motivation

Whether when working alone or collaborating with others, opportunities for change will come up. While many such changes are trivial, some are not:

• Changes that impact others, such as restructuring the filesystem of a project, or reformatting all source code to the latest standards.

• Changes that are not easily reversible, such as the decision on a programming language or framework to use for a new project, or the switch to a new paid subscription of a third-party tool.

To make decisions on whether or not to move forward with such opportunities, we need to have as much information about the change and its implications as possible.

We want to collect all relevant information regarding this decision from all stakeholders. At the same time, we want to make sure that all stakeholders understand the context and motivation around this change, and the impact it will have.

To do: Add a paragraph about asynchronous work. Research for decisions should be made independently, asynchronously. Avoid making decisions synchronously (e.g. in a real-time meeting).

Proposed solution

Write up a proposal document in the following format:

1. Context (optional): What background information (if any) is needed to understand the rest of this document? Consider adding a glossary in this section.

2. Motivation: What pain point does this proposal address?

3. Solution constraints (optional): What is the set of requirements for every solution for the aforementioned pain point?

4. Proposed solution: How will the aforementioned pain point be addressed? What are the implications of this proposed solution? What are the advantages and disadvantages of this solution? Consider adding examples of how this solution would work, if applicable.

5. Alternative solutions (optional): What other solutions would also alleviate this pain point? How do they compare to the proposed solution? Do they meet the solution constraints listed above?

6. Open questions and concerns (optional): To do: write me

Consider writing this document on a platform that supports real-time updates, and has fine-grained commenting functionality, such as Google Docs or Notion. While other approaches work (e.g. sending Word documents and updates to them over email), they have a long and cumbersome feedback loop, which decreases participation.

To do: Clarify that decreased participation means less information and thus possibly worse decisions.

Ensure that there is only one person responsible for writing and maintaining this document. All suggested changes to the document should go through this person.

Until the proposed solution in this document is accepted, keep the proposal document updated with any new information that comes in. Ensure that all people involved are aware of updates to the document.

Ensure that there is a clear point where the proposal is either accepted or rejected. Setting a deadline up front can be useful.

Example

This very document you’re reading is structured using this format.

Advantages

To do: Mention that the act of writing up the proposal document (and thus doing the necessary research around the impact, advantages and disadvantages of the proposal) can already bring enough clarity.

By documenting the decisions around proposals, a historical record can be kept, and can be referred to later on if needed. In particular, it can shed clarity on the constraints that were (and presumably no longer are) present when a past decision was made.

This approach ensures all potential stakeholders are involved in the process, and that their input is taken into account.

With this approach, not everyone is required to participate in the process. In this way, this approach can be used to Get people on board with breaking changes by radiating intent.

Disadvantages

This approach is not well-suited for urgent decisions.

Open questions and concerns

• It might make sense to split the solution constraints into “must have”, “should have”, “nice to have”, and “optional”.

• It might be worth adding a RACI matrix to the document, to state who is responsible, accountable, consulted, and informed.

• It might be worth documenting the thought process that went into the proposed solution. References (bibliography) would then probably go into a subsection of the Proposed solution section.