Technical debt: Architecture’s ticking time bomb

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 Ries¹:

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 everyone’s responsibility, but none so much as leadership’s.

Technical debt

‘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. 

Conclusion

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.

References

¹ Ries, E. (2011). The lean startup: How constant innovation creates radically successful businesses. Penguin, London, pp.239-242.