The more an organization matures, so does their need for new and innovative — and increasingly complex — solutions to business needs. To ensure that these problems are being approached in the most systematic way possible with all the right skill sets and perspectives, teams can leverage a methodology composed of Proposals and Braintrusts, an amalgamation of concepts inspired by Pixar, Amazon, and 7CTOs.
Much of what is described here is tailored towards engineering teams, but the same general structure can be applied to any highly-collaborative groups who are engaging in creative discourse.
This process starts with a document — the Proposal — and it broadly follows the format of:
Approach: How? Who? When?
The Proposal is written in the form of an essay — a narrative or persuasive document that will likely go through several rounds of editing and revision to clearly convey the situation and proposal in a way that even unfamiliar audiences can understand. By writing in complete sentences and paragraphs, the author is not simply breaking down a project: they are telling a story and providing context about the problem and the solution.
In Jeff Bezos’s 1998 letter to Amazon’s shareholders, he describes how Amazon employees use the six-page narrative to propose new ideas at all levels of the company. In a 2004 email, he describes this approach and the inherent power of long-form content:
Well structured, narrative text is what we're after rather than just text. If someone builds a list of bullet points in word, that would be just as bad as powerpoint.
The reason writing a good 4 page memo is harder than "writing" a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what, and how things are related.
For many, the act of writing does not come naturally or easily, but it is an invaluable skill honed through time and practice. To help authors structure their proposal, it can be valuable to provide guidance up-front about the types of things that should be addressed. For example, engineering teams should be thinking about and addressing certain common topics as they write their proposal. Some of these items might include, but certainly are not limited to:
Operational Considerations and Production Support
Analytics and BI requirements
Internationalization and Localization
This methodology can extend beyond engineering teams as well. As one example, Marketing organizations may also choose to leverage this process to discuss rolling out new campaigns or acquisition channels, and there will be certain, common aspects that should be addressed in that context as well.
At the core of any proposal is a problem someone is trying to solve. By clearly articulating this problem statement from the outset, everyone who will be offering feedback will start this process from a point of agreement (this is a problem we need to solve!) and it will frame the conversation.
This section summarizes the proposed solution for the Challenge, in as little as a paragraph or two. Where the Challenge section described why this solution was necessary, the Solution describes what the future-state looks like.
Once the reader understands why and what, they need to understand the how, who, and when. The Approach section is all about tactics: what are the specific steps to solve the problem? This will almost certainly be the longest and most detailed section of the document and should likely incite the most lively conversation.
After the initial draft of the proposal is written, it is important for the author to gather feedback from a group of peers and trusted advisors. Not only is it important to solicit feedback on the implementation and approach but also to get feedback on the problem statement and solution overview. Does the document assume a certain base of knowledge and “inside baseball?” Is the problem statement itself controversial in any way? Depending on the subject matter and the scope of the proposed change, this phase of the editing process could go through several rounds of feedback before it is ready to be presented to the group.
Once the final draft of the proposal is ready, a Braintrust can be assembled. This Braintrust, an adaptation of the concept by the same name in Ed Catmull’s book Creativity, Inc, describes a group of individuals who bring unique perspectives and talents to bear in a round-table discussion about the proposal. This group may or may not consist of people who have already helped in the feedback process.
You don’t have to work at Pixar to create a Braintrust. Every creative person can draft into service those around them who exhibit the right mixture of intelligence, insight, and grace. “You can and should make your own solution group,” says Andrew, who has made a point of doing this on a smaller scale, separate from the official Braintrust, on each of his films. “Here are the qualifications: The people you choose must (a) make you think smarter and (b) put lots of solutions on the table in a short amount of time. I don’t care who it is, the janitor or the intern or one of your most-trusted lieutenants: If they can help you do that, they should be at the table.”
It is important to limit the size of the group. By reducing the list of attendees to a number around 5, you are encouraging more direct conversation and providing more opportunities for discussion.
Before the scheduled meeting, the presenter should share the document with the group as a pre-read so that:
All team members will have had the opportunity to absorb the content on their own time and will be joining the conversation with the same understanding as everyone else
Team members will be able to join the conversation with thoughtful opinions, rather than their gut reaction to the proposal.
The Braintrust meeting has a singular purpose: to make the Proposal better.
The meeting is a conversation amongst peers; the Braintrust itself implies no authority. The presenter is asking for perspective, not permission. Members in some groups may find this dynamic to be difficult, especially those who are used to wielding a certain amount of influence or authority in the organization. As Ed Catmull explains: “That is part of the reason why Steve Jobs didn’t come to Braintrust meetings at Pixar—a mutually agreed prohibition, based on my belief that his bigger-than-life presence would make it harder to be candid.” Participants must view this as an egalitarian exchange of ideas, devoid of self-censorship, competition, or opportunity for grandstanding.
And at the end of the session, the presenter is ultimately the owner of their decisions to accept or discard the feedback given.
The discussion is guided by a deliberate structure:
To start, the presenter will give a high-level overview of the Challenge, the Solution, and the Approach. This is not a verbatim reading of the document, and it should simply be a 3-5 minute high-level recap of what everyone in the room already knows.
After the overview, the team members have an opportunity to ask clarifying questions. This is a format adapted from the 7CTOs organization's “Challenge Processing Framework” — a systematic approach to introducing a problem or challenge to a group for feedback or thoughts. CTOs are creative problem solvers by nature, as are the participants of Braintrusts, and it is tempting to jump directly into that “problem solving capacity”. That’s why this step in the process is critical: even though all members of the group have had an opportunity to pre-read and come to the meeting with the same base of knowledge, there still may be different interpretations and open questions. Team members should not ask leading questions; their questions should simply strive to bring clarity and understanding about the proposal being presented.
Once the team shares a collective understanding of the proposal, they can begin to offer their unique perspectives. When exploring alternative solutions, team members should avoid being prescriptive. They should offer these suggestions in the form of anecdotes or personal perspectives (“In my experience…”, “What has worked for me in the past…”, and “A way I might approach this…”).
At the end of the meeting, the presenter reflects back on the suggestions and feedback that have been given. In many cases, the presenter may be able to identify obvious action items right away; in other cases, there may be more things to consider and other problems to solve outside of the context of this meeting. Regardless, the presenter should conclude the meeting with their next steps, whether that is the sharing of the finalized plan or a follow-up conversation with one or more people.
The use of Proposals and Braintrusts is a systematic approach to collaborative problem solving involving the identification of a problem statement, the clarity and self-introspection of writing, a feedback and revision process, and real-time group discourse. Teams that employ each of these techniques are creating multiple opportunities for perspectives to shape and improve their proposals.