About
Engineering Manager focused on people, technical leadership and building software that solves useful problems.
Introduction
I’m Azlan, an Engineering Manager with a long-standing software engineering background spanning customer-facing products, frontend engineering, internal platforms, APIs and distributed systems.
Most recently at JustGiving, I led a geographically distributed engineering team that grew from five to eight permanent and contract engineers, including senior and principal engineers. I worked closely with Product and Design on customer needs, engineering priorities and delivery, while supporting engineers in their growth and remaining involved in architecture, technical design and implementation.
My work sits between technical decisions and the people who have to build, run and live with them: creating clarity, making trade-offs visible and giving teams enough context to make good decisions themselves.
Over time my focus has shifted from primarily building software myself to creating the conditions in which engineers and teams can do their best work. I still value being close enough to the technology to understand the consequences of a decision, ask useful questions and recognise when complexity is solving a real problem rather than creating another one.
Most problems that look purely technical eventually involve clarity, ownership, priorities or people. I like those problems. They reward patience, evidence and good judgement more than cleverness.
Leadership philosophy
Good leadership is mostly about creating conditions.
Teams do their best work when they understand the problem, own the outcome and trust that decisions will be explained rather than imposed.
I try to give context before instructions. If people understand what the organisation is trying to achieve, which constraints are real and what has already been tried, they will often reach better answers than I would on my own. Autonomy depends on that clarity. Without it, autonomy can become uncertainty.
Trust is built through small, consistent behaviours: doing what I said I would do, admitting when I am wrong and not surprising people unnecessarily.
Feedback follows from that. I would rather give it early, specifically and kindly than late and generally. Most people can act on a clear observation. Very few can do much with a vague impression.
Culture shows in similarly small moments: how an incident review is run, who gets credit for good work, whether someone can challenge a decision safely, and what happens when somebody makes a mistake. I pay attention to those things more than to anything written on a wall.
Growing engineers
Growth rarely happens by accident.
I try to make expectations explicit, give people work that stretches them without setting them up to fail, and look for evidence of progression throughout the year rather than waiting for a promotion cycle to surface it.
Coaching, for me, means asking more than telling. I want an engineer to leave a conversation with a clearer understanding of their own situation and options, not simply a list of my opinions.
Sponsorship matters too. Sometimes development means putting somebody forward for the design review, an incident lead role or a conversation with a senior stakeholder, giving them enough support to succeed and then getting out of their way.
Promotion decisions should not be a surprise. If somebody is genuinely surprised by an outcome, I have to ask whether the expectations and feedback leading up to it were clear enough.
Team building works in much the same way. I look for complementary strengths and for people who will make the team better, rather than treating recruitment simply as filling an empty seat.
Product and delivery
Engineering management does not stop at the engineering boundary.
At JustGiving, I partnered with Product and Design to translate customer and business needs into engineering priorities and delivery plans, with responsibility for the annual engineering roadmap. We used customer research, behavioural evidence and experimentation to inform decisions rather than treating technical preference as the starting point.
That experience reinforced something I have found throughout my career: good engineering decisions depend on understanding the problem around the software.
That means being able to discuss customer needs and priorities as well as architecture, delivery and system health. Part of my role as an Engineering Manager is helping those perspectives meet without turning the team into an organisational translation layer.
Technical background
Before moving into engineering management, I spent a significant part of my career building software.
My experience started broadly in full-stack development, developed more deeply through frontend and product engineering, and expanded into internal platforms, APIs, backend services and distributed systems. As my responsibilities grew, so did my involvement in architecture, technical direction and helping other engineers make sound decisions.
That background continues to influence the way I lead.
Technical credibility as a manager is not about writing the most code or being the deepest expert in every room. It is about staying close enough to the work to understand its consequences.
I can take part in a design discussion, ask what happens when a dependency fails, look for the operational and cognitive cost hidden in an apparently simple solution, and ask how expensive it will be to change our minds later.
I still read designs, participate in reviews and stay interested in the platforms and technologies teams depend on. At the same time, I try not to become a bottleneck for decisions that engineers closer to the problem are better placed to make.
I also favour writing important decisions down. A short record of the context, options, trade-offs and reasons behind a decision is inexpensive when the decision is made and surprisingly valuable months later when somebody asks why a system looks the way it does.
In practice, I use lightweight architecture decision records and RFC-style documents where that level of shared context is useful.
AI-assisted engineering
I’m interested in AI-assisted software delivery because it presents a practical question about how engineering teams work.
Used well, these tools can lower the cost of exploring ideas and handling routine work, allowing engineers to spend more time on valuable problems. Used carelessly, they can simply increase the volume of software that somebody must review, understand, secure and maintain.
I therefore approach adoption as an evaluation and change-management problem rather than a tooling exercise.
When evaluating a new tool, I prefer to start with the problem it is supposed to solve and agree how we will know whether it helped. Depending on the problem, that might include delivery speed, review quality, defects, security and the experience of the engineers doing the work.
I prefer a limited experiment on real work to a broad rollout based on enthusiasm alone. The results provide evidence to weigh rather than a verdict.
The principle I keep coming back to is simple: people remain accountable for what ships, regardless of what helped to produce it.
I applied the same approach while building this site. The case study on AI-assisted engineering describes what the tools did well, where they struggled and where human judgement still mattered.
Beyond the job title
The parts of engineering management I find most rewarding are helping engineers grow, solving difficult organisational problems and watching teams achieve things they previously thought were beyond their reach.
That interest in helping people develop extends beyond the teams I manage. I have been involved with children’s coding activities, STEM Ambassador work and mentoring through School of Code. I value opportunities that make technology and engineering careers more accessible to people who might otherwise struggle to see a route into them.
Outside work, family matters a great deal to me. So do fairness, honesty and treating people properly.
I also have interests that have very little to do with an engineering roadmap. Sport and music are both somewhere on that list, and through the Heavy Metal Truants I have been able to connect two of those interests with fundraising for good causes.
I try to stay curious. I read about how other organisations work, revisit my assumptions when they stop matching what I see, and learn from the engineers around me.
I’m ultimately more interested in improving how an engineering organisation works than in any particular title, framework or technology.
I would rather be useful than impressive.
Get in touch
If you are hiring for engineering leadership, thinking about how to grow an engineering team, or working through an interesting technical, product or organisational problem, I would be glad to hear from you.
I would be glad to hear from you. You can find me here: