I’m proud of what I’ve built. Proud of the teams I’ve led. Proud of how people have grown under my watch.
But if I’m being honest, there’s one thing I wish I did better: I wish I stayed closer to the code.
It wasn’t a conscious decision. It was gradual, then sudden.
When I moved from Team Lead to Software Development Manager, I noticed the first signs. I wasn’t in the weeds anymore. But it wasn’t until I became Head of Development that the shift really hit. The day-to-day engineering work didn’t just slow down for me. It stopped.
Sure, I still helped with hotfixes and took on the occasional side project. But real, hands-on technical fluency? That quietly faded.
At the time, I didn’t notice. There was always something to focus on: planning, prioritization, team dynamics, hiring, stakeholder alignment. And all of it made me feel like I was growing. There was momentum, visibility, the rush of solving people problems and scaling systems. It felt like progress. I didn’t need to write code, I was empowering others to do it.
I gave away the shiny projects, thinking I was being generous. “Let them shine,” I told myself. “They couldn’t do it without me.”
But here’s the truth: the industry doesn’t reward the person who made space. It rewards the person who shipped it. The eyes of the organization don’t trace lineage, they see outcomes.
At first, it didn’t bother me. I felt powerful. I was the boss. And the boss doesn’t have time to work on tickets.
Then one day, in a meeting, someone said they go to one of my reports because they’re “more technical than me.”
It stung. Not because it was insulting, but because it was true.
My first reaction? Defensiveness. What are they talking about? I’m incredibly technical.
But I mulled it over. And I had to admit they were right. I’m not anymore.
You want to talk about management? Vision? Organizational design? I got that in spades.
But ask me to architect a modern solution from scratch? Not without Google. Not without second-guessing myself. Not like I used to.
That hurt. Not just because I felt out of date, but because I built my career on being technical. On being good at this.
These days, I rely on my tech leads. I ask the strategic questions: ARR, ROI, break-even timelines, KPIs, monitoring, trade-offs. I them align the work to the business. I pressure-test the outcomes.
But I don’t think about the solutions themselves anymore. And that gap, that distance, is starting to cost me.
Rebuilding fluency hasn’t been easy.
When you’re young and single, learning is easy. Nights and weekends are yours. Now? I have a wife. A daughter. A life. Late-night tutorials come after bedtime routines, dishes, and whatever energy I have left.
And the real kicker? I don’t even love it like I used to. It feels like obligation. Like a thing I have to do to stay relevant.
That’s the hardest part.
Because I’m not chasing passion. I’m chasing competence.
Not to prove something to the world. Just to not fall behind.
That realization reframed everything. I’m not trying to be a Staff Engineer again. I’m trying to be a leader who can actually follow the architecture conversations, sense when something doesn’t add up, and see beyond the diagrams.
I don’t need to be the best engineer in the room. But I do need to be dangerous enough to ask better questions.
That tension, between knowing what you love and knowing what you need, stays with me. It’s what I’d pass on if you’re earlier in your leadership journey: stay close to the work.
Not every day. Not every sprint. But enough to keep your instincts sharp. That might mean carving out a few hours a week to shadow tech reviews, dig into a codebase, or build something scrappy just to feel the friction again.
Because in tech, strategic judgment without technical fluency eventually becomes theater.
And when the pressure’s on, the audience notices.