Modern Software Engineering
AI can write code faster than you. Can your organisation actually run on it?
Who I am
I've spent two decades building the infrastructure that has to hold when everything else is on fire.
At Google, that meant over ten years on systems where a silent regression costs the business real money — most recently as Technical Lead for the Chrome Speed Tooling team, running the performance infrastructure that catches Chrome regressions before a billion users see them. I'm also the main author of LLVM XRay, the function-call tracing system now used across the industry to find the one-in-ten-thousand failure hiding in production. From there I spent four years as a Principal Software Engineer at Microsoft, inside Azure, applying the same discipline to internal infrastructure that public-facing Azure services quietly depend on.
Today I'm a Principal Software Engineer at d-Matrix, leading the compiler team for an AI accelerator built for high-performance generative-AI inference. On the side, I run Dean Berris Consulting for engineering leaders who want that same discipline applied to their own AI adoption — before a competitor, an audit, or a departing engineer forces the question.
I'm not a consultant who used to write software. I'm still in the room where the production incidents happen. Everything I teach, I'm still doing.
What I focus on now
Every engineering org is being told to "adopt AI." Almost none of them have a way to tell whether it's actually working — whether a team is further ahead than "some people use Copilot sometimes," or whether the org could survive its AI-fluent engineers leaving.
That's the gap I work in: organisational enablement of AI initiatives — helping engineering leaders take their teams from scattered individual AI usage to something the whole organisation can rely on, measure, and scale.
The spine of that work is the Meta-Harness Maturity Model, four stages every dev team moves through as they mature their use of AI agents:
Ad hoc — engineers use coding agents inconsistently; results vary by person.
Harnessed — a working setup exists, but it lives in one champion's head.
Codified — it's written down, and the team applies it consistently.
Institutional — it's how the org ships: governed, measured, and onboarded into.
Most public advice on "AI for dev teams" stops at tool recipes or abstract governance decks. What I bring is the part in between: the actual human process of building a harness, iterating on it, and scaling it from one engineer to a whole team to an enterprise.
Who this is for
Engineering leaders who need to know where their teams actually sit on AI maturity before they commit budget or headcount to "AI transformation."
Teams with a working AI habit that hasn't survived a single departure or a single new hire yet.
Individual engineers and technical leads who want the underlying engineering discipline — system design, testing, documentation, deployment, continuous evolution — that makes AI-assisted work actually hold up in production. (This is also what Modern Software Engineering (Vol. 1) is about.)
Working with me
I take on a limited number of engagements alongside my full-time role, in this order:
Assessment — a structured read on where your team sits on the Meta-Harness Maturity Model, and what's actually blocking the next stage.
Bespoke engagements — installing and documenting a harness with your team, live.
Retainer — ongoing support to advance and sustain a stage once it's in place.
If you're not sure which one you need, start with the Assessment — that's what it's for.
Based in Sydney, NSW, Australia.
Email: [email protected] · Signal: d15s.83 · LinkedIn: deanberris
