Engineering is a well-run kitchen
Companies that build software products have the typical divide between their Product and Engineering departments. Getting the flow right between those two sides of the organization is vital.
Being overly Product-driven is all too common. People write lengthy requirements documents and throw them over the wall to the Engineering department. It's a chaotic, deadline-driven way of building lousy software. On the other hand, organizations driven by Engineering build high-quality software that no one buys. Getting it right is a tricky balancing act.
This vague equilibrium leaves much room for interpretation, and companies struggle to find the right balance. What is a healthy way of building software products together? What does a good relationship between Product and Engineering look like?
A metaphor I like is that of a local restaurant. The Engineering department is the kitchen; the Product organization is the Front of House. Let's dive into their relationship a little deeper.
Product is first in line when it comes to serving customers. They take orders, push specials, deliver the dishes and check whether customers enjoy their meals. Without them, we wouldn't know what to build.
Engineering is in charge of meal prep, planning, and quality control. They cook, clean, and control the flow to keep the kitchen from getting backed up. Without them, we wouldn't be able to build.
If we look at this relationship between FOH and the kitchen, it becomes clear that the kitchen must be in charge of planning.
It would be crazy for servers to decide which meal to cook next. They don't know which sous-chef is available and how long the stew needs to simmer. They have no idea which meals can be cooked in parallel and which need special attention. That's obviously Engineering's job.
On the other hand, it would be equally crazy for the cooks to start preparing a meal that no one ordered. To just guess that three people would like the salmon. Or worse, to serve the customer salmon because that's what we've cooked up.
Product needs ways to influence the plan. The kitchen owns it, and the FOH gives feedback to steer it. That's the healthy way of running a restaurant.
Waiters need a way to expedite an order when table 5's fries have gone missing. The same waiters can't ask the kitchen to drop everything at the whim of table 5.
The kitchen needs to report progress and delays early and often. Waiters need to know when the kitchen is getting backed up so they can inform the customers. "It's done when it's done" isn't good enough.
In some cases, the customer should be able to discuss dietary restrictions directly with the cook. But customers can't storm into the kitchen asking for a dessert.
Customer feedback should drive changes in the kitchen. If there's a demand for a vegan option, Product should put this on Engineering's radar. Whether that's a quiche or a curry is up to the cook.
Overly Product-driven organizations reduce the kitchen to literal order takers. They will tell the cooks which meal to prepare next. They'll go as far as to specify the recipes in Jira tickets. That's an unhealthy relationship that is, unfortunately, still very common. It leads to a kitchen that's backed up where pots are boiling over, and the dishes stack up. It ultimately results in unhappy customers.
A healthy Product organization is obsessed with serving customers and gathering feedback. They notice when a patron doesn't touch his salad and check whether something is wrong. They flag opportunities when another birthday party asks for the dessert menu. Product people have better things to do than meddling in the kitchen and checking whether the soup is salty enough.
When we talk about self-organizing Engineering teams, I want you to think of a well-run kitchen. They own their plan, control their flow and communicate their status to the rest of the organization. They provide ways for Product to influence that plan through feedback and can expedite orders if needed. They are responsible for the quality and timing of their deliverables. Under no circumstance do they allow someone to barge into the kitchen and make demands.
While all metaphors are flawed, this relationship is a great model for that balance. The Product organization should refrain from specifying requirements and should not be involved in QA.
Product is a company's eyes in the field. If those eyes are busy looking at what the kitchen is doing, they turn their back to the customers.