We have a backlog of complex technical decisions that affect the whole company that we are slow to close or close them in a way that does not produce the intended outcomes. This happens because of the large blast radius of such decisions and the fact that many of our smartest people would disagree with any particular outcome. This document outlines a path for improving the process of making such high-level, sensitive technical decisions in a way that leads to effective execution on their outcomes.
When multiple intelligent people disagree on the course of action it is rare that you end up having to decide between a terrible option and a universally awesome one. How you make those decisions, on the other hand, really matters. First, notice that a decision in-itself accomplishes nothing. The decision is a milestone that unblocks and lights up the path for execution. Excellent execution, in fact, can even turn imperfect technical decisions into successful products. If getting things done successfully in service of user needs (#landings) is what really matters, at the end of the decision making process you face the challenge that a substantial fraction of your team may disagree with the decision.
The most powerful tool in your chest to engage them towards successful execution is the legitimacy of the decision making process. In short, we need to treat the process of arriving at those decisions as being about as important as the decisions themselves.
The rest of this document outlines a process for producing official Technical Roadmap Report (TRR) documents. These documents don't have to be produced for every decision but they will be used for the most critical or otherwise difficult technical decisions we face. We expect, in steady state, single-digit numbers TRRs every year, and for new TRRs to take between 1 month and 1 quarter to produce. This framework could, of course, be used for more localized decisions within teams under the discretion of their management and technical leads.
The goal is that such documents provide the official technical direction in critical areas that are rich in diversity of opinions, and they need to be disseminated in such a way that resourcing and prioritization for those areas across all of Google are based on them.
The process for producing TRRs will be as follows:
-
I.
Identify authors for each document. These should be technically senior and respected names in the areas. Ideally no more than five authors per document. Domain leads should be primarily involved in selecting the right authors for each topic and in many cases Domain leads will be co-authors but experts will be drawn from across the company.
-
II.
Identify key stakeholders/partners that must be listened to before a first document draft is produced and have structured conversations so that they can contribute to the initial draft. Missing key stakeholders can be hard to recover from, especially if they will have a role in execution. Stakeholders are essential in producing findings that decisions are based on, for example.
-
III.
Use an appropriate mechanism to keep track of all of the input from stakeholders such that a record of the rationale for the decision making process is kept for future reference.
-
IV.
Write a decision document using the template outline below.
-
V.
Review it with the same group of stakeholders in II.
-
VI.
Publish it to a broader audience still as drafts and provide a destination for a broader audience to find and publicize them alongside a web form for feedback to be collected for suggestions for future revisions.
-
VII.
Schedule a date to perform revisions. Yearly revisions are likely useful for most cases. Revisions could borrow from IETF RFC protocols, for example.
-
VIII.
Declare the decision as finalized and work with the authors to help teams involved plan accordingly.
- A bug tracking system is one way of keeping a log of the feedback and evidence from various stakeholders.
- Product leadership should be considered for co-authorship.
A common template for decision making documents is useful in building trust in the process itself. I propose we use the following structure for the documents:
-
1
Goal Describe what technical decisions are in scope and why they matter.
-
2
Background Provide the minimum context so that people somewhat familiar with the area can follow the rest of the document.
-
3
Findings List the facts upon which the decision is anchored. Examples: what are the capabilities of existing systems, what are the gaps and overlaps among candidate solutions, what are the key requirements for successful solutions in the area today and over time, what objective metrics for landings in the area need to be observed, and any other factors that are pertinent to the decision. Findings ideally should be unambiguous and unanimously agreed upon by all the authors and preferably stakeholders.
-
4
Recommendations The actual decision and its rationale is presented. Ideally this should provide both a north star (what would a perfect world look like for the issues in scope) and a path for getting there. A time horizon for a “perfect world” should be 3-4 years, a timespan that is far enough from today to allow us to not be anchored by what is feasible this year but not too far into the future that our forecasting abilities begin to fade.
-
5
Downsides Acknowledge the advantages of the options we didn't choose and the problems associated with the decision chosen, so that a reader can appreciate the diligence of the process.
-
6
Follow-up Owners Identify the teams that are primarily responsible for executing on the decision, and work with the owners on planning and progress follow up. Since likely owners were involved from the beginning of the process (by design), this should not be a surprise to them. Execution plans should be led no more than one quarter after the TRR is finalized, and they will be tracked by a central technical office.