About me
Role and focus
I am a technical leader focused on reducing organisational and technical risk through earlier, clearer decisions.
I work at the intersection of architecture, product ambition and organisational structure. Most systemic failure is not caused by poor code. It is caused by unclear authority, delayed decisions and trade-offs that no one is explicitly accountable for. My role is to design those decision surfaces before they fracture delivery.
I do not just build software. I design the conditions under which it can be built well.
How organisations fail
Across defence, telecoms, fintech and startup environments, I have operated in systems where constraints are real and ambiguity is unavoidable. The consistent pattern is structural. When authority aligns with accountability, delivery stabilises. When it does not, coordination cost compounds.
Over time, my centre of gravity shifted from implementation to direction, governance and operating model design. I stay close enough to engineering reality to keep judgement grounded.
Systems thinking
My background in physics shaped how I think about complex systems. Uncertainty is not a flaw. It is a property to be modelled, bounded and made explicit. That mindset informs how I approach software organisations. Not as collections of individuals but as systems of incentives, constraints and decision flows.
Failure tends to occur at boundaries rather than within components. The same is true of teams.
How I got here
I started in C and C++ in defence and research environments, working on systems where failure had real consequences. A decade in telecoms followed across a large organisation where I moved from integration through development, project management and team leadership and where I began to understand how authority and decision flow shape delivery outcomes as much as any technical choice.
From there, a sustained move toward Python-centric backend and API work: cloud platforms, fintech, regulated environments, startups. At each stage the technical problems were different. The structural problems were the same.
Over time, the centre of gravity shifted. Not just building systems but designing the conditions under which they can be built and sustained. That is what Decision Architecture formalises.
I continue to build real systems under real constraints. Working across hardware, firmware and software keeps judgement anchored in implementation reality.
Why this site exists
This site, CrankTheCode, is where I think in public about authority, decision design and structural clarity. It is not a collection of opinions. It is an exploration of how technical organisations scale without losing coherence.
Decision design and governance
Architectural direction across domains.
Trade-off modelling between product ambition and technical constraint.
Escalation surface design and authority definition.
Technical governance in regulated and high-risk environments.