I’ve been working as a developer in software consultancies for close to twenty years now. And I’ve seen how important it is to establish a project’s foundations correctly from day one.
I joined Triad in early 2022 and have worked as a Technical Architect on some large projects since then. This role has grown naturally over the years and allows me to combine my love of problem-solving with creating solid, scalable, and easy-to-work-with systems.
What I do
As a Technical Architect, I get involved right at the start of a project. Based on the scale of the system, the userbase, and what the client needs, I design an architecture that can support the application throughout its lifetime. That includes deciding what services need to be built, where they should be hosted, how they’ll be tested, and how to secure them. My job is to ensure that everything is thought through. And nothing is left to chance.
Once we get into the alpha stage, I will start writing proof-of-concept code for the parts of the system that might be tricky—things that could become blockers later. This way, we can de-risk them early so development can move smoothly.
Heading into beta, I focus on getting the project set up properly. Building out the API foundations with built-in security layers. Setting up the front end and back end. And creating a clean structure so that developers can jump in and start working without having to reverse-engineer how things fit together. Once feature development starts, I’m still very hands-on, writing code, fine-tuning the infrastructure, and making sure I’m available to help anyone on the team who’s stuck.
I’m also heavily involved in technical assessments throughout the project lifecycle, ensuring that we have the necessary documentation and evidence to pass each phase gate.
The best thing about being a Technical Architect
For me, the most rewarding part of this role is building the core architecture—the foundation that everything else sits on. It’s the code that enables all the feature development, so it’s got to be solid. Things like setting up API communication with the front end, handling error messaging, managing data access, and authentication are essential. They’re in the background, making everything run smoothly.
I enjoy designing a structure that other developers can understand and work with quickly. If someone can join the project and start contributing without spending days figuring out how things are set up, I know I’ve done my job well.
I also really enjoy problem-solving. It’s a great feeling when someone on the team is stuck and I can help figure it out. It keeps us moving and means we’re always improving the codebase together.
How do I keep learning
The Triad Technical Community of Practice is a great source of support and knowledge. It’s a group where I can bounce ideas off with other specialists and learn from their experience.
Outside of work, I stay current through a few YouTube channels that regularly share new techniques and ideas. Of course, every new project brings unique challenges that push me to read, research, and try new things.
Advice to my younger self
I didn’t set out to become a Technical Architect. It just happened. Over time, I took on more responsibility. I realised that I enjoyed designing systems and enabling teams. But if I could go back and give my younger developer self a few pointers, they’d be (cue stern voice!):
- High unit test coverage isn’t optional. It’ll always save you time and stress later.
- Never throw away old code. It’ll either remind you how not to do something or come in handy when you’re in a jam.
- Talk to your peers. Share what you’re doing and learn what they’re doing—it’s the best way to grow.
Working at Triad has given me the space to do work I’m proud of alongside great people who are always up for solving problems together. Whether shaping the architecture or helping a colleague overcome a tricky challenge, that mix of design and collaboration keeps the work meaningful.
If you have a question for Richard or the Triad team, please get in touch.
