This article was first published (in a simplified form) on Thomasnet.com. You can read the original here.
When young executives discover enterprise technology, their first instinct is to build a unified, organization-wide workflow. (Actually, this tendency also extends to the not-so-young!)
It seems perfectly sensible. The idea appeals to the innate desire we all have for elegance (and the love we have for new technology).
But in practice, more often than not, this is a mistake. What you end up with is the oversimplification of work, the destruction of information, and the generation of conflict between departments.
If your business is any more complex than a lemonade stand, it’s likely that you do not need (and should not have) a unified, organization-wide workflow. But what you should have are unified inboxes within each department.
And it turns out that our local restaurant—a business not much more complex than a lemonade stand—contains a perfect example.
Two important definitions
For clarity, let me start by defining a couple of terms.
By inbox, I mean the portal via which work finds its way to a person or a department. I’m not referring specifically to the email inbox, although your email inbox may actually (for bettor or worse) fit this definition.
By unified workflow, I mean the idea that you can deconstruct your organization into a single network of work packets (tasks) that are routed dynamically from person to person.
The lure of the unified workflow
Years ago we worked with an organization that was transitioning to Netsuite. Netsuite promotes themselves (as ERP providers like to) as a unified operating system for the organization.
The chief executive of this organization was in the process of making Netsuite tasks the default organizational work packet. His idea was that all knowledge work, organization-wide, would be done within Netsuite and, if a unit of any work could not be done within a core Netsuite module, it should be represented as a Netsuite task.
The dream, obviously, was to capture the complexity of the organization entirely within the ERP where it could be tamed, managed, and scaled. This is an alluring idea. What it allows you to do is to simplify your organization into two components. There’s a set of resources that transforms stuff. And then there’s a routing system that shuttles work from resource to resource. It makes perfect sense that this routing system should be centralized and that it should live in a piece of software.
The problem with the dream is that it ignores the true nature of reality.
The problem with oversimplification
The folly of this line of reasoning first became visible within our friend’s technology department.
The technology team had traditionally used Jira to manage their work. Jira is the software that most engineering teams use to manage the software development process. As well as coordinating the development process (from user stories to lines of code), Jira has deep integrations with critical resources, like code repositories, chat, software lifecycle management, and dashboards.
Management recognized (correctly) that Jira was fundamentally a task-management system and replaced it with the Task module that comes standard with Netsuite. After all, why have two task-management systems when you can have one?
It took less than a week for the damage to become obvious.
Babushka dolls
It used to be that there were two conversations. There was the technology conversation that occurred outside the technology department and there was the technology conversation that occurred within the technology department. Now, because of the unification of tasks, these conversations had been collapsed into one. The result was the sudden emergence of conflict between technical folks and the rest of the organization, and a dramatic reduction in output.
The problem here is that these conversations are materially different from one another. And they MUST be, for the technology team to generate value for the organization. And this is true in all specialized domains. (Think of the conversations doctors have with one another versus the ones they have with patients; or air-traffic controllers, with one another, versus pilots.)
Another problem is that there is often not a one-to-one relationship between work packets as they are defined within, and outside of, specialized domains. What appears to be one task will often explode into multiple tasks (with different owners) or, conversely, what appear to be multiple tasks might coalesce into one.
Our friend’s mistake is that he had visualized his organization as one large conversation. But this is a bad model of his organization: a bad model of pretty much any organization.
It would be more correct to think of an organization as a collection of discrete conversations with very limited (but very important) connections between them.
Or, better still, rather than visualizing an organization as a two-dimensional workflow map (like the map of a subway system), it makes more sense to think of it as a three-dimensional set of those maps, with maps on the third dimension nested under the first two, like Russian dolls.
You should not be striving for a unified, organization-wide workflow because this is not reflective of the inherent nature of your organization.
The magic of loose coupling
It turns out that there’s a better use of technology if you want to dramatically improve information flows within your organization.
Rather than trying to unify workflows, globally; unify inboxes for each department. That is to say, ensure that each department has a single portal via which work is received. The benefit of that single portal is that it decouples the local (departmental) workflow from the global (organizational) one.
It allows the local conversation to be independent of—but loosely coupled to—the global one.
Now, these inboxes do not have to be of the same type (in most cases, they should not be). The type of inbox should be driven by the ease of unification, not by the careless pursuit of standardization.
Some general rules. If inbound tasks can be corralled into a single inbox, then they should be (think of a ticketing system for a technical helpdesk). If some inbound tasks must be received via an email inbox, then route all tasks to a central email inbox (think of a customer service team). If work cannot be processed according to a simple algorithm (e.g. first-in-first-out), then route all work to a human scheduler (think of a job-shop production environment)
The unified inbox, done right
Consider your favorite restaurant. Within this establishment, there are two critical conversations. The front-of-house conversation, involving guests and waiters. And the conversation that occurs in the kitchen. As you know from watching Gordon Ramsey, these are two quite different conversations. (No good would come of any attempt to unify them!)
What’s interesting here, is not the conversations, it’s the integration point. The integration point is the chef’s ticketing system. A rail containing tickets representing guests’ orders.
This ticketing system is a perfect example of a unified inbox. All work that enters the kitchen enters by way of that ticketing system. If a staff member wants a meal, they create a ticket and add it to the rail. If a delivery order comes in from Uber Eats, someone converts it into a ticket and adds it to the rail.
Imagine if the kitchen didn’t operate that way. Imagine if requests emerged from multiple sources and were routed directly to different kitchen staff members? Obviously, if we owned that restaurant, we wouldn’t allow that to happen. That would be idiotic!
But, and I think you know where I’m going here, if you take a look around most organizations you’ll see that this is exactly what is happening, all day, every day; often with the explicit sanction of management.
What’s really concerning though, is that the negative effects of this poor organization design tend to be misdiagnosed as communication problems, and the default cure for these problems is—you guessed it—a unified, organization-wide workflow!
My advice to you is don’t focus on the conversations. Focus on the integration points between the conversations. An attempt to unify conversations by unifying workflows is a fool’s errand. But there’s massive potential to improve flow by focusing on the integration points and unifying inboxes.
By the way, once you’ve unified inboxes (within each department), you’ll come to recognize that the content of each inbox is probably your organization’s most valuable source of real-time information. But that’s a conversation for another day.
Photo by Ronan Kruithof on Unsplash
