I work at Triad as a Senior Technical Architect. It’s a job that involves collaborating with developers, architects and stakeholders. My focus is on delivering resilient, robust, and clean solutions, often using agile methodologies and collaborative tools for rapid prototyping.
Working as a Technical Architect
Before joining Triad, I spent 5 years leading an Integration and DevOps team, delivering a critical national infrastructure project for the Metropolitan Police Service. I was responsible for the integration architecture and deployment of a 99.99% availability middleware solution that connects client systems to COTS products. This required constant collaboration with architecture, security, data, testing and management teams.
What drew me to Triad was the opportunity to continue contributing to UK defence and civil service challenges while shifting from engineering management back to hands‑on architectural work, and to utilise over a decade of experience as a senior consultant.
Being a Technical Architect is ultimately about creating the conditions for developers to excel. When you remove friction, clarify requirements, and design systems with intent, teams can focus on solving complex problems and learning across multiple disciplines. A Technical Architect’s impact should be felt across the entire software development lifecycle, and it’s one of the reasons I love this work.
The role also demands versatility. A Technical Architect will often wear multiple hats, such as facilitator, designer, negotiator and investigator. You can spend significant time understanding how systems currently operate versus how they need to operate. This can be intense and occasionally draining, which is why maintaining a healthy work-life balance and recognising early signs of burnout is essential.
Triad’s flat structure was a refreshing change from the hierarchical environments I was used to, making it easy to reach out to anyone, from peers to Directors, for support or collaboration.
My journey to Technical Architecture
I began my career as a developer, investing heavily in design patterns, data structures, and understanding the trade‑offs behind implementation decisions.
After establishing myself as a seasoned developer, I was given the chance to lead my own team as a technical lead, which broadened my scope and gave me my first glimpses of the bigger picture of complex solutions.
I would eventually grow into leading multiple teams and learning to context-switch and adapt to a variety of situations as an engineering manager. I would establish myself as a technical authority and validate solutions or provide suggestions to move forward.
These experiences became the foundation for translating business needs into technical capabilities and for designing solutions that avoid downstream pitfalls.
Being an architect allows me to continue leading from the front, but with a broader lens and greater influence on the overall solution.
Self-development is really important
The truth is that you need to be self-driven and understand what motivates you. I take great pride in my professional accolades and accomplishments, which drive me to try to do better. Having S.M.A.R.T. goals or similar frameworks to write down what you’d like to accomplish, in what timeframe, and using what metric as evidence can be helpful for this.
I like to set two types of goals. “HARD” goals have a tangible output, such as receiving a certificate upon completion. “SOFT” goals relate to skills like communication, where it might be more difficult to measure success. Having a balance of both gives you a rounded set of objectives.
I’m currently completing the final module of my second master’s degree and plan to pursue additional accreditations, including cloud certifications and CEng. By challenging myself in this way, I can stay on the cutting edge.
I have always considered software development to be a team-based activity, and learning from your peers is a valuable way to quickly advance your knowledge. I suggest that you attend team events, go to conferences, say hello around the office and generally network for a fast way to develop yourself.
What I have learned
It is easy to be hard on yourself. Tech is tricky. And that is okay. Getting other perspectives is important. I have learned to lean on the people around me, and if I feel like I am on an island, I reach out and talk to someone. It’s amazing how a conversation can drive the storm clouds away.
For anyone aspiring to become a Technical Architect, I recommend finding a mentor and investing time in understanding how they think, not just the answers they give. For personal development and growth, the reasoning behind a solution is often more valuable than the solution itself.
If you have a question for Matthew or the Triad team, please get in touch.
