We Need Process, But Process Gets in the Way

How do you manage a company with 50,000 employees? You need processes that give you visibility and control across every function such as technology, logistics, operations, and more. But the moment you try to create a single process to govern everyone, it stops working for anyone.

One system can't cater to every team, every workflow, every context. When implemented you start seeing in-fighting, projects missing deadlines, people quitting. Compromises get made, and in my experience, it almost always becomes overwhelming.

The first time I was part of a merger, I was naïve about how it would go. The narrative we were sold was reassuring. The larger company was acquiring us because we were successful. The last thing they'd want to do was get in the way of that success. But that's not how it went.

It doesn't matter what made you successful before you join a larger organization. The principles and processes of the acquiring company are what will dominate. Your past success is acknowledged, maybe even celebrated, but it doesn't protect you from assimilation.

One of the first things we had to adopt was Scrum. It may be standard practice now, but at the time it was still making its way through the industry. Our team, developers and product managers, already had a process that worked. We knew how to communicate, how to prioritize, how to ship. Adopting this new set of ceremonies felt counterproductive. It didn't make us faster. It didn't improve communication. What it did do was increase administrative overhead. Standups, sprints, retrospectives, layer after layer of structure added on top of work that was already getting done.

But there was no going back. We were never going to return to being that nimble, ad hoc team that could resolve issues quickly and move on. We had to adopt methods that got in the way.

Eventually, we adapted. We adopted the process. And in doing so, we became less efficient at the local level. A lot of people, frustrated by the slowdown, left for other opportunities.

But as far as the larger company was concerned, that was acceptable. Our product was just one of many in their portfolio. Slowing down one team to get everyone aligned was a price they were willing to pay. It wasn't efficient, but it was manageable from their perspective. The math made sense at the organizational level, even if it felt like a loss from where we were standing.

I understand that logic. I just don't think it's the best way forward.

Think about how a computer works. A CPU doesn't concern itself with how a hard drive retrieves data. Whether it's spinning magnetic disks or a solid state drive, the internal mechanics are irrelevant to the CPU. All it knows is that it can make a request, and the response will come back in the expected format. If the CPU had to get involved in the actual process of fetching data, it would waste enormous processing power on something that isn't its concern.

Organizations can work the same way.

Rather than imposing a single process across every team, a company can treat its departments as independent components. You make a request, the department delivers an output. How they produce that output like what tools they use, how they run their meetings, how they structure their work, that shouldn't be a concern, as long as the result meets the requirement.

There are places where unified processes make sense. Legal and compliance, for example, probably need to be consistent across the whole organization. But for how individual teams operate day to day, autonomy is often the better choice. Will every team's process be perfectly aligned with every other team's? No. But they'll actually work. And the people doing the work will be far less likely to walk out the door.

Sometimes in large organizations, it's important to identify which process works, and which team is better left alone.

---