How I communicate, decide, and deliver.
My working style has evolved as the scale and nature of the problems I’ve been responsible for has changed. What began as hands-on delivery within defined systems has progressively moved upstream into shaping the systems themselves - how work is structured, governed, and sustained.
This isn’t a change in personality; it’s a response to increasing scope, responsibility, and consequence.
This table summarises how my operating focus has shifted over time as scope increased - from executing within defined delivery slices, to shaping the systems, constraints, and enabling structures that make delivery repeatable. It’s not a move away from delivery; it’s a move upstream into problem framing, trade-offs, and system responsibility.
| Capability Dimension |
≤2018 (EXECUTION) | 2019–2020 (COMMERCIAL / MODELLING) | 2020–2022 (BIDS) | 2022–PRESENT (PO -> EM) | SO WHAT FOR ARCHITECTURE? |
|---|---|---|---|---|---|
| Problem framing | Problems predefined; execute correctly | Question why outcomes vary | Shape ill-defined problems | Define boundaries and constraints | Architecture starts by framing the problem |
| Primary value | Do the work right | Improve how work is done | Decide what work should be done | Design systems that enable delivery | Architecture creates enabling structures |
| Change | Implement local change | Design targeted improvements | Sequence and de-risk change | Land large-scale change | Architecture governs how change enters systems |
| Decision horizon | Immediate task and quality | Medium-term cost and performance | Bid lifecycle and programme risk | Full lifecycle and downstream impact | Architecture optimises across time |
| Artefacts | Plans, drawings, procedures | Models, analyses, bespoke tools | Bid frameworks, risk models, governance | Frameworks, dashboards, operating models | Architecture works through durable artefacts |
| Learning mode | Learn by doing | Build models to explain behaviour | Test assumptions through bids | Prototype, instrument, iterate deliberately | Architecture validates through evidence |
| Authority & autonomy | Limited autonomy | Local ownership of solutions | Influence without formal authority | Authority to design and implement change | Architects operate through trust and mandate |
| System position | Within a delivery slice | Improve parts of the system | Operate across functions | Align people, process, and technology | Architecture sits between domains |
One constant throughout has been how I learn. I learn fastest when theory is embodied in real systems: building models, tooling, dashboards, or simulations to test assumptions and observe behaviour.
More recently, this work is grounded in AWS-native architecture. My builds focus on practical concerns such as identity and account boundaries, network isolation, cost and quota management, failure modes, and infrastructure-as-code trade-offs. The intent isn’t certification-led familiarity, but practical fluency with how systems behave under real constraints.
To keep the transition disciplined, I periodically assess my experience against formal architecture skills frameworks (e.g. TOGAF). I use these as diagnostic lenses rather than scorecards, to understand where my experience already aligns strongly and where I am deliberately building deeper technical capability.
The chart below shows an aggregated view of relative strength by domain. Areas where I over-index reflect accumulated experience in delivery, governance, and business-facing problem solving. Amber areas highlight domains where I am actively building hands-on technical depth through practical work such as TacSA and cloud labs.
As responsibility increased, my work moved upstream - from delivering within systems to shaping the systems themselves. Increasingly, those systems are cloud-based, security-constrained, and automation-driven. Much of my current focus is on defining architectures, migration paths, and delivery structures that allow teams to move safely and repeatedly.
Moving into Solution Architecture isn’t reinvention - it’s a formalisation of how I already operate: combining system-level thinking with hands-on technical understanding to align people, process, and technology around sustainable outcomes.