A World Without Email
Service Management domain defined through communication and workflow
I previously attempted to define service management and how it maps to my current practice of designing enterprise IT apps within the ServiceNow ecosystem. While reading Cal Newport A word without email, I got an idea to describe service management using selected quotes from the book. Though Cal’s takes academic approach and some of his recommendations come across as technologically naive, the first part of the book describes the organizational challenges and serve as a value proposition for workflow automation and service management applications. The full credit goes to Cal, and I highly recommend using this article as a motivation to grab the book. Anyone working in Service Management, ITSM, ITIL, and (GSS) Global Shared Services domains would benefit from the general patterns and engaging writing style.
The Hyperactive Hive Mind
A workflow centered around ongoing conversation fueled by unstructured and unscheduled messages delivered through digital communication tools like email and instant messenger services (Slack).
Email reduces productivity
…Data scientists sought to connect communication to productivity by restricting their attention to the time spent in activities that the users self-reported as “productive.” For each user, they split this productive time into five-minute buckets and then isolated the buckets that did not include a check of an email inbox or instant messenger application. These isolated buckets approximate undistracted productive work. The average user had only fifteen such uninterrupted buckets, adding up to no more than an hour and fifteen minutes total of undistracted productive work per day. To be clear, this is not an hour and fifteen minutes in a row, but instead the total amount of undistracted productive work conducted throughout the entire day. The implication is striking: the modern knowledge worker is almost never more than a few minutes away from sending or receiving some sort of electronic communication. To say we check email too often is an understatement; the reality is that we’re using these tools constantly.
On closer examination, however, a distinction emerges between communicating about tasks and actually executing them. In fact, these two activities are often in conflict. One minder role that long ago identified this conflict was IT support. As desktop computers spread through offices in the 1980s and 1990s, they brought with them the need for a new type of employee within these organizations: information technology professionals to fix the computers when they broke. As these systems got more complicated, the demands on IT departments became more insistent — with frustrated users calling and emailing with new urgent problems or to check on previously reported issues. A catch-22 emerged: if the IT staff put off responding to these calls and emails, the employees they supported would be irate, but if they dedicated themselves to being fully responsive, they wouldn’t have the uninterrupted time needed to actually resolve the issues. To solve this problem, these departments began to cobble together custom software tools that became known as ticketing systems. Loosely inspired by the old model of physical help desks, where you would be handed a ticket in exchange for the piece of broken machinery you brought in for repair, these systems automated most of the communication tasks related to submitting, monitoring, and solving IT problems.
Ticketing Systems
If you have a problem, you send an email to an address like helpdesk@company.com. The ticketing software monitors this address, and when it sees your query, it extracts the problem and your contact information, assigns it a unique number, and submits this data as a “ticket” in the system. At the same time, it replies to your email, letting you know the issue has been received and giving you instructions on how to check its status. Inside the ticketing system, the problem is categorized and typically assigned a priority — this might be automatic or require some triage by a staff member who monitors incoming issues. If you’re a member of the IT team using the system, when you log in, you’re shown only the tickets that apply to your specialty, and you can select the most urgent to work on. At this point, you focus on the selected issue until you finish or reach a natural stopping point where further help might be required. Only once done do you return to your queue to select the next ticket to tackle. As progress is made, updates are sent automatically to the person who originally submitted the issue, and other staff members can monitor your progress and chime in with help when you get stuck. Ticketing systems have become big business because they’ve consistently been shown to reduce IT staffing costs, as focused technicians solve problems faster. They also increase satisfaction, as they provide structure and clarity to the process of resolving technical issues.
The premise on which this effectiveness is built is that communicating about tasks often gets in the way of executing them — the more you can off-load this communication from the cognitive space of your staff, the more effective they become at actually getting things done. Which brings us back to our example of the University department admin as an example of another knowledge work. If we can somehow create space between communication and execution, people in these roles would find the tasks before them more easily dispatched.
Email makes us miserable
This effect implies there’s something irrational lurking in this system we use to allocate cognitive resources in the workplace. If slightly increasing friction drastically reduces the requests made on your time and attention, then most of these requests are not vital to your organization’s operation in the first place; they are instead a side effect of the artificially low resistance created by digital communication tools. The idea that eliminating friction can cause problems might sound unusual, as we’re used to thinking about more efficiency producing more effectiveness, but among engineers like me, this concept is commonly understood. Too little friction can lead to feedback loops that spiral out of control, as happens when a microphone gets too close to a speaker and the self-amplification recursively explodes into a deafening screech. Something like the workload equivalent of the microphone screech is happening in modern knowledge work. When the friction involved in asking someone to do something was removed, the number of these requests spiraled out of control. I frantically try to grab other people’s time and attention to make up for the time and attention they’ve already grabbed from me.
In our shift from industrial to knowledge work, we gave up automaton status for burdensome autonomy. It’s in this context that the hyperactive hive mind, once in place, became devilishly difficult to eradicate, as it’s hard to fix a broken workflow when it’s no one’s job to make sure the workflow functions.
The scenario, which eventually became known as the tragedy of the commons, considers a town that maintains common grazing land for cattle and sheep, as was typical in Great Britain in the nineteenth century. Lloyd pointed out an interesting tension: it’s in the individual interest of each herder to graze his animals as much as possible on the commons, and yet when all herders act in their best interest, they’ll inevitably overgraze the commons, rendering it useless to everyone.
The Attention capital principle
The Attention Capital Principle The productivity of the knowledge sector can be significantly increased if we identify workflows that better the human brain’s ability to sustainably add value to information.
In the industrial sector, the primary capital resources were materials and equipment. Some ways of deploying this capital returned far more value than others (think: the assembly line versus the craft method). In the knowledge sector, by contrast, the primary capital resources are the human brains you employ to add value to information — what I call attention capital. But the same dynamics hold: different strategies for deploying this capital will generate different returns. It’s clear that the brain-addling constant network switching required by the hyperactive hive mind is far from optimal, providing, in some sense, the cognitive equivalent of the old craft method for building cars.
Work Execution vs Workflows
Knowledge work is better understood as the combination of two components: work execution and workflow. The first component, work execution, describes the act of actually executing the underlying value-producing activities of knowledge work — the programmer coding, the publicist writing the press release. It’s how you generate value from attention capital. The second component, workflow, is one we defined in the introduction of this book. It describes how these fundamental activities are identified, assigned, coordinated, and reviewed. If work execution is what generates value, then workflows are what structure these efforts. Once we understand that these components describe two different things, we find a way to escape the autonomy trap. When Drucker emphasized autonomy, he was thinking about work execution, as these activities are often too complicated to be decomposed into rote procedures. Workflows, on the other hand, should not be left to individuals to figure out on their own, as the most effective systems are unlikely to arise naturally. They need instead to be explicitly identified as part of an organization’s operating procedures.
Don’t Fear Inconvenience
When other knowledge workers imagine shifting their own organizations away from the hyperactive hive mind and toward something more structured, they easily conjured potential issues. Losing the ability to grab people’s attention for anything at any time might lead to deadlines getting missed, or urgent tasks not getting completed, or long delays before you get the answers you need to make progress on key project steps. Leaving behind the simplicity of the hyperactive hive mind, in other words, might create a steady stream of inconveniences for everyone involved. This objection is important because it’s relevant to most attempts to apply the attention capital principle. As argued, one of the key explanations for the hyperactive hive mind’s persistence in the knowledge sector is that it’s really convenient in the moment for the individuals who use it. There are no systems to learn or rules to remember; you simply grab people electronically as you need them. Almost any alternative to this workflow is going to be less convenient, in the sense that it will require more effort to follow, and lead to short-term problems, like missed tasks or occasional long response delays.
This reality helps explain why so many work reform movements, born out of inbox exhaustion, end up reduced down to only small tweaks — like promoting better “etiquette” surrounding messaging — as these toothless suggestions prevent anyone from having to confront the hardships that follow real changes to the hyperactive hive mind status quo. Imagine you want to make a major change to your own or your organization’s workflow. How can you avoid the inconveniences associated with this experiment? You can’t. You must instead adjust your mindset so that you no longer fear these annoyances. To support this advice, let’s turn back to the industrial sector, where an embrace of inconvenience is commonly accepted.
…Perhaps even more crucial, Carpenter made it easy to instigate further improvements. “If an employee has a good idea for improving a procedure, we will make an instant modification — with no bureaucratic hang-ups,” he explains. He takes this employee involvement so seriously that he now requires his service representatives to submit at least a dozen proposed improvements before they qualify to receive their annual performance bonus. Carpenter’s approach makes sense in the context of what’s known as locus of control theory, a subfield of personality psychology that argues that motivation is closely connected to whether people feel like they have control over their ultimate success in an endeavor. When you have a say in what you’re doing (placing the locus of control toward the internal end of the spectrum), you’re much more motivated than when you feel like your actions are largely controlled by outside forces (placing the locus of control toward the external end). This is what goes wrong if you defy Carpenter’s model and instead attempt to deploy a brand-new workflow on your team by fiat. Regardless of the workflow’s inherent benefits, you might be accidentally shifting your team’s sense of control from the internal to the external, sapping motivation and making it unlikely that they’ll stick with the changes. On the other hand, if your team members are involved in the construction of the new workflow and equally important, feel like they’re able to improve it as deficiencies arise, then the control remains internal, and the workflow is much more likely to be embraced.
IT professionals quickly realized the futility in requiring those they served to interface directly with the ticketing system; for example, by having them log in to a special support site to create and track these tickets. This might be the most efficient way to handle these issues in the abstract, but the concrete reality of many organizations is that most people wouldn’t put up with the extra overhead. The solution to this issue was to create a seamless interface. In most IT setups, you now submit a problem in the most natural possible manner: by sending an email to a general-purpose address like support@companyname.com. Most ticketing systems can be configured to receive these emails directly, then transform them into tickets and place them in a virtual inbox to be processed. As the IT staff works on a ticket, the system can then send automatic updates, as email messages, back to the originator of the issue. The person interacting with IT doesn’t have to know anything about ticketing systems. They simply send an email and receive email updates back in response. Internally, however, something much more structured is unfolding. This lesson applies to the systems you put in place to organize your personal workflows. Don’t require the people you work with to learn about your new systems or change the way they interact with you. Instead, when possible, deploy a seamless interface.
The process principle
The process principle introducing smart production processes to knowledge work can dramatically increase performance and make the work much less draining.
In the pages ahead, I’ll argue that if knowledge workers admit that these processes exist, and then clarify and optimize their operation, then they’ll discover the same result as the Pullman brass works: the expense of the extra overhead will be far outweighed by the boosts in productivity. When the costs and benefits are compared, it’s common to end up with a “substantial profit.” The problem, of course, is that few knowledge workers are used to thinking this way: they focus on people, not processes. As a result, the knowledge sector prefers to leave these processes unspecified, relying instead on the hyperactive hive mind workflow to informally organize their work. For sure, a major explanation for this process aversion is the insistence on knowledge worker autonomy that we explored earlier. Production processes, by definition, require rules about how work is coordinated. Rules reduce autonomy — creating friction with the belief that knowledge workers “must manage themselves,” as Peter Drucker commanded.
This dislike of processes, however, goes beyond a general bias toward autonomy. There’s a belief, implicitly held by many knowledge workers, that the lack of processes in this sector is not just an unavoidable side effect of self-management, but actually a smart way to work. A lack of processes, it’s commonly understood, represents nimbleness and flexibility — a foundation for the type of outside-the-box thinking we’re constantly told is critical. This vision is fundamentally Rousseauian, a reference to the eighteenth-century Enlightenment philosopher Jean-Jacques Rousseau, who believed that human nature, before the introduction of political influence, was fundamentally virtuous. It claims that when left alone to work in whatever way seems natural, knowledge workers will adapt seamlessly to the complex conditions they confront, producing original solutions and game-changing innovations. In this worldview, codified work processes are artificial: they corrupt the Edenic creative, leading to bureaucracy and stagnation — a Dilbert comic brought to life. Having spent years studying the nuances of knowledge worker productivity, I believe this understanding is profoundly flawed.
To stick with the analogy to Enlightenment philosophy, the reality of knowledge work is much more Hobbesian, a reference to Thomas Hobbes’s belief, originally detailed in Leviathan, that without the constraints of the state, human life is “nasty, brutish, and short.” When you reduce work to a state of nature by allowing processes to unfold informally, the resulting behavior is anything but utopian. Much as is observed in actual natural settings, in the informal process workplace, dominance hierarchies emerge. If you’re brash and disagreeable, or are a favorite of the boss, you can, like the strongest lion in the pride, avoid work you don’t like by staring down those who try to pass it off to you, ignoring their messages, or claiming overload.
Also as in natural settings, in workplaces without well-defined processes, energy minimization becomes prioritized. This is fundamental human nature: if there’s no structure surrounding how hard efforts are coordinated, we default to our instinct to not expend any more energy than is necessary. Most of us are guilty of acting on this instinct when given a chance. An email arrives that informally represents a new responsibility for you to manage; because there’s no formal process in place to assign the work or track its progress, you seek instead the easiest way to get the responsibility off your plate — even if just temporarily — so you send a quick reply asking for an ambiguous clarification. Thus unfolds a game of obligation hot potato, as messages bounce around, each temporarily shifting responsibility from one inbox to another, until a deadline or irate boss finally stops the music, leading to a last-minute scramble to churn out a barely acceptable result. This, too, is obviously a terribly inefficient way to get work done.
A good approach to figuring out whether this effort is warranted is to apply the 30x rule. As explained by the management consultant Rory Vaden, in its original form, this rule states: “You should spend 30x the amount of time training someone to do a task than it would take you to do the task yourself one time.”
