Five years ago, I picked up a test framework and a terminal and started breaking things professionally.
That might sound like an odd origin story for an IT Architect. But the longer I’ve worked at the intersection of quality engineering and system design, the more convinced I am: the skills that make you exceptional at QA are the exact same skills that define great IT architecture.
What quality engineering actually teaches you
When you’re responsible for the quality of a system, you can’t just test the happy path. You have to understand:
- Every integration point and how it can fail
- The boundaries of each service and what happens when they’re crossed under load
- Where the implicit assumptions live in a codebase
- How a change in one module sends shockwaves three systems away
That’s not testing. That’s systems thinking — the same systems thinking that sits at the core of every sound architectural decision.
I’ve spent years at this intersection: building automation frameworks in Python and Java, designing test infrastructure on Docker and Kubernetes, evaluating AI/LLM systems for bias and reliability. Each role expanded the scope of the question I was answering. It stopped being “does this work?” and became “under what conditions does this stop working, and what does the system do when it does?”
The architectural questions quality engineers already ask
The best architects I’ve worked with ask the same questions that experienced quality engineers ask by default:
- What happens when this fails?
- How does this behave under pressure?
- What are we assuming that we haven’t proven yet?
- Where are the implicit contracts between these components?
The difference between a QA mindset and an architectural one is not the questions — it’s when you ask them. IT Architects ask them before the first line of code is written, at the design stage, when the cost of changing course is still low. Quality engineers have always known these questions matter. The natural progression is to move them earlier.
What you’ll find here
This blog documents how I think about the intersection of quality, system design, and IT architecture — from the field, not the textbook.
You’ll find posts on:
- Quality Engineering — automation strategy, AI/LLM governance, adversarial testing, and what it means to build quality in rather than test it in
- Architecture & Systems — cloud design, scalability, decoupling patterns, and the trade-offs that determine whether systems survive at scale
- Career & Growth — the honest account of what it looks like to grow from individual contributor to the architect’s chair
I write for senior engineers and technical leaders. If you’re a CTO or VP evaluating whether someone can think at the architectural level — this is the record I’m building in public.
Let’s get into it.