I think there is a terrible irony in Microsoft kicking off this week’s Ignite event – one dedicated in large part to the concept that Microsoft’s vision of collaboration will be a core component of the transition to a hybrid workforce – with a bunch of analysts unable to join in the Day 0 analyst day running on the Teams platform. The reason was simple: The process for opening the link we were provided was profoundly counter-intuitive. I had to repeatedly monkey around with the Teams UX in order to finally succeed, and I’m hardly a novice user. I don’t think any of my fellow analysts who weren’t lucky enough to make in would be considered Teams novices either.
Microsoft is betting a ton of money and brand equity promoting Teams as the nexus of its effort to become the go-to vendor for the flow of work, an ethereal remake of the term workflow that sounds fine with me. It’s not like workflow has really lit the world on fire either. This flow concept is of course deeply rooted in the collaboration that we all agree is necessary for the emerging hybrid workforce etc. etc. I would be so much more excited for Teams’ prospects in this regard if it weren’t for the fact that counter-intuitive and collaboration should never go hand in hand.
And yet that’s what Teams is: A counter-intuitive collaboration tool. Most companies struggle with automating collaboration within teams that are already organized around a particular project or task, and just having a tool that can schedule a meeting and invite everyone to join is already a good start. If the tool also supports a central document repository to be accessible to the team, all the better.
(A quick survey: how many features beyond schedule a meeting, attend a meeting, share a file, and chat do you use in Teams? That’s about it? You’re in the majority, congratulations. The vast majority, to be specific.)
But once you move beyond the basics of collaboration, there is little consensus on how teams should use Teams to work together and what the mechanics of those processes should look like. Teams-the-product wants to impose a version of collaboration that has two main attributes:
- Teams’ version of collaboration is counter-intuitive – not just because it’s hard to intuit a process that is poorly understood or performed but because it’s hard to second guess how Microsoft wants a user to intuit how that process should be performed in part because…
- In addition to a lack of workflow and process, Teams is constantly changing, updating, adding new stuff, and is otherwise a moving target that just like a run-on sentence becomes really hard to follow even though all the words are familiar and you think you understand the context but by the time you get to the period at the end of the sentence –if there is one and there won’t be –you’re not entirely sure what’s actually going on and so you soldier on hoping something makes sense enough to be useful or understandable
The convergence of the two is the real problem. We don’t collaborate well, and Teams makes it hard to get better when the product itself keeps changing so much. And it has no innate concept of process – a point I’ll get to at the end of this post.
(There was a double irony during the analyst event when Scott Guthrie, executive vice president of Cloud and AI, was asked what he thought was the biggest problem facing enterprise apps users. Scott replied by talking about the problem of upskilling employees. Said the EVP of a product that provides exactly the kind of moving target that makes it hard to keep employees’ skills up to date.)
The result is a pile-up of user experience problems: Teams never seems to fail at failing to provide a consistent, reliable experience. There’s even a joke to that effect:
There are two type of Teams calls: those that are glitching and those that are about to glitch.
For the record I’ve been an extensive user of Teams since it first became available in 2018. And I was an enthusiastic user at that. When it kicked off there was a simple elegance to its limited functionality – it did what I wanted in ways that were… intuitive. And then an incessant need to lard up the app with more features – while skimping on feature stability and any hope of appearing truly intuitive – overtook the product. Teams is without a doubt the app I use the most that garners the most complaints when I use it.
(Ok, there’s another app that I dislike even more, but as it’s not an app that pretends to be collaborative, it only annoys me when it glitches. Teams glitches in the context of a team of people, or an entire event full of people, so its complaint index is significantly higher.)
Among the many problems I have with Teams is that I have two separate Office 365 accounts and am also a member of a Teams team run by a vendor client. Without going into gory details, Teams has walled these environments off to such an extent that there is no intuitive way for me to move between these different identities, something I need to do because – that’s the way I want to work. But it’s not how Teams thinks I should work. So I actually can’t do the kind of sharing and cross-pollination I want to do, though there are some unhandy kludges and workarounds that I can sort of use, though they are, of course…counterintuitive.
Basic example: each O365 account has its own calendar – which Outlook displays in one calendar view. Teams won’t let me see both calendars simultaneously, so I can’t see in Teams if I’m scheduling a meeting in one account that might conflict with another. There’s a lot more where this came from, believe me.
Which also means that Teams’ ambitions to be the hub of all things collaborative in the enterprise, as evinced by Microsoft’s execs in the analyst briefing, is going to run smack dab into the biggest, hairiest, most intractable foe any piece of enterprise software could possibly have: change management. Collaboration should not require a massive paradigm shift in user experience, and unfortunately there is no way to look at Teams’ aspirations as a hub for all things enterprise and not see that its model of collaboration – or non-model, really – is going to require a degree of change management that itself will be a barrier to collaboration.
But that’s not all.
It’s clear from the Ignite event I just attended that Microsoft is prioritizing the collaborative experiences users can have within the Microsoft enterprise applications portfolio– primarily Dynamics and Office – and is leaving behind for now trying to be part of a flow of work that includes extensive use of non-Microsoft apps. This is fine, and understandable – and wrong-headed.
Of course there are 100s of apps on the AppSource site that pop up when searching Teams for Salesforce.com, or Teams for SAP, or Teams for Workday, so the interoperability issue is sorted, right? Not really. Salesforce for Teams is a free, very thin veneer of functionality. Workday’s own Teams app – available on AppSource – simply doesn’t work, according to three out of four reviewers. SAP seems to have several apps in AppSource that work with Teams, but none (and I scrolled through a few of them) are really going to seamlessly integrate SAP and Teams in the flow of work the way work across silos should flow. One could start stringing together a collection of these apps and eventually end up with a real end-to-end process flow, except it would have more seams than a circus tent. And probably – make that definitely – not be worth the time or effort.
The wrong-headedness of the aspiration to be the go-to-flow vendor for the enterprise while providing a rather sparse palate for flowing non-Microsoft apps is this: Supporting heterogeneous end-to-end processes is a very big problem in search of a solution in the enterprise. For the most part end-to-end processes tend-to-end at the edge of the silo they were created in – and it’s genuinely hard for an ERP, or CRM, or HCM, or other silo vendor to make a strong case for supporting end-to-end processes from inside the silo. Obviously, vendors that sell multiple silos have tools that do this integration – but they frankly don’t really hit the mark for reasons that I won’t go into. Read my Death to All Silos post for details.
A neutral third party app like Teams would be extremely well-suited for the task, but in theory only. In reality, in its current state, Teams is ill-prepared for this mission. And is thereby walking away from a huge opportunity that could substantially increase the market for Teams and fix the user experience problems I ranted about above.
How? If the Teams team that’s developing Teams would step outside the building and engage with the heterogeneous enterprise – and really listen – they would quickly learn that the current Teams paradigm for collaboration, aka my way or the highway, is the wrong way to go about things. What enterprise end-to-end processes need is a very flexible, adaptable platform that allows users to collaborate the way they want to, not the way a vendor thinks they want to. Kind of basic, actually.
And if that third party product comes from a vendor that already caters to pretty much every line of business in the enterprise, all the better. The LOBs tend to own and control the silos, and they need to be on board in order to break down the silos without breaking the LOB in the process. Microsoft is unique among software vendors in having a role to play in pretty much every LOB in the enterprise, and as long as the Microsoft brand (or the glitchy Teams brand) doesn’t get in the way, Teams could at least get its foot in the door.
This could be a serious play for Teams. Silo-busting end-to-end processes don’t exist for the most part. By being there on the ground floor Teams could help define what these processes actually look like by working with the users who need to use them. It would require a better sense of workflow than exists in Teams today, and of course lots of connectivity – real connectivity – to those third-party enterprise apps that need to be part of these end-to-end processes.
Any vendor that aspires to solve this problem would need to pay attention to four big problems:
- Collaboration is a poorly defined process that needs careful and clear definition, not as a diktat but as a concept. And not with a product demo, but with a thoughtful walk-through of what it is today and how it can be incrementally improved. Big bang collaboration will fail because it’s just too radical for most enterprises to adopt without a bloodbath. One step at a time.
- Understand that your customers already have everything they need to collaborate, it’s just that none of these tools and processes collaborate with each other. So be sensitive to the fact that you need to be open to working with the tools they already use. Are you planning on replacing every single one with your own way of doing collaboration? Here’s a short list of what you’re planning on prying from the cold, dead hands of your customers’ users. Good luck:
- Basic productivity: email, calendar, video, text, and messaging
- Meeting platform
- Task and process management
- Content and knowledge-management
- CRM. Most collaboration will be about buying and/or selling something, so at a minimum a little CRM will be needed.
- Telephony
- Remember, there’s more, this is just the short list.
- Be open – very open – to supporting robust integration with any and all LOB apps. All collaboration eventually makes it into an operational framework– once collaboration has produced an agreement to actually do something – that often involves executing transactions in your ERP, CRM, HR, SCM, etc. etc. An aspiring collaboration vendor shouldn’t be leaving this to lightweight partner apps – they can at best provide a thin veneer of collaboration that will be more frustrating than complete.
- Don’t forget about process debt and process management: Collaboration is the graveyard of dead processes, which is to say there’s a lot of poorly designed collaborative processes that have basically proven how poorly we understand collaboration. Collaboration needs the explicit support of process. Teams has no sense of process – neither its own nor those of its prospective customers –and it shows.
The vendor that pays attention to the above will have a fighting chance to do what Teams currently can’t: appeal to customers who are already doing collaboration – which is everyone – but don’t want to stop doing what they’ve always done and replace those minimalist processes and rudimentary technology with something that tries too hard to support a single poorly envisioned version of collaboration.
I’ll end with a note on the sociology/anthropology of collaboration. Collaboration and teamwork are natural outgrowths of the fact that we are social animals. Sociobiology has made it clear that we are wired to collaborate, and there are well-defined rewards in both the Darwinian model and untold economic and social models that make it clear this is what we should be doing. History, however, teaches us that collaboration between people, families, tribes, nations, and empires is not just hard, it’s generally a messy affair that ends poorly as often as it ends well.
The world of social animals generally deals with the problems of collaboration through a combination of strict hierarchies (wolves, wasps and whales have well-defined hierarchies, for example) and well-defended borders. Hierarchies provide a structure for collaboration – every member knows its place in the social order and its activities. And boundaries map the physical limits of those activities and define when other groups’ activities are a threat. Conflict occurs when hierarchies and boundaries are violated – and the responses, particularly to the latter, can be violent. There are a few anomalies – Bonobos have relatively well-structured societies that tend to resolve conflict by having sex. Not kidding. But in general the violent conflict that arises from violating hierarchy or boundary is the result of how we’re wired on the animal side of our brains.
(There’s an old joke from academia about hierarchies and boundaries:
The reason academic politics are so vicious is that the stakes are so small.
It would funnier if it weren’t so true and so applicable to the business world as well.)
The modern hybrid workplace we all are striving for violates both hierarchy and boundary. Indeed, we’re trying very very hard to contain that violation and collaborate across these hardwired constraints. And that’s why we’re not doing too well in my opinion. It’s actually against our nature to collaborate in this manner, and products like Teams makes the mistake of assuming that deploying tools that break down hierarchies and borders is all we need.
What’s really needed are processes that show us how to do the things we’re not innately hardwired to do. Process is profoundly absent in Teams, and the lack of any innate sense of process leaves us mere humans to invent something we’re not very good at in the end: a collaborative process for getting a task done. If you don’t believe me when I say humans are lousy at collaborating even though it’s in their best interests to do so, you haven’t been paying attention to the lessons of history, politics, and, yes, the world of business.
This is why Teams is such a mess. It has a hidden, unspoken sense of a collaboration process that fails to acknowledge the complexities of both the technology and the sociobiology people bring to problem and opportunity presented by collaboration. And so we are left to flounder across the borders and hierarchies of our workplaces, literally trying to make stuff up as we go and wondering why it’s not really working that well.
Oh, and Teams is glitchy too. So in the end Teams doesn’t really do what we need to do, and what it does do, it does poorly. Which reminds me of a joke, the one about the two little old ladies eating food in the resort dining hall, the gist of which goes like this:
“Mildred, this food is really awful, isn’t it?”
“Yes, dear, And the portions are too small.”
Get it?
[…] year I wrote a post complaining how Teams has become a perfect example of bloatware, and was gratified to see the response: basically a […]