Embedded Files
Did you read the small print on your job description? "In addition, will be required to spend at least 30% of their time replying to email". It's like being stuck in traffic: if you are in it, you are part of the problem. Could a little bit of process design stop tons of emails?
I've recently read "A world without email" by Cal Newport (recommended by a reader of this blog). Here are some ideas that might instantly resonate with you.
Processes do not have to be complicated. But a Google Form can save a thousand emails.
Email cannot replace processes, or: "Here is your inbox! Be useful."
Email cannot replace processes, or: "Here is your inbox! Be useful."
Much of modern misery of the overworked knowledge worker may have started with management writer Peter Drucker, who coined the term "knowledge worker" and endowed them with an anarchic spirit: "The knowledge worker cannot be supervised closely or in detail. He must direct himself."
Drucker should have limited that to the area of expertise of the knowledge worker. Where structure is missing, knowledge workers will create it themselves - and will often reinvent the wheel in an insular and amateurish way. While knowledge workers are hired and paid to do specific tasks, they usually act as all-purpose calculating machines. Modern information technology makes it easy to invent informal processes.
And those informal processes are held together by communication in the form of email and instant messages.
Creating processes that replace email and informal communication
Creating processes that replace email and informal communication
Create phases
Create phases
Define phases that your deliverables may be in. Preferably not too many.
Signal progress
Signal progress
As deliverables move through the pipeline, people should be able to get updates about the deliverables they are interested in. Either automatically or by looking it up themselves.
Channeling resources between phases
Channeling resources between phases
Handoff between phases should occur in a self-contained way. It should be clear what information is expected when something transitions to another phase. No emails, no discussions required.
These tools should not be email or instant messengers - they should be forms for input, spreadsheets for controls or dedicated expert systems. Some professionals have mastered huge levels of interactions without getting drowned in email are developing teams. One example are software developers, who translate requirements into individual features and track their implementation and testing, separate from the conversations that created them. Others are IT support professionals who create tickets, also separate from calls or emails, and route them around as they are getting resolved.
Once you have processes, you can manage them, question them, remove them. But if everybody is just emailing around, that's impossible.
Highly recommended.
When designing processes, rely on specialists. Overload is created by having everybody "chip in"
When designing processes, rely on specialists. Overload is created by having everybody "chip in"
The default operating mode in large organizations is to have everybody participate in tasks that have nothing to do with the core tasks they are being paid for. Many of these tasks would normally done by support organizations, but these often lack appropriate tools, are understaffed or are entirely absent. Under those circumstances, people will start asking everybody to "just chip in" a little bit, by emailing requests and setting up a meeting here and there.
To serve a client means to provide value with as little friction as possible. That can be translated to internal functions as well, which exist to make it easier for client-facing folks to serve clients. A great organizing principle for everyone in the organization is thus:
Does my process reduce as much friction as possible for my customers?
This may include reducing hard-to-understand fields in forms and steps added for edge cases. Maybe someone from my team will have to reach out to the customer and explain something to the customer. That might mean a couple of minutes more work for the provider of the service, but the experience for the customer will be so much better.
Elon Musk recently gave an interview about his development philosophy, which can be summarized as simplify before scale. "All requirements must have an owner - a person, not a department, who is responsible for defending need to keep it" he said, and added "If you are not occasionally adding things back in, you are not deleting enough. The bias tends to be adding things to processes 'in case we need it'".
Reducing email overload will not happen overnight - there are very few quick fixes. Most of them are related to personal productivity and how you let email handle you. Using the world's most popular email client also helps. But beyond that, "winning" at email requires all of us to rethink it. Emailing is easy and convenient, but email is a terrible infrastructure to build processes on. Thinking about processes is a great way to start rationalizing about what your team is actually doing (and should be doing!), and naturally drives workflows away from email and instant messengers, leaving the lines open for truly human communication.
"A world without email" by Cal Newport is a great book about much more than email. You will be working with other people more and more - this book will provoke thoughts about how to get more actual work done. Thanks for reading!
Join 1600+ people who read these tips twice a week. Subscribe now!
Page updated
Report abuse