👋 Hey {{first_name|there}},
The Illusion of “Simple”
Every team loves the idea of simplicity.
“We’ll rewrite this as microservices; it’ll be cleaner.”
“We’ll use serverless, fewer ops, more focus.”
“We’ll standardize on a single database, fewer moving parts.”
And every time, the promise is the same: less complexity.
But here’s the truth:
Complexity never disappears. It only moves.
You can push it into infrastructure.
You can hide it in tooling.
You can spread it across teams.
But it’s always there, waiting to be paid for.
The real question isn’t “how do we make this simple?”
It’s: “Where should the complexity live?”
🧭 The Mindset Shift
From: “This design simplifies everything”
To: “This design moves complexity to where we can handle it”
Developers are often trained to chase elegance, the “simplest” possible design.
Architects learn to accept complexity, but place it deliberately.
Some complexity is best handled by machines (infra, automation).
Some must live with developers (code, interfaces).
Some belong in process (checklists, reviews).
And sometimes, it sits with people (skills, communication).
The architect’s job isn’t to erase complexity.
It’s to move it where it hurts least and helps most.
📔 Where Complexity Hides
Code
Example: Implementing your own auth logic.
Result: Every dev touches complexity they shouldn’t have to.
Infrastructure
Example: Outsourcing auth to a managed provider.
Result: Simpler code, but now ops must manage integration and trust contracts.
Process
Example: Deciding that every deployment needs a sign-off.
Result: Less risk, but more coordination overhead.
People
Example: Relying on one staff engineer to “just handle” a tricky subsystem.
Result: Hidden SPOFs, burnout, or bottlenecks.
If you don’t address complexity where it resides, it leaks everywhere.
🧰 Tool: The Complexity Placement Matrix
Use this tool when evaluating a design decision.
Step 1: Identify the source of complexity
What are we trying to “simplify”?
Security?
Scaling?
Data consistency?
Coordination?
Step 2: Decide where it belongs
Rate the options:
Should this live in infrastructure (tools, platforms)?
Should this live in code (explicit logic)?
Should this live in process (manual safeguards)?
Should this live in people (expert knowledge)?
Step 3: Assess the tradeoff
Infra → Reduces developer effort, but adds dependency risk
Code → Transparent, but increases maintenance load
Process → Safer, but slows velocity
People → Flexible, but fragile
Step 4: Document the decision
Write it down:
“We chose to move complexity to X because Y.”
This prevents future confusion when someone asks, “Why is this so hard here?”
🔍 Example: The Caching Trap
A team I worked with had constant performance issues.
They said: “We’ll add a distributed cache; it’ll simplify things.”
And it did. For devs.
Queries got faster. Apps felt smoother.
But the complexity didn’t vanish:
Ops now had to monitor cache consistency
Engineers had to debug cache invalidation bugs
Users saw stale data during failovers
They hadn’t removed complexity.
They’d moved it from the database into infra + ops + user experience.
That was fine, but it only worked once the team accepted and prepared for the new form of complexity.
🛠 Architect Behavior: Moving Complexity on Purpose
1. Name the Complexity
Say it out loud. If a design “simplifies” something, ask: “Where is the complexity going instead?”
2. Put It Where You Have Leverage
Strong ops team? Push complexity into infra.
Strong devs? Keep it explicit in code.
Weak monitoring? Don’t bury it where you can’t see it.
3. Minimize Human Complexity
Never let a design hinge on one person’s brain.
If complexity must sit with people, document, train, and rotate.
4. Pay for It Early, Not Late
Moving complexity into hidden corners just delays the bill.
Expose it upfront so the team can prepare.
➕ Advanced Tip: Use Complexity as a Design Constraint
The best architects treat complexity like budget.
You don’t spend it everywhere.
You allocate it strategically.
Ask in every review:
Where is this system spending its complexity?
Is it worth the payoff?
Would moving it help us evolve faster?
✅ Mini Challenge: Run a Complexity Audit
Pick one system you work on.
Ask:
What feels “too simple”? (Where’s the hidden cost?)
Where is complexity showing up most, code, infra, process, or people?
Is it in the right place for your team’s strengths?
Then propose one move:
Shift complexity to infra (e.g., managed service)
Shift it into code (explicit logic)
Shift it into process (reviews/checklists)
Or remove hidden people-SPOFs (share knowledge, write docs)
You’ll be surprised how much clarity comes from simply asking: “Where does this belong?”
🎯 Join the Updated 5-Day Crash Course
If this resonated, the new version of my free 5-Day Crash Course – From Developer to Architect will take you deeper into:
Mindset Shift - From task finisher to system shaper
Design for Change - Build for today, adapt for tomorrow
Tradeoff Thinking - Decide with context, not dogma
Architecture = Communication - Align minds, not just modules
Lead Without the Title - Influence decisions before you’re promoted
It’s 5 short, focused lessons designed for busy engineers, and it’s free.
👋 Wrapping Up
Complexity never disappears. It only moves.
Architects don’t chase “simple.”
They:
Identify complexity honestly
Place it where it hurts least
Align it with team strengths
Keep it visible and intentional
Because the only thing worse than a complex system…
is a system where no one knows where the complexity lives.
Thanks for reading.
See you next week,
Bogdan Colța
Tech Architect Insights