How I Work

Most engineering organizations don't have a technology problem. They have a systems problem.

Slow delivery, technical debt, quality issues, unclear ownership and frustrated teams are usually symptoms of deeper issues.

I enjoy understanding how an engineering organization works, identifying the real bottlenecks and designing systems that continue improving long after the initial engagement.

I enjoy technology. I don't enjoy adopting technology because it's fashionable.

Whether it's AI, cloud platforms or engineering practices, I always ask the same question:

"Does this create measurable business value?"

Technology is a means, not the objective.

Metrics should help people understand a system, not become goals themselves.

Lead time, deployment frequency, reliability and customer outcomes all tell part of the story.

The interesting part is understanding why those numbers change and using them to improve the way teams work.

Complexity grows naturally. Good engineering removes it.

Whether it's architecture, software design, AI workflows or development processes, I prefer solutions that remain understandable, maintainable and easy to evolve.

Simple systems generally outperform clever ones.

The best ideas can come from anyone.

I value honest discussions, respectful disagreement and teams that challenge assumptions instead of defending opinions.

At the same time, quality matters. Clear ownership, engineering discipline and reliable delivery are never optional.

Leadership should not create distance from reality.

I enjoy staying close to engineers, prototypes, customers and code.

Not because a leader needs to write every line of software, but because better decisions come from understanding how things actually work.

AI is changing software engineering rapidly.

The interesting question isn't whether to use AI. It's how to build engineering organizations where humans and AI consistently produce better software together.

That is where much of my work is focused today.