Collaboration in AEC
Rome wasn’t built in a day — or alone
Designing and constructing buildings is inherently a collaborative thing to do, yet if we look at the tools we use in AEC we see that they are actually quite siloed. Why did this happen and how did we get here?
How did we get here?
I find the history of design collaboration extremely interesting, and the role of an architect lies smack in the middle of it. Architects are the conductor of the orchestra. They have to facilitate collaboration between the plethora of stakeholders involved in building design and construction. Then they have to communicate this design intention to the person on site who’s going to actually build it.
It’s telling as to how we got here. Imagine you’re a neanderthal — If you want to design something and communicate it, you pick up a rock and start scraping it off the internal wall of your cave to show your fellow neanderthal. If one of them has another idea, they pick up a rock and start etching over your drawing. The process is frictionless and collaborative; you can be creative and productive all in the same environment.
The underlying principle of communication did not change much before the introduction of CAD. People moved to drawing on paper, and the scale of buildings evolved, but if somebody wanted to show you something you could still walk over and draw on the page.
Then we had the introduction of CAD in the late 1950’s (thank you Dr. Hanratty). The interface for design moved from a physical representation (i.e paper) to digital (i.e computer screens). This brought a huge amount of advancements in productivity and complexity of buildings that could be created as the computer could do much of the heavy lifting.
One of the interesting things around this time was the transition to CAD. We never really fully moved digital. The city planners and contractors still required a physical sheet set, because their internal processes required it and they didn’t have computers on site. That transition is still seen today: our outputs (in most cases) are still 2D sheets of the building.
As we widely adopted the internet in the workplace and workforces became more decentralised, the cracks started to show. Sending large BIM models is difficult — we use Dropbox, email or *shiver* physical USB sticks. This form of “just go stand by the computer and work together” hasn’t served us well in a 21st century workplace.
The cracks fully split open in March 2020 when SARS-CoV-2 was declared a pandemic. People fled cities and started to work remotely. Now “syncing with central” isn’t as easy as shouting across the office to tell somebody to sync their work, how are we going to work in this changing environment. The current design tools clearly can’t help us here; they’re not built for this.
How can we pick up rocks digitally and start being more creative and collaborative? Let’s take a look at the types of collaboration to see how.
Types of Collaboration
There are 2 main types of collaboration: asynchronous and real-time. Both of these types have a place in how we work, while both serve different purposes. Creators of design tools should be thoughtful and empathetic about how and where these are used.
Asynchronous Collaboration
This is getting work done faster, more efficiently and effectively by working on different parts of a shared project.
Historically software has defaulted to this style of collaboration, mainly because it’s easier to develop and because web technology is only now making this viable.
Tools like Google Docs and Slack allow you to facilitate asynchronous productive collaboration (i.e you can be more efficient over a long time span) by sharing files, commenting etc.
CAD as a paradigm is built for asynchronous collaboration — you are forced to “sync to central”. Think about any time you’ve had an argument over text, it’s super frustrating. You’ve got to wait for their reply, you’re limited by the speed of your thumbs, etc. Isn’t it just easier to actually call that person on the phone and sort it in real-time? Syncing to central is the equivalent of arguing over text.
Real-time Collaboration
This is allowing those creative juices to flow, thrashing out an idea with a colleague etc. Real-time collaboration is interesting because it is the essence of design.
Real-time collaboration in software is a workflow that people misunderstand the most. It should foster those “aha” moments by providing a frictionless way to simulate standing at a whiteboard.
Currently the AEC industry defaults to asynchronous forms of collaboration. Yet creative industries (like AEC) are inherently built upon real-time collaboration — the current toolsets in AEC don’t allow for this.
Tools like Figma, Miro and others have proved the value of being in this simulated real-time environment. We are seeing this in action within firms, deploying these tools for early stage conceptual design and collaboration. We want to bring that form of collaboration to the entire design phase and standardize it.
AEC is the most creative and beautiful industry in the world, in my opinion. When I talk to architects, the thing they tell me they really miss working at home is the studio culture. The exchange of ideas that happen when you gather around a piece of paper. We want to recreate that feeling wherever people are.
Creativity at its core is a thing that is done together. Our tools should mirror this thesis, but they don’t (yet). Collaboration is core to us at Arcol. We believe that we should default to real-time collaboration to enable the creative process, while respecting that asynchronous collaboration also has a huge role to play in the AEC workflow.
But wait, isn’t real-time collaboration bad?
I have heard this a few times over some of my conversations with AEC folks. They usually go like this:
“Well I don’t want people looking over my shoulder when I work, won’t my boss just use this to micro-manage my time remotely”?
“I want to do my work and push it, buildings are complex and can’t be done in real-time”
“We don’t design by committee like this”
These are all reasonable conclusions for users to come to. I found this article recently from the early days of Figma. Figma has pioneered ‘multiplayer’ styled collaboration.
This one in particular didn’t age well. If you follow this line of thinking, you’re essentially saying that design is a solo operation. You think of something all by yourself and you will it into existence. Either the conclusion is, “AEC is entirely different to everything else” or perhaps the tools we use don’t enable collaboration in a natural way.
If you look back, people viewed real-time as a terrible thing in the early days of Figma, now it is seen as one of the most valuable aspects of a Figma workflow. I haven’t heard anybody saying “I want to go back to Sketch”. In the same vein in AEC, we moved to using computers not too long ago. I haven’t heard anyone (seriously) say “I want to move back to tracing paper”. This leap is required for us to cross the chasm that we’re going through in this industry, and collaboration is core to successfully completing the leap.
This post by Co-screen summing up their conversation with John Lilly does a great job addressing some of the above concerns. John is also an investor in Arcol ;-) I’m also going to drop a great post from Figma about how collaboration at Github has adapted throughout this ecosystem transition.
So where does that leave us?
Dylan Field wrote this elegant tweet recently. Every industry should default to “multiplayer experiences” — we want to push for that change in AEC.
The argument of “oh well buildings are different” has been used in every other industry since the dawn of time. The truth is yes, buildings are way more complex than some of these other verticals, but they are not different. At the end of the day we design and construct buildings together.
Our tools should help us do that. That’s our goal at Arcol.
If that sounds exciting then come help us build this new future by applying to one of our open jobs or joining our ever-growing waitlist!
Thank you Daniel for giving me amazing feedback, as always!
