I've had a bunch of different roles through the years. From programmer at the bottom of the totem pole to being CEO or CTO in my own company and having my own department in a large corporation. The perspective in these different roles tend to be very different and I have learned a lot in each of these roles.
Being at the bottom of the totem pole is the easiest job of the bunch. Your focus is gloriously narrow and straight forward: deliver value within some set of constraints and try to enjoy yourself.
Being a leader in charge of people who deliver value is a lot more complex. Especially if you have experience being one of those who you are tasked to lead. You remember what it was like being them, but now you have a wider range of concerns to balance. Yes, there's delivering value, but you also have to take care of your employees, investors and customers. And these concerns will come into conflict with each other.
I've spent a lot of time evaluating companies, products, codebases, practices, leaders, developers etc during technical due diligence projects. This has also been a great learning experience to me: the chance to get an intimate glimpse of other people's shops without having to work there.
I can recommend doing this kind of work because it is easier to see clearly what is going on when you are not part of it.
A lot of problems tend to stem from imbalances. For instance, sometimes I come across companies with problematic leaders who "rule" their fiefdoms rather than involve the people working for them in decisions. I also sometimes see the opposite: a breakdown in discipline where developers lack direction and everyone does their own thing - either because there is nobody to lead them or because developers can't take direction.
It isn't uncommon for investors to require companies to replace managers that perform poorly before investing in companies. It is less common to require the removal of problematic developers. Quite possibly because tech DD processes often aren't thorough enough to discover what goes on in the bowels of the beast.
I've actually written tech DD reports where I've made both types of recommendations: both recommending getting rid of bad leadership (which is usually an easy recommendation to make), and I've had cases where I have concluded that sometimes entire software teams need to be restructured. In the latter case it is devilishly hard to actually come up with recommendations for how you fix broken teams.
In the corporate world (of large companies) these things are harder because you will encounter more ineffective middle managers (and layers thereof) and quite often, that more senior management have their positions not on merit, but due to political games. To make positive change in large corporations is harder. But it can be done. However it will fail 100% of the time if one resigns oneself to "I'm just a minion - I have no power".
From personal experience though: it is hard to make change from the bottom without somehow disappearing into management. Corporate cultures tend to assume that only certain types of "officer class employees" can make decisions. (Which is how I wound up as a programmer in a large corporation with a VP title. Yes, it was confusing and weird)
Nicely put. I also spent decades in the SW industry, tried about a dozen things, but chose to stay out of management. For me, business and engineering are two completely different areas, often conflicting, and my training is extensively in math and engineering. Trying to do both ends up with mediocrity almost certainly.
Being at the bottom of the totem pole is the easiest job of the bunch. Your focus is gloriously narrow and straight forward: deliver value within some set of constraints and try to enjoy yourself.
Being a leader in charge of people who deliver value is a lot more complex. Especially if you have experience being one of those who you are tasked to lead. You remember what it was like being them, but now you have a wider range of concerns to balance. Yes, there's delivering value, but you also have to take care of your employees, investors and customers. And these concerns will come into conflict with each other.
I've spent a lot of time evaluating companies, products, codebases, practices, leaders, developers etc during technical due diligence projects. This has also been a great learning experience to me: the chance to get an intimate glimpse of other people's shops without having to work there.
I can recommend doing this kind of work because it is easier to see clearly what is going on when you are not part of it.
A lot of problems tend to stem from imbalances. For instance, sometimes I come across companies with problematic leaders who "rule" their fiefdoms rather than involve the people working for them in decisions. I also sometimes see the opposite: a breakdown in discipline where developers lack direction and everyone does their own thing - either because there is nobody to lead them or because developers can't take direction.
It isn't uncommon for investors to require companies to replace managers that perform poorly before investing in companies. It is less common to require the removal of problematic developers. Quite possibly because tech DD processes often aren't thorough enough to discover what goes on in the bowels of the beast.
I've actually written tech DD reports where I've made both types of recommendations: both recommending getting rid of bad leadership (which is usually an easy recommendation to make), and I've had cases where I have concluded that sometimes entire software teams need to be restructured. In the latter case it is devilishly hard to actually come up with recommendations for how you fix broken teams.
In the corporate world (of large companies) these things are harder because you will encounter more ineffective middle managers (and layers thereof) and quite often, that more senior management have their positions not on merit, but due to political games. To make positive change in large corporations is harder. But it can be done. However it will fail 100% of the time if one resigns oneself to "I'm just a minion - I have no power".
From personal experience though: it is hard to make change from the bottom without somehow disappearing into management. Corporate cultures tend to assume that only certain types of "officer class employees" can make decisions. (Which is how I wound up as a programmer in a large corporation with a VP title. Yes, it was confusing and weird)