Keeping skyscrapers from collapsing
Problem solving when failure is not an option
It’s pretty amazing that we hardly ever hear about skyscrapers collapsing. Keeping a skyscraper upright is insanely complex. To complicate matters there is no room for failure: most often built in highly dense populated areas a collapse would be a major disaster. Yet, they’re springing up like wildflowers. How do they keep from failing? Can we tap into and leverage those ideas ourselves?
Quite a few of us live with skyscrapers as a part of everyday life. Often built in busy cities buildings went into the sky when we ran out of space on the ground. Defying gravity they stand tall and give thousands of people places to live and work, despite mother nature being committed to bring it all down at the first sign of trouble. Even if you only consider the designing and planning phases you would be mind boggled by the engineering and architectural ingenuity involved. Let alone getting the things constructed.
No matter how smart the architects, engineers and planners are, the construction of their designs happens in the real world and is done by people. This is a virtual guarantee that mistakes will be made and unforeseen things will happen. The plans are made by people as well and by that logic contain mistakes too. The thousands of workers involved in their creation are spread over numerous teams, subcontractors, areas of expertise, etc. It’s also not uncommon for the buildings to have multiple owners and often many public stakeholders as well, causing requirements to change mid-build, another potential source of trouble.
So how on earth don’t we hear about these superstructures tumbling over and crashing to the ground more often? Think about it: our own way smaller projects can be a struggle to complete to the standards we aim for. Sure, there is a couple of magnitudes difference between your budget and that of a skyscraper constructor, but so is there in complexity. There must be something they do differently than the rest of us.
A world of specialists
Before the 20th century buildings were successfully put up by a Master Builder: a single person who oversaw the entire process of design, engineering and construction from beginning to end. When problems would pop up their heads they would use their mastery and understanding of every little detail to come up with a solution to counteract it, resulting in a buildings that mostly stayed upright. However, as every stage of the construction process kept advancing, the complexities eventually outgrew the abilities of the human individual. Master Builders started to disappear to the point of having practically vanished by the middle of twentieth century.
In place of the Master Builder specialists started to appear. First engineering and architectural design were considered separately from construction. As advancements kept being made each of these areas of expertise were split up further. For example, engineering now consists of many specialities like mechanical engineering, electrical engineering and plumbing engineering, to just name a few.
The rise of the specialist, however, meant that the builders had to confront the fact that a single person dealing with problems and making decisions was now seriously flawed. With the Master Builder — an expert with a command of all knowledge required — reduced to a mythical creature, giving an individual such autonomy became a source of unsuitable decisions and overlooked errors. A recipe for disaster, quite literally. So they abandoned it.
The fragmentation of knowledge had another consequence. With sections of the construction process being split up bit by bit, so did the once shared sense of values. If you were to put engineers in charge, every building would just be a box. Let architects go wild and you will run the risk of having beautiful inventive models, but a slim chance their full scale counterparts could actually be built.
Ever more complicated buildings were still put up reducing the margin for error even further. Forced to evolve the industry came up with a different way of dealing with problems to make sure their creations would remain standing tall and proud.
Thinking as one
While the construction industry lost their Master Builder, they haven’t stopped planning. Incredibly detailed construction plans describe how the building is to be put up, with each trade having their own sections. What starts as an architects sketch is expanded and transformed into plans that depicts everything from how the structural foundation is built to how carpet will be laid on the 52nd floor.
The construction plans are turned into an equally detailed schedule. A day by day series of tasks describing what needs to be done, under what constraints and in what order. Some are highlighted to indicate special conditions like critical steps that could prevent other tasks from being completed. For example, a task describing the concrete having to be delivered before the fifteenth floor could be poured. By the use of checkmarks job supervisors can indicate the progress made, turning the entire schedule in basically one long checklist.
So far, this doesn’t sound that different to how the rest of us plan our projects, albeit in more detail. Most of us recognise the need to think ahead and formalise what we are — and are not — going to do. But what good are these plans in a world of unforeseen problems and mistakes?
With the stakes of completing work on time, on budget and correctly immensely high the construction industry realised they needed all hands on deck. It had to find a way to combine the knowledge now distributed amongst the many specialists involved in putting up buildings.
Alongside the construction schedule another type of schedule got introduced: a communication schedule. Just like the construction one it’s basically a checklist of tasks, but depicting the solving of a problem affecting two or more fields of expertise. Rather than detailing when and where the pipe-fitters has to put in their drainage pipes it describes a chief electrical engineer having to discuss a problem with their colleagues of mechanical engineering and crane operations. A task can not be checked as “done” unless each representative of the involved divisions has signed off on a way to address the issue. Once checked, each department adjust their bits of the schedule and construction plan, to then move on.
In having to deal with the unknown, the knowledge that — no matter how well they plan these immensely complex projects — problems will occur, the builders rely on communication. They confront and live with the fact that, despite their potential differences of opinions, they need every piece of the puzzle to complete it. They believe in the power of multiple eyes looking over a problem — all from a different angle — and deciding what to do to prevent them from making possible catastrophic mistakes.
By the nature of complexity what might seem like a mostly inconsequential issue has the potential to be an ingredient of a recipe for a way more substantial problem. Through the involvement of others the builders leverage the expertise of the entire team in detecting potential risk. Their approach of scheduling communication and treating its execution like any other task makes for problems to be dealt with early and quickly. When the involved parties either forgot to communicate or didn’t come to an acceptable solution further progress is halted, just as it would when the beams holding up the 40th floor couldn’t have been welded. Even though the entire construction process could be held up the builders understand that lots of minor complications pile up to form major headaches.
For the rest of us
When I first learned about what it takes to keep a skyscraper from collapsing I was working together with Baz Deas on an app called Rallypoint. With it, at that point not more than a couple of poorly thought out prototypes, we tried to solve — what turns out to be — a very similar problem: how do we keep small issues encountered in the making of apps from turning into way harder to fix problems. How can we make decisions as a team rather than as individuals?
We actually didn’t realise that it was a cascade of lots of small problems that was causing us grief. All we knew is that we worked on interesting projects, based on good ideas with competent and willing teams, but yet somehow quite a few of them didn’t deliver on their potential. Even worse the teams often turned into little islands of developers, designers, project managers and clients and didn’t feel like a joint effort anymore.
After we blamed and tried to redesign our project management tools (like Trello, Basecamp, Flow) we realised they were just not designed to help you make decisions as a team. Despite most of them having comments or discussion sections, decisions would often get buried, if they were even made properly in the first place. When we learned about the construction industry dealing with the exact same problem with great success we finally grasped it was not the planning or scheduling of what we knew had to be done. It was a lack of understanding and structure about what to do when we didn’t.
The story of our work getting more complex and becoming the place of specialists is one that resonated with us strongly. In a world where we continuously try to achieve better and greater things we run into the limits of how much knowledge we can fit in our heads. We either differentiate ourselves by specialising in a very narrow field of our work, or become— by consciously staying on the surface — a generalist: a specialist who understands just enough of a couple of areas to help different groups of more narrowly specialised people work together.
Rallypoint is the result of us trying to apply the principles uncovered in the world of construction to our own. Most of us just don’t work in projects with a couple of thousand others, a budget of a couple of billion dollars and humans lifes at stake. Our plans aren’t as complicated and detailed, nor is there reason for them to be. However, even in a team of only a handful of people, mostly ourselves with a project manager and a client, there is enough complexity that leveraging each other’s expertise and making decisions as a team is essential to success. With Rallypoint we have — we hope — put together a tool that helps anyone do that, without having necessarily having to understand all the theory behind it.
At first glance when our projects end in a sub-optimal way most of the time not much else than our egos get hurt. Surely their failure is not as big of a deal compared to a 70-story building in the heart of a sprawling city caving in on itself. Their ideas have might had potential to improve some situation somewhat, or even just have caused a laugh or fixed a little annoyance, but without them the world just keeps on turning.
But ask yourself this: if lots of little problems add up to major headaches, why wouldn’t lots of small steps in the right direction be just as necessary to affect bigger, positive change?
From little things big things grow.
I really hope you enjoyed reading this article, I put quite a bit of work into it! You can support me by recommending it to others using the button below. Thanks!
