Leadership
Engineering leadership is a system, not a job description.
Leading engineering is not simply managing developers. It means connecting people, architecture, product strategy, delivery systems, and business outcomes so that a team's work compounds instead of cancelling itself out.
Leadership is a system
Most engineering problems that look technical are really systemic. A team that misses commitments is rarely lazy; more often the architecture forces cross-team coordination, the product intent is unclear, or the feedback loop from commit to production takes days.
So I look at the whole system: who is on the team and what they are growing into, how the software is structured, how work is chosen and prioritized, and how quickly it reaches customers. Improving one of those in isolation usually just moves the bottleneck.
My job as a leader is to make the right thing the easy thing — clear priorities, sound architecture, short feedback loops, and an environment where good engineers can do their best work without heroics.
The four pillars in practice
People
Strong teams are designed, not hoped for. I hire carefully, set clear expectations, and create the conditions where engineers grow into leaders.
- Hiring, onboarding, and team composition
- Trust and accountability held together
- Psychological safety without lowering the performance bar
- Mentoring, career development, and growing new leaders
- Autonomy with real ownership
- A healthy engineering culture that survives pressure
Technology
Technology is an enabler, not an end. I favour pragmatic architecture that keeps optionality and avoids complexity nobody asked for.
- Architecture and technical strategy
- Modularity, high cohesion, low coupling
- Technical debt as an explicit business decision
- Build versus buy, and simplicity as a default
- Scalability, observability, reliability, security
- Engineering standards that raise the floor
Product
Engineering is not an internal service department. Teams that understand customers and commercial context make better technical decisions.
- A real partnership between Engineering and Product
- Customer outcomes over output
- Prioritization and discovery engineers take part in
- Avoiding technology for technology's sake
- Business context shared with the whole team
Delivery
Shipping continuously, predictably, and sustainably is an engineering leadership responsibility — not something to demand from a team that lacks the systems for it.
- Continuous delivery and CI/CD as leadership concerns
- Developer experience and fast feedback loops
- Quality and testing strategy proportional to risk
- Sustainable velocity instead of crunch
- Less unnecessary process, more clarity
- Measuring outcomes rather than activity
Leadership at different scales
What leadership means changes as scope grows. Having worked across these levels, I can adapt the altitude I operate at.
A single team
Close to the work. Hiring and onboarding, one-to-ones, technical direction, code and design review culture, unblocking, and building the habits that make a team predictable.
Multiple teams
Ownership boundaries, dependency reduction, shared engineering standards, developing tech leads and future managers, and keeping planning honest across teams.
An engineering organization
Organizational design, hiring strategy, career frameworks, platform and developer experience investment, architecture governance that enables rather than blocks, and credible delivery forecasting.
Executive technology leadership
Technology strategy tied to business strategy, build-versus-buy, risk, security and reliability posture, budget and vendor trade-offs, and explaining engineering reality to a leadership team in language they can act on.