My experience as a Development Manager for the past ~year (YMMV):
1. I'm playing chess; senior management is playing checkers. No, not because I'm some sort of genius and they are simpletons, but rather they talk about interchangeable "resource units" and I know these FTE's as "Tom" and "Amy", each with specific strenghts and weaker areas. Big strategic plans cannot differentiate but we front-line managers need to figure out how to position and leverage individuals.
2. Actually, genuinely, caring about your direct reports goes a very long way towards solving a lot of culture problems but...
3. Dev Managers need to put a lot of effort out into their teams to drive change and it is often (most of the time?) not returned. Your biggest enemy is not active sabotage, it's apathy at all levels of the organization. I started pushing for some specific cultural-ish changes about this time last year and, while I was given passive approval & support and lots of latitude to make change, it has been physically exhausting. If I was in an organization that didn't even give me this much freedom it would have been exhausting and pointless.
4. A Dev Manager can make localized changes when not all teams want or can reciprocate, but I'm not convinced yet that the requisite firewalls you need to erect aren't ultimately harmful in the long run. It is a very delicate balance.
In the end my take-away is you need space and time to make any meaningful change, and even that is limited by the crushing inertia of the organization. For me personally it has been physically consuming and I have 6 month & 1 year goals, plus an overall 3-year plan that I'll either complete in the coming year or look for an new opportunity elsewhere.
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 an isolated HR unit controls hiring and freezes the hiring managers and team out of the process, or effectively alienates them, you're wasting a huge amount of energy.
This is part of the methodology I try to weave into my organizations:
- A thoughtful and literate job posting, purged of gratuitous jargon, will accurately describe the job and foreshadow the company culture.
- Candidates will be evaluated using a simple quantitative assessment of core competencies (see Ch. 21 of Kahneman’s Thinking Fast and Slow).
- Final decision will be a collective decision of the hiring team.
- After hiring cycle is complete, hiring team will hold a retrospective.
- We will acknowledge mistakes and work to correct them quickly and humanely.
>Candidates will be evaluated using a simple quantitative assessment of core competencies.
I've tried implementing that with a coding take-home task, with "mixed results".
On-paper great candidates often refused.
On-paper good candidates made mistakes because they completed it very quickly, while mediocre candidates invested x10 the time and produced "better objective result".
Comparing code turned out to be much less straightforward or objective than I've anticipated: X handed great consistent well-commented code, but didn't null check inputs, Y covered all cases but left internal class implementation details public, and so on and so forth.
I posit it's still the least bad way to evaluate a candidate. If a 'mediocre' candidate is able to complete the task well, they have still completed the task well.
And, IME, 'great' candidates, even with a storied resumes, can simply be good at self-advancement and job application as much as actual competent at their job.
I don't care how someone looks on paper. Nor should you. Your process should optimize for people who are good at the job. You can look at all the negatives and try and guess "maybe that was a false negative!"...but who cares? What's your rate of true/false positives? That's the only data point you have; optimize for that.
In my case I got zero positives. It's easy to build an accurate classifier if recall is ignored. Not a single candidadte completed the task perfectly. Not hiring would be a failure for me.
If I remember correctly Kahneman said not to do this though and to just go by the quantitative evaluation you mentioned in the previous point. 'Final decision will be a collective decision of the hiring team'
Not the parent but a good goal for me is a goal that will stand the test of time. If your change is fundamentally a good one and is part of a strong industry trend it will more likely succeed. I have been pushing a consolidation system for finance (2,000+ finance professionals where I work) over the past 3 years, only lately it's picking up steam with the leadership. If I had been pushing a change that was not so strongly trended (automation and all) I would have failed because something else would have come up as "best practice" in the industry. This does not mean you just go with the industry and become a "benchmark" monkey, hype is still a problem. Take AI, Big Data, etc., those are not so good trends to latch on today because they seem to be too hyped. But it means you stay real with yourself, your company and, most disregarded, your industry.
1. I'm playing chess; senior management is playing checkers. No, not because I'm some sort of genius and they are simpletons, but rather they talk about interchangeable "resource units" and I know these FTE's as "Tom" and "Amy", each with specific strenghts and weaker areas. Big strategic plans cannot differentiate but we front-line managers need to figure out how to position and leverage individuals.
2. Actually, genuinely, caring about your direct reports goes a very long way towards solving a lot of culture problems but...
3. Dev Managers need to put a lot of effort out into their teams to drive change and it is often (most of the time?) not returned. Your biggest enemy is not active sabotage, it's apathy at all levels of the organization. I started pushing for some specific cultural-ish changes about this time last year and, while I was given passive approval & support and lots of latitude to make change, it has been physically exhausting. If I was in an organization that didn't even give me this much freedom it would have been exhausting and pointless.
4. A Dev Manager can make localized changes when not all teams want or can reciprocate, but I'm not convinced yet that the requisite firewalls you need to erect aren't ultimately harmful in the long run. It is a very delicate balance.
In the end my take-away is you need space and time to make any meaningful change, and even that is limited by the crushing inertia of the organization. For me personally it has been physically consuming and I have 6 month & 1 year goals, plus an overall 3-year plan that I'll either complete in the coming year or look for an new opportunity elsewhere.