Good process is a pact to ship bad stuff
First let me define ‘bad’. Imagine a baby pacifier. Here are two things that can be wrong with it:
- It’s the wrong color
- When heated to body temperature, it explodes
Problem two is a valid objection at any point in the process of designing & selling this product. The cost of shipping an exploding baby pacifier is always going to be higher than the cost of not shipping it. It might be illegal (but I’m not a lawyer).
But if your pacifier is the wrong color, there is a time to cheaply redesign it, and that time isn’t the day before your global launch, with lots of famous babies on instagram getting paid the big bucks to be seen strolling with your new brand. Even if color has a known effect on sales, weighed against the sunk cost of manufacturing you should probably ship.
The problem here is doing most of the work of a thing and then having to redo or scrap it as new stakeholders panic or original stakeholders rebel. My guess is that if you’re reading this article you’ve lived some version of that story. The point of good process is to discover problems early but ignore problems you discover late unless they’re critical.
I should caveat that all my experience is in shipping software that has an iterative release cycle, and despite my example above these thoughts have no applicability to shipping something physical and safety-critical like a car.
Fewer surprises
The role of process is to create a reliable path to delivery by reducing surprises from ‘internal information’, i.e. information held by an in-house expert.
It’s okay to iterate but if you’re iterating prior to a release you have to question what new information you’ve gotten. If the new information is internal, you’re experiencing a process failure where an internal stakeholder with the authority to stop the train didn’t sign off on your spec. Or maybe a manager didn’t understand what was going out the door until it was finished, but this sort of imagination is a manager’s job.
The best way to learn new things is to ship to users, especially when you have the ability to iteratively release fixes and new features, and we should usually bias to release.
Testing is sort of an exception to this. Trouble discovered in test is always going to happen after the build has started. A good process will leave time for testers to add a cycle, especially when there’s a hard deadline. But measure how often this happens and how long these cycles take, and do whatever you can to push them earlier in the process.
Always be shipping
Everyone is here to ship. If you don’t, people will either leave your team or leave your company. Getting work out the door is the only thing that everyone in your company agrees on – even people in a compliance / risk role are there to enable the company to ship safely in a risky environment.
Delaying a single feature is bad but the really bad version of this is failing to act on your strategy. For a startup that might mean never shipping your MVP. For an established car company it might mean missing electrics, or falling behind in manufacturing efficiency. For google it might mean missing the jump to mobile. (They didn’t – android can be a mess but it’s way better for them than not having android).
For every company that’s blindsided by its competition there’s another that knows what’s up but fails to act.
Groups that fail to ship are often overestimating the cost of releasing something imperfect. An org-chart correlate of this is having too many people with veto power over a project.
There are cases where a bad release can tank a product line. Bad movie sequels are in theory dangerous because they break the franchise. But there are always diminishing returns to sequels. Yes, Indiana Jones and Star Wars earned tens of billions of extra dollars in box office and merchandise by being good twice. Hint: your thing isn’t Star Wars. Don’t benchmark against the outlier.
Shipping slower than you should is way costly. Estimation isn’t easy but if you’re 3x slower than the competition, you’re executing badly. Unless you’re in a narrow niche, someone is going to out-innovate you. Even in a narrow niche, the ability to execute opens doors for your business.
Authority & expertise
Good process balances the perfectionists and hurriers on your team by letting the perfectionists get heard at the beginning, then letting the hurriers take over at the end. Process makes this transition predictable so that nobody wastes time arguing. ‘You should have raised that in spec’ is a valuable thing to say because next time, they will. Sticking to process lets companies get better in ways that transcend individual managers.
While writing this, I heard the Defense One podcast on wargames, and particularly liked this section on bringing together diverse experts:
(circa 10:00) And so a game is something that can literally bring together people with really different areas of focus and help them build a common model together. … where otherwise you might end up with lots of people working in kind of stovepipe ways, you end up with a book that’s got interesting chapters on specific topics, but no integration … . Thinking about how to knit all of that together … becomes really hard to do without something that’s a common integrated model like a wargame.
Speccing will serve you better if you treat it like wargaming, with the goal of creating a design that your experts won’t object to because it already integrates their objections.
One of the friends I interviewed for this compared ‘fast’ and ‘slow’ managers by how many editing round trips they took to get to a finished product. He used the word ‘vision’ to compare that. I think vision probably means a combination of experience + authority: the experience to know that something is ‘ready’ without a lot of rumination, and the authority to say ‘okay team, move on to the next thing’.
Iterating on process includes designing authority. One way to reduce objections to shipping is to create narrower groups that can get work out the door without asking for permission.
I really like the movie moneyball because every scene in there is a realistic authority conflict. Arguing about how to replace key players, for example. The middle managers in the room aren’t making an argument, they’re resisting a change in strategy by saying things like ‘let us do the job’. This movie is about applying a statistical strategy to win games on a budget, but whoever wrote it understood that while good strategy is based on good arguments sometimes authority is the deciding factor. This is why it’s so important to have good authority structures and promote well.
Raise problems in spec & get signoff
A spec is finished not when it’s possible to build, but when it’s plausible to ship. That includes resolving objections from stakeholders whose job only kicks in at delivery time, like sales and marketing. You don’t want to manufacture a truck that doesn’t fit in a shipping container.
Align your team around the concept that speccing should be painful. Spec pain is cheaper than pain later. Specs are nonlinear and frustrating so that work can be linear and predictable. Speccing is the time for all stakeholders to take potshots at the idea, not for one domain expert to say what we’re building and hand it off.
(You’ll define ‘stakeholders’ according to the structure and needs of your team, but at minimum it should include anyone who gets a veto later).
Also align them around the concept of signoff. Nobody likes chasing stakeholders for a yes more than once. Managing up is hard but it shouldn’t be as hard as it is.
If you’re having arguments that are shredding people’s adrenal systems and delaying work, pay your conflict forward by having it out during the spec process. People love getting work out the door and become frightened and frustrated when that fails – partly because wasting time sucks, but also because their jobs or career growth are threatened by being on a crappy project. ‘Big project got scrapped’ and ‘never going to ship’ are real reasons people ditch big 5 paychecks to try small biz.
Reliable process that ships work is a force multiplier. Invest in it.
