The Window Was Open

Recently I joined a new project team. We came together from different parts of the business, most of us new to one another. Our task was to take an existing project and reimagine it.

That meant absorbing a great deal of information that already existed and was scattered everywhere. Reports, models, drawings, decisions made and then remade, produced over years by different groups, each stored in whatever system that group happened to use and organised in whatever way made sense to whoever created it. Before we could reimagine anything, we had to work out what had already been imagined.

We had the problem that modern collaboration tools exist to solve. And we had the tools. Teams. SharePoint. Both installed and ready to go for a team with no history, no legacy configuration and no accumulated habits to unpick.

Here's what we did.

We used the chat function in Teams. We set SharePoint up as a folder structure. And we ran the project through email, the way we always have.

What struck me was not that this was a poor outcome, and it was. It was that nobody chose it.

There were no discussions where the options were laid out and the wrong one was taken. Nobody argued for email. No one proposed channels and lost the vote. In the first fortnight the way we would work simply assembled itself out of what each of us already knew how to do, and before we knew it we were doing things the way we always have done. Working sub-optimally and inefficiently.

Why does this happen? It's not a failure of intelligence or being in a team of unintelligent people.

A team is formed to deliver something, and the clock starts on the first day. Setting up how you will work is on nobody's to-do list. It is not in the programme, it carries no budget line, and it belongs to no one in particular. Meanwhile everybody arrives from a different corner of the business carrying different habits, and the only tool all of them already agree on is email. So email wins — not because anyone rates it, but because it is the lowest common denominator in a room that has to move today.

And the person who stands up in week one and says we should spend three days designing this properly before we start is not thanked for it. They are the person holding everything up.

The cost doesn't arrive at the moment the decision isn't made. It's not paid up front. It turns up months later, in disguise.

The information stays scattered, so nobody is quite sure the version in front of them is the current one. Because nobody is sure, they attach a copy to an email to be certain the right people have the right file. Every attachment creates another version sitting in another inbox, or in another folder on SharePoint, and the fragmentation the team was formed to resolve gets marginally worse every week — produced entirely by people behaving reasonably. This is the hidden cost of friction. And we never stop to consider how it might be reduced, or removed altogether, to make things run better.

I have been struck, watching how software teams operate, by how differently they treat the same moment. When a new team forms, the first job is to set up how the work will run: where things live, how changes get reviewed, where decisions are recorded, how somebody joining in six months gets up to speed without asking anyone. It is not heroic and nobody is congratulated for it. It is simply understood to be the first task, and the building does not start until it is done. More to the point, the convention travels. It carries from team to team and from company to company, so nobody has to rediscover it.

Property has the tools, they're not new, we just use them with thirty-year-old outdated thinking and convention. Every time a new team starts it reaches for what it did before, which is already broken.

How many times have you heard people in property curse SharePoint, say how bad and clunky it is? That is not because it is a bad tool. In property, we just don't use it properly.

This is why I have come to believe that technology is the easy part. The software is never the constraint. The tools were sitting on every person's laptop in the team before we even commenced. What we were missing was three days and somebody whose job it was to say how we would work. Both of those are organisational rather than technical. Both were free.

I still don't know whether it would've worked. A properly configured workspace only works if everybody uses it, and one senior person who prefers email can quietly undo the whole thing inside a fortnight. But we never got far enough to find out. Too often in property it's senior leaders who aren't willing to change how they work.

We had a chance to start afresh and we blew it. The window is only ever open at the beginning, before the habits set — it was open, and then it was gone, and the team now works the way property has worked for three decades, on tools built for something else entirely.

So the next time your organisation stands up a new team, watch the first fortnight. Not what they are asked to deliver. Watch how they decide to work — and whether anybody challenges the status quo that has delivered so many suboptimal outcomes in the past.

If nobody does, and the folder structure simply appears the way ours did, then the question is not whether your organisation should invest in technology. You already have. The question is can you imagine working in a way that actually leverages your investment properly?