Throughout my career, I’ve sat on both sides of the enterprise tools table, as both a user and a provider. Despite the constant evolution and plethora of new tools coming into the market, I’m getting a sense that two fundamental problems that get in the way of unlocking real value (for both sides) are still getting very little attention.
The tool is only as good as the process it enables
In the past, enterprise tools providers hard-coded the way in which the tool should be used into the tool. They were extremely perscriptive about what is considered best practice, and to some extent forced their customers to follow it. Customer revolted.
Today, most enterprise tools are designed to be extremely free-form: you can model whichever process you’re currently using in the tool and there are 1,000 different ways to use it. There’s also no judgement: each one of those ways is valid.
Consider Asana as a good example: with a super-simple object model (just a “project” and a “task”), everything goes: a project can be a project, a team, a meeting, an event. No right or wrong answer.
Or consider Slack , where everything can be a channel. Granted, they nailed a couple of big innovations compared to other enterprise communication tools – namely designing with the user’s delight in mind, and building a platform rather than a tool, which puts them (through the players building on top of the platform) in a better position to address other core problems. But as Brad Feld also points out the core problems that existed with Google Groups, like discoverability (finding which groups/channels to join/use) and staleness (defunct groups/channels adding noise) still exist with Slack. If you’re a 100+ person company and have more Slack channels than employees, have you really made any progress towards better enterprise communication?
I’m not picking on Asana and Slack, the same is true for almost any other enterprise tool: JIRA, Salesforce, WorkDay, you name it.
I believe the pendulum may have swung a little too far to the other end of the prescriptive<->free-form spectrum. As the examples above illustrate, the free-form end of the spectrum is just as bad as the prescriptive end. There are multiple shades of grey that get us closer to the optimal outcome, in which the responsibility around “effective usage” needs to be shared between the provider and the customer.
Providers, on their end, can provide guidelines and best practices for the customers who seek them. They can play a more active role in disseminating lessons learned on tool usage throughout their customer community. And they can use smart (yet overridable) defaults inside the tool, to nudge customers towards a more thoughtful use. To use Slack as an example, when you try to send out a notification-triggering communication to an entire channel (@channel), Slacks confirms that you really want to send a communication that will trigger a notification for X people across Y time zones before letting you proceed. Can a similar approach be used when you name a channel? or when a channel hasn’t been active for 60 days?
Customers, on their end, need to acknowledge that some of the responsibility for getting value out of the tool rests on their shoulders as well. They’re likely going to get very little value out of the tool without being thoughtful about the way in which the tool will be used and proactively managing and curating this usage on an on-going basis. If that’s everybody’s job – it’s nobody’s job. As I’ve advocated for here, organizational systems (and the tools that reflect them) need an explicit and well defined “system architect” role who can be held accountable to the value the tool unlocks.
No clarity on where the tool begins and ends
Enterprise problems don’t exist in a vacuum. As Russel Ackoff pointed out, in complex systems problems tend to be intertwined in a “mess” where each problem has some derivative impact on the other problems.
Enterprise tools don’t exist in a vacuum. New tools get introduced into a preexisting set of solutions aimed at solving related and partly-overlapping problems. There are far too many examples of tools that fail to take that into account, offering their own solution/functionality to problems that have very little surface area with the core problem that they are solving, and are already well addressed by a more generic tool.
There is one problem area where this message seems to have fully sunk in already, at least in most cases: authentication. Very few new enterprise tools aim to reinvent the wheel there and add yet-another-set-of-credentials, rather than assume a pre-existing credentials system (Google Apps, Facebook) or at the bare minimum supper SAML integration. But that’s not the case for many other basic functionalities such as calendaring, file storage and messaging/notifications.
To give one example, consider Namely , which created its own custom shared “steam”/“wall” functionality for automatically posting work anniversaries, birthdays and sharing out HR announcements. But does it really make sense to have a dedicated view just for that content? Or would it be much more effectively consumed if it was part of the core enterprise communication system, be it a daily email digest, or a channel in Slack?
Again, responsibility lies with both sides.
Providers, on their end, could be more thoughtful in deciding where their tool starts and ends, focusing on the core capability that they are bringing to the table and “playing nicely” with other tools for anything else. Des Traynor of Intercom has a fantastic 10 minute talk on this matter.
Customers, on their end, would benefit from having a clearer picture of their own enterprise tools portfolio, identifying areas of overlap and areas of gaps, and using this analysis to proactively push providers to de-dup overlap and fill in gaps.