Why did you decide on this career?
I started my career in finance operations, in a hybrid role combining trading operations with product management. The product work was my gateway into tech - I was involved in redesigning our back-office system to fit operational needs.
The experience showed me that I enjoyed building solutions and designing systems, so I formalised that interest by achieving the MSc Management of Information Systems and Digital Innovation at the London School of Economics and Political Science (LSE).
During that time, I met people from various tech backgrounds, which helped me see a clear path into the industry, and I eventually joined Accenture.
How did you get your job?
I applied online and progressed through a rigorous multi-stage interview process.
The first stage consisted of a more classic consulting-style screening - an online behavioural and numerical assessment.
This was followed by an assessment centre, comprising a:
- formal interview round
- short tech showcase presentation (lasting 10 to 12 minutes)
- case study exercise
- aptitude-style game.
Finally, the last stage was a technical interview focused on my technical grounding, including software delivery methodologies and an understanding of tech fundamentals.
What qualities are important for a technical architect?
A good tech architect needs a strong technical grounding to make sound design decisions and understand trade-offs, which I continue to deepen through hands-on delivery.
But the differentiator is communication and the ability to explain complex technical details clearly to different audiences, especially non-technical stakeholders.
Finally, there's a design mindset to the role - the ability to bring components together into an overall solution that is a cohesive whole.
What's a typical working day like?
This can vary slightly depending on the type of engagements/projects.
On strategy/advisory engagements, the day is centred on discovery and decision-making.
The day tends to kick off with gathering inputs, including:
- clarifying the scope/objectives
- client workshops
- reviewing existing architecture.
This is followed by working sessions where we develop and refine the:
- delivery approaches
- roadmaps
- target architecture designs
- vendor assessments.
The rest of the day is dedicated to documenting and enriching the artefacts, such as:
- architecture diagrams
- views
- decision logs
- strategy decks, etc.
The pace is fast, and the core skill is turning inputs and requirements into an actionable target-state architecture.
With delivery-focused engagements, the day is more focused on execution and cross-team alignment.
It typically involves coordination across delivery squads on surface blockers, risks, and dependencies - particularly in larger projects involving multiple systems and interfaces.
There will also be frequent technical working sessions with engineering SMEs:
- supporting building and testing
- resolving design and integration issues
- troubleshooting defects.
The overall focus is on maintaining clarity and alignment as delivery progresses.
What do you enjoy most about your job?
I get to work with clients across different industries, which means varied exposure to different operating models, challenges and technology landscapes.
Beyond the variety, I find it genuinely rewarding to serve organisations in tangible ways, whether that's shaping an architecture strategy or helping realise it through delivery.
Ultimately, seeing the end result of tech solutions coming together to improve how a business operates is something I truly enjoy.
What are the challenges?
One of the biggest challenges is the pace and complexity. On demanding programs, you're expected to absorb new technical concepts quickly, sometimes across unfamiliar domains, and apply them immediately in real design and delivery decisions.
Another practical challenge is that the role often requires operating under a strong degree of ambiguity. You may have to work with incomplete information sets and evolving requirements.
In practice, the bulk of the job involves identifying and addressing unknowns early and driving decisions with the right level of detail.
How has your role developed?
My role has broadened over time in scope and ownership. Earlier in my career, I was more focused on contributing towards shaping and delivering technical deliverables. Over time, I've increasingly taken on more responsibilities in owning and leading workstreams.
What advice would you give to those looking to become a technical architect?
- Invest in strong technical fundamentals - such as integration, data, and security. Tools change across different industries/contexts, but fundamentals compound.
- Practise architectural thinking - develop the ability to simplify complex concepts. You also need to be competent in articulating ideas, options, constraints and rationales behind why a certain choice is 'right enough' for the cost, time, and risk, etc.
- Get comfortable with ambiguity - you rarely have perfect information, so you need to be confident with making assumptions, validating them quickly and adjusting as you learn more.
Find out more
