I’ve always wanted to build things that outlast me. That impulse grew into a series of habits that grew into a way of working.
Part I: College
I spent about a year and a half working on large autonomous vehicles in my undergraduate robotics lab, under the supervision of a professor whose CV included time as the VP of Engineering at iRobot and a stint as a director in Disney’s Imagineering arm¹. He told me that I was the best project manager he’d ever had. I didn’t even remotely believe him until years after graduation, when one of my college teammates visited campus and mentioned to me that our professor was still saying that about me.
He hasn’t actually convinced me that I’m the best PM he’s ever worked with, but I’m starting to understand why he appreciated having me in his lab. It’s pretty simple: I made it easy for other people to carry my work forward.
Nothing that I did was revolutionary. My labmates, many of whom are now professional roboticists working on groundbreaking technology, were the ones trying to blaze new paths.
I mostly assembled electrical systems built from off-the-shelf components, which required an understanding of Ohm’s law, access to the McMaster Carr catalog, and basic soldering skills. I stood out because my work was clear, understandable, and reusable. I made CAD models of the power supplies and fuse blocks and motor controllers and got acrylic mounting boards laser cut to perfectly fit all of them. My wires were color coded, labeled at both ends, and bridged with pull-apart connectors so that nothing had to be unscrewed to swap out a part. I made overhead diagrams of all of the wiring, and inserted them into detailed system writeups that I saved into the shared lab drive.
And when I led a team, I made them do the same things. Everything was labeled. (Almost) everything was routed neatly throughout the vehicle. Our end of term reports included detailed diagrams and written descriptions for each subsystem, along with explanations for the chosen design. The result was a system that was still in active development when we returned for our five year reunion. Not bad for a bunch of college kids.
Part II: Windows
Microsoft is a big company with a lot of internal movement. People leave the company. They change teams. Interns come and go. New coworkers join, college hires mostly in the summer and more experienced folks all throughout the year.
At a more localized level, work moves around. Priorities shift. Ideas are deferred because they don’t fit this release’s strategic priorities. People get loaned to teams that are overloaded, and their projects shift to their coworkers.
People go on vacation, or parental leave, or get sick.
Change is inevitable. Even the most junior employees quickly learn that handing off features is a normal part of the job.
There are standard practices, reinforced at every level of the organization.
The rationale behind a feature, the key outcomes, the desired functionality are all documented and uploaded to a searchable shared store. Leads have few enough reports that they can track what each person is working on. Everyone learns to create shared notebooks and folders for their thoughts. Design artifacts are kept in a searchable repository managed by the design team. Work items are tracked in a shared project management tool that anyone in the organization can look into.
Beyond that, there is a culture of communication. Product managers talk to their teammates about their ideas, and they review key product decisions with the other product folks in their management structure. Managers hold regular meetings where all of their employees openly discuss their projects. Successful product managers socialize their ideas across the organization; those with a more introverted style receive feedback from their supervisors: work on your visibility.
Nothing is ever dependent on a single individual, making the organization and the product more robust. If someone goes away, the people around them are able to step in and fill the space they occupied².
Part III: Designing for transition
One of the unusual things about 18F is that nothing I work on is truly mine³. I work with people across state and federal government, helping them achieve their organizational goals. Even though I come in as a consultant who brings specific expertise that the partner organization doesn’t have, making myself essential to the product would be an act of hubris.
The projects I work on are normally 6, maybe 12, months long. My term at 18F expires in 2.5 years. Nothing I’ve worked on is small enough to fit into that time scale.
I see only one way to go about my work: I must set up systems that carry forward without me. Here’s how I do that:
Rule 1: Transition starts on the first day.
It’s all too easy to push off the work that makes for a clean handoff — who wants to spend time talking to stakeholders and documenting things when there’s something new and exciting to build? Documenting your product is like cleaning your bathroom: the longer you put it off, the worse it’s going to be when you finally have to do it.
Rule 2: Write down what you’re trying to achieve.
I start off every project with a product specification (spec)⁴, which I’ve been calling a framing document when working in an agile environment. It holds a few essential pieces of information: the product vision, context on the problem space, a list of prioritized outcomes to realize, and key performance indicators. If I’m working with a partner, they write the framing document (with my help).
This creates and anchor for the entire team. It serves as a key piece of onboarding material — it’s one of the first things that any new teammate will read. It’s also a good tool to maintain alignment with executive sponsors, partner teams, and other stakeholders.
Rule 3: Ideas don’t belong to individuals.
Ideas may come from individual team members, but once they’re shared they belong to the entire team. Even as the team changes, the core ideas should stay. That doesn’t work when ideas are tied to individuals.
Key decisions and important considerations about the project need to be socialized both inside and outside of the team. Making the knowledge belong to the team instead of the individual helps preserve ideas and keep future teams from having to retrace their predecessor’s steps.
Rule 4: A little documentation goes a long way.
The best documentation conveys all of the key information about the product without being so long and detailed that nobody will actually read it. A repository full of GitHub issues and pull requests is not enough. Code, even really good code, is not enough. A folder of raw research transcripts is not enough. None of these things provide enough context for the next team to make informed decisions about the product.
Good product documentation helps future teams understand several things:
- What does the product do?
- Why does the product do what it does? Why does it do it that particular way?
For teams with high turnover, it’s helpful to document not just the product itself but also the processes that the team follows (like how sprints are planned, how bugs should be filed, and so on).
Rule 5: Handoffs are a team sport.
Every team member has their own unique perspective on the product. If someone doesn’t document their work, that perspective is lost and the next team will have to retrace their steps. At best, this is inefficient. At worst, it will cost future teams money and social capital. Project leads should make sure that everyone is documenting their work — whether that means adding documentation to the acceptance criteria, holding periodic documentation jams, or whatever else works for the team.
¹ I’m still not sure exactly how he ended up at our tiny college in Needham, but he certainly seems to be enjoying it.
² I once got a concussion while biking to work, and was very suddenly completely unavailable for two weeks. Nothing that I was working on got dropped when this happened and I was able to reintegrate seamlessly when I recovered.
³ There are a few products that 18F fully owns, like cloud.gov. I don’t work on any of them.
⁴ A traditional spec includes a lot of detail on the intended solution, including a lot of product requirements. Since we work in an iterative manner at 18F, I leave all of that out. Those requirements tend to shift quite a bit as you build anyway, if you’re paying the least bit of attention to the world around you. This doesn’t diminish the value of the other parts of the spec format.
