Skip to content

Ground Rules

This is the most important guideline in the entire playbook. Live music is essential at a concert but probably unwelcome at a funeral. What works well for me depends on a mix of intentions, constraints (many of which might be poorly understood), assumptions, timing, and - quite often - my current state of fatigue.

What works for you may be different.

If you had a magical device that always delivered the right decision - the right priorities, the right tradeoffs, the right design - you wouldn’t need much of a playbook. Since Magic 8-Balls don’t actually work (though I’ve been in roadmap meetings where I suspect the participants had them lodged between their brains and their mouths), my process journey has focused on developing good judgement.

At the risk of being pedantic: judgement is about making the optimal, the sufficient, or the least-bad decision. Which features do we ship this release? What architectural decisions should we commit to and which should we defer? Which customer will we knowingly disappoint?

While much of my emphasis is on judgement, it’s equally about not flailing. I define flailing as impulsive, reactive, or impatient decision-making - trying random things and usually wasting effort and time. Deliberate and methodical decision-making is the best antidote I know.

I have no idea what your starting point is. You may be a process ninja or just beginning your journey into adding (and later removing) red tape.

So at times, some of what I write may seem obvious. I ask for your patience and hope not to inflict such trivial advice often.

All ideas are derivative. Or at least, all of mine are. I’ve been studying and tinkering with process for over twenty-five years. Everything in this playbook is an amalgamation and adaptation of something I’ve learned. I’ll note many of these influences in Thank Yous.

So I encourage you to borrow, adapt, or ignore any of my ideas. And to seek out the ideas of others. Austin Kleon has a whole book on this.

Thinking about process can be stressful. Not only do you have the strain of your project and its outcomes, but now you might worry: “Am I using the right tools? Are we doing MVPs right? Is my tag structure optimal?”

Don’t do process for the sake of doing process. While I’ll offer some ideas on process evolution, remember that process should help. It shouldn’t be a burden.

Sometimes I’ll note assumptions and factors for using a process or guide, but please always remember the first principle above.

Or simply remember: “Chris is probably wrong.” I won’t mind, because:

  1. I might be wrong, and
  2. I won’t lose sleep over the idea that someone, somewhere on the Internet thinks I’m nuts.

But if you’ll indulge me, ask “Why is Chris wrong?” That question might reveal assumptions and subtleties, and let you learn something - albeit not from me. I’ll wish I was there with you, because I might learn something too.

I did a lot of contract negotiation while at Pivotal Labs. Periodically, I’d get questions (or pushback) on our agile process: “Do we need to pair program? Do we need to…?”

My response was always the same:

We aren’t asserting this is the only way to do things or even the optimal way. But it is the best way we know how. And we take our client’s money very seriously. We need you to let us do our process so we don’t waste your money, because not doing our process means we won’t be doing the job the way we know best.

Clients found this reasonable. So everything on this site is just my ideas - the ones that work for me. They’ve changed and will continue to change. But they are my playbook. Feel free to borrow, try, adapt, and abandon any part of it.

The best process is the one that works for you: the one that gets the results you want and that you can live with.

My only ask is that you be thoughtful about what you do and why.