Employees are happier when led by people with deep expertise (2016)
hbr.org
hbr.org
I also don't see this a refutation that we shouldn't hire good engineers into management, rather we shouldn't do this blindly and as the single criteria. My best managers were all top quartile engineers but probably not top 5-10%, because they also cared about the non-technical requirements that a good manager needs to cover, and this inevitable consumes focus, effort and time that your best engineers don't want to allocate.
I'm a relatively new engineering manager (~3 years) and wrote about the traits of a good development manager from my perspective here:
https://www.codeleadmanage.com/articles/20200204-four_qualit...
It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.
From my perspective, as a relatively new technical manager who also spent years as an engineer working with technical managers, it's not only about empathy but also about having a thorough understanding of, or at least an accurate intuition around the subject matter. When I was working as an engineer, what I often found frustrating about working with non-technical managers is that they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project, or are relevant to the work, and often the team is led down a more difficult path than is necessary because requirements are set in the wrong terms.
I think it's possible to compensate to some degree with empathy and people skills, but it's hard to compete with having the experience and speaking the language.
I see this sentiment or implication that technical skills and people skills are somehow mutually exclusive often, even on here which is crazy. I think this stems from some broader trope that people are "balanced" like RPG characters or something, e.g. nerd vs. jock or artist vs. scientist, salesman vs. accountant, etc. The reality is that people who achieve in one area are more likely to achieve in others. If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.
Aptitude is in general going to be either uncorrelated or positively correlated across different areas, but time invested is going to be negatively correlated. Hence the stereotype of nerds with poor social skills: building social skills takes time and effort, and time and effort spent on building those skills is time and effort not spent on, eg, improving your programming ability.
Of course, people who have off the charts aptitude will be in the top percentiles across the board. But you're not going to find too many organizations staffed entirely by those people.
[1] https://en.wikipedia.org/wiki/Berkson%27s_paradox
edit: removing markdown syntax
There are some technical mountains to climb which require superlative engineering talent, but in terms of impact it's hard to compete with a leader who is able to coalesce a team or organization effectively towards a single goal.
True, but this may not be seen as relevant to the individual if they enjoy engineering more than those other things.
The number you are looking for here is zero, at least for organizations of any size. With a bunch of luck and money you can put a small team together like this; otherwise they are just too scarce.
Expecting someone with five years of engineering experience to become an effective manager overnight - often with no training or mentorship at all - makes as much sense as expecting an intern to operate at the same level as a senior on Day 1.
Even really smart people with multiple talents need more of a warm up than that. And most people are neither that smart nor that talented.
In some companies, like Gore Industries, and other employee owned entities the engineers and operations people organically select their own supervisors by consensus and set pay democratically. I have been in environments that did that without explicit structure even, and it was very productive. Unsurprisingly,none of those were publicly traded.
The "if they wanted" part is key. It's hard to become extremely good at something unless you really enjoy doing it. I'd imagine that most people who are top engineers would rather be doing engineering than anything else. If you make them a manager, they're going to enjoy that less and not be as good at it -- but a lot of people get pressured into becoming managers nonetheless.
If your goal is to have an impact, you have to be lucky to do this as an engineer. There has to be a structure around you which converts your work into value. As a manager it's much more reliable that you can be the person to create that structure.
Really? I love software development, but I don't think just churning out random CRUD software based on some specs is very interesting. A lot nicer to solve problems of your customers, see how the product makes them happier and think about ways to improve their user experience.
Somehow I assumed that's how others felt as well.
Good engineering is about understanding the problems of your customers, designing software that solves these problems, and improving their user experience.
Yes.
The v1 isn't the hard part of building a competitor to Twitter. The hard part is scaling the user base, getting funding to keep the site running and being able to grow it.
But a basic microblogging platform? It's not impossible to do in a week.
Why would you want to make one at all?
But my point is, everything looks easy if you look at it shallowly, managers without professional programming experience will look at the problem from that angle.
The best will be able to help, the worst will have this shallow look and expect the moon by morning.
Moreover, I found that non-technical managers had often trouble in empathy and people skills departments. I think that a lot of issues stemmed from non-technical manager having basically inferiority complex, confusing disagreement with disrespect, being unable to distinguish between mistake and lie. Moreover, not understanding culture technical people tend to create or even not being aware that there is such a thing as difference of culture.
The cultural difference is a big thing - non-technical management in my experience value completely different things, ends up insulting engineers or otherwise creates difficult situations. All of that then implies that I as a programmer suddenly have to deal with interpersonal issues that manager created or is unable to deal with.
The thing is, the choice is not between non-technical person with people skills and technical without. The choice is between person with technical knowledge and one without, where the one without them has also disadvantages in peoples skills.
> they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project,
There's a fairly large gap between those two positions. Personally, I'm a fan of a manager that knows enough to discuss the topic with me, but they don't need to know enough to analyze the problem itself. I want to be able to explain to my manager what the problem is, what the various solutions are, and which one I think is best and why. If they can understand all that, that's enough for me.
It’s nice to be able to say, “what do you think I should do?” as an IC, and nice to be able to analyze the problem if necessary as a manager.
On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.
Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.
It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
I think I understand the disconnect here. From my point of view it's the manager's job to figure out what problem the client is trying to solve. It's the developer's job to figure out what the possible solutions are, and recommend what they think is the best one. As a developer, I expect to be in the meetings with the clients long before the solutions are chosen.
It's just that both sets of somewhat orthogonal skills are less likely to reside in one person.
An analogy from baseball is why are pitchers generally lousy hitters (even pre-DH)? Did they get less practice? Probably. But it's also the case that (again even pre-DH) any ability to do more than lay down a bunt was absolutely a nice little bonus but their job 1 and 2 and 3 is pitching the ball.
On the other hand, even the best fielding shortstop in the league still needs to have a half-way decent batting average, even if they can get away with a lower one than other positions.
In middle/high school, there is often 'that kid' who _is_ the best at all skills - they are the pitcher, they bat cleanup, they do everything.
In the pros, though, that's virtually unheard of these days, because the amount of time it takes to specialize in a skill sufficiently to make it to the majors is so extreme it precludes you from being able to do that for multiple skills, with rare exceptions.
Not disagreeing with you, or at least I don't intend to, but I definitely remember playing against 'that kid' when I played baseball in middle and high school. Same analogy for the kid who's great at several sports in HS but has to specialize to get the DI scholarship or go pro, etc.
I read the OP with a very different takeaway than what you may have inferred. I did not get the impression they were saying empathy and technical skills are mutually exclusive. By saying their best managers were in the top quartile, they are implying they were technically competent but not necessarily the most competent in a single domain.
1. Manager proposes low quality requirements
2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization
3. Endless discussion around this one detail
4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal
OR
4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline
What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.
- Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B"
- Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C."
With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.
Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable
True, but your top-10% engineer who's also a top-10% manager is going to be 10x rarer and harder to find.
To be honest, I would love to work for a place that implements self management even half hartedly. My understanding is that Valve is like that. Valve may not make things on the schedule that people want them to - but no one can deny that their quality is supreme.
Arguably my best manager had a graphic design and UI background. Where they excelled was having worked directly with software developers and non technical people for a decade they could understand the relevant tradeoffs without getting into the weeds.
However, former software developers where generally much better the deeper and more relevant their technical background. Seemingly because they understand what to prioritize, but perhaps it’s was simply easier to communicate with them.
In settings where the people being managed are professionals, I have come to think that there should be a vote of no confidence option where a majority vote of the team can immediately remove the manager.
Like in a band. Best projects I've worked on have been like bands. Each engineer skillfully playing their instrument, while the manager secures the gigs, promotes the band, listening and acting on feedback from the members.
So we reward visible work. The higher flames in Ops the better, to not be invisible.
This is why manager must have domain knowledge.
But is it actually true?
At the very least our scheduling would start being based on reality, not what we’d like it to be.
The (now retied) director of the art museum at Cornell could be seen out in his suit passing out pamphlets for an exhibition together with students promoting clubs and concerts.
Go to the exhibition and he'll personally give a talk about the art that will help you appreciate anything from a suit of Samurai armor to Mark Lombardi's conspiracy diagrams. It's nice to see the top guy, who performs like a top guy, doing the simple work.
The station was a part of a chain of dozens. The owner was a well-known local multimillionaire. For whatever reason, he happened to be at my station on my first day at work.
He and I spent over an hour pumping gas, checking oil, doing an oil change, patching tires, and so forth.
I learned a lot more than simply how to work at a service station that day. I continued working at that station for over a year. Never saw the guy again. As I recall, when I started he had stores over half-a-dozen states.
> Never saw the guy again.
It doesn't scale. If you have the knack to build a company like that, eventually you won't be able to touch the front lines of what your company is doing. Hopefully, having that type of leadership at the top creates emulation all the way down, but still, it rings of "die a hero or live long enough to become the villain"
I think that's truer than you mean. The legend can scale, but the reality doesn't. Unfortunately I'm more interested in the latter.
At a certain point, you've got to stop pumping the gas. You want the company to outlive you. Gas needs to get pumped after you're gone. You fade into the background and replace yourself; others carry on your legacy. You cash out and ski six days a week or whatever.
Edit: some legends are bullshit. Scale that up and it's called "toxic culture".
If you are a leader in a field, and you have forgotten or no longer can do the work at the very lowest levels (for example, even something simply like mopping), you have lost an expertise that made you valuable in the first place.
Since safety at sea comes in large part from 'simple work' being done rigorously, it is heartening to see the top man wiping down a slick deck to prevent the chance of accidents.
https://mogadalai.wordpress.com/2008/12/02/what-is-leadershi...
(Not the original source, but the most readable I found.)
As you say:
> It's nice to see the top guy, who performs like a top guy, doing the simple work.
How many CEOs could do all of the CFO, COO, CTO, and General Counsel's jobs? Zero.
How many programming team leads can do the junior programmer's job? Basically/hopefully all of them.
Even in the case you gave, a good CEO might be able to do that. When you are at the C level, whatever the role is, you're probably going to mostly have to be good at stakeholder management, strategic thinking, listening to your peers and the people working under you and taking good decisions based on the inputs available. A good CEO should be able to step in and apply those skills outside of their domain of expertise, even if they are not going to be the best CFO/CTO in the world.
I've spent some time employed by organizations whose decisions are disconnected from day-to-day reality; train wrecks are fun to watch, but they get less fun when it's your job to ride the train into the brick wall.
Basically the more you see yourself as a “manager that facilitate work” the easier it is to go higher and the less expertise you need (social expertise exempted). Need something done? Hire someone to do it!
Is there a specialist under you that isn’t replaceable? Better keep him in his position!
I really wish we had what you seem to have though.
A good COO will also have specific experience and therefore hard skills and easily outclass a general manager that's just winging it... but some operations are simpler than others, so the requirements associated with any of these C-level roles (including CFO and GC) are really on a spectrum
But as you said, the more senior you become, things completely change. There isn't a CEO in the world that could do all of the jobs they hire other executives to do (finance, sales, tax/accounting, HR, marketing, technology, operations, legal). It's impossible.
Impossible, yet accomplished by thousands and thousands of small business owners every month.
Similarly, a small business owner might call themself a CEO.
Neither is wrong per-se, but when we're talking about CEOs who have hired a team of executives to run their company, it's most reasonable to assume that GP was not talking about such a small business.
This also doesn't quite acknowledge that even if you can do all of those functions [in a small business or one-person company] it does not mean you're actually good at those jobs.
It's an appealing thought, but really they are doing a different job. Vast majority of those thousands of small business owners couldn't effectively step into one of those roles at even a mid-sized corp, let alone all of them.
In my experience, often, not many. And it is usually a recipe for disaster.
I understand the function of creating, launching, and orbiting a satellite geosynchronously to do GPS so it's easy, right? Yea, not so much.
I'm a firm believer that you need to understand everything at least one layer deeper than high level functional descriptions so you can start to reason about the difficulty or amount of skill needed to accomplish something. You understand the real problems (even if only at the surface) and know where opportunity lies. With a pure functional perspective many current managers have, you simply can't reasonably manage and plan and are instead a glorified resource scheduler with whims.
Having said that, I am possibly a bit like your boss. I am a major bottleneck to my employees, and they struggle to overcome technical skill gaps between their knowledge and what they need to work on. Frequently I find they are blocked for days or weeks and when I finally get to sit down or spend time with them, their problem is sometimes solved within minutes. Sometimes I resent it because it's clear to me with some basic effort in learning new skills, they could get over these humps but they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help. It's really alien to me because as a young developer I would never have done that, I would just keep acquiring knowledge until I solve it (possibly taking a lot of time). While I'd never outright deny a direct request for help, I will often redirect where I think they can figure out the problem themselves with some investment in their own learning - "you need to learn about X, do some reading and tutorials, I think that will help", etc.
I am curious if you would have advice? Assume you can't solve the problem of actually getting your bosses' help (they simply have too many responsibilities to be helping at a micro level), how could one develop a culture of self-learning and proactive responsibility to progress things?
Optionally, you could put an interim step where someone else on the team is given the chance to advance it; might keep it from your doorstep. But I don't know if that'd help in your situation!
I've assumed that the problem is with them, not you, as that's how you wrote it. But if you have (possibly) set a tone where their solutions work but not as well as yours and are switched because it's not done as well as you'd do it, then it's on you (possibly?)! :-)
That's a metaphor - of course you shouldn't treat your reports like children. But if they possess the following attitude, it's on you as the manager to let them know that it's not an acceptable practice on your team.
> they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help
This advice doesn't stand on its own; you'll need both more specific tactics and a broader strategy for dealing with the situation (providing tooling or scaffolding for improving their behavior). But the fact of the matter is that everything else you do for them won't matter if you condone this behavior - which you are, by allowing it to keep happening.
PS I am an engineer-turned-manager and this is easily the least favorite part of the job for me as I get used to it. But it is ultimately your responsibility to do so, and you are impeding your own ability to improve as a manager the longer you resist doing it.
Yes it is quite the learning exercise to get used to all of this and know where to be drawing lines, when to reinforce boundaries and when to let things go. What I am realising is that my threshold for giving direct feedback is way too high. I keep trying, instinctively to achieve outcomes indirectly - but way too often it doesn't work or even backfires and breeds more of the behavior I don't want.
I really appreciate having your thoughts!
What I like to do is to find the win-win for both me and my team members. If there's no reason for them to do better, why should they? Maybe you can get an understanding of what motivates them. Is it improving as an engineer? Better compensation? Getting promoted? I would imagine all of these are fairly easy to align with a goal of decreasing blocked time from weeks to hours. That's a huge difference in time!
My advice is that if you know what someone needs to work on, and they don't, just frikkin' say it. Don't wait until they are burned & trying to drag a merge request across the finish line. Also invest in tooling & processes that encourage people to figure things out & generally do better (which may be simply don't give them excuses to do worse).
This especially stings if it comes from a team lead because in my mind, the team lead exists to bounce ideas off of and to iron out issues.
But if you ever see a team lead or manager dinging you for just reaching out to them, switch teams or quit.
Sounds like the Team Pb XD
Working for an expert engineer is fun because their expectations are in line with reality, and they don't compel you to solve problems in stupid ways or in the wrong order, because they know how things should work. In any case they understand when to help and when to delegate to you.
Working for a bad engineer is the worst. They criticize smart or elegant solutions because they differ from the stupid way they would have done it. They try to dictate how everything is done because they think they know how, when all they really know is how to fuck things up.
Working for a smart person from a completely different discipline is fun. Say if you are programming CGI special effects for a movie director. They have respect for your different expertise and defer to you when needed. They find joy in your work because to them it's a kind of magic. They don't tell you to solve problems in stupid ways or the wrong order because it's not their area. It's fun that they request impossible tasks sometimes, because working out how to get close to the impossible dream they are imagining is how you get to do your best most innovative work.
Working for a inexperienced person from a different field is also fun. Although they don't know much, they know that, and won't dictate how your job should be done. They will still have appreciation of your expertise. They probably have unrealistic ideas about how long things take, and what is possible, but as long as they are willing to be guided, the project can still turn out OK. Their lack of knowledge of what's possible or how things normally work often leads them to come up with crazy new ideas, and working out how to make those real is my favorite thing.
Not saying that this is true in your case but I have seen this too often that managers think they can code just because they did it 10 years ago. It's surprisingly hard to write good code when you are not in practice.
1. “Leaders must always set the highest standard. In a summer campaign, leaders must always endure their share of the sun and the heat and, in winter, the cold and the frost. In all labors, leaders must prove tireless if they want to enjoy the trust of their followers.”
2. "There is small risk a general will be regarded with contempt by those he leads, if, whatever he may have to preach, he shows himself best able to perform."
I swear, some of the articles in HBR should just be sub-titled:
"STUFF YOUR MAMMA TAUGHT YOU BUT YOU FORGOT WHILE GETTING YOUR MBA"
With that said, I actually DO NOT want my C-suite to have coding prowess. I prefer them to be gifted in their areas. I love knowing that our CEO is one heck of an inspiring guy but I don't want him meddling in engineering. I'm sure he's smart enough that he could figure it out, but that would be a waste of his talent. Right now, his brilliance is evident in the people he's put into leadership. They're all experts of their domain. This frees him up to do more CEO things (like get our next round of funding)
The CEO certainly shouldn’t be expected to have the skills of every expert across the entire organization. But if they were to be the executive in charge of Marketing/Sales/Engineering/whatever they’d ideally do a passable job. Now that is kinda unreasonable at the very top (CFOs and CLOs are very specialized roles) but from the VP level down it works out quite often.
I think you're missing one thing here that makes it a little more analogous to your boss: not only should the CEO and your boss be good at their own jobs (e.g. securing funding), they should be good at their reports' jobs as well (just like yours is). Expertise that is 3+ layers down the org chart is completely irrelevant, of course, as you point out.
There are executive situations where there's a lot of specialized knowledge one level below where this doesn't quite work, but that should garner lots of extra attention.
Perhaps a significant effect is that people with deep expertise tend to be much more passionate about their job, because without passion they could not have developed deep expertise.
The best engineers don't usually make the best managers either because they have a hard time giving up control. Good managers let their staff do their jobs and give them the tools needed to excel (including mentoring and coaching).
"We went through that stage at Apple where we thought, ‘Oh, we’re going to be a big company, let’s go out and hire professional management.’ We went out and hired a bunch of professional management; it didn’t work at all. Most of them were Bozos. They knew how to manage, but they didn’t know how to DO anything.
If you are a great person, why do you want to work for somebody you cannot learn anything from? And you know what’s interesting - you know what the best managers are? They are the great individual contributors who never ever wanted to be a manager, but decide they have to be a manager because no one else is able to do as good job as them."
* Setting bad expectations with stakeholders and customers
* Taking on bad opportunities, committing the organization to unnecessary technical debt for no monetary gain
* Fracturing teams across competing opportunities
* Top down decrees issued from abstraction that causes organizational thrashing
* Decisions made in abstraction with no understanding of the stubborn technical constraints that block fruition
The major difference there is one is support and tracking, the other is just incompetent in all areas if management.
> Ex-programmers turned managers who still code from time to time are far more realistic about how long something might take to complete.
Is that they had huge egos and thought they could do everything in much less time than I could, or would just "put in the time to make sure it was done when it had to be"
So nah, I prefer not having ex programmers as my manager.
My supervisor has absolutely no clue and just wants updates; thats all.
E.g. I am an amateur coder. Anyone who has typed 3 pages of code without looking up on a book or a website, is x100 better than me. If someone decides to make me the leader of coders, I won't tell them "I command you to use this syntax over that paremeter (?)" (coz I'm like Jon Snow.. I know nothing), but I WILL tell them to a) take daily backups/use version control, b) write comments on your code, c) do daily huddles, d) sit in pairs and review each other's code, e) some bright ideas/suggestions that THEY will make, f) I will bust my ... and try to study as many books/blogs/resources to learn the area (and managing coders better), g) I will talk to as many coders (young and old) as I can to understand them and their needs better.
Does that make me a good coder? Hell no! I didn't mention "read Java" in any of my aformentioned example. Will this make me a good manager? Well I have managed OTHER teams in & around IT.. why not coders? They are people too!
Imagine managing a team of diamond cutters and not being able to cut diamonds yourself... you would only recognize poorly cut diamonds after they had been cut and you would have no idea of how to help your team improve with specific recommendations and guidance.
I am currently managed by a person who although has a technical background but for a long time is only doing management, so definitely can't do my job. And it is totally fine, because he's not making any technical decisions, these are made by technically excellent people.
Examples of management failures that I have seen on the other hand involve product managers and/or people with sales attitude playing product designers or solution engineer's roles. That doesn't end well and creates a lot of conflict between the management and the technical people.
Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion." with incompetence being "flushed out of the lower levels" of a technocratic hierarchy, ensuring that technically competent people remain directly in charge of the actual technology while those without technical competence move into management.
have fun ;)
At a certain point that may be effective but we were not at that point.
When a manager lacks the expertise then what it comes down to is how much a manager is, 1. Willing to work hard to gain the necessary knowledge to be effective in their job, 2. Listen to their subordinates on matters they are less knowledgeable about and displaying a deep interest in truly understanding it.
What I have noticed is that if a non expert manager is not willing to do these two things what usually happens is they become yes men/women for upper management. They will agree to commitments that the team can’t necessarily meet (or in some cases will require them to work overtime), other times they will make the team cut corners or do things that are going to create a lot of problems down the road. When it comes to cleaning up the mess that was created, they have already moved onto to their next role leaving the clean up to their old reports and the next manager.
A manager that is an expert in the field they work in can do just as much damage as a non expert manager when they micro manager everything leaving little opportunities for growth.
Even worse, the lack of deep understanding means that the manager cannot distinguish good ideas from bad ones, and often cannot distinguish talent from bluster, leading to poor hiring decisions and directionless leadership.
Everyone knows that putting a untrained business major in charge of a squadron of soldiers would end badly. He might be able skate by until they got into combat, maybe, but after that they wouldn’t listen to him for long. But for some reason we think that putting an mba in charge of an engineering team is a good idea.
Citation needed.
That being said I also have had other really bad managers who were star IC's that were promoted to mgmt as they really had no where else to go in their career. These managers usually are clueless on dealing with people and other teams.
This is tricky, of course -- for low-level managers with typical engineer IC reports especially, it's super common for them not to have a single report whose judgement they can trust.
It’s missing key words
Star ICs who went into management but can't leave tech could end up micromanaging or just being an aloof unhelpful resource.
Employees are happier when led by people with deep expertise - https://news.ycombinator.com/item?id=13481218 - Jan 2017 (238 comments)
If you’re in a leadership position, you generally get there by being a subject matter expert, a professional manager (ie money person) or an attorney.
Being able to walk a mile in someone’s shoes means a lot.
If you find your team deadlocked on decisions and you think the way forward is to find a tie-breaking vote, I have bad news for you.
Often all it takes is a qualitative comment that one could mistake for leadership, and the guy who won’t be accountable for any decisions is not leading anybody.
I think you want to aim for consensus building that doesn't have half of the stakeholders spending 100% of their time to get your decision reversed, basically. Maybe it's impossible to build a consensus, and you have to act. That's the value in the tie-breaking vote, and that's what Congress does. But we shouldn't try to model getting things done at work as an epic battle between Blue and Red. That level of polarization is toxic. Maybe Congress can't fix that problem, because they represent 328,000,000 people, but we can aim for something better in a smaller group.
tl;dr: Let the leaders lead and the managers manage. It's nice when one person can do both well, but that's an unreasonable expectation for the amount of work involved.
If you got higher in the org, the focus of managers become more strategic and process oriented, with stronger alignment with the business side of things.
Employees most happy being led by clueless, ignorant, inactive managers who throw them under the bus?
What. A. Surprise.
Anecdote: in one of the law firms whole departments were sent to LWOP due COVID-19 and department heads had to do all the work themselves. They found out that they are perfectly capable of singlehandedly doing the job of the whole department.
My take: if your boss can do your job, you're not needed.
If your boss can do your work, has the time to do your work (eg there isn't enough work), the work doesn't need to be done in parallel, and can do similar quality work, and is willing to do that work, you're not needed.
That's the takeaway, without oversimplification, which makes sense.
It's actually an interesting point that. Oversimplified a bit, I feel there are two different ways that people measure their worth in the workplace. There is "no one else can do what I do" and then there's "I make sure that everything I do can be done by someone else".
Personally I much prefer the latter.
I can program in ASM, since I did it in college. That's a different assertion from "if a colleague can do your job, you're not needed". ASM programmers are still needed. Also, there's the whole "making a baby in 1 month with 9 wombs doesn't work".
If he has time to do your job. My boss can code, and very well. But he doesn't have time to do so.