Reengineering Work: Don’t Automate, Obliterate

Reengineering Work: Don’t Automate, Obliterate is the title of an HBR article introducing what became a highly influential movement called Business Process Reengineering. By the time its author, Michael Hammer, followed up with a full-fledged book, Business Process Reengineering had–to put it in today’s terms–gone viral. Its authors became household names, and, I assume, quite wealthy. The book was one of the most popular business books of the 1990s, with a new edition being released in 2003 (that latter edition proudly sports a quote by Peter Drucker–what more proof do you need?) In the introduction to that new edition, the author’s claim that “it can be argued that much of the great leap in productivity in the 1990s should be attributed to the impact of reengineering”. Personally, I’d put in a vote for personal pump espresso makers, but what do I know.

During the time that reengineering was taking the world by storm, I was leading a small team developing a business process modeling tool, so I got to watch the debate between the reengineering camp and the quality camp, the latter focused on long-term change through incremental improvement. At the time, best practice was to create two models–one of the current process (aka the “AS-IS” model), and another of the desired process (aka the “TO-BE” model). The rationale was that you needed to understand both in order to plan out and execute the transition from the AS-IS to the TO-BE, although I often wondered whether this was just a clever ploy to keep business modelers on staff. OK, I am criminally impatient, and I’ve thankfully worked at startups and small companies for much of my career, so I can’t claim to have any real insight into the functioning of really big companies, but the whole thing always seemed just too damn complicated and slow!

Right now, I’m focusing my efforts on recruiting for my new software development team at SiriusXM. At the same time, and equally important, I’m developing the recruiting process so folks can learn and build on something in the future. I don’t have an AS-IS model;I obliterated the incumbent process right to oblivion, like Stalin photo-editing disgraced comrades out of history). But I do have a TO-BE model (using MS Word shapes embedded in the process description document), and it keeps changing every time we interact with a candidate. As a small example, I’ve been modifying my set of behavioral questions, and the engineering lead has also been modifying his technical questions each time either of us interacts with a candidate. Sure. These are minor changes–the boxes in my diagram don’t change, they’re just little tweaks to a single activity in the process. It also looks like the question sets are starting to stabilize, which is a good thing.

But we’re also looking at automated skills evaluation as a new–early–step in the process. Introducing that adds a new activity and will certainly have a ripple effect along the whole process chain–are these changes small or large? I don’t know. Perhaps we’ll have to try it out on a few candidates and see what happens, then adjust. Napolean said: “I engage and then I see”, which sounds right, but if you prefer von Moltke (the Elder), we can go with: “no plan survives first contact with the enemy” and substitute candidate for enemy. Likewise, we’re still not sure–a few days before bringing our first candidate in for face-to-face interviewing–exactly what format we’re going to use, and I think we’re going to have multiple revisions right up till the time they walk in and then a bunch of changes afterwards. We want to do something interactive, and we’ve got a bunch of ideas that we want to think through.

…and I really have no idea where this will all lead. I don’t want to inhibit the process of defining this process by dictating what I think the end result should look like–because I don’t know the answer. I don’t have to know the answer. At least not now, and not for this task. Yes, sometimes a leader has to put a stake in the ground because there is no other option; I often refer to these as arbitrary executive decisions (AED) and liken them to automated external defibrillators (also AED, not coincidentally)–in both cases things have seized up and somebody has to get something going–right now–but high voltage isn’t something you want to be jamming through somebody’s torso (or your team) every day!

So today’s thought is: go with it. Try a little less (but more thoughtful) planning. Ask your team for input (gasp!). It’s their process too! A leader does not have to control everything–think of steering a luge sled, or sliding a curling stone. (for future readers: the Sochi Olympics are happening) Think subtle, flexible, yielding, opportunistic.

If you’re in the software business, get David Anderson’s book on Kanban, because it puts a method of incremental process improvement in terms that you will grasp. Then apply it everywhere you can, and watch it all unfold. You’re a leader, not a pile driver. Chill.

This is what happens when we get a blizzard and I’m stuck inside.


About jeffmershon

Director of Program Management at SiriusXM.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s