"I'm nowhere near as good technically as the senior devs in my team."

I hear this repeatedly from many of the technical leaders I work with.

But let's dig in a little...

"Our team performs well because I lean on my senior devs for execution, and they lean on me to make sure they get whatever they need."

OK, so you're definitely performing a useful purpose?

"I understand the business logic, dependencies of upcoming projects, can do T Shirt sizing alone and I run technical analysis meetings just fine since I understand everything high level."

Yes! You're doing a great job, right? But...

"I'm scared to death that my tech skills are stagnating, and eventually I'll lose the respect or ability to lead seasoned devs."

Ah, here's the rub. You're supposed to be leading them, right? And you're a technical leader, so you should have better technical chops than them? You should know more than them at all times?

Aren't I supposed to be the cleverest in the room?

But hang on a minute. How is that even possible? How can you be doing all the leadership stuff you need to do, the meetings, the prioritisation, the organisation, preventing any office politics from affecting your devs, being the technical interface with stakeholders, the analysis... AND stay technically ahead of the devs who are spending far more time than you are, on a daily basis, close to the metal and where the technological detail is most in evidence?

Short answer: You can't.

But don't lose hope. There are things you can do, and if you perform this one simple action I'm about to explain, you can make a huge difference.

The secret is to spend time side by side with your devs as they work on your product. They know many of the ins and outs of the product better than you do. And if you accept this, embrace this, you can make it work in everyone's favour.

Spend time pairing with your developers

This does NOT mean breathing down their necks every hour of the day. We've already established you don't have time for that. This can be a light touch activity. It can last for only an hour or two. It can happen once a week, once a fortnight or once a month. It can be a different dev every time. The key is that you make the most of what they know.

Get them to explain the details they know, but at a level that makes sense to you. Ask questions when necessary, either to deepen your knowledge or encourage them to zoom out a little. The great thing about this is, not only do you learn more and stay close to what's happening, they get to strengthen their ability to summarise, to take a bird's eye view, to explain what they're doing to someone else. This is great for them, not only because this is a hugely useful skill, but because it shows that you respect them, that you value their input, that the time they spend with the product is useful. Because if you have your insecurities, you can bet they'll have their own, no matter how hidden they might be.

This may not be a pure pairing session. The details are up to you. If you do it frequently enough, you may be able to play an equal role in a pairing session. That level of equal pairing might happen only sometimes, depending on the detail of the product and the developer. Your main goals are to deepen your understanding, and to level up the respect and confidence of all team members.

And remember: Handled without apology, this exercise will deepen your team members' respect for you, rather than the other way around. But more on that in another post.

Want to talk this through in more detail? Join the workshop!

In June and July '25 in the UK, I'll be running workshops at LDX3 and Agile on the Beach, around How to deal with the “technical” in “technical leadership”. Click here for more info.

LDX3 countdown:

​

🔗 Want to share this article or save it for later? Here's a handy link for you!​