It seems to me that there are two dominant problems in most digital workplaces at the moment: Search and Notifications. If we don’t get this right, the employee experience will always suffer.
There are many elements to a digital workplace such as communication, collaboration, finding and sharing, business applications, employee services and support for agile working. Although there are challenges specific to each element, the thing that almost no organisation is tackling well is the integration between them – the glue that makes it a productive digital workplace rather than a collection of individual systems.
In IT when we’ve talked about integration in the past, there’s been a cyclical temptation to conclude that the only way to really do it is by bringing everything into a single platform. It’s the kind of naively over-ambitious thing only an idiot would try (I’ve tried several times). The alternative is many APIs to interface between disparate systems, and that can turn out to be both slow and costly.
For sure, there are some platforms that offer a multitude of tools, but the reality is that there is no clear cut-off point for when a platform should end. This means there will always be something else that isn’t integrated, causing friction. Even Office 365, for all its breadth, doesn’t cover all bases – it’s very weak on employee self-service for example. It doesn’t even integrate all that well with itself (e.g. Yammer, Teams and SharePoint).
The only practical way to integrate is a much loser coupling – and that’s where search and notifications come in as a very flexible form of glue.
Not searching but finding
Search has enormous potential in the enterprise because it can span multiple systems well – if we let it. We often use the term ‘search’ because it is widely recognised, but really what we mean is finding things within the enterprise.
Unfortunately, we often play a trick on users by putting a search box on an intranet labelled “Search everything” when it isn’t really everything. Usually it is just all content stored on that CMS. Customer records in a CRM or contracts in a legal system are unlikely to be indexed, for example.
Finding goes much more broadly than a Google-type search box that returns a page of results. It may also involve browsing a page of benefits to see things the user had not thought about; looking only within a policy library; collating every contract relating to a specific client; or trying to find the system to claim expenses rather than just documents about expenses.
A coherent digital workplace needs to support all of these kinds of finding across multiple systems. If this isn’t supported then some of the use cases above become very hard to accomplish, such as collation around a topic or even feeling confident that a better answer hasn’t been missed. Even finding things by navigating and browsing is hard if you want to be sure you’ve seen all options but feel they may be scattered across an HR system, intranet page and employee handbook document for example.
Not finding but doing
In nearly all the cases above, the finding behaviour is just an interim step to taking action. This is why digital workplace search needs to provide answers not links.
Before Google a search of “London to Edinburgh” on Yahoo or Altavista would have yielded many pages of links to timetables, blogs and news articles. Now Google gives answers as a map with directions, actual train times and airline prices. Mere links are well down the page.
The recently-released Microsoft Search is going in the right direction for Office 365. Administrators can add ‘bookmarks’ for canned answers to common queries (Microsoft again opting to name a feature in a way that maximises confusion). These can even be targeted, so that users in Spain and Japan see different answers to HR queries. The search engine will also use text analysis to try to determine responses from uploaded documents such as policies. However, the text is static unless you add a PowerApp.
The other element to supporting actions and not just links is to embed microservices in search results, so that what people see isn’t a link a system but an actual interface to it. I wrote recently about how Wells Fargo is using microservices in this way.
Notifications and the battle for attention
The other glue element for digital workplaces needs to be how we manage attention. We are surrounded by notifications. Jason Fried of 37signals put it perfectly when he said “The modern workplace has become an interruption factory”.
Our phones do a pretty good job of letting us manage notifications by aggregating across a range of sources, from email, SMS, voice calls, twitter, Facebook, LinkedIn, WhatsApp, airline apps and so on. This makes it easy to go into a ‘do not disturb’ mode, or even a ‘do not disturb unless really important’ mode by letting certain people or sources get through. We don’t have the equivalent for our digital workplaces.
In many digital workplaces, we have to deal with a dozen or more systems: email, Slack, Workday, SAP, Concur, Salesforce, Servicenow, Basecamp… and if you use Office 365: individual alerts from Microsoft Teams, Yammer, OneDrive, SharePoint, Planner etc.
Every system generates its own alerts, often in multiple ways: a desktop pop-up, a phone alert, and then an email follow-up alerting us to the fact that we missed the other two alerts. In the absence of a common aggregator, falling back on our swollen inboxes as the only way to keep track.
We need a more unified activity stream. Not only would this let us dial up or dial down the interruptions, but it would help us get on with our work coherently.
For every alert we need to know:
- Has something changed that now lets me progress an action I’ve been waiting on?
- Do I need to stop what I’m doing and act so I don’t hold something up?
- Is this new information that will change a decision I’m about to make?
- Did somebody bring in cakes? (just kidding, but you know…)
However, we can only decide what to attend to if we can see a joined-up view, not a system specific one. In other words, if it’s all glued together again.
This article was originally published over at CMSWire.