> A (really) good dev will recognise where strategic framework falls short or is non-existent and will be able to find a way to fix it. He will know that he needs to build trust and budget it to get the really important stuff done. For a good tech lead this is significant part of engagement as there is typically no other very technical person that would be better positioned to do it.

This comes with some serious caveats. On an operational level, it is never your responsibility to "fix the strategic framework where it falls short". You're not expected to, nor are you incentivized to do that and you certainly don't have the authority to do it.

For instance, if you get inundated with deadlines and unreasonable requests, there's a handful of ways you could respond. You could go into crunch time / overtime until you burn out. You could draft a list of priorities and suggestions of a manageable workload and send it upstairs. You could even suggest reorganizing or expanding the team.

However, you can't hire someone new yourself, you can't ignore planning or requests, you can't decide from one side what kind of value the team is going to deliver. Why? Because you are subordinate to the authority of management on an operational level.

If you feel that shortcomings in the strategy of your employer impacts your work to the extent that what you do on a day to day basis doesn't align anymore with your views on how you want to contribute, well, that's a red flag.

> As a tech lead, for example, I am in a constant battle against complexity.

That's par for the course. On a fundamental level, you don't stand on equal footing with management. You can hope that your suggestions will be incorporated in the overarching strategy, but don't have the authority to actually make it so. At best, you may play your cards right and gain enough clout to exert influence from the sidelines.

That changes when you move into management.

As a manager, you will sign off on the solutions that needs to be build. You're accountable for the definition of the high-level requirements of a product / service, how it fits with available budget, how it matches with the envisioned value its going to provide to stakeholders. You might collaborate with experts in interaction design and design thinking to help guide this big-picture process. Depending on how much responsibility you're allotted, you may even have the authority to hire staff, organize teams, come up with your own projects and strategies and so on.

Being able to draw from your experience with the overall process of software development may help you in your estimations and the outcomes ahead. However, the usefulness of deep technical knowledge on a managerial level is very limited. As manager, the one thing you can't do is apply that knowledge directly on a day to day basis. That's where you are expected to delegate towards the team you're managing.

Indeed, having experience as a developer can even be disadvantageous. Your inherently biased towards particular tools and solutions and stepping back from them can be surprisingly hard. You also can't be overly sympathetic to the particular challenges faced by the development team. As an erstwhile developer, you might acutely relate to the pain of dealing with legacy and technical debt. But as a manager, you'll quickly find that you just can't afford addressing those as priority without potentially negatively impacting overarching goals, interests, budgets and so on.

One of the biggest challenges you will face is to unlearn to purely think from the perspective of a developer in the trenches.

Whether you like it or not, over the course of time, your technical knowledge will grow stale as technological progress replaces today's programming languages, IDE's, database systems, etc. If you keep on the managerial track, inevitably, there will come a day when you find yourself in a meeting with the next generation of developers and you can't readily bridge the gap between your and their technical expertise / perspective / knowledge.

That's not necessarily a bad thing, but you have to be mindful that becoming a manager implies that you're not a developer / craftsman anymore.