This sponsored article was written by Justin Roff-Marsh, the author of The Machine: A Radical Approach to the Design of the Sales Function. You can get the first 4 chapters of his book in hard copy for free here
When young executives discover enterprise technology, their first instinct is to build a unified, organization-wide workflow.
It seems perfectly sensible. The idea appeals to the innate desire we all have for elegance (and the love we all have for new technology).
But in practice, more often than not, this is a mistake. What you end up with is the over-simplification 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.
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.
The problem with the dream is that it ignores the true nature of complexity.
WATCH: 5 Minutes With ID: Justin Roff-Marsh Wants to Set Salespeople Free
The folly of this line of reasoning was immediately visible within the technology department. The technology team was angry when Jira was scrapped, in favor of Netsuite tasks. Netsuite provided those folks access to information from around the organization (which they didn't need) but took away deep integrations with critical development resources, like code repositories, chat, software lifecycle management, and dashboards.
But it wasn't until a few weeks down the road that the real damage became obvious.
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, in order 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.)
The mistake our friend made 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.
My argument is that you should not be striving for a unified, organization-wide workflow because this is not reflective of the inherent nature of your organization.
Turns out that there is one simple thing you can do, using technology, that will provide you with immediate and significant benefit, without downside risk.
And that's to unify inboxes, within departments. Let me explain with a metaphor.
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 the chef was receiving orders via multiple mediums? If, for example, staff members gave the chef their requests in person and the chef was expected to pull delivery orders directly from an Uber Eats portal?
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.
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.
In other words, figure out how to unify each department's inbox. That's a much better use of your expensive technology. (Oh, and stop shopping for unified enterprise systems: the unified workflow is a chimera!)
Roff-Marsh
