Staying Technical: Why an Engineering Lead Needs to Code

In my last article, I wrote about 30 years in IT. About change, disruptions, hype cycles. But I left out one question: How do you actually stay technically sharp when you have a leadership role?

I'm "Head of Engineering & IT" at GBI Genios. That sounds like meetings, budgets, and strategy papers. And it is. But if all I did was meetings and strategy papers, I'd have a problem. Because without technical understanding, I can't make half my decisions. I wouldn't know whether a problem takes five minutes or five days. Whether it's a bug or an architecture issue. Whether we need to touch the monolith or just change a configuration.

How It Happens

It doesn't happen overnight. Nobody wakes up one morning and suddenly can't write Java anymore. It's more like this: You go to a meeting. Then another one. Then a one-on-one, a budget review, a weekly sync. By the end of the day, you haven't made a single commit, haven't read a single line of code. That's one day. No big deal. But when it becomes the norm, you lose your edge. And at some point you're the manager who nods in architecture meetings and hopes the developers know what they're doing.

In 30 years, I've seen too many of that type. Managers who eventually just pushed slides and wondered why the team didn't take them seriously. I don't want to become that.

Why It Matters

It's not about proving to the developers that I can still code. It's about the fact that from my years in system administration and development, I can see both sides. When a problem comes up, I can tell whether it's better solved in code or in settings. That mix — what they now call DevOps — isn't a buzzword for me. It's my daily life. Without that closeness to the tech, it simply wouldn't be possible.

Or rapid prototyping. Developers are often a bit... helpless when it comes to operations. Simple things like deploying a JAR or restarting a service can already be a hurdle. I can then set up a prototype in an hour, deploy it, and show: "Here's what this could look like." That saves discussions and meetings. And it gives the team a concrete starting point instead of just an idea on a whiteboard.

What I Actually Do

Open Source

Morphium, my MongoDB driver and ORM for Java, is probably the most important one. We use it in production at Genios — with a billion documents. That means: real project, real requirements, real bugs, real performance problems. Not a toy.

Then there's jblog3, the blog software this article is running on. I recently migrated it from Spring Boot to Quarkus — and Quarkus supports Morphium directly, thanks to open source and the help of other developers. Also a running application with real problems and real deployment cycles. Projects like that keep you alive.

Architecture

I don't just read code, I'm actively involved in the architecture. I proposed the entire IT and software architecture at Genios and refined it together with the team. I'm regularly in exchange with the architects — not as a rubber stamp, but as someone who joins the discussion and also says: "That's not going to work, because..."

Especially with architecture, it's hard to tell "right" from "wrong." Experience shows: there is no "wrong." Just maybe impractical, or inefficient. And sometimes that changes over time — what's impractical today might turn out to have been the right call tomorrow. But we have to carry the architecture together, evolve it together, and stand behind it. If I propose something solo and everyone else thinks it's nonsense, it's not going to succeed. That's how I get feedback, too. And the important thing: stay open. Admit mistakes when you make them. You go down the wrong path sometimes, it happens. But then having the maturity to recognize you were wrong — that's not easy. I'm not always great at it either. But I try.

With Morphium, I now have a team that shares responsibility for architecture decisions. That's a good feeling — when you realize your open source project has grown big enough that others are thinking along and shaping it with you.

Code reviews are part of that. Not every pull request, but enough to understand what's happening. Where is the architecture heading? Where is technical debt building up? Every now and then I see things others miss because they're too close to the code. A fresh perspective has its value, even if you're not deep in the same module every day.

And when something new comes along, I want to try it. First-hand experience, not second-hand opinions. Sometimes an evening with a new library is enough. Sometimes it's a weekend project. And sometimes the result is: this isn't for me.

Docker, for example. I've tried it, multiple times. And every time the feeling was the same: I could have done this directly in the shell or on a dedicated LXC container. And done it better. I don't want to install hundreds of black boxes in VMs without knowing what's happening inside. I have a bit of FOMO about it, I'll admit. Everyone talks about Docker, everyone uses Docker. But so far, everything that's been implemented with Docker at our place has caused more work than benefit. I'm not talking about orchestration like Docker Swarm or Kubernetes here — we have our own solutions for that. I'm talking about the pure container approach, the "pack your application in a Docker image and everything will be fine." It won't be. At least not for me. I'm still waiting for the killer use case that makes it click why I need Docker.

And that's OK. You don't have to follow every trend. But you have to have tried it before you reject it. Otherwise you're not being critical, you're just being ignorant.

The Homelab

This might sound odd for a "Head of Engineering": I've set up a Proxmox cluster at home. Not as a toy, but so I can have informed conversations about operations and actually understand how things work. When my team talks about virtualization, network configuration, or cluster setups, I want to know what they're talking about. Not from a book. From hands-on experience.

The cluster now runs a complete test infrastructure. Automated tests for Morphium, but also for the entire Genios stack. It's my sandbox where I can try things I wouldn't touch on the production system.

The Time Question

I won't lie: part of it happens in the evenings and on weekends. Open source projects don't maintain themselves between 9 and 5, especially when the day is packed with meetings.

But code reviews are work time. Architecture decisions are work time. A prototype that saves the team a week of discussion is work time. I try not to treat technical work as a distraction from "real" leadership work, but as part of it. That doesn't always work out. But mostly it does.

The Letting Go Thing

My biggest weakness. When I see a problem that's solvable and I know how, my fingers itch. Write the fix, commit, move on. You think you'd be faster. And with experience, in some areas you are. But "faster" often means: something overlooked. An edge case missed. A test not written. Because you were in such a hurry.

At its core, this is a trust issue. I trust my team. They can do it. And yet I want to get my hands dirty. That's actually the point: it's not that I don't trust the team. It's that I miss the work. The making. The building. Solving problems with my own hands.

If I do the fix, the team doesn't learn anything. And I become a bottleneck. That doesn't scale. So I hold back. Most of the time. I explain where the problem is, give hints, do a review. But the fix is the team's job.

And that's exactly what the homelab, the open source projects, the prototypes are for: so I can get my hands dirty without getting in the team's way.

It Doesn't Happen By Itself

Staying technical as a leader doesn't happen on its own. It costs time, energy, and sometimes sleep. But the alternative — a CTO who no longer understands what his people are doing, who sits in meetings hoping everything will work out — that's worse.

So I code. Not every day. Not as much as before. But enough to know what I'm talking about. Enough to put together a prototype when the team is debating. Enough to recognize in a code review whether a solution is elegant or a ticking time bomb.

Because in the end, it's like everything in this industry: if you stand still, you fall behind.