One of the hardest changes in an engineering career is moving from being the person who solves the problem to being the person who helps the team solve it.
I still enjoy the technical side of the job. Reading logs, following a trace across services, working out why something behaves differently under load, reproducing a bug and staying with it until I understand what is really going on. Becoming a team lead didn’t change that. What changed is where my work has the most impact.
Earlier in my career, fixing a hard problem myself was a good day. Now a better day is usually one where an engineer fixes it, understands why it happened, and feels more confident about the next one.
The pull to take over
When people know you can handle difficult technical problems, they bring them to you. A tricky Elasticsearch issue, an OpenTelemetry pipeline that isn’t behaving, a customer escalation with the clock running. The fastest option is to take over, and in the moment it often feels like the responsible one.
I’ve learned it isn’t always the right one. If I solve every hard problem myself, the problem gets fixed but the team doesn’t get any stronger. The same kind of question comes back next week, and slowly the lead becomes the bottleneck. That isn’t the team I want to build. My job is to help build a team that can solve hard problems without needing me in the room every time.
Staying hands-on still matters
Leading people doesn’t mean walking away from technology. For me, staying hands-on mostly means staying curious. I still build things, try new tools, read the documentation when something doesn’t add up, and get into the details when a problem calls for it. Lately most of that has been OpenTelemetry, Elastic Observability, AI agent observability and MCP.
That work keeps me close to the problems the team actually deals with, and it makes my conversations with engineers better. When someone brings me a hard problem, I want enough depth to understand it, ask useful questions and recognise when I need to get more involved.
But being technically involved is not the same as doing everything yourself. Most of what I’ve learned about leading comes from that difference.
Ask where it breaks before you look
Say an engineer tells me, “The application is sending traces, but nothing shows up in the backend.” I could open the Collector config and start reading. These days my first question is usually: “Where do you think the telemetry stops?”
That question changes the conversation. We walk the path together, from the application over OTLP to the Collector’s receiver, through its processors and exporter, and finally into the backend. Then we check each step:
- Is the application producing telemetry at all?
- Can it reach the Collector?
- Is the receiver listening, and is it actually part of a pipeline?
- Are the processors changing or dropping the data?
- Is the exporter succeeding?
- Is the backend accepting what it receives?
It’s the same approach the OpenTelemetry project recommends in its Collector troubleshooting guide: check each hop on its own instead of debugging the whole pipeline at once. I wrote up the failures I run into most often in OpenTelemetry Collector Troubleshooting: 15 Common Problems and How to Fix Them.
The point isn’t for me to produce the answer. It’s for the engineer to learn how to find it, because that skill stays with them long after this particular bug is gone.
Sometimes you should just give the answer
There’s another side to this. Leading doesn’t mean answering every question with another question. If a customer is waiting, production is down, or time matters more than learning, step in and give clear direction. That isn’t bad mentoring. It’s judgment.
The question I try to ask is what this person and this situation need right now. Sometimes it’s the answer. Sometimes it’s a nudge in the right direction. Sometimes they just need someone to listen, and sometimes they need someone to push back on their thinking. Telling those apart is a big part of the job.
Turn escalations into learning
Escalations are stressful. There’s a customer waiting, the information is incomplete, there’s pressure to respond, and there’s a pile of technical detail to work through. Once the immediate problem is under control, I like to ask one more question: what can the team learn from this?
Take a Collector that stopped exporting data. The fix might have been an endpoint, credentials, a TLS certificate, a processor setting or a network rule. The bigger opportunity is in the follow-up. Why did we look in the wrong place first? What evidence would have got us there faster? What should we check first next time? Can we write the investigation down so someone else can follow the same path?
Often the answer is better habits and tooling for the next person. The Collector exposes its own internal telemetry, and the debug exporter shows whether data is being received and processed. If the team knows to reach for those early, the next incident is shorter.
The fix solves today’s problem. What the team learns from it can prevent the next one, and that’s where a lead gets real leverage.
Delegation means handing over decisions
Delegation is easy to get wrong. It isn’t “you take this ticket.” Real delegation gives someone enough context and ownership to make decisions. Before I hand something over, I try to make sure we’ve covered:
- What we’re trying to achieve, and why it matters.
- Which decisions are theirs to make.
- When they should pull me in.
- What a good outcome looks like.
If I hand someone the work but keep making every decision for them, I haven’t delegated anything. I’ve just created a different kind of dependency. The goal is to move decisions steadily closer to the person doing the work.
You don’t need to be the smartest person in the room
A strong team doesn’t need one person who knows everything. It needs people with different strengths. One engineer knows Elasticsearch inside out, another is deep in Kubernetes, someone else is great with customers, and another loves digging into application performance.
My role isn’t to make everyone work the way I do. It’s to help each person get better at what they’re good at while raising the technical bar for the whole team. In practice that means giving people hard problems, letting them make real decisions, giving honest feedback, noticing when they improve, and being there when they genuinely need help.
Empathy doesn’t mean lowering the bar
This one matters to me. Being supportive doesn’t mean accepting weak technical work. If a solution is fragile, we should say so. If the documentation is unclear, we fix it. If the same problem keeps coming back, we find out why. If a decision adds security or reliability risk, we challenge it.
People should feel safe asking questions and admitting mistakes. They should also know what good looks like. Empathy and accountability aren’t opposites, and good teams need both.
Being available isn’t the same as leading well
A lead should be easy to reach. But if every time someone asks “What should I do?” I hand them the answer, I’m making myself necessary instead of making them stronger.
Often the more useful reply is a question. What have you checked so far? What does the evidence tell you? What do you think is happening? What would you test next? It takes a little longer in the moment, but it builds the habit of independent thinking, and that’s one of the most valuable things an engineer can develop.
Staying close to technology keeps leadership grounded
Our field moves fast. OpenTelemetry keeps evolving, AI agents are changing how applications are built, MCP is creating new patterns between models and tools, and systems keep getting more distributed. A technical lead doesn’t need to be an expert in all of it. You do need to stay curious enough to ask good questions, weigh trade-offs, support your engineers and make informed decisions. That’s a big part of why I keep building things and writing about them.
Writing has changed how I lead
Writing technical articles has turned out to be good leadership practice. When you try to explain something clearly, you find out quickly whether you really understand it.
Writing up Collector troubleshooting is a good example. It’s tempting to jump straight into config changes. Writing it down forces a slower set of questions: where does the data start, where does it go, what happens to it on the way, where can it fail, and how do we prove where it failed? That’s the same thinking I try to bring to mentoring. An article can help someone fix a problem today. A good mentoring conversation can help them fix similar problems for years. Both are worth doing.
How I measure impact now
I used to measure my impact mostly by the problems I solved. Now I look at other things too. Did an engineer become more confident? Did someone take ownership of a hard problem? Did the team learn something from an escalation? Did we improve a process? Did someone solve a problem on their own that would have needed me six months ago?
These are harder to measure, but they compound. One engineer gets stronger, helps someone else, and the whole team moves up.
There’s no perfect balance
I don’t think technical leadership has a formula. Some days need deep technical work. Others are about mentoring, planning, coordination, or simply being available. Sometimes you step forward, and sometimes the best thing you can do is step back. What matters is knowing why you’re doing either.
I use two checks on myself. If I’m solving every hard problem, am I creating dependency? If I’ve drifted far from the technology, am I losing touch with what the team deals with every day? The balance sits somewhere in between: close enough to the technology to stay credible and curious, with enough space left for people to grow.
What I’m still learning
I haven’t figured this out. There are conversations I could have handled better, work I should have delegated earlier, times I stepped in too fast, and times I probably should have stepped in sooner. That’s part of it. Leadership isn’t a fixed playbook. It’s learning to read what the team needs and adjusting.
The real shift
Moving from a strong individual contributor to a technical lead isn’t about becoming less technical. It’s about changing how that technical knowledge creates value. I used to solve the problem. Now I want to help someone else solve it, and over time build a team that can take on harder problems together than any of us could alone.
You can also read this article on Medium.
Connect with me on LinkedIn.
Related articles:
Leave a Reply