Code and problem-solving are the most valuable skills for a developer.

The current standard career progression in tech looks something like this: Junior --> Senior --> Tech Lead --> Staff Engineer (that's obviously an oversimplification, bear with me). The Tech Lead and Staff Engineer types of positions are "more technical" as compared to moving into people management -- a way for people to continue advancing their career while retaining and leaning on technical skill.

Unfortunately, a common issue once you hit Tech Lead level: you spend more time architecting tickets, sitting in meetings, and directing others. The time you spend writing code and directly hands-on solving problems falls off a cliff. I can't speak to Staff Engineer levels -- but it seems sort of similar, at least in terms of very high-level architecture and dictating which practices align best with the company mission and goals.

True for my experience upon promotion into a tech lead sort of role. I was spending more time thinking about how to do a ticket and writing out the ticket, reviewing code, speaking with stakeholders and project managers -- much more time than coding and problem-solving. I felt my technical skills starting to rot, and saw the long-term writing on the wall as either being forced further into non-technical work or just being unable to compete and keep up with advancements in tech, code, etc.

Part of this is absolutely necessary, as -- when you sit more time in meetings and can be interrupted at any time by an urgent request or high-level emergency -- your ability to dedicate heads-down, hands-on code time suffers, and you can wind up delaying big feature tickets if you take them on yourself. Actually delegating out the work seems necessary to keep things moving. I avoided taking on larger tickets because I just knew, from the flow of my day, I'd wind up dragging them out and less able to dedicate the initial big chunk of time to them, as well as less able to walk the tickets through any code review and quality assurance bouncebacks.

This is often brushed off as a natural progression. "Soft skills and people skills are more important than code and problem-solving skills" is the common refrain. "As you move along in your career, you'll spend less and less time in the code editor, and more time force-muiltiplying others on your team."

I have some questions about those ideas...

How do you force multiply others if you don't write code? How do you help make others better if you become disconnected from the code and technical problem-solving? How do you keep your ability to architect, direct, and make things good from a high level, if you do not code anymore and your technical skills deteriorate? Does it actually and consistently work to remain at a lofty academic level, dictating downward, without reality-checking your assumptions and real-world testing your proposed problem solutions?

The core most valuable skill for a developer is and remains the ability to code and problem-solve. Those technical leadership skills may be layered on top of this base skill... but the core remains the same regardless of location in career progression pathways.

Good technical leadership requires that you remain technical. You cannot spend 90% of your day making slide decks, talking in meetings, attending conferences, delicately handling the team -- and maintaining true technical competency. Your skills will rapidly atrophy and become based entirely in the realm of theory (or outdated information) -- not actual practice and boots-on-the-ground experience. Skills atrophy when you don't use them -- "use it or lose it" is a common refrain for a reason.

Even coding outside of work doesn't fix this: the problem set you face outside of work is often completely different, and at a completely different scale. And we're politely looking past the absurdity of expecting people who work 40 hours a week to dedicate even more time to skill-building -- that's an above-and-beyond. For it to be intrinsic to the industry, baked into the process -- well, reality's calling.

Why?

The soft skill focus and shunting people into the Tech Lead and Staff Engineer types of roles are a sort of corporate cope. Technical, code-focused people are expected to fill the gap created by the fact that there are almost no strongly technical project managers in the industry. To clarify that a bit, "technical project manager" meaning a project manager who has a decent enough grasp on the client's business needs and what is technically feasible given their budget, timelines, and the developers involved in the project. A project manager deeply skilled in the arcane arts of moving tickets across a Jira board is not required.

To be perfectly frank and provide examples, I work with project managers who don't know that "it's broken" alongside a crappy screenshot from a client is insufficient information to troubleshoot a problem. They don't realize they should (without asking a developer first) push back on that kind of bug report and ask for more information on their own initative. Another example of a project manager lacking in technical skill, swapping out one icon for another icon should not raise questions about whether the site is still responsive after this change.

These examples are not deeply technical things that require some kind of arcane knowledge; they are pretty barebones basic aspects of the job. To me, these examples are like having a project manager of a building project asking if it's possible to make the walls out of sand, or a project manager of a new car build wanting to know if a different type of horn will increase fuel efficiency.

It's just not possible to do a good job with that kind of knowledge at the helm and leaves a massive gap that tech leads (particularly tech leads) and staff engineers have to fill to ensure project success.

In the current-era, project managers don't know the most basic aspects of development, and so (naturally) mostly focus on making sure ticket statuses are appropriately updated, spreadsheets are filled, boxes are ticked, meetings are created, and other such minutiae that doesn't significantly advance projects forward. Meetings and aligning stakeholders is certainly useful, to a point -- but most project managers fall short beyond that.

Project management work is absolutely necessary to move any sufficiently large project forward. That's why we have project managers to begin with. Or, it should be why, anyway.

Sort of a quietly vicious cycle: project managers aren't good at the technical parts and aren't required to learn, so tech leads and staff engineers step in to fill the gap, so over time tech leads and staff engineers experience technical skill rot, and wind up essentially as glorified (and very good, granted) project managers.

What to Do?

What to do about it? Well, industry-wide -- I have no idea. The problem does seem to be rooted in the lack of technical project management skill. That pervasive industry-level issue seems a bit above my paygrade.

On an individual level, I'd probably recommend remaining in a less code oriented role for only brief amounts of time. At the first sign of skill atrophy, get back into the editor by any means necessary, even if that involves finding another role and organization entirely. Tech moves incredibly quickly -- three years in a Tech Lead role where you code only 10% of your time at work will close many doors and degrade many skills. If you wish to prioritize your actual long-term career and employability, stay in the editor and out of the Jira boards and meetings.