The fear of letting go of software development

Question

Have been doing software development, coding and integration for the last 10 years. My company is now offering me a lead position of a development team. As a technical lead here, the way it works is we lead the team closely but with other responsibility (meeting with customers, project management, etc.) and leads don't do the hands-on work, coding, etc.

After doing a pros and cons list, it turns out at this point, I would actually enjoy the dynamic nature of the lead role more.

However, that means I really will be letting go of the hands on coding, etc. and this realistically means the skills will gradually fade. This is actually causing me fear, second guessing, etc.

Ideally would love to have a side project to keep the skills up but with full working days and family obligations, it won't happen.

Any advice for letting go, how others may have navigated this and any other things to consider ?

---1.5 YEAR UPDATE---

For me (where I am in life, personality, how I would like to be in the world, financials, etc.) this has worked out very well, enjoy it much and am able to lead/serve a team well. It really all is a journey and we are all so susceptible to career tunnel vision.

I also see that doing things out of fear, approval, accolades (vs. inner alignment) is not helpful except to the executives bottom line (if you have the opportunity to do so of course).

Thanks all for your help and who knows what can evolve in the future for anyone! Stay healthy and free.

Answer 1

I'm not in software development, but I've encountered similar challenges in my field.

It's one thing to supervise somebody in an area which you know well - "if Bob was sick tomorrow, I could take over his job, and do it better than him". It's quite another when you move far enough up that you can't be across all the technical minutiae, for the kinds of reasons that you mention.

It might be helpful to think of it as not so much "letting go" as "increasing abstraction".

When you're writing a simple program, you might code the whole thing yourself; you might understand what every single part of the program does and how it works. But past a certain level of complexity, that becomes inefficient and unsustainable. If I want to invert a matrix, I could code that myself, but it makes more sense to use a numerical library that somebody else has already written. If I want to use weather data, rather than trying to build my own weather station and link it into my code, I'm probably better off figuring out how to use an API to get that from some external source.

As a developer, you've probably spent a lot of time learning how and when to do that abstraction. Probably a lot of your work is not in coding new stuff from scratch, but figuring out how to assemble components that abstract away the messy details, so that you don't have to cram an impossible amount of detail into your brain and do an unreasonable amount of work.

Moving into technical leadership is a bit like that, IME - but instead of abstraction via code libraries and APIs and modules, you're trying to achieve abstraction via delegating people.

Impostor syndrome is a big risk here. One of the most popular tropes in office culture is the idea that managers are ignoramuses, and when you're used to measuring yourself by technical proficiency, it's easy to feel like you're becoming that stereotype. So you need to find new, more relevant metrics of success, which mostly boil down to "am I helping my team do their job?"

When you're delegating work well, and each member of the team knows what their job is, you may find that being on top of the technical micro-detail isn't important as it once was. The small stuff goes rusty quickly with disuse, but a lot of the higher-level skills remain. Now and then I've been able to debug other people's code over the phone, in languages I've never learned, just by drawing on my experience of the kinds of things that often go wrong and the kinds of methods that are effective for identifying them. ("What did you change?" "Why don't you run it up to this point and check whether the problem is before or after that step in the program?" etc. etc.

I know that's a bit rambling, but maybe there's something in there you can use.

Answer 2

Preface: I've been on software development for 23 years and have taken on lead/management roles and are currently employed as an IC Principal Developer.

Letting go is exactly what you need to do as your description would indicate that you're moving into a completely different job family. Although the title may say lead, what you will in fact be doing is managing a team. Customer engagement, project management, delivery management and presumably people management is a completely different skillset, and this what your day would be take up with.

As much as the fundamentals are important in development, you will fall behind and your ability to contribute to design/discussions etc. will diminish - this is something you're just going to have to accept if you take up this role. We all know that working in software means lifelong learning and that tech marches on at a staggering pace, and unless you're managing to keep up elsewhere, you're gonna fall behind. There will come a time, maybe not for a few years, that what you know is outdated.

I know plenty of developers who have transitioned to a management role and really enjoy it. It brings a fresh set of challenges and opens up a whole new career ladder for you. It used to be the case that this was the only way to advance your career, but companies are realising that plenty of developers want to remain technical but still require advancement and have a lot to offer in the wider organisation.

Given that you're unsure - one option you could suggest to your employer is a probationary/transition period. Try it out for 3-6 months and reevaluate - if you're not enjoying it (or you're not good at it), go back to your previous position.

Answer 3

leads don't do the hands-on work, coding, etc.

Is this a "rule", or just the way things are with existing leads?

Perhaps you can still allocate a little time each week for more hands-on activities? Fix some bugs, refactor existing code, own a lower-priority feature.

It will help you to keep your technical edge (at least to an extent), and could even help you in your leadership role.

Answer 4

It depends where you see yourself in the future. This is a stepping stone role into management type roles, or a dead end. You're absolutely right that you lose the edge once you're off the coal face. But you gain skills and experience to move up the ladder in other ways and coding becomes a part of your skillset rather than all of it. Once you progress in these sorts of roles, you don't need the cutting edge, you need a solid grasp of the fundamentals and a bigger picture of how things work.

If you don't see yourself progressing up that career tree then you're better off being the best coder there is until you are sure where you want to end up.

Answer 5

It is a natural order of things for professional, well rounded people

Lead role is usually extremely satisfying and engaging. IMHO, what you referring to is a horizon expansion (big picture :) ), that naturally comes with more authority.

You should ne fear "loosing" the coding skills, sorry to say it stays with us forever. and getting it back, or learning a new development environment is not very hard.

In any case, nothing is stopping you from carving a bit of coding time for yourself in tickets allocation system

Even better you will get to cherry-pick what you like :)