9 Things I learned at Google: #1 - Design Documents
If you read my previous post about my 9 years at Google, I am sorry if I left you with a feeling of doom and gloom. The truth is, my time at Google was also full of learning, growing, and developing. Summarizing the experience, the rather cliche “9 lessons in 9 years” came up as an obvious topic, so here we are. My hope is that I will provide a different and deeper perspective than others offer. My original aspiration was to fit all 9 lessons into a single post, but as I started writing the piece, it became obvious that it would wind up being way too long. I decided to break it up into nine smaller, digestible posts. This way, I won't need to limit the amount of detail I’d share for each lesson.
Let's start with Design Documents. Design Documents? Yes, Design Documents! I know, I know… “how exciting”
To keep you engaged, I’ve put a link to my Design Document template further down.
The lingua franca at Google is the “Design Document”. Maybe during your first week you won’t hear about it, but by your second, your inbox will be full of them. Learning how to write a “Google” Design Document is an art and craft in its own right. But what is it exactly?
In order to fully appreciate and understand what Design Documents are, let’s go back to the DNA encoded in Google. Google was founded by academics. Most of the early staff members were PhDs or PhD dropouts from Stanford and other “lesser” institutions. Larry Page, Sergey Brin, and Urs Holzle (Google’s first VP of Engineering) came from academia. Rumor has it that Larry and Sergey wouldn’t initially interview Eric Schmidt until they found out that he too had a PhD in Computer Science and many academic accomplishments, in addition to his business track record. No matter, they put him through the technical interview process nonetheless.
You have to understand that the way Google approaches decision making is through a very academic style of thinking. Within academic circles, the most valuable currency is that of “the paper”.
How many papers have you published?
How many times have you been cited?
Have you presented your paper yet?
What conference are you submitting to?
Who reviewed your paper?
When that is the world you are coming from and those are your core values, invariably you are going to try and rebuild it as best you can at the company you create. These are the genetics that led to the Design Document.
What is a design document?
The simple explanation of what a Design Document is can be summarized like so:
A Design Document is a self contained, written representation of a problem statement, proposed solution, and an execution path to make it a reality. It is clear, concise, and builds on the work of others. It challenges the status quo with a new and novel perspective that isn’t immediately obvious, but once presented and read by the audience, makes the new world the only clear path forward. To quote Jeff Bezos, a good design document should feel “... like angels singing from on high”. Most of the same questions that apply to academic papers also apply to Google Design Documents, to this day.
“How many Design Documents did you author last quarter?”
“How many people referred to your design document?”
“Have you presented your design document at a tech talk?”
“Who reviewed your design document?”
Being able to author a design document is a quintessential step to being successful at Google. But what IS a design document, why is it so important, and how does one go about creating one?
Why is it important?
The reason design documents are so important is because they force you, the author/engineer/designer, to think long and hard about what it is that you want to do. More precisely: Why is it that you want to do it, the specific way you are proposing, and why this method versus other approaches to the problem at hand. It is an incredible forcing function to get you to think critically about your work. In a way, doing the writing slows you down and forces you to explain yourself to your peers and stakeholders. A design Document is the software equivalent of an architectural diagram and a cost breakdown.
Imagine a contractor came to your house to do a kitchen remodel, and on a first walkthrough just started whacking at a wall with no plan or explanation. That is what writing code without first doing a thoughtful design is like. On the other hand, the same contractor, drawing up a plan, with a clear sequence of steps, cost breakdowns, alternatives, and approaches and then showing it to you in a visual form is much easier to get behind. You can provide feedback, “no, we want the vent hood to be like this, and the dishwasher to be over there”, before the changes are too far along and you are way too far into the project to make changes. I have had personal experience with this. Three kitchen remodels using this strategy worked well, one basement remodel without this strategy did not.
It is much easier to review an idea as a design than it is to review it as a sequence of code changes. You will never have a piece of code that entirely encompasses the breadth of a meaningful design. In practice, a design document translates to dozens, if not hundreds of incremental code changes over a period of weeks, months, quarters, and sometimes even years. You can’t tell someone “listen, I’m going to put these 250 different code changes, and it’ll just work”.
Design Documents, especially with collaborative tools like Google Docs allows for iteration and engagement that was very hard to achieve 20 years ago. The ability to create the Document and share it with collaborators and stakeholders for feedback and iteration is truly priceless. In the post-Covid era, where so much of the workforce is remote, this takes on even higher value and importance. In effect, you are bringing MORE voices, perspectives, and opinions into the communal square. The more views, the more complete your understanding of a subject is, the more complete your understanding is, the more certainty you have that what you are proposing to do is indeed the right thing.
How do you create one?
“Fine, I get it, I’ll do a Design Document, it feels very English 1A to me, but I’ll do it. Just one question? Where do I begin?”
The answer is simple, begin wherever you have the most clarity. If it's a specific API that you are certain of, describe that. If it is a specific, well articulated problem statement, start there. If it is a data model that is completely obvious to you, then that’s your starting point. A critical observation you just made over lunch? Go for it. No matter where you want to go, start from what you know best or have the most clarity in, then build from there.
There are a number of key sections that your document should have, and a link to my template is here, you can make a copy of it for yourself, no credit necessary (although… duplicative language IS discouraged, my alma mater heritage aside). The below will be “duplicated” into the document linked here.
Objective
This is the section that describes as clearly as possible what you are trying to accomplish with this document. It could be a proposal for a new system, product feature, a complex analysis, or a change in plan. Whatever your “thesis statement” is, goes in this section. You can go right ahead and say what you want to do. The shorter, the clearer: the better.
Overview
Include whatever context the reader might not have or that you’d like the reader to have. Prior art, existing state, published research, pick. This is your opportunity to bias the reader but also demonstrate that you’ve done your homework. It really wouldn’t look great if you proposed building a bridge across the SF Bay peninsula when one already exists in the precise location where you wanted to build your bridge. This is also your opportunity to establish credibility with the audience to demonstrate that you know what your talking about, and here is the proof with hard evidence and level setting.
Design (or some clever name here)
Now you get to switch gears and go into the meat and potatoes of what you’d like to do. Describe what the new world order is going to look like. What assumptions you made, data collected, and how you arrived at your conclusion. Although in THIS writing it is the shortest paragraph, in practice, this is where you’ll spend most of your time.
Alternatives Considered (Optional)
What other options existed or that you evaluated before settling on your final design. Why did you disregard them? What was problematic about these approaches or why is your approach somehow uniquely better? Although this section is optional, including it along with multiple alternatives, demonstrates that you’ve really thought about the problem. Once the document is sent for review, a few things can happen.
This section grows in scope without any particular alternative truly challenging the original proposal
The feedback winds up being such that an alternative emerges as the front runner because of a missed point. Remember my reference regarding getting feedback? I can’t tell you how often I’ve seen a reviewer jump into the “Alternatives” section and propose an idea that is better than the original design or any of the alternatives that were written down, to ultimately become THE solution.
This is one element that makes the design document so valuable. Being open to alternatives turns the document into a living discussion forum that enhances the original premise and value of the document. The more participants, the stronger the claim, the more complete the world view. It is peer-reviewed publishing in real time.
Implementation Plan
Here you get to tell everyone HOW you are going to make this design document a reality. What is the sequence of steps you are going to take, what data you will gather, what will be built in which order and how. How will you validate your solution and what are the key milestones? Are we making progress? Is the project working? Do we have validation that the lights really do turn on? The more complex the project, the more sequencing and dependencies matter. Listing them out and calling out the various dangers and pitfalls is critical to ensuring that you’ll have a successful execution. In this section is where feedback is also paramount. You are invariably writing from incomplete information, and getting other colleagues' perspectives can help avert a disaster.
The reason doing this type of writing and exposing yourself to critique is hard is because there is always an ego that gets in the way. You want to feel like you have the complete picture, your approach is right, and that your insight is amazing. The reality is that going through this type of analysis will invariably take your personal ego a few notches down. No one is infallible or untouchable in a design document. And this type of constant polishing makes all of us better.
The truth of the matter is you won’t be good at writing design documents right out of the gate. It takes practice, repetition, and openness to feedback and growth. But once you enter the Design Document world, you’ll never be able to go back to the “let’s just put it together and see what happens” universe again.