No Email, No Problem: A Workflow Engineering Case Study

An Insightful Tale 

I recently ate lunch with an executive who manages several teams at a large biomedical organization. He told me an interesting story.

Not long ago, he hired someone new to help tackle an important project. A logistical problem, however, delayed some paperwork processing for the new employee.

The result was that he spent his first week with no company email address.

In isolation, this is just a story of minor HR bungling. But what caught my attention was what happened as a result of this accidental experiment in email freedom: nothing bad.

The Workflow Engineer

The fact that the new employee had no email address had no discernible impact on his productivity. In his first week, he jumped right in and became a valuable contributor — even though he couldn’t be reached by digital means.

The secret to this surprising outcome is the mindset of the executive who made the hire. It turns out that this executive is a supporter of workflow engineering (though he wouldn’t use that term).

He rejects the conventional wisdom that the best way to manage knowledge workers is to give everyone an email address or slack id and then just rock and roll — figuring things out as they arise in an unstructured, incessant flow of messages.

He instead asks, “what’s the best way for you to get your job done?”, and is willing to experiment relentlessly to validate his intuitions.

Scrum over Email

This brings us back to the new hire without an email address. The executive managed him using a variation of the scrum project management methodology (for more on scrum, read this book or this book or this book — all three of which I devoured after hearing this story over lunch).

In more detail, the executive had the new hire externalize his obligations onto a physical board split into columns for tasks in waiting, tasks underway, and tasks completed.

Each morning, the executive holds a quick in-person meeting with the hire. They look at the board and discuss what the hire will be working on that day and what he needs to succeed. A plan is agreed upon and the hire then turns his attention to execution.

Many knowledge workers implicitly implement similar workflows using email. The tasks on their plate exist only as pointers in obtuse messages lurking in an overflowed inbox, and coordination and planning takes place throughout the day in a lazy exchange of dashed off notes and questions. This approach works well enough, but it’s exhausting, and it fragments attention, and, in general, is riddled with inefficiency.

The executive and the new hire made those implicit workflows explicit. And once they did, it was clear that in this instance email was not an optimal implementation of what needed to get done.

The Power of Workflow Engineering

My goal in this post is not to promote this particular scrum-style approach to knowledge work. It might be a good fit for some jobs but not for others. What I do want to promote is the workflow engineering mindset that generated it.

The executive in this story wasn’t content to simply accept the sugar-coated convenience of email-based management. He instead made the effort necessary to investigate the best way to complete a given knowledge work objective, and the result was a worker who, by all accounts, is exceptionally productive, and probably much less stressed than his inbox-slaved counterparts.

(Photo by barcoo)