5 ms·

I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an enviro

I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an environment with very different incentives, interpersonal relationships and so on. As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control. That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road. Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick. At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word. So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC. Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent. However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.

throwawaybutwhy 5y ago
> At this level, the people you're going to work with don't care how the pie is being made. Hear, hear... oh. Here be dragons. A manager at each rung of the ladder who doesn't have insight into the technical constraints will over-promise and embellish things, and the least technically capable will do it with the greatest zeal. And the grunts will be left with an impossible task of storming a well-protected fort with inadequate support.
lmilcin 5y ago
> As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control. 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. As a tech lead, for example, I am in a constant battle against complexity. Managers want to only add functionality, developers want to only add technology, and I try make people aware of how this ends if it is not supplemented with hefty effort to manage complexity. And this ideally ends in significant contribution to strategy if I can succeed or, if I can't, with inevitable problems later. > At this level, the people you're going to work with don't care how the pie is being made. They might not, but that does not mean that how the pie is made isn't influencing the outcome. A manager that has significant experience with development knows how the pie is made and can be very valuable if he is able to use that knowledge for better outcomes. There is of course risk that the knowledge is misused (like people using certain solutions just because they are familiar with them and not because they are right for the particular situation).
- CaptArmchair 5y ago
  > 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.

throwawaybutwhy 5y ago

> At this level, the people you're going to work with don't care how the pie is being made. Hear, hear... oh. Here be dragons. A manager at each rung of the ladder who doesn't have insight into the technical constraints will over-promise and embellish things, and the least technically capable will do it with the greatest zeal. And the grunts will be left with an impossible task of storming a well-protected fort with inadequate support.

lmilcin 5y ago

> As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control. 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. As a tech lead, for example, I am in a constant battle against complexity. Managers want to only add functionality, developers want to only add technology, and I try make people aware of how this ends if it is not supplemented with hefty effort to manage complexity. And this ideally ends in significant contribution to strategy if I can succeed or, if I can't, with inevitable problems later. > At this level, the people you're going to work with don't care how the pie is being made. They might not, but that does not mean that how the pie is made isn't influencing the outcome. A manager that has significant experience with development knows how the pie is made and can be very valuable if he is able to use that knowledge for better outcomes. There is of course risk that the knowledge is misused (like people using certain solutions just because they are familiar with them and not because they are right for the particular situation).

CaptArmchair 5y ago
> 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.