Staff engineering

Technical direction, cross-team leverage, decision records, mentoring, and production-grounded leadership.

• Platform architecture: from standards to a usable product · Guide · A practical guide to turning architecture standards into paved roads, reusable contracts, and measurable platform outcomes.
• AI governance for software systems: controls that fit delivery · Guide · A delivery-focused guide to AI inventories, risk boundaries, evaluation, human oversight, and operational evidence.
• Staff engineering practice: create leverage through clear systems · Guide · A practical guide to technical direction, decision records, cross-team delivery, mentoring, and operational credibility.
• Architecture Solution Blueprint platform · Project · Designed and led the zero-to-one delivery of an enterprise platform that turns 1,000+ architecture patterns into real-time service recommendations, solution blueprints, and automated architecture workflows.
• Staff Software Developer & Enterprise Architect — Royal Bank of Canada · Experience · Building enterprise platforms and standards across architecture automation, observability, cloud infrastructure, and responsible AI.
• "Engineering metrics that matter: DORA, SPACE, and the ones in between" · Note · Every engineering organization measures something. Most measure the wrong things, confidently, on beautiful dashboards nobody acts on. Velocity is up; the engineers say everything is on…
• "Managing technical debt like a portfolio" · Note · "Technical debt" is the most overused and least managed concept in software engineering. Every team says they have it. Almost none can say how much, where it is, what it costs, or what…
• The staff engineer operating cadence · Note · Staff engineering is often described through its outcomes — leverage, influence, technical direction — and rarely through its weekly reality. But the difference between a staff engineer…
• Staff engineering is measured through leverage · Note · Staff level engineering is not defined by taking the hardest ticket or writing the most code. Its impact appears through the decisions, systems, and people that enable many teams to…
• Technical roadmaps should preserve options · Note · A technical roadmap should explain how engineering investments change business capability and system risk. A list of technologies with quarterly dates is a delivery calendar, not a strategy.
• Incident command is a coordination system · Note · During a serious incident, technical skill is necessary but insufficient. Many responders changing the system without shared priorities can increase risk. Incident command creates a…
• Architecture decision records that remain useful · Note · An architecture decision record is valuable only if a future engineer can understand what changed, why it changed, and when the decision should be reconsidered. Length is not the goal.…