It is 2:07am and your phone lights up. Production is down. Traffic is still coming in, campaigns are running, and a client has just emailed asking why leads stopped flowing. Slack is buzzing, and someone has tagged you with, “Any idea what changed?” You are half awake, staring at a glowing screen, trying to remember how the system is wired together.
You start running through possibilities. It could be an API failure. It could be a cron job choking. It could be the custom plugin, the caching layer, or even that third-party dependency that “shouldn’t affect anything.”
In moments like this, you do not want clever. You want obvious. That is why one of the most practical rules of software engineering is simple: you will regret complexity when on-call.
How Complexity Sneaks In
No one sets out to build something fragile. Complexity does not show up as sabotage. It shows up as ambition.
It shows up when we try to future-proof. It shows up when we try to make systems flexible. It shows up when we say, “We might need this later,” or when we choose a tool because it offers more control or customization. In isolation, each decision seems reasonable.
There’s No Vacuum
But nothing happens in isolation. One more plugin, one more integration, one more automation, or one more layer of abstraction rarely feels risky. Individually, these additions appear harmless. Collectively, they create a system that only makes sense to the person who built it, and even then, only on a good day with adequate documentation.
Complex systems rarely fail because of a single catastrophic mistake. They fail because of accumulated friction. A fragile cron job tied to a third-party API, an undocumented environment variable, a custom override layered on top of another override, or a reporting dashboard with dozens of widgets and no clear signal can all contribute to failure.
Everything works until it does not. When it does not, complexity becomes debt with interest.
Complexity Multiplies Stress
When something breaks, technical difficulty is only part of the cost. Complexity increases cognitive load, recovery time, onboarding difficulty, the risk of secondary failure, and emotional stress.
In the heat of trying to restore service, you do not just debug the immediate problem. You end up debugging the system that created the problem, and the more moving parts there are, the larger the blast radius becomes. At 2am, your brain is not optimized for elegant architecture diagrams. It is optimized for problem-solving under fatigue and, ideally, getting back to bed.
Clear systems and clear processes reduce panic. Obvious systems restore confidence. Over-engineered systems create hesitation.
Build for 2am, Not for Applause
It is easy to design for a demo or for a client presentation. It is much harder to design for failure.
Within software development, the real question should not be, “How impressive is this?” It should be, “Can someone else understand this quickly?”
If someone new joins the team or fills in while someone is on PTO, can that person trace the data flow without a long whiteboard session or extensive backstory? Can you roll back safely? Are dependencies explicit? Is documentation current and complete? When you build like you will be on-call at 2am, your priorities shift.
Software Development Values
The most successful, and least panic-inducing, development professionals prioritize disciplined fundamentals:
- Clear naming conventions
- Environment parity, where development, test, and production behave consistently
- Fewer dependencies
- Thoughtful automation
- Clean rollback paths
- Logging that actually helps
- Complete and up-to-date documentation
- Simplicity
That final bullet, simplicity, is not about minimalism for aesthetic reasons. At its core, simplicity reduces decision fatigue during stress and uncertainty. Falling back on a defined set of rules and processes creates consistency and helps calm everyone involved in a high-pressure situation such as a website outage.
Complexity Outside of the Computer
This principle does not apply only to code. Complexity does not live solely in repositories and 1s and 0s. It shows up in organizations as well.
Layered approval chains slow delivery and often do not meaningfully improve quality. An excessive meeting cadence absorbs energy instead of producing clarity. Poorly defined handoffs between teams create invisible friction. Organizational complexity creates the same problem as technical complexity: fragility.
When a client escalates something urgent, does your team know exactly who owns it? Does your team know how to translate urgency into appropriate action? When a campaign underperforms, is the signal clear? If a deployment fails, is responsibility obvious?
If the answer to those questions is unclear, then complexity has been built into your operating system, and it will surface under pressure.
Simplicity Is Not “Less Advanced”
There is a subtle trap in technical environments. Complexity often feels like sophistication to developers and non-developers alike. However, sophisticated systems are not the ones with the most features. They are the ones with the smallest blast radius and the fastest recovery time.
Simplicity is not a lack of intelligence. It is disciplined constraint. Saying no to features that do not create leverage is not restraint; it is strategy. Building guardrails instead of workarounds requires foresight.
Simple systems scale because they are understandable. Understandable systems are maintainable. Maintainable systems survive.
The Ego Factor
There is another layer here that we all possess to some degree: ego.
It is tempting to build systems that showcase technical depth. It is tempting to architect for edge cases that may never happen. It is tempting to optimize for flexibility instead of stability.
However, when you are on-call, no one cares how clever the solution was. They care how quickly it is resolved.
Designing for resilience requires humility. It requires admitting that you, or someone else, will eventually be tired, stressed, or unfamiliar with the system. You should build for that version of yourself and for your team.
The Hypothetical 2:07am Moment
Let’s get back to the middle-of-the-night scenario. It’s 2:07am. You open your laptop and because the system was intentionally simple you know where to start:
- You know where logs live.
- You know how data flows.
- You know which dependency likely caused the issue.
- You know rollback is safe.
Armed with those four things, it’s simpler and faster to isolate the failure and restor restore stability. You document what happened. Then you go back to sleep without drama, or major effect to the next day. There’s no scrambling or guesswork. The difference wasn’t talent. It was design.
Complexity Compounds. So Does Clarity.
Every system trends toward complexity unless it is actively constrained. Every team trends toward friction unless it is actively simplified. Every stack trends toward sprawl unless someone decides to say, “Enough.”
If you are leading digital work, whether in engineering, marketing, analytics, or product, your responsibility is not to make systems impressive. Your responsibility is to make them resilient.
Build like you will be on-call, because someday you probably will be. Coach your teams to adopt the same mindset. When that moment comes, you will either be grateful for your discipline or regret your complexity.