What is Reengineering?

My first impression of reengineering was that it seemed like reorganizing the same work under a new set of boxes and lines in the org chart. It seemed like asking every department to do the same work with ten percent fewer people. It seemed like trying some new concepts such as desk-sharing and remote work. Reengineering seemed to be tweaking things to be more efficient.

There are a lot of books and blogs on reengineering by academics and experts. I have my own view, based on years of reengineering and my background in engineering, finance, and strategy. Dispensing with the theory, in practice, I think of reengineering as going back to first principles, and asking some fundamental questions:

1. What are the firm’s goals and objectives?
2. What are its competitive advantages — the things it can genuinely do better than its rivals, not the things it merely believes about itself?
3. Given those goals and those advantages, what outputs and processes does the firm actually require?
4. What would the ideal version of those processes look like, built today, with no obligation to preserve anything that currently exists?
5. How do you transform the current company into that ideal state?

Notice what isn’t on that list. Headcount isn’t step one. The org chart isn’t step one. Cost isn’t even step one, although it is very often the reason the exercise starts in the first place. Step one is always the same question: what is this company actually for, and what is it genuinely good at? Everything downstream — which processes matter, what they should look like, and eventually, which people and roles the redesigned process actually requires — follows from the answer to that question. Skip it, and you’re not reengineering anything. You’re maybe rearranging the furniture in a room that your company might no longer need.

This is the difference between reengineering and restructuring, and it’s worth being precise about it rather than treating the two words as interchangeable, because they are not. Restructuring changes the shape of the organization without necessarily changing what the organization actually does or how it does it. It can be entirely appropriate on its own terms: sometimes a company genuinely just has too many managers for the work in front of them, and fixing that is valuable, focused work. But restructuring alone answers a narrower question than reengineering does. It asks “how do we do the same thing with less.” Reengineering asks “should we still be doing this thing, and if so, is there a fundamentally better way to do it.” Only after answering that does it ask what the resulting organization should look like.

The distinction sounds academic until you’ve watched what happens when a company skips straight to restructuring under cost pressure, without ever doing the first-principles work above. The org chart gets thinner, but the work underneath it hasn’t changed at all, because nobody asked whether the work should change. Within a year, the same volume of the same tasks is being pushed through fewer people, quality erodes, good people leave for saner jobs elsewhere, and the company ends up quietly rebuilding the capacity it just cut, through consultants, through overtime, through a new hire with a different title doing the same job.

None of this means the first-principles version is easy, or that it stays clean once you get past step one. Asking what a company is genuinely good at is a strategy conversation, and strategy conversations are full of people who are certain their own function is indispensable: for reasons that are sometimes true and sometimes simply self-preservation. That problem gets sharper, not softer, once the analysis reaches individual roles and tasks, and we will come back to it directly when we get to the people-level work in this book.

For now, the point to take away is simpler: reengineering starts at the top, with the firm’s goals and its genuine advantages, and works its way down. Everything else in this book is downstream of that starting point, not a substitute for it.