Technology should create leverage.

I don’t begin with “Should we use AI?”, “Should we move to microservices?” or “Should we migrate to the cloud?” I begin with a simpler question:

What problem are we trying to solve?

Architecture follows the problem. Sometimes the right answer is a major platform investment. Sometimes it’s a small architectural change. Sometimes the best technical decision is not to build anything at all.

Good technology leadership is largely about judgment.

One of the easiest mistakes engineering organizations make is designing for a scale they don’t yet have. I prefer architectures that are simple today, scalable tomorrow, and replaceable when necessary.

That means understanding where scale actually matters, and where complexity is simply creating future operational cost. Leading cloud migrations, platform modernization, distributed systems, data platforms and SaaS architectures has taught me something simple:

Complexity has a cost. Make sure you’re getting something valuable in return.

I don’t want engineering teams waiting for executives to tell them what to do. I want engineers who understand the customer, the business, the problem — and then the technology.

When people have that context, leaders can give them meaningful autonomy. So rather than controlling every decision, I focus on creating clarity around four things:

• Direction
• Priorities
• Constraints
• Accountability

Then I give capable people room to operate.

A technology executive doesn’t need to be the best programmer in the company, but should remain technically credible. I’ve spent my career building and leading systems across SaaS, cloud platforms, distributed systems, data infrastructure and, more recently, LLM- and RAG-based search and AI-enabled products.

Staying close to architecture lets me ask better questions:

• Where does this fail?
• What happens at 10× scale?
• What’s our operational burden?
• What are we optimizing for — and what are we giving up?
• What would make us regret this decision two years from now?

The point is to help the organization make better decisions, not to win the architecture discussion.

Engineering doesn’t end when code reaches production. I’ve led organizations through incident management, business continuity, disaster recovery, security, compliance, cloud migrations and production modernization. That experience shaped a principle I care deeply about:

If customers depend on it, reliability is part of the product.

Observability, resilience, security and operational readiness are how we earn customer trust — not platform work to schedule later.

One of the best indicators of a technology leader is the organization that remains after them, more than the software built while they were there.

I’ve led organizations of more than 100 engineers across geographies, and spent a lot of time mentoring engineers and engineering leaders. I want people on my teams to need me less over time — which means coaching them to make decisions, handle ambiguity, disagree constructively and take ownership of outcomes.

Your responsibility is to grow your people into a better version of themselves.