Why big companies are slow

Following one line on a product page to see where the time goes.

6 min readways of working

In a small company, a change can happen in an afternoon. In a big one it can take months.

People who move from a startup to a big company notice this quickly, and they often say so: “we were much better at this at my last place.” Usually they have a point. Big companies do get messy, especially ones that have been around a while. Years of growth leave old systems behind, along with processes that made sense once and decisions nobody quite remembers making.

But the mess doesn’t explain all of it. Some of the slowness would be there even in a tidy company, and the easiest way to see why is to follow one small change all the way through. The change is adding a delivery date for a kettle: the “Arrives in 3–5 days” line you see under the price when you shop online.

The small shop

Suppose a small shop wants to add that line. The owner knows what’s on the shelf, what’s been put aside for someone, and how long the local post usually takes. That’s everything they need to give their customers a delivery estimate, so they can add the line in an afternoon.

The big company

Now suppose the kettle is sold by a big company. It has many factories and a logistics network that carries goods to warehouses around the world, so there’s no longer one place to look to answer “do we have it?” There might be plenty of kettles in one warehouse and none in the one near the customer. Some of the stock still on its way may already be promised to online customers or retailers.

So the date has to change as stock moves through the network. If the local warehouse runs out, another one might supply the order. If that one is empty too, the customer might have to wait for a shipment to clear customs. At this size, a date that’s only occasionally wrong still lets down a lot of people, so the website has to work all of this out for each customer, at the moment they look.

What a delivery date depends on

The estimate we want the website to giveArrives in 3–5 days

From the local warehouse.

A fictional network, with invented stock and delivery times.

Who knows the answer

No single team knows all of it. The warehouse knows what’s on its shelves. The order team keeps the record of online sales. The sales team knows which stock it has set aside for retailers, and logistics knows how long delivery takes from each warehouse.

Each of those teams has its own systems and its own ways of working. To turn what they know into a date the website can use, they have to agree how the pieces fit together. When does stock count as reserved? Can an online order use stock held for a retailer? Which warehouses can serve this customer? The website needs those answers to estimate a date, and checkout needs them to reserve the kettle before another order claims it.

Not worth it at first

That’s a lot of work for one line on a product page, so at first the company decides it has more important things to build. The website shows a rough estimate, and the company lives with the occasional late kettle.

The website isn’t the only part of the company that needs the answer, though. Sales teams need to know what they can offer retailers. Warehouses need to know which orders have a claim on their stock. Customer care needs to know what to tell someone whose kettle is late. Each of them works it out with spreadsheets, phone calls and best guesses.

Over time the pressure builds, until someone can argue that it’s worth fixing properly. By then the request has grown. What they’re asking for is a system that can say which stock can be promised to a customer and how long it will take to get there. The date on the website is one small use of it.

Making the case

Even with all that pressure, starting the work isn’t simple. Every team already has a ranked list of valuable work lined up. Making room for the delivery system means putting some of that on hold.

The bigger the project, the more teams it touches and the more plans have to change. Someone has to work out what each team would need to do, how much time and money it would take, and what would have to wait. Getting the teams to agree on that plan takes time too.

A small change can be decided inside one team. This one needs time from several, and no team lead can decide what the other teams should put on hold. So the decision goes up to senior leaders, who can weigh those priorities against each other.

Senior leaders are busy, and teams that change direction too often struggle to finish anything. So decisions at this level tend to be saved up for a planning round, perhaps once a quarter. If other work wins that round, the delivery system waits for the next one, or the one after. Several quarters can pass in planning, discussion and waiting before anyone starts building.

Orange is the delivery proposal. A sketch with invented timings and reporting lines.

Building it

Once the work is chosen, it takes a place in each team’s plan. The warehouse team has to share available stock, the order team has to reserve it, logistics has to supply delivery times, and the website has to put the answer on the page.

That doesn’t mean every team drops what it’s doing. One can start now. Another has a release to finish first, and another has work that still comes ahead of this. Some of it can happen in parallel. The website team can build the page with sample data while the other teams build the systems it will use.

An illustrative schedule, with invented timings.

Then the pieces have to be connected and tested together. The page might be ready long before it can show a real estimate, one backed by stock that checkout can reserve. The feature isn’t finished until every team’s part is.

The same line on the page

When the day comes, adding the line to the page might still take an afternoon. The customer sees the same “Arrives in 3–5 days” the shop owner would have written. What’s different is everything behind it. The shop owner could keep the answer in their head. The big company had to build a system that several teams feed and several more depend on.

Building that system is real work, but much of the time went on the work around it: working out what each team would need to do, agreeing what could wait, waiting for a planning round, and then waiting for each team to be ready. Nobody was idle in that time. Every team was busy with work that had been judged more important, and often it was.

The newcomer who said things were better at their last place usually has a point, and some of the difference really is mess. But even a tidy big company would take longer to ship this. The change runs through teams with their own systems, their own full plans and their own leaders, and all of them have to plan for it and make room for it at about the same time.

Links