​

"I'm worried my current position only works at my current company. I moved up fast because soft skills come naturally for me. I prevent any office politics from affecting my devs, and they have the freedom of implementation at an execution level. But ask me to implement code for multi-threading? I am starting from 0."

You are not alone

When I'm running workshops with technical leadership, I see concerns like these raised repeatedly. People who started out as engineers and were promoted into leadership, have developed their soft skills and become great at all the wrangling required to create a great environment for their developers to get on with the work. But they're finding themselves with less and less time to do any hands on software development, and this makes them angsty.

"I'm scared to death I'll make it through the interviews, arrive in a team with senior devs and suddenly what worked at my current company won't work anymore."

What if your new team expect you to have tech skills even stronger than theirs? What if they don't respect you because you don't understand what they're talking about? What if you go for interviews and fail the technical challenges? What if you're laughed out of the room?

Fear and insecurity are your enemies

As is often the case, fear and insecurity are your enemies. But there is one simple thing you can do to get your brain weasels to stop chattering their nonsense in your ear and settle back into the corner for a nice little nap.

Because the fact is, your skills have grown since you started this role, not diminished. That voice in your head that says "But all I do is attend meetings and shield the real experts from all the bullshit side quests" needs to be reminded that attending those meetings is hard. Your devs aren't doing what you're doing because they wouldn't find it easy, any more than you would find what they're doing easy. Teams are made of contributors, each bringing their strengths and skills, each doing different work, each part combining to a glorious effective whole.

One small trick

So here's the trick, and like all good tricks it's simple even if it isn't always easy...

Identify your strengths and contributions.

Sit down and make a list. What have you achieved in this role? What have your devs achieved, that they wouldn't if you hadn't been there, to pave the way and shield them from the bullshit? What have you brokered, in all those meetings with other leaders and departments?

If you struggle with this task, get others to help. Ask your devs, what have you helped them to achieve? Ask your peers, what have you collaborated to achieve? And ask your manager(s), what have they appreciated that you do?

Once you have that list, try typing some of the items into LinkedIn, or into some job sites. What roles come up? How many people are looking for exactly those skills and contributions?

Yeah, sure, there are Tech Lead roles out there that ask for hands-on contributors. But honestly? You probably don't want those jobs. In the vast majority of companies, even if they say they want hands-on technical leaders, they don't provide the conditions necessary to make this a reality. The extra work required from a good leader necessitates time away from the code. The good jobs will recognise this and celebrate all the other amazing skills you've acquired since you took on a leadership role.

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!​