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)
19 thoughts on “No Email, No Problem: A Workflow Engineering Case Study”
Did they stick with that approach after the new employee got access to email? Or did they switch to email, Slack, Trello, Jira, or some combo?
There’s a really great scene in the show Silicon Valley where they use the scrum method not only for productivity, but for competition among workers.
A good scrum master will transform a team
This is great and I highly recommend this approach (I use this myself). Trello is a useful tool to use and you can easily setup a ‘trello board’ with the following columns: Future, Backlog, Priorities for the week, This week, Today, Doing now, Done, Postpone (this is actually my workflow).
It works so well (for when I stick to it, which is about 65% of the time…) !
Hey everyone, I just wanted to chime in with something that’s often been on my mind lately while reading Study Hacks. I’ve been reading this blog for many years now, and I’ve been impressed with the quality of the posts and have certainly learned a lot.
My one qualm lately is that so many of the recent posts (including this one) seem repetitive and are variations of “why too much email is bad, and when we stop using email it is not bad.” I agree that this is an important topic to discuss, but I was wondering if anyone else was feeling the repetitiveness that I’ve been getting after reading this. Is there any chance we might get some additional variety?
I think this is an exception and may not work for everybody. Email is fine, if we are smart enough about how to use it. Like everything else. Ironically, this comment section requires an email address…
Another workflow process you may be interested in researching is Kanban.
I am a software developer and I’ve worked with both Scrum and Kanban.
My team used to follow Scrum but for the past couple of years have been using Kanban. Kanban is very similar to Scrum but doesn’t have the sprint planning and review. Instead, each task/card is worked on independently (Scrum works on a group of tasks/cards). In Kanban, you work on a task/card, and when you’re done, you pick another card from the list. Scrum is timeboxed (has a fixed time period); you decide how many cards to work on in a sprint; at the end of the sprint you decide whether the number of cards is too high or too low. Too many cards and you have a sense of urgency and stress and possibility of team burning out; too few, and you have everybody sitting around waiting for the next sprint. Kanban doesn’t have a time box. You work on the highest priority task until it’s done, and then you work on the next highest priority task. There’s no sprint, like Scrum, so there’s no gap waiting for the next sprint, and the priorities of the next task can always be changed (which frequently happens when working with clients/stakeholders).
Both Scrum and Kanban are very helpful in communicating to the entire team (including clients) what is currently being worked on and the priority of future work. It’s up to the team to decide whether to adopt Scrum or Kanban for their work.
P/S : Just to confuse things, there is also a Scrumban, which combines elements of Scrum and Kanban. My team looked at it briefly, but went straight to Kanban.
Thanks for sharing this information.
What about some relaxing music in the background to boost the concentration?
Thanks for the books You recommended Cal, I devoured them too!
Hey Cal, have you checked out “PEAK:Secrets from the new science of expertise” by Anders Ericsson and Robert Pool ? It’s right up your alley!
I am reading your book “So Good They Can’ Ignore You” and then came across this article: https://www.nytimes.com/2016/07/24/upshot/first-rule-of-the-job-hunt-find-something-you-love-to-do.html?_r=0
The theory is to become an expert, you first have to enjoy the work you do and then you will be so mesmerized by the task that you will naturally (and not painfully) become an expert at what you do. Since you do not have social media, this is the only place I could find to engage in this conversation online.
In his book, Call argues that people eventually fall in love with what they’ve been trying to master. The more you master it, the more you love it. I found (parts of) it to be true. Since the beginning of this year, I’ve been working on a field that I barely understood. The learning curve was steep and many times it drived me crazy and led to frustration. But, as I began to master the foundation of the field, I began enjoying it regardless the fact that I had no idea that I would love it in the beginning and the mess it caused on the path of mastery.
However, I mentioned it’s only partially true since I still enjoy my previous field much more than the current one. (Though I might be biased as I’ve spent so many years on the previous field compared to less than a year on the current.)
It’s still an unfolding journey for me to prove these two notions (Love-Then-Master and Master-Then-Love). Let’s see in a couple of years.
Hi Cal, not specifically related to this article, but certainly related to all the great work you do here. I came across an article about what the author calls the “Five Hour Rule” that I thought you’d find interesting if you hadn’t already seen it. https://observer.com/2016/08/bill-gates-warren-buffett-and-oprah-winfrey-all-use-the-5-hour-rule/
Love the blog! It’s taught me so much. Thanks!
However good the scrum master, the success of the program lies in the hire executing the plan.
Email is nice, just that its effect depends on how on the usage. Almost everything you wanna do online now required email. Even dropping a comment on this blog post, email is also needed.
Thanks for sharing.
“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.” Love this part, nice post