After years of moving from engineer to leadership, one thing has become clearer to me: technology is the easy part. The hard part, and the most decisive, is the people behind it. I have watched well-funded projects with clean architecture stall because the team could not operate what they built, and I have watched modest stacks run for years because the people around them understood every moving piece.

Innovation without people is debt

It is tempting to adopt every new technology. A new database, a new orchestration layer, a service mesh, the framework everyone is talking about this quarter. But every tool the team does not genuinely understand adds operational debt, and that debt comes due at the worst possible time, usually in the middle of an incident.

I learned this the hard way early on. We brought in a piece of infrastructure that looked elegant on paper and solved a real problem. It also had failure modes nobody on the team had seen before. The first time it broke in production, we spent hours not fixing the problem but learning how the thing worked at all. The technology was not the issue. The gap between what we ran and what we understood was the issue.

Healthy innovation moves in step with the team's ability to maintain it. That does not mean refusing new tools. It means adopting them at the speed the team can absorb, with someone owning the knowledge before it reaches production, not after.

The 3 a.m. test

The question I ask before adopting anything: can this team operate and fix it at 3 a.m. when I am not around?

It sounds simple. It is ruthless in practice. It rules out tools that only one person understands. It rules out clever solutions with no runbook. It forces a real answer to a question most teams avoid: what happens when the person who introduced this is on leave, or has left the company.

If the honest answer is no, the work is not done. Either we write down what is missing, pair people on it until the knowledge is shared, or we choose something the team can actually carry. A system is not production-ready when it works. It is production-ready when the team can fix it without me in the room.

Grow people, do not just assign them

The best technical leaders I have worked with were not the most technically brilliant. They were the ones who made everyone around them better. A few things I hold to:

Give context, not orders. People make far better decisions when they understand the why behind a task. Tell someone to restart the service and they restart the service. Tell them why it needs restarting and what you are worried about, and they catch the three other things you did not think to mention.

Allow room to fail safely. Staging environments that mirror production, feature flags, and a blameless postmortem culture make people brave enough to try and to learn. Fear produces people who hide mistakes until those mistakes are expensive. I would rather hear about a problem while it is small than discover it once it is large.

Delegate decisions, not just work. Handing someone a task grows their skills. Handing someone a decision, with the context and the room to own the outcome, grows a leader. This is the slowest and most uncomfortable thing to do, because in the short term you could decide faster yourself. It is also the only thing that scales you past your own two hands.

Hire and keep for judgment, not just skill

Skills age out. The framework someone mastered three years ago matters less than how they reason when the situation is unfamiliar. I have come to weight judgment, curiosity, and how a person behaves under pressure above any specific tool on a resume. You can teach a sharp, calm person a new system. It is much harder to teach someone to stay calm and think clearly when production is down and everyone is watching.

How I actually run this, week to week

Principles are easy to write and hard to live. Here is the concrete version, the habits that turn this into something a team can feel:

  • Run a blameless postmortem on every real incident, and publish it internally. The goal is the lesson and the fix, never the name of whoever typed the command.
  • Keep a runbook for every system that can page someone at night. If a system has no runbook, that is the next ticket, not a nice-to-have.
  • Rotate who is on call and who leads incidents, so knowledge does not pool in one person. The first time a junior leads an incident with a senior watching quietly is the moment they grow.
  • In one-on-ones, ask what is in their way more than what they finished. Removing blockers is most of the job.
  • Before adopting any new tool, name the person who will own the knowledge, and give them time to learn it before it ships.

The real balance

Digital transformation is often framed as a technology race. What actually decides it is balance: reliable systems and adaptable teams, each reinforcing the other. Systems that hold up buy the team room to grow. A team that keeps growing is what keeps the systems holding up.

Build technology as if it will run for a decade, and build teams as if they are the ones who will build the next one. That, to me, is the whole of leading with purpose. It is not being the smartest engineer in the room. It is leaving behind a team that no longer needs you to be.