The cultural assumptions in collaboration software

Semiotics isn’t something I’ve heard much about in the two and a half decades in which I’ve been working in the technology industry. It’s a bit woolly for the tech world. But I’m a big believer in how you can understand much about the culture of an organisation through the artefacts that it creates as part of its day-to-day work.

For example, you can tell an awful lot about an organisation from the reception areas of their buildings. A few years ago I was interviewing for a role at a fairly significant tech firm in the UK. I was told by their CTO that they were are very un-hierarchical business. On the way into the building I noticed that the parking spaces closest to the front door were very clearly marked “Directors Only”. For that, and few other reasons, I turned down an offer to work with them…

Software itself provides many, many pieces of semiotic evidence that reflect on the culture of the organisation that produced the product. And over the past few years I’ve been coming to the conclusion that there are many cultural values that are commonplace amongst companies in the tech industry, and in West Coast American software companies in particular, that don’t necessarily manifest in other organisations. Moreover, these values underpin the way in which software that is designed to allow organisations to collaborate has been designed.

In the days before Cloud you could muddle along with the misalignment. But Software as a Service means that those values have become pushed even harder; partly because of the way in which internet-based software can provide functionality that reinforces such values, and also because the concept of “evergreen” software means control over release is now firmly in the hands of the publisher in a way it never has been in the past.

So what are these cultural values, and why are they important? Here are some I’ve observed…

1. Transparency is always a good thing

In general principal, I think I agree with this. But that doesn’t mean that either organisations agree with it, or that (more importantly) regulators agree with it. Whilst being free and open with your information within an organisation might be fine in a software business (and even there, if they are a public company, it might not be), if you work in a regulated industry, or deal with lots of regulated data, it really isn’t fine.

2. People always work under their own identity in a system, not under one delegated to by others or shared with others

In my time at Microsoft in the UK, a business at the time of a couple of thousand people, only the very top people (the General Manager and (at the time) his direct reports) had PA resource, and and for many of the second tier that resource was shared.

Now PAs and EAs aren’t littered liberally across many organisations these days, but there are often far more at deeper levels of the management hierarchy than in the average software company. And people who work with technology on behalf of their bosses are a thing in a way that is almost completely absent in tech firms. And that means that most collaboration software fundamentally assumes that the person using the tool is the person using the tool… there’s no concept of delegated identity in most modern tools (yeah, you can do it in Outlook. But try it in Teams…)

3. Most work is project work

I’ve a theory (one of many) that the reason most offices these days look the way that they do, and that for many people they are totally unsuitable, is because that most offices are designed primarily by office designers to suit the needs of people who design offices. And the needs of someone who designs offices are primarily that the office looks nice enough for someone else to commission them.

When it comes to collaboration software, most people designing the software have only the reference point of people who work on software. And software is primarily a project-based activity.

But we don’t all work on projects all of the time. Some of us provide ongoing services. Some of us manage relationships between people. Some of us come up with ideas. And most of us do all of those things at some point or other.

It’s not to say that everything is like Microsoft Project. But most collaborative software appears to me to be optimised for project activity which means it can sometime not feel quite right when applied to other sorts of work.

4. Storing as much data as possible is always a good thing

You’d be amazed at how much data Google and Microsoft are collecting about how you are working on documents. Even the stuff that they do let you see, let alone the stuff that they keep to themselves. You know, the thing you tick to say that they can improve their products? E V E R Y K E Y S T R O K E. (Possibly).

Keeping all of that data is a ticking time bomb for regulated industries. Version histories on Cloud-based documents will be nefariously mined if they’re not being so already. Remember all those times you’ve learned something because of a meeting you’ve seen in someone else’s online diary? That, on steroids.

5. Management hierarchies are flat. Management span of control is wide.

I can’t remember the exact numbers, but when I was at Microsoft I think it was expected that the Span of Control for the average manager was 12 people reporting to them. Maybe it was 7. I had 16. Such large teams aren’t uncommon in many industries, but not all. Shallow and wide means that tools like Slack or Microsoft Teams are optimised in a certain way. Deeper and narrower doesn’t necessarily need the same sorts of function. If I’m in a team of three or four people, my collaboration needs are very different.

6. The benefit of a new feature will always outweigh the cost of its adoption

This is a common fallacy across external and internal software development teams. The new thing is both new and better that what came before; therefore people will obviously adopt the new thing.

But that doesn’t take account of the interruption to work that comes from having to do things differently. Which of course the people developing the product rarely have to account for.

7. Removing friction from processes is always desirable and beneficial

The most common complaint I hear from knowledge workers in non-tech organisations is “I don’t get time to do anything because all of my time is spent in meetings.” This is as a direct result of the way in which the economic cost of setting up meetings today is very low because most people’s diaries (particularly inside organisations) are available to see online.

Just imagine what the world will be like when everyone is on a cloud-based calendar which is accessible inter-organisation and you can do a web-conference for them all at the click of a mouse (we’re not quite there yet, but the tech is all available today). Complex meeting arranging will be friction free. The only people who will survive are those who have PAs whose main job will be to find increasingly polite ways to tell other people to fuck off.

Friction is not a bad thing.

8. Busy-ness is a good thing and a natural state

On the Android version of Google Calendar it’s possible to email the guests of a meeting invite, and the software provides you with four default options:

– Be there in 10 minutes

– Go ahead and start without me

– Running just a couple of minutes late

– Sorry, I can’t make it. We’ll have to reschedule.

Notice a common factor in all of those? Yes, they all assume that I’m too busy.

Ironically the most common reason I want to email guests is to confirm a meeting either the night before or the morning of the appointment. Just as a courtesy. I guess maybe I might be assuming busy-ness but actually I’m mostly doing it to be polite. There’s a lot of assumed busy-ness in software when you start to notice it.

=/=

Now this isn’t supposed to be saying that the current crop of collaboration software isn’t fit to be used outside of a software company. It’s just that there are some quite fundamental assumptions made that might make adoption more challenging. And, moreover, that the providers of the software will struggle to understand these factors because they don’t represent their own reality. Identify them (and probably others) and you can take account and hopefully make better use of the tools.