Templates

Accomplished people shouldn't need their ways of working written down. I've heard some version of that from more than one leader I've reported to, and the logic sounds reasonable at first. If you hired well, the people in those roles should be smart enough to figure out how the work gets done on their own, without a document spelling it out for them.

It breaks down almost immediately. Everyone on a team shows up with a different background, a different way of thinking, and a different set of lessons, usually learned at a company that did things its own way.

Take an engineer whose last job called a feature done the moment the code merged, and put them on a team where done means it's live, tested, and working for customers. They're sharp, and they're still going to hand over work your team doesn't consider finished, because nobody ever showed them where the line was. A marketer who came up planning launches a quarter out will hit the same wall on a team that releases every week. Swap in any role you like and you'll find the same gap.

I learned what that gap feels like from the inside when I came into a large corporation as a project lead. I had three people reporting to me who were managing five projects between them, and the first month on the job was a nightmare. I remember one meeting that pulled in three departments and eleven co-workers. A month in, I still couldn't keep the work under control, because of how disorganized everything was. It becomes hard to use your skills or work effectively if you don't know where shit is.

So everything got one home, and going forward, no documents went out by email. I've done the same thing since at startups of 5 people and at corporations of 60,000, and every time, value was found and efficiencies were earned.

The clearest result I've seen came from an engineering team that hadn't shipped a quality release in a year. Once we fixed how that team worked, they shipped their first release in a year without major defects, and their bug count dropped by about 85 percent. New people ramp up faster, and the work they turn out is better.

Some of the doubters come around once they see it. A senior vice president I worked with didn't believe in the work I was doing on how our teams ran. Once they saw how cohesive the teams had become, and the outcomes that came with it, they picked up on the reasons behind it and were appreciative after.

Letting people be creative about the problem without stopping to work out the process first is what this whole playbook is about. The ways of working are the bigger picture, the shared answer to how a piece of work moves from a customer problem to something shipped. Templates are where that picture turns into something you can actually fill in. When the process is already mapped out and every piece of information already has a place to go, the work gets a lot easier to start and a lot harder to get wrong. Nobody stares at a blank page wondering what goes where.

The five cards below are the ones I use, in the order they hand off to each other, from the first customer problem down to the bug that slips through. Each page gives you the blank to copy and the same card filled out on one running example. When you want the craft of writing one well, it lives in the Opportunity Backlog and Delivery sections.