If you want a better analogy that doesn't belittle senior leadership, try Go instead of Checkers.
One of the keys to successful management and leadership is understanding sustainability. Incremental changes over a period of time beat a huge lift followed by burnout and stasis.
A senior leader wouldn’t be caught dead holding the same position for more than 18 months. The whole game is to make a huge lift, collect the monetary and prestige rewards, and move on to the next thing before burnout becomes apparent.
Sustainability is the domain of entrenched/ossified/bureaucratic middle managers, moderating or outright sabotaging whatever BS senior leadership is excited about this month.
I actually think current "leadership" is on its way to being extinct. It will be replaced by algorithms and best practices, along with better tools. If you're not contributing to code, there will be very little room for them in the software company of the future. The concepts that non-technical leaders have to learn are trivial compared to the advanced techniques of software development.
If leading people is so goddamn easy compared to software engineering, why do so few engineers want to move into people leadership, and why do so many of them absolutely suck at it?
I think you are severely discounting the skills it takes to lead people, and you are also making an extremely optimistic assumption that companies in the future somehow would be magically more meritocratic than existing companies, when there's no evidence of the sort. On the contrary, people with great interpersonal skills will continue to advance off of the labour of the people with only great technical skill.
Your glorious engineer's revolution will probably not come to pass if history is any indication.
Maybe I should have clarified, but leadership will have to be an additional requirement on top of knowing how to develop. If you look at the history of software development in enterprise, software developers have increasingly had to work multiple overlapping roles, the more recent of which, in my experience, is making developers be testers as well. It used be QA was a separate role, but now it has evaporated because there are so many tools surrounding this discipline that require knowing how to code, so exclusive testing roles are not favored as much anymore. I don't how many years from now this is, but I really believe that everyone will have to know how to code to a great extent in order to use the software tools of the discipline.
If you look at the history of software development in enterprise, somehow, engineers never seem to be rewarded according to their actual contribution to the bottom line.
Somehow, the managerial class and the investor class insert themselves between the fruits of the labour and the engineers performing said labour. And if you think that's suddenly going to stop because the nature of the labour changes, then I think you're mistaken.
Enterprise structures rewards rent-seekers, because they are built by, and controlled by rent-seekers, utilizing disposable labour. The only way a power structure like that can be flipped, is through revolution. Or by forming your own company, out-competing these enterprises.
That's an interesting point. I worked in QA for years and was out of the country for a few years. When I returned my old role (QA and process development/project management) didn't exist. The industry had moved on and those roles were handled by SDET/automation engineers and product managers respectively. I had to do a bit of retooling of my skillset.
Every QA person I've worked with that is still in the industry has moved on to almost pure test automation. A few years ago that was more like 30% of the role. Now I rarely do almost any manually testing, except for exploratory purposes and to design the test plan. Also for certain things that don't automate well. These days I do more pure development than I have at any other point in my career. It's been super fun, but still quite a change. I've seen colleagues that were more the business analyst flavor of QA get pushed out of the industry when they couldn't/wouldn't adapt.
I don't disagree with you about leadership being hard. But the argument you use to get there is easily rebuttable:
> If leading people is so goddamn easy compared to software engineering, why do so few engineers want to move into people leadership,
a) because they wouldn't enjoy it as much as their current job?
b) because for engineers, being a manager does not give them status amongst their peer group.
> and why do so many of them absolutely suck at it?
a) citation needed. Is it provable that engineers are particularly worse at leadership than the rest of the population per capita?
b) if engineers tend to suck at being managers, it doesn't show that managerial roles are harder than engineering ones. How good are managers at attempting engineering roles, for comparison?
"b) because for engineers, being a manager does not give them status amongst their peer group."
I am so reminded of Brave New World...
"Alpha children wear grey. They work much harder than we do, because they're so frightfully clever. I'm awfully glad I'm a Beta, because I don't work so hard. And then we are much better than the Gammas and Deltas. Gammas are stupid. They all wear green, and Delta children wear khaki...I'm so glad I'm a Beta"
You are an optimist in a way. What you seem to be forgetting is that the leadership does make the decisions. What do you think are the odds of making a decision hurting their bottom line? It is a rhetorical question.
I don't really agree with commenter above, but this argument is blatantly wrong. Executives are paid the way they are just because they are in charge of, among other things, compensations.
No, but I did leave out some important clarifications. It's not that leaders will go away, but that I think leaders will also be required to contribute to some code. Also this isn't in the near future either, but just like many roles (i.e. QA), leadership will slowly become absorbed by developers who will have multiple specializations along with knowing how to code.
If you want a better analogy that doesn't belittle senior leadership, try Go instead of Checkers.
One of the keys to successful management and leadership is understanding sustainability. Incremental changes over a period of time beat a huge lift followed by burnout and stasis.