I wrote recently about the differences between interactions and transactions, and the trouble with scaling interactions.
Yesterday I was chatting with a client in reflection on experiences that they have had recently in helping people to adopt Microsoft Teams, and it seemed to bear out an assumption I’ve had for a while that products like Teams and Slack are best geared towards project teams. My assumption to date has been that most software like this is primarily designed to meet the needs of the developer, and given that software development businesses are themselves project-centric, they build project-centric products.
But in light of yesterday’s conversation, I’m wondering if it might be more related to the transactional nature of project work.
The project paradigm for delivering stuff in organisations is pretty well accepted. Methodologies can vary, from non-existent to extremely draconian. And they are a strange mix of transactions (plans, deliverables, budgets, artefacts) and interactions (cajoling people who don’t want to do things to do things they don’t want to do). Good project manager in my experience blend those two styles. The worst are the ones who think that everyone will do what they are told.
The Collaborative Team Styles model that I’ve been evolving over a number of years now has three types of team in which we mostly find our day jobs – Service Delivery Teams, Project Teams and Client/Supplier relationship teams.
Service Delivery teams usually have the support of robust and process-centric systems, the bread and butter of enterprise IT in ERP, CRM and Case Management tools. Whether those tools are any good is a separate issue, but these platforms in essence are collaboration platforms build around hard processes (and are rarely thought of as such).
Client/Supplier relationship teams are very interaction-based. They are much more about the casual chat or the occasional panicked escalation. They’re telephone and face-to-face and maybe instant messaging. They are not great in deep threaded discussions Most of that is probably actually Project-team related, and at any time we find ourselves in many teams.
For the three team types that are usually seen as secondary to our main job, only the work of Committees might fall well into these new platforms, and I’ve been floating the idea of Meetingless Papers with some folk in recent months.
Communities can be supported in tools like Slack, but what’s often missed is that a community needs to be facilitated, managed and built. Just sticking tools in front of a group of people and telling them they are community will not an online community make. This can be particularly problematic for line management teams, who increasingly in matrix-managed are little more than communities where the common interest is the same boss. Line management teams rarely are cohesive work units. The line manager in such instances should be seen as much as a community manager as anything else – again, this rarely happens.
Finally, while discovery of the people with whom you might need to network might be facilitated by tools like Teams, the actual meeting and chatting and finding out about one another needs little technological support above a chat. There are less complex places to do that than a full-blown collaboration platform. Like a coffee shop.
Sure enough in yesterday’s client conversation, the project teams are going gangbusters, the decision-making committees less so, and the communities are not flourishing because no-one is stepping up to manage them.
3 thoughts on “Transactions, Interactions, and Teams”
Interesting comment on Teams from a senior exec recently: “Please don’t contact me on Teams — I can’t delegate it! Email is best for communications… “
That lack of delegated rights is a crucial way that tech company culture ignores how other businesses operate.