Should we make a process?
Make it faster, make it safer. The rest is just paperwork.
When deciding to systematize something, I’ve concluded there are only 2 reasons to do so: Make it faster. Make it safer.
This can be summarized by asking yourself the following two questions:
Does adding this process make this step faster?
By faster, I mean: take less time, thought, resources, pain and agony, difficulty, barriers, etc.
Does adding this process make this step safer?
By safer, I mean: reduce risk, improve consistency, improve yield, lower headaches, reduce cognitive load, reduce injuries, etc.
If the answer to both of these questions is no, don’t create the process.
If the answer to both of these questions is yes, double-down on the investment and make something that scales.
One step further, if you encounter a process that cannot be adequately explained as increasing speed or decreasing risk, eliminate it.
Cover sheets on weekly reports: Faster? No. Safer? No. Eliminate.
Part number tracking system for production: Faster? No. Safer? Yes. Keep it.
Document templates for weekly presentations: Faster? Yes. Safer? Yes. Keep it. In fact, double-down on it.
The far harder trade-off is understanding when to compromise safety for the sake of speed, or when to sacrifice speed for the sake of safety.
This framework also helps explain the motivations behind many systems.
A startup wants fast, because fast means higher use, more iteration, and ultimately more effective services. Often, they are willing to sacrifice consistency, yield, and stability in order to outpace the competition. Implementing systems that reduce case-by-case evaluation, and systematize trivial tasks will ultimately lead to quick outputs. Processes like a stipend or budget help reduce cognitive load on management to approve every expense, and team mantras or mission statements help guide complex, multifaceted decision making by reducing steps between cognition and action.
Ultimately, in a face-paced environment, speed matters. This article summarizes the concept of face-paced (and the consequence of slow-paced) systems beautifully.
A large corporate entity or organization like the military wants stability, lower risk, and reduced cognitive load. In a complex environment like a battlefield or the public market, reducing risk is more important than moving quickly. When you have many individual components to care for, ensuring the machine keeps working even if a few break is more important that accelerating headlong into the future. Facebook famously touted the “Move Fast and Break Things” mantra, until of course, they reached a scale where that became dangerous. Then, seeking to reduce risk, they transitioned to their current mantra “Move Fast with Stable Infrastructure”.
A great example is Coca-Cola, the beverage titan (amongst other things). I am confident that even with a covert team of 20, working diligently for years inside the corporate walls, you could not bring down the company. That isn’t a slight at your ability for espionage, but rather that Coca-Cola has optimized their systems such that no individual cog in the machine has so much control. The company is designed to progress forwards regardless of mishaps and short-comings.
When evaluating processes, structures, and flow of information in a team, organization, or system, evaluating whether speed or risk is more important is a great starting place.
If I make this process, what could go wrong?
And more specifically, what are the second order effects of doing so?
For example, implementing an engineering purchasing process for R&D can be a great way to control and monitor spending. At previous companies I’ve worked for, to purchase something, I needed to find the part online, create a purchase order document, send it to the purchasing manager who would review it, make edits, and then email it back, at which point I would revise, submit, and then wait for them to push it through the accounting system to buy the part, at which point it would ship to us over the course of a few days or weeks. This often took days to weeks (or even months!) to implement.
The pro to this system is that it is repeatable, low-risk, and controlled. The con, of course, is that it is mind-numbing in its slowness. Often, ordering something simple like bolts or stickers, took longer than design of the project.
As mentioned in the Speed Matters article, this emphasized (implicitly, as a second-order effect) a culture of only purchasing parts when they were really needed. That was a great way to emphasize frugality and utilizing the tools that were available rather than solving problems by spending money. However, it dramatically slowed down the R&D process. The balance here, is that R&D is expensive (in time and salaries) so speeding up that process makes sense, but not at the cost of spending money you don’t have.
A counter process to improve this might be a monthly budget.
Every month, the team is given $1000 (or some amount that makes sense) to spend on whatever they see fit — tools, parts, software, etc. The goal here is to reduce the time and effort between concept and action. Instead of weeks, development should take days, and the bottleneck should not be on ordering.
If that feels too scary, implementing a lower-bound is a good policy for small businesses. If the purchase is less than $200, for example, no need for approval, simply purchase the components and expense them. If it is over that limit, it is worth a discussion. This dramatically reduces the time and effort of managers to approve small, trivial tasks, and focuses the risk on the large items that are worth evaluating.
The underlying asset to both of these processes is trust.
Do you trust your employees to make thoughtful decisions with the company’s interest in mind? Or do you need to monitor their activities? And if they abuse the system, what is the worst that could happen?
Put that way, of course most people would say they trust their colleagues and the people they work with. However, in some cases it isn’t that straight-forward. A friend of mine runs a small business where most of his employees are high-school students. Any particular employee might be great, but as a whole, they can be unreliable, difficult to manage, and unmotivated. Many of the systems he has built within his business are ones of reducing risk rather than improving speed. If his staff want to purchase something, he wants to know about it (as he has been burned here in the past). The trade-off of his time to approve against the cost of purchasing is well worth it for him. Specifically, for him, the Lifetime Value of a customer is substantially higher than the cost of his time to approve expenses, so he wants to keep a finger on all company spending.
In my experience working for small companies, many do not have processes implemented at all, let alone ones that need review. When you’re building something new, taking the time to systematize your efforts often doesn’t make sense.
But when you reach the scale that things are repeating, it’s worth thinking about processes and systems.
The critical question to ask at this junction is:
Should this process improve speed or reduce risk?
If you are a start-up, generally, improving speed is the way to go.
Reduce complexity, disseminate information, allow individuals to make their own decisions, limit steps between ideation and action, and have trust in your people.
If you are a hospital, government, or Fortune 500 company, generally, reducing risk makes sense.
Set clear goals, measure key metrics and track results, reduce reliance on individuals and create robust teams, improve repeatable workflows, and have faith in your systems.
And perhaps, most importantly, when goals change and the environments shift, be willing to destroy and reinvent out-dated processes.
Does it make it faster? Does it make it safer? The rest is just paperwork.
Brendan is a Mechanical Designer at Nymi, and blogs about startups, mental models and why hardware is hard here. He’s a Venture for Canada alumni, coffee aficionado, and cookbook collector. If he were an action figure, the three items he would come with are: a coffee mug, a library card, and a chef’s knife.
