Architecting The Defaults

2026

work

Architecting The Defaults

Jessica Brentnall

16 Jul 2026

Prepared patterns, over reactive hussle.

I have a lot of empathy for the cognitive load and breadth of knowledge expected of engineers today. When they sit down to solve a problem, they aren’t just writing code. They are expected to ensure that solution is reliable, sustainable, and maintainable. They’re juggling testing practices, infrastructure trade-offs, cost optimisation, performance, user experience, and security… the list goes on.

There is tooling to help, of course, and in larger organisations, you might have specialists to lean on. Some argue that AI is the answer to this cognitive load; while it is a fantastic productivity aid, I’d argue that if these foundational concerns aren’t considered early, they only become exponentially harder to address the longer they are neglected. AI isn’t the silver bullet some sell it to be.

When I was first putting my thoughts together for this post, I kept re-visiting the format of “X-Driven Design” for the title. It’s a pattern that is familiar to technical people, and we all understand the intention: whether it’s focusing on behaviour (BDD) or thinking about testing first (TDD). I align with many of these practices, but what I want to discuss is broader. The closest phrasing I could capture in that format was “Requirement-Driven Design,” but that sounds incredibly obvious, feels very “waterfall,” and doesn’t capture the spirit of what I am proposing.

In my experience, when we treat security, compliance, and infrastructure as separate, competing practices, it leads to overwhelming “task-list” fatigue. When every non-functional requirement feels like a chore, teams tend to reach for quick-and-dirty fixes. Or worse, they de-prioritise these concerns entirely because the rework feels too daunting.

Often, the impact of ignoring these technical or legislative concerns isn’t clear and the path to implementing the right solution isn’t obvious. It can come across as just another layer of “red tape”, something the business knows they need to address, but doesn’t really care about. When business owners aren’t invested, it’s hard for engineers to justify the effort; the work is perceived as neither valued nor valuable. It’s understandable that when a team is faced with many competing priorities, these are the ones that slip, or are done in a way that builds up significant technical and cognitive debt. The problem is that this creates risk; the impact can be devastating when a problem eventually occurs, and the build up leads to having to support poor-quality and fragile systems.

How do you create high-quality software without overwhelming your engineers or stalling delivery? You stop treating compliance as an add-on. Instead, you embed these concerns into the design phase, establish repeatable patterns, and bake them into the definition of “done.”

Is it easier said than done? Absolutely. It requires a significant cultural shift. However, in a regulated environment, the trade-off is worth the investment.

Warning Signs Of Overwhelm

It is easy for teams to exist in a state of chronic overwhelm without truly recognising it. This is often referred to as the “boiling frog” trap: the friction of the work increases so gradually that it becomes accepted as simply “how we work.” In reality, these teams are often work-rich and time-poor, trading their bandwidth for the sake of just getting the job done. This can sneak up on teams resulting in burnout and mistakes.

This is most common in high-pressure, regulated environments. In these settings, teams can appear deceptively productive, shipping features at speed, but they are often working hard rather than efficiently. The team is burning through capacity, held together by sheer effort, while the underlying process generates a mounting, hidden debt of cognitive load.

If you aren’t sure if your team is carrying this unnecessary weight, here are some of the indicators I look for:

The “Final Sprint” Panic. Developers are left scrambling to add security, logging, or auditing features at the very end of a project. These requirements are often treated as “implicit”, expected to be handled without being explicitly defined, or are shunted to separate tickets that are perpetually de-prioritised. This eventually results in critical security gaps, compliance failures, or last-minute delivery delays when the “hidden” work finally becomes impossible to ignore.

The Review Bottleneck. Team delivery speed is consistently throttled by manual, opaque, or late-stage architecture reviews that act as “gatekeepers” rather than collaboration. Because these reviews happen too late and rely on external specialists, they inevitably trigger costly rework. This creates a dangerous cycle: teams start to bypass the process entirely just to ship their work, which leads to inconsistent technical decisions and a sprawling landscape of unmanaged...