simpler things

The start of the project, just after you get the thing working for the first time, is the best. Look at this neat thing we built! We have all this time in front of us to make it amazing!

The end of the project usually comes with a sense of relief. Phew, we made it! And it's nice to not have to do any more tedious launch chores!

Handing off the project feels the strangest. What you poured so much time and attention into has quickly become a stranger. How do I deploy this service again? Why did we leave these janky lines of code here? The handoff stirs up guilt. You're passing off all those TODO comments (and all the things left to be done that no one wrote down).

For me, at least, that guilt masks possessiveness. This is my project! I'll hand it to you once it's absolutely perfect. So perfect that people will always remember what I built. So perfect that no one will have any reason to criticize my work or ask me to improve.

You can see why people love starting new projects. And why they avoid the work necessary to hand the system off to new people.

The benefits of documentation, writing playbooks, building monitoring, and making deploys fast are all shared and largely invisible. The glory of shipping new features or swooping in to put out a fire on an important system is clearly visible and flows to individuals.

“In the Navy, if you haven't built training, you haven't built anything. The moment you step away from the project, the team will be pulled onto other projects, and the whole thing will fizzle out,” Dave Madden told me last week, when we were talking about learning through training versus learning by osmosis.

What does the Navy have to do with startups?

You can think of a startup as two companies. One company ships new things, some of which hopefully delight users. The other company maintains and improves whatever's already a hit with users.

As much as you want to run one company focused on a single goal, you have to run two companies. You have to build new things quickly. And build them well. And maintain a high level of service even when you've turned your attention elsewhere.

The lines between the two companies are not clean. Most people work at both companies simultaneously. Each company requires a different approach, though.

The fastest way to learn to delight users is by doing it. Ship, observe, iterate. Making it clear how quickly and boldly to move helps, but ultimately you learn by doing. Hiring people with passion and energy and throwing them into the deep end is a great strategy for the first company.

Launching products at scale, maintaining high service levels, and monitoring systems for regressions are all teachable skills. As with anything else, you learn the most by doing, but while you're learning you'll make a lot of avoidable mistakes, causing pain for users and your team. Training, documentation, checklists, and shadowing more experienced employees bring people up to speed faster with fewer costly mistakes than throwing people into the deep end.

You can think of the second company's goal as taking the successful parts of the business and executing well (and repeatably) on them.

As often happens midway through writing a post, I'm reading the paragraphs above and thinking “this is all obvious.” Of course you have to ship new things and execute well to succeed as a startup. Of course you have to do a lot of work to smoothly hand over a system to a new owner. Of course, of course.

But this post answers a question that's been on the back of my mind, just a level below conscious thought: why have I resisted investing in training and documentation? Why have I kept throwing people into the deep end? It's because I've been focused on running the delight-users-with-new-things company. Not because I'm distracted by shiny things, but rather because I want to work with people who can :justdoit:.

:justdoit: looks different at each company. When trying to delight users, :justdoit: means “just put something out into the world.” When amplifying successful projects, :justdoit: means “just use tried-and-true techniques and you will have good outcomes.” The key is recognizing when you're showing up to work at which company!