Leading Technical Teams: Innovation and People, In Balance

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.

TL;DR: Adopt new technology only at the speed your team can absorb it, and test every candidate against one question: can this team operate and fix it at 3 a.m. without me. Grow people by handing over context and decisions, not just tasks, and hire for judgment over the framework on the resume.

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. It is the same calculation behind knowing when to stop self-hosting your internal platform: the question is not which option is most capable, it is which one the people on the rota can still run next year.

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. Every real choice looks like picking between Falco, Tetragon and Tracee, where the most powerful option is also the one that hurts most when the team does not understand what it will do. 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. DORA's capability write-up on generative organizational culture puts it in research terms: how a team treats failure, and the people who report it, predicts how that team performs. 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. Google's SRE book argues the same case in its chapter on postmortem culture, and it is the habit I would keep if I could keep only one.
• 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. An upgrade like Cilium 1.19, with a dozen traps waiting in it, is exactly the night a runbook gets written for.
• Rotate who is on call and who leads incidents, so knowledge does not pool in one person. The on-call chapter of the Google SRE workbook treats the rotation as training, not just staffing. 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. If you would rather work through this with someone on your own systems and rota, that is what I do.

FAQ

How do I know if my team can really operate a new tool before it ships? Ask whether they could fix it at 3 a.m. without you. If the answer is no, name the gap: knowledge that has to be paired until it is shared, a runbook that does not exist yet, or a tool the team simply cannot carry.

What belongs in a runbook for a system that pages at night? The failure modes you already know about, how to tell which one you are in, the safe action for each, and who to wake if that action does not work. A runbook that covers only the happy path is a design document.

How do I delegate decisions without losing control of the outcome? Hand over the context and the constraints along with the decision, and agree in advance on what would make you want to be pulled back in. You decide slower in the short term and gain a leader in the long one.

How do I stop incident knowledge pooling in one senior engineer? Rotate both on-call and incident command, and publish every postmortem internally so the lesson outlives the person who learned it. Knowledge that lives in one head is an outage waiting for that person to take a holiday.