Every architecture office has that one project that has gone (or is going) horribly wrong. Deadlines are not being met. Staff are leaving en mass. And the organisation is hemorrhaging money. Much like Volermort’s ‘He who should not be named’ tag, everyone knows which project they are referring to, and no one wants to be a part of it. Somewhat reassuringly, this phenomenon is not isolated to a single architecture practice. Depressingly, however, is that it is systemic across the industry. Given its non-discriminatory nature, the root cause must extend beyond geographic location, building typology, or design intent. This post proposes that at its core, much of the issue derives from ‘Technical debt’. That is, how shortcuts taken today to hit a deadline means more work tomorrow. Technical debt is architecture’s ticking time bomb – one that must be diffused before it is too late.
A familiar story
Consider the following thought experiment through the lens of the ‘5 Whys’ technique, as championed by Eric Ries1:
Why is this architecture team so stressed? Because they are not meeting deadlines and are working considerable overtime.
Why are they not meeting deadlines? Because they have to redo a lot of previous work, which was never accounted for in the program.
Why do they have to redo previous work? Because the team took shortcuts in order to ‘save time’.
Why were shortcuts taken? Because the organisation is deadline-driven.
Why is the organisation deadline-driven? Because they think only of contractual output rather than digital process.
The spiral of death
As more and more deadlines pass, the project soon spirals out of control. Word spreads throughout the office, and now no one wants to work on the project. The only thing left to do is hire new staff. Unaware of what awaits them, the fresh-faced staff jump in, eager to impress. But so deep is the technical debt, they soon find themselves drowning. More corners are cut so as not to be the source of future missed deadlines. Finally, after endless overtime and being unable to arrest the downward pull, they resign. And the vicious circle repeats.
With no one held accountable for poor digital processes, each new team member inherits the accumulated failings of all that came before them. And even if they wanted to hold someone accountable, the churn is so high that no one is left to blame. And worse of all, all of the project knowledge is gone due to high attrition. The project has surpassed a tipping point beyond which there is no going back.
‘Technical debt’ is the term derived from the software industry used to describe how shortcuts taken today to hit a deadline means more work tomorrow. Far too often, project leaders take a hands-off approach to technology. Unfortunately, this means they can’t manage the technical debt ledger. Unaware of the dire consequences unfolding, there is a ‘just get it done’ attitude. When this approach fails – which it always does – blame is often attributed to insufficient digital capabilities within the team or poor BIM leadership. While these may be contributing factors, the real reason is that had the project leader been a true leader, they would have understood and managed technical debt before it got out of control. Technical debt is everyone’s responsibility, but none so much as leadership’s.
Breaking the cycle
Through our strategic consulting work as well as via the recent Australia Institute of Architects’ (AIA) ‘BIM and Beyond: Design technology in architecture‘ report, which Parametric Monkey co-authored, we’ve come to see systemic errors in how organisations – both big and small – embrace technology and most importantly, how they manage it.
Old-fashioned organisations tend to see technology as a functional silo and categorise it as ‘overhead’. Managing technology becomes an expense to be minimised, and this manifests itself through the appointment of a single digital leader. Modern organisations, on the other hand, manage technology with rigour and accountability. Technology permeates the organisation at every level, from the CEO to the interns. A technology-led approach is the modus operandi. And by this, we’re not talking about what organisations say they do. We’re talking about what they actually do. And the two don’t always align.
Middle managers & digital capabilities
The point of departure for any organisation looking to eliminate technical debt should be a review of their project leader’s digital capabilities. At a minimum, project leaders must have a base understanding of the software their team are using. This might mean sending project leaders to a Revit workshop designed for managers. The purpose here is not to become proficient in the software but rather to highlight critical issues that can become highly problematic so that they can be proactively managed.
After one of our Revit workshops earlier this year, one of the studio leads gave probably the best feedback we could hope for. He reported that he now understood that while two drawings may look the same, they can come from fundamentally different models – one full of quick and dirty hacks, the other modelled correctly. But since he was only ever reviewing 2D drawings, he never knew the actual state of the model. In other words, previously, he was unable to manage technical debt because he never actually looked at the model nor understood how it was modelled. Now, with improved capabilities, he was equipped to manage technical debt.
The Revit dashboard
Many organisations have begun implementing Revit dashboards to assist the management process. And while this is undoubtedly a step in the right direction, often, they provide limited insight. Sure, you can get a feel for how many errors or filled regions are in the model, but this is not a true reflection of the model’s fitness for purpose.
Consider the task of documenting windows. Depending on your office standards or the client’s standards, windows may be documented on a ‘type’ or an ‘instance’ basis. This decision then informs how those windows should be modelled. Suppose a team member begins modelling windows as curtain walls (instance-based) because they are quicker and easier than a window family (type-based). In that case, they may look exactly the same but will behave fundamentally different when documenting. One will be highly efficient and minimise errors. The other will be incredibly time-consuming or require complete remodelling. These types of issues often don’t factor in standard Revit dashboards. As such, technical expertise is needed to make the correct decision about the best way forward.
Managing the technical debt ledger
Many BIM managers will be well aware of this very issue. But if there is only a single BIM manager in the office, they can’t be in all places at once. But here’s the thing – they don’t need to be. Project leaders must take a hands-on approach to technology if they are to have any chance of managing it with rigour and accountability. This does not mean they need to be Revit experts. Nor does it mean that everything has to be modelled the ‘correct’ way from the beginning.
It means having a discussion with the project team to unearth the best way. The decision may still be taken to do the ‘quick and dirty’ option, for example, in a competition when it isn’t yet a ‘real’ project. But at least it is in the ledger, and everyone knows what is needed down the line – both technically and in terms of time and resources. Only once this is understood can the ‘correct’ decision be made and technical debt managed.
Embracing an early adopter mindset
Many modern organisations that manage technical debt well have an early adopter psychographic profile. This is a challenging concept to convey to clients, as almost every organisation believes they are technically savvy and leaders in their field. Much like car drivers rating themselves as ‘better than average’, we can’t all be above average. Most, in fact, are average. So, where does your organisation fall on the spectrum of digital savviness? It’s an involved process, but the canary in the coal mine question is: “How many digital leaders are there in your organisation?”
Early-majority and late-majority organisations tend to search for that one key individual to fix all of their digital problems. Unfortunately, unicorns don’t exist, especially digital ones. But even if they did, consolidating technical expertise to minimise ‘overhead’ is not the solution. We’ve seen organisations with one digital leader per +200 staff (1:200). Such an organisational structure is doomed to fail, regardless of the leader’s competence.
On the other hand, early-adopter organisations understand that architecture and technology have converged and that digital management must be distributed across the entire organisation, not just concentrated on a single ‘chosen one’. These organisations have created deep expertise across all project teams. And because of their attitude to technology, they have the added benefit of attracting digitally competent staff. In this scenario, it becomes a self-reinforcing loop.
Technical debt is the culmination of many interdependent forces that require addressing across multiple fronts – from digital capabilities, team structures, hiring practices, establishing psychological safety for staff to ask questions, to even how staff are remunerated. But it is achievable. Organisations must resist the temptation to palm-off responsibility to a single digital leader. Instead, senior management and middle managers must take ownership of the situation and embrace proactive technical debt management. Technical debt is everyone’s responsibility, but none so much as leadership’s.
1 Ries, E. (2011). The lean startup: How constant innovation creates radically successful businesses. Penguin, London, pp.239-242.
Paul, I like that term of debt, really ties in to the financial meaning. The people+process+technology in order of importance and collective benefit, all tied together, where an imbalance in one affects markedly the others. nice one
Thanks Pierre. Yep the name says it all.
Covid with it’s blind draconian lockdowns has to be an added factor.
I’m pretty sure technical debt existed long before COVID. But it may have magnified the issue.
But I have experienced all of above at all levels and there is nothing more heartbreaking in this business as taking over a Revit model that is beyond salvation.
Thanks for sharing Paul, great article
Thanks Franz. Glad you enjoyed it.
Paul, this is an excellent article! Having spent much of my career in electrical infrastructure – we have definitely been on the late adopter side of the curve and your final point about organization structure is extremely important. I’ve been a part of both org types and I can tell you the decentralized organization wins every time. Innovation progresses much faster while typically creating less technical debt. Overall corporate collaboration is important, but the decentralized organization typically has more autonomy to budget and prioritize work to be done – both innovation and maintenance.
Thanks Fred. Glad you enjoyed it.
Agree with the sentiments of the article. Perhaps for those people who don’t use Revit and update to explain the same situation can occur no matter the BIM platform you use? I do find however that I have to force myself to overcome the software fatigue of having to learn countless pieces of disparate software and new assessment vehicles to remain current. However I have been engaging lately with open source software like BlenderBIM / Ladybug/ Honeybee and find that they have come along way and seem to be much more inline with what users need rather than what software companies think that we need.