>The benefit of having a highly competent boss is easily the largest positive influence on a typical worker’s level of job satisfaction
This is one of those great discoveries that is hardly surprising and makes you wonder why it hadn't be seen before.
Honestly some of my worst work experiences were getting jerked around by a superior who completely failed to understand the work required to do my job.
I suspect it is a comparatively new phenomenon in the workplace which is in part attributable to the recent surge (5-10 years) in knowledge work.
When I worked in bigco as an analyst, the director and even managers were from a different era. The better ones knew excel to some extent but had no idea how to do sql or even excel automation which was a large part of what the analysts were required to do. Part of this is a rapid almost stepwise change in the work that is done, part of it is due to tech companies recruiting from a diverse set of industries.
In other industries like law, finance and accounting, most people start at the bottom and slowly work upwards so the skillset is more of a continuum up the hierarchy so it is feasible that your bosses can still do your job.
It used to be the same in other industries but that is fast changing. For instance, the top level accountants will have been studying at a time where bookkeeping was literally done in paper books...
Another phenomenon is the development of management as a science. People can end up in positions of oversight where they have a deficient understanding of the tasks people below them are performing.
Study of management and processes is not without merit, and the rants against MBAs can be one dimensional by not recognizing the benefits. But if that was all that it took, then the economy wouldn't "waste" medical doctors or highly skilled engineers in administrative functions.
I think that is true, although people have been doing MBAs for a much longer time than the tech boom has been around for: e.g. doing an MBA was viable a route into Finance since at least the 80s.
Though MBAs have certainly been growing in popularity over the past few years.
I think that longevity is why people can feel so bitter about it. It has become strongly embedded in a lot of corporate cultures where management can find itself in a homogeneous bubble. This can serve to limit mobility of non-management level workers who could excel if provided the opportunity to take on managerial functions, which means that is lost economic potential.
It's not constant across the board, as there are plenty of IT companies that seem to be doing a decent job at promoting engineers. But then I read a lot of people here talking about "up or out" views of engineers who are above a certain age. It's complicated.
> doing an MBA was viable a route into Finance since at least the 80s.
That makes sense to me actually, since you need to have a high level understanding of how businesses work and what stuff the C-suite needs to be doing in order to understand how to value a business.
The C-suite might be the one place where the "generic management skills" might actually be really useful. But middle management and day to day supervisory functions? You can't manage what you don't know, and if you don't understand the processes of the people you're managing you're blind.
It seems like MBA schools recognize this to some extent - my brother got an MBA with a focus on software project management. They even had to learn to do some coding and worked on a couple software projects as a team in order to apply what they were learning.
In my personal take on all this, it is those people who have wrecked this entire country. They bear incredible blame for many massive failures that cost billions of dollars and millions of jobs. It is that level of a tragedy. But somewhere, some few people pocketed billions of dollars.
In my experience who ever makes this argument is incapable of coding and hence went to management. Some are really nice people but still they can be misled due to their I capability to understand he nature of work.
I would be willing to be those people still knew how to do the job, just without Excel. They fundamentally understand the reason for "analyzing" things and the output generated by that.
It's when you put a recent MBA grad with 0 domain knowledge as the manager of these people where problems start.
And again, with the accountants. The crusty 60 year old accountant will still be able to read a report generated by a fresh college grad. He could even open the books and spot problems. Issues arise when you put someone who isn't an Accountant in charge of the other accountants.
But when your boss has never even made a model, let alone tried to fish data out of a database, then the kind of work he can imagine, his idea for time duration for work are all off.
More importantly, what he values in the team (for when it comes to promotions) is also likely to be off. And hence, you can end up in a situation where you don't get promoted despite being very good at your job.
This is one of those great discoveries that is hardly surprising and makes you wonder why it hadn't be seen before.
Well, the traditional view of "management" is that it's a distinct job from "doing". Therefore, so the thinking goes, there is a distinct difference in skillsets, and thus the manager should be good at the managing bit, and the doer should be good at the doing bit.
The reality is that in order to effectively manage, you have to understand what the doers are actually doing.
Interestingly, this relates to a topic that came up yesterday about product managers (who are not "managers" in a traditional sense). Every time I see complaints about PMs, the root cause often starts with the PM not understanding how software is built and how developers work. Thus they disregard practical technical realities. Those folks describe as a "good" PM are often those with a technical background... who could, as it happens, do your job if needed.
>The reality is that in order to effectively manage, you have to understand what the doers are actually doing.
There is an important distinction. An effective manager should understand the general process and what can be time sinks, but they don't have to understand extremely specific details of what each worker is working on at any given time. For example, a manager of a software team doesn't need to understand the idioms of the programming language used by the team or even be that effective of a programmer. Some of my best managers have been ex-software devs that understood architecture, requirements distillation, etc really well but wrote the ugliest code you would ever see. :)
My best manager was an ex-Air Force fighter pilot who had a general idea of what we were doing. He understood his role wasn't to do what we were doing but instead to enable it.
Some of the worst bosses I had were technical people who had been promoted to upper management and couldn't let go of the tech stuff. My attitude towards them was that if they wanted to code then they could take a demotion (and give up those huge equity grants) and get down in the trenches. Otherwise they could STFU.
you have to understand what the doers are actually doing.
While this may be necessary it is definitely far from sufficient. Especially in academia, where my wife works, I've seen countless examples of people whom are perfectly competent research scientists becoming scarily incompetent managers.
No argument here. I'd never claim good managers don't have additional skills beyond the technical. Only that the crisp line we try to draw between the two roles is a false one.
I'd also claim the following: sometimes doers have to manage up or laterally. In that sense, a good doer must have some of the skills of a good manager, just as the reverse is true...
> The reality is that in order to effectively manage, you have to understand what the doers are actually doing.
Actually it is not. One of the best bosses I ever had had no clue what I was doing. He was smart enough to admit that he didn't know how to do my job. He was excellent at his job though: figuring out who were good people and removing roadblocks from their way. He identified a few good programmers to do the technical interview part while he focused on are the people he was hiring good fits for the people he already had.
If you cannot have a great manager who will get out of your way, then a manager who understands what you are doing means at least when he tells you to do something it was probably what you were going to do anyway.
The worst boss I've ever seen took some programming classes as a door into management - he knew enough to be dangerous when telling programmers what to do, but not enough to be helpful.
Well, the HBR studies cited, here, indicate a correlation between a manager who could do their direct report's job and job satisfaction of that direct report.
It does not claim that this is necessary for direct report job satisfaction, only that it makes it more likely.
So, my comment could have been better phrased as:
The reality is that in order to effectively manage, it helps if they understand what the doers are actually doing.
If you cannot have a great manager who will get out of your way
I claim that knowing how to "get out of your way" is a necessary but not sufficient skillset in a "great" manager. Understanding how you do your job will better enable a manager to remove impediments and provide you with the right environment (both physical and technical) and right motivators to help you perform even better.
No one would claim that a football coach should try to handle the ball themselves (as per the manager you described in your last paragraph). But a coach that just stands back and lets the players play is only doing half their job (at best).
Yeah I think there's a balance here. One of my favorite managers also didn't understand my project (although he did understand software engineering in general) and I later found out everyone else hated him. I've seen what I suspect is similar later: managers who just see their job as defending their team. Someone needs something from the team? Push back. Their teams needs something? Hound those responsible. Team has an opinion? It's undisputed truth now. No ability to mediate or help with the bigger picture. Just like a lawyer for their employees.
What you need is someone who will take care of the employees and jump on grenades of distraction so they can focus on their job. But you also have to have enough context to step back and say, "hmm... doing this would be best for the greater good - my team should take a look at this." It doesn't need to be the ability to do it themselves, but they have to have some.
I agree. It would be a mistake to assume that every level of management must somehow know many of the low-level details of every single person he/she might manage, directly and/or indirectly.
A CEO, like Jeff Immelt of GE, cannot possibly know how to do all of the jobs of all of the people in the entire company. Yet, he somehow does a good job of leading GE.
You'd be lucky in software engineering if your non-technical manager sees their job as just defending their team. Someone needs something from the team? Push the team to give it to them. Their teams needs something? Give excuses on behalf of higher management but take all the flak from your employees for the excuses. Team has an opinion? Promote upper management's opinion as undisputed truth. Does have ability to recognize the bigger picture of their next promotion or new job. Just like a lawyer for their own CV.
Agreed - I guess what I'm trying to say is if you have a boss who doesn't understand the technicalities and won't understand them, this kind of manager is the best-case scenario. Certainly there are worse managers, but there are fundamental limitations preventing them from becoming better.
I believe what constitutes a great manager will depend a lot on the context. The "team lawyer" archetype mentioned elsewhere may in some cases be exactly what is needed. (Some dysfunctional corporate environments comes to mind.)
In other situations (small startup? consultancy) a very technically minded manager may be just the thing.
For revolutionary products (truly revolutionary) the big picture person may be crucial.
The other dimensions, like detecting bullshit, help team members overcome insecurities, have courage to make impopular decisions, these are orthogonal but very important too, I think.
> The worst boss I've ever seen took some programming classes as a door into management - he knew enough to be dangerous when telling programmers what to do, but not enough to be helpful.
But this doesn't satisfy the original assertion, right? The article specifically references deep expertise. Taking some programming classes is not that.
I had a boss who was a decent manager, but not very technical. At first I hated her because she thought she could learn to be technical overnight, and wouldn't listen to our teams technical suggestions. Fast forward to a year later, and she was a great boss. She had given up on becoming technical overnight, and just referred to her technical employees instead.
I also had a boss who was very technical, but not a great politician or manager. It was nice being able to discuss the tech-side of things with him, but he didn't know how to get shit out of my way so I could get the job done. Nice guy, but I'd never want to work for him again.
I think a good boss knows their limitations, whether they be technical, political, managerial, etc. and knows how to delegate to the right people.
I had the same experience, the best manager I ever had was clueless about software development and instead trusted us to do what was asked. A part of that trust was believing when we told him something rather than having him tell us.
It became a symbiotic relationship where we'd bring business decisions to him, and he'd bring technical decisions to us.
OTOH, there's a certain amount of reassurance when you're working under someone who is much better at what you do than you are. You know you'll always have a resource you can grab if you find yourself up against a wall, and it allows you to respect that person even more.
So I understand why the conclusion would be what it is, but I agree with you wholeheartedly about not needing to "understand what the doers are actually doing" to be a good manager.
The way I would put it is that the key skill is knowing how to manage engineers. It's different from managing other kinds of employees. The easiest way to acquire the necessary understanding is to be an engineer oneself, but it isn't necessarily the only way. In particular, it takes considerable humility, which doesn't seem to be something they teach in MBA programs.
I would argue that the key isn't knowing how to do the job but instead trusting the doers not to be misleading.
If the manager is technical and you raise a legitimate concern they know and understand the concern. If the manager isn't and doesn't trust the doers they will assume they are trying to get away with something or are lazy.
Honestly, I have a hunch most of this distinction comes down to trust between both parties.
I've had managers that were highly technical and it's a great experience to be able to learn technical skills from your manager. I've also had managers that were not technical with respect to the technology used on the project (i.e. couldn't do what the doers were doing) but they understood this, trusted us to get the job done, and it worked out. Both were very pleasant experiences.
Now, I've had non-technical AND non-trusting managers before and it was a miserable experience.
Because what your boss does, day-to-day, is very different than what you do. So it seems natural that they'd need different skills.
I'm a software engineer, and hiring managers has been a problem at every company I've worked at. You want someone who has written software earlier in their career, and has a degree in software engineering or similar. In other words, people who have chosen to spend a lot of time with computers -- devices that are very logical and literal.
But you also want someone who has good people skills. In other words, someone who chooses to spend a lot of time organizing other people, maybe was on the yearbook club in high school, that sort of thing.
And you don't want their knowledge of software construction to not be too out of date. So you want someone at a very specific point in their career, i.e. a few years after giving up coding.
In my experience, this part isn't true: "And you don't want their knowledge of software construction to not be too out of date." One of my best bosses was largely a C programmer (from back in the 80s). He'd still tinker with things from time to time, but I think the fundamental principles of software engineering haven't changed a whole lot since then. A software engineer who could have written a book like SCIP or Programming Pearls back in the day but were in management now, would probably make excellent managers.
> I think the fundamental principles of software engineering haven't changed a whole lot since then.
Not sure I agree with that.
A lot of todays best practices and workflows (and the tech to go with it), especially considering team and release management, simply weren't around or at least widespread even twenty years ago. You know, stuff like CI, TDD, DVCS etc. etc.
Are any of these concepts particularly difficult to understand for a seasoned developer?
I have a really hard time imagining that a C and SVN expert couldn't learn how to use git "well enough" in an afternoon, and effectively within a few days, for example.
In particular, the freaking author of git is an 80's C programmer and SVN expert...
> Are any of these concepts particularly difficult to understand for a seasoned developer?
Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn.
Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :)
And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
How do you figure? Why should my boss care about unit test frameworks and the relative merits of various TDD strategies. If he has some useful advice from previous projects then great. But otherwise, as long has we aren't having major problems, I don't expect him to interfere with those sorts of decisions. And if we are having major problems I expect him to sit the relevant people down and go "look, we're having too many regression bugs. Whatever you are doing with regards to testing isn't working, so let's come up with something better".
It's not about specific unit test frameworks or TDD strategies. It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
That's cute.
Too bad when the project timeline doesn't fit, the teams themselves don't fit, etc. etc. Yeah, team members can decide all they want when they don't have any resources to work with, because the primary strategic decisions didn't account for the workflows people had in mind. And yes, I've seen that happen to otherwise great managers (who took the blame and readily admitted their lack of experience with the (then) new techniques and accommodate planning accordingly - but by then it was rather late in the project...).
Of course, those cases are getting rare, but remember, we're talking about the statement "I think the fundamental principles of software engineering haven't changed a whole lot since [the 80's]".
As a S/W dev who started 30 years ago and finished his MSCS 27 years ago, I totally agree - S/W engineering (SWE) today is NOTHING like it was in the 1980s. SWE then was seen as mainstream CS and often a required part of a CS degree. Today, CS profs working in SWE are rara aves.
SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing.
Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose.
In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop.
No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...
That process was too heavy for most business needs and far too expensive as a result. It could never last. I do think developers were more respected back then. Today, developers, like all non-managerial (and to a lesser extent HR) people are completely fungible. For various reasons, we let our expertise be commodified. And as a result, we cheapened the entire field.
The way to get it back is thus: No non-developers ever manages a developer. This is how doctors keep their scam going.
One of the VPs at my prevoous companies used to sit in on our quarterly hackathons and build something. Made him a fantastic and well regarded engineering manager.
I've had bosses who couldn't do my job but trusted me and didn't get in my way and gave me the exact environment I needed to work in. Those were the best work experiences I ever had. It's the bosses who can do my job I have to worry about, they feel like they need to get involved with it and that hurts my job satisfaction. I need a boss with complementary skills to mine, not the skills I already have.
People have all different values and making absolute statements about them is folly.
That would be great, as long as the employee is motivated and smart enough to do great work, else it would be difficult for the manager to gauge employee's quality of contribution.
Right, employees have different values and different capabilities and should be managed differently. Saying "Employees are happier when [x]" always breaks down because employees aren't homogeneous.
Just because some dudes in suits or some bureaucracy academic had not talked about it yet it doesn't mean it's now been "discovered", don't fall for this trap. Everyone's who's experienced a virtuous workplace also "discovered" this as it's a self-evident truth(when it happens). How many times will we "discover" human nature again? Depending on psychologists, economists, administrators and business gurus, infinite times(corollary: we will keep on 'discovering' the same things because we never actually learn). Edit: To try and make it clearer: we are all human yet we systematically neglect our nature/ignore it in others and treat it as if it's a million pieces puzzle we can't figure out. Seems we're just looking at stuff ever more fractioned, we take 1/2, make it 1/10 and act like we made a +8 advancement in knowledge, but we haven't. Holism and shit. To me it's an example of the stupidity of modern thinking.
Indeed. So much of it comes down to behaving in a natural manner. It gets jumbled up because we've constructed artificial institutions on top of human society that don't comport with our natural behaviors.
Everyone understands these things fundamentally, but they pretend like they don't because we've set up a farcical structure and told them to play along or lose their well-being.
It's obvious that everyone wants a leader who has been in substantially similar shoes and done an acceptable job. That's the only way to have the credibility to boss someone around. That HBR pretends this instinctive truth is a revelation is typical of the haughtiness that makes people hate the bourgeoisie.
Humans are evolved to stay in fixed family units that expand only by marriage and child birth and contract only by death. The permanence afforded there allows humans to cooperate while also behaving naturally. The survival benefits of remaining in the tribe easily surpass emotional/personal benefits that could be had by fracturing off. There is no credible fear that expressing your feelings or otherwise behaving naturally will get you fired from your tribe.
It turns out people are quite fickle, and that if circumstances don't compel them to work together, lots of things get broken quickly. The modern corporation is a poor stand-in for the tribe.
Just because some dudes in suits or some bureaucracy academic had not talked about it yet
Well, as you know, things aren't true or factual until Science™ has confirmed it as such with a statistically significant quadruple-blind placebo trial. After all, many anecdotes from employees that they are happier with a competent and capable leader most certainly do NOT equal data.
There could possibly be some outside factor, like a competent and capable leader ensures the water-cooler filter is actually being changed on a monthly basis, which is really the reason for all that employee happiness.
I've always wondered if I can start a mgmt consulting company that exclusively focuses on doing Science™ that researches facts that are already known to be true to just about everyone outside the skeptical academic bubble. Just sit back and let the grant money roll in while I spend it producing papers and managerial books on things like "Can more advisers help your plans succeed?" or just about any other applied statement from the Biblical book of Proverbs.
This is also one of those "discoveries" that raises the suspicion hairs on the back of my neck. Survivor bias will play large into this. In particular, people often assume teams that failed had failed members. That goes up to the leadership.
So, it is likely that people were happy on successful teams. This will be a post-hoc explanation for why they were successful. Which will also be a post-hoc for why the members are happy.
I want to give this research the benefit of the doubt. So, please take my post as an overly pessimistic view of the landscape. Hopefully this will help persuade me otherwise.
And, as I can attest first hand along with more than a couple other employees, a highly incompetent boss can result in talent fleeing and the collapse of an entire functioning team responsible for millions in project bids annually.
I thought that was one of the nice touches in Better Off Ted. It turns out that Ted probably could fill in for any one of the team if he needed to, and the reason he didn't interfere more technically was just that (as a good manager) he was avoiding micromanaging.
True, their actual expertise is left kind of hand-wavey. On the one hand they can genetically engineer exploding pumpkins, on the other hand they can't fix their lab door alarm keypad. Maybe they're more biochem-based, but I digress... I don't think we ever learn enough about their skills to know what they can and can't do.
I was just thinking about this today. I'm usually happier when I'm doing things that I know my boss nearly-fully understands and when I know that they're able to work on it themselves if needed.
This not exactly surprising but yes, it's nice to be able to talk to your boss about the subtleties of my work. This is what makes work interesting. I hate when it's clear that all he is interested in are deadlines and budgets.
The only thing my manager is interested in, is if i solve their customers problems correctly. Most of them have little to no knowledge of computer systems. This usually applies to both the customer and the manager.
There are virtually no any other meaningful rewards than the paycheck.
It pays the bills, which is about the only reason i have this job anyway.
I've had a boss who was very competent technically, but was completely incompetent as a people manager. Somehow he rose to a VP level, but still wanted to micromanage everything down to individual code reviews. It was comical at times. Eventually he was fired.
Absolutely disagree. They need enough technical skills to understand gist of what is going on, but beyond that they should be deferring to the people on the team with the most relevant experience/expertise in technical questions.
The most important skill my boss can have is the ability to sweet talk his boss.
I disagree. A manager is not an individual contributor. It's important for them to have technical skills, but I don't think it's necessary they be on par with an average developer, let alone better than the best.
I had a similar experience but not sure the guy was ever fired. I ignored the soft skill deficit he had and enjoyed the fact that a manager cared about the code.
The real shame is that his boss didn't know how to manage him. Unfortunately, it's not unusual for middle managers to languish without decent coaching.
I feel like this often happens due to one or more of: a) the senior management chain was similarly not coached and so they wouldn't recognize a management failure if it bit them in the arse, b) the evaluation structures in place aren't suited to evaluating management types so bad management is "invisible" (e.g. skip level feedback), or c) there's an expectation that if you promote someone into management because they were a strong staff member at the line level, that they'll just automatically excel as a manager, too.
I suspect there are a lot of bad managers out there that could've avoided their fate with early intervention...
The most surprising part about this to me is that this matters at the top. Sure, for a middle manager it makes sense that it matters quite a bit. I'm pretty surprised that it matters much at the top, though.
If Elon Musk decided to head a major grocery chain I wouldn't stop to consider whether his lack of experience in retail groceries mattered much. But maybe it does?
Really interesting to see the analogy extend to sports, too. Professional sports teams, even successful ones, are almost universally run (coaches, GMs, etc.) by people who didn't play at a high level. Without actually pulling the numbers up, I'd estimate with high probability that the number of "all-stars" either managing or running teams is countable on one hand.
I mean, hell, this year's superbowl is being lead by two coaches who played D3 football, and one GM who played football for a Canadian university. One of said coaches is pretty universally considered one of the greatest coaches of all time.
For the most part these coaches/GMs absolutely could not do the job of the players on the field, nor could they ever.
But if you listen to his interviews, it's clear the guy has a nuanced, clear understanding of the technology and business model behind both Tesla and SpaceX. He may not be able to do every job, but he can do the job of his direct reports.
In contrast, there's the "professional manager" archetype, who Musk is definitely not.
Elon musk already proved his rigor and discipline with coding the zip2 product. It is in no way match to the rigour in management. So he gets lot of respect with other tech guys. Where as it's hard to take order from a manager who has never build anything.
But those lower level players still have strong knowledge of how to play, and probably tried just as hard as some top level players. They're not going to suddenly announce that they put some numbers in a spreadsheet and figured out that a 5 second 60 yard dash would guarantee victory, so it's time to start training for it.
In technical fields it's not uncommon for managers to ask people to do things that are literally impossible.
In a large company, the VPE isn't managing engineers. S/he is managing managers. If the VPE is capable of people management, project planning, etc. (the line manager's actual responsibilities) in addition to the VPE responsibilities (strategy, hiring pipeline, and the like), then the line managers will be happy. If the line manager is capable of building software, the engineers will be happy.
The VPE doesn't have to be a software engineer, just a decent people manager with enough tech background to not be completely lost when the line manager informs them that we need to make room for a couple extra weeks of maintenance in the schedule next year because our vendor is changing their API format and we'll need to rebuild the integration. (The line manager is the one who needs to understand what the engineer means when s/he says that the vendor is discontinuing their SOAP API in favor of a RESTful JSON API.)
Domain knowledge (groceries, space flight, whatever) is important to a degree for an exec involved in strategy decisions. But they need domain knowledge related to the current shape of the market and the pros and cons of currently available solutions - not the technical details of how those solutions work.
I don't understand what your point is, coaches are precisely an example of a boss having deep understanding of the work being done, as opposed to being hired purely for his people-management skills. You don't poach the manager of a retail chain to be your basketball coach.
Obviously a coach can't replace a player on the field, that's primarily because playing is more important and pays better than coaching at the top level, so no sports star wants to be "promoted" to a coach, they will coach once they can no longer play. And even then, being a coach is not necessarily the life goal for super-rich star athletes. It's a downgrade from what they used to be in their prime.
I remember being taught how to mop a floor by the store manager at a supermarket. It's a very small thing but it added to my positive feeling about the company.
This is why, all other things being equal, it's better for an engineer to work for an engineering driven company (Facebook) rather than a sales driven one (Oracle).
This is really interesting. I don't know if it reaches the level of detail necessary to understand how it influences lots of tech work.
E.g., "employees are far happier when they are led by people with deep expertise in the core activity of the business." Well, I have deep experience in IT and building websites, but I'm not a great programmer and I have had devs reporting to me who were concerned about that (so I've worked on supporting them in other ways).
This is very interesting, and rings true on many levels.
For one, it takes a certain level of competence to be able to differentiate between good and bad work. If your boss can't tell the difference between the two, workers will be rewarded/punished/promoted/fired based on some other metrics, which are likely to be unfair or even arbitrary.
Another, is that bosses and managers are responsible for providing guidance. If you have two ways to do something and aren't sure which is best, it's natural to go to your manager for advice. If you get the feeling that the advice you get is worthless (or even harmful), then you'll feel lost and unsupported.
And finally, in many organizations, the boss sets priorities. If he doesn't understand the work, he is likely to have unrealistic or actively harmful expectations. And you'll feel like you're wasting your time.
There is nothing more demotivating than realizing that the person in charge of making technical decisions has no idea what he is talking about. You have no authority to make good decisions or hope of explaining things to willfully ignorant management. All you can do is quietly implement their stupidity and hope to avoid the fallout.
I think one of the biggest saps of motivation in that situation is that even successes are meaningless. Because one instinctively doubts the whole thing then (even a broken clock is right twice a day, but it still doesn't make one feel great).
There is nothing more demotivating than realizing that the person in charge of making technical decisions has no idea what he is talking about.
Maybe it's simply a question of different semantics, but I've never worked at a place where my boss was in charge of making technical decisions. That is always done by whatever senior engineer is in charge of that particular project.
>A company that doesn't hire MBAs is one I want to work for.
Can you point to all the successful companies that make a conscious effort to not hire MBAs? Tough slog. Maybe these companies know something you don't?
But any company that eliminates candidates based simply off their degree is no company I want to work for.
I think it's probably a bit like Uncanny Valley this one; it goes from no understanding at all, slowly to increasing understanding but just before you get to "boss can do my job" you have "boss knows enough to be dangerous and counter productive"...
Yeah it probably depends on what the job is. If it's generally seen as skilled and prestigious then you'll get respect but if it's skilled but seems easy then you won't.
This is not true for a creative/synthesis/multi-functional/unconstrained design process.
I've been basing my career on acquiring skills/knowhow on being unique in my ability to synthesize different crafts together with a defined worldview (similar to a Meta Model in NLP).
Having a boss be able to do my job has often led to bike-shedding & lack of space to explore novel ideas. Since I have taken on clients that aren't able to build what I build, I have had room to perfect my craft & my process wilst learning how to communicate with others who do not share my knowledge.
It's been more satisfactory to find people that share my worldview but don't necessarily share my skillset. It's kindof like a tribe of ideology or spirit.
I thought this has more or less been identified in the software world. That also probably was the reason to grow people organically for management than bringing from the outside, more so for lower management positions.
What's with HN editors changing the title on this one from the actual title of the article ("If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work") to "
Employees are far happier when led by people with deep expertise"? The original title was far more descriptive.
HN mods have a really strong propensity for editing titles they consider either misleading or clickbaity. I guess this is supposed to be the latter. IMO they can be... overeager about it.
I agree with your comment. The new title seems to be taken from the article itself though (as opposed to just made up by someone).
"Using these three measures of supervisor competence, we found that employees are far happier when they are led by people with deep expertise in the core activity of the business."
I skimmed the comments and didn't see the following perspective so thought I would add it: one thing that makes it great for me to work with people with deep expertise is the ability to learn amazing things. I am willing to put up with a lot of 'management personality/quirks' if it comes with learning that is invaluable. I believe people who work with 'interesting' (sometimes abusive) chefs such as Gordon Ramsay may also share this motivation. However, this is just my opinion and I can't say that there is a general trend for this sort of thinking.
I based my comment on my personal experiences and also from reading Ramsay's biography. I have also read some anecdotes from people who worked with Jobs.
Ramsay's temper and abusiveness are legendary but people who work for him tend to stay with him for a long while; probably no correlation to subsequent success, I admit. That was the crux of my comment: the trade-off of putting up with a lot of quirks vs. learning things that you cannot learn anywhere else. Some people find the learning experience overrides the quirks to a certain point of personal tolerance.
Nothing more annoying than an incompetent co-worker or boss. I don't think you're alone in that regard. If someone is competent that means I can trust them to do the right thing. If they're incompetent it's a crapshoot and causes unnecessary stress. I guess that is not necessarily the same as deep expertise but it's hard to imagine someone with expertise who is also incompetent in that domain.
Yes, just because a boss is expert doesn't mean they're innovative. The best bosses, IMO, know the state of the art, the state of the practice (both cutting edge AND reliable), and place a high value on invention and creativity, esp. toward improving on the status quo. Support for learning and exploring AS PART OF THE JOB is central to that zeitgeist.
Missing from this study is the fact that we tend to project confidence, intelligence and wisdom on those that we like.
A staffers perception of the competence of their boss may mostly be a function of how much they like their boss.
Also - staffers may have no ability to judge the competence of a boss.
Example: boss is highly technical, nice, gives you good feedback, stays 'out of your hair' - and 'let's you do your job'.
Problem: you're all way behind schedule, and he's afraid to be unpopular by steering you and the team in the right direction. From a management perspective, he's failing, and causing the whole company to fail.
>"staffers may have no ability to judge the competence of a boss"
They often do. The biggest indicator is one you touched on... 'let's you do your job'. A good manager sets clear but fair expectations, and then works to shield you from roadblocks so you can get the job done as promptly as possible. In my experience it's easy to see this in action.
I agree that a worker can often reasonably evaluate their boss.
But unless you've been a director level person - with 'managers of people' working for you, it's easy to see how a 'well liked boss, who lets's their workers do their jobs' is often not the best manager.
Team staffers may think their job is to do ABC, but really it's XYZ. A dev may think it's his job to write 'quality software'. But the business objective may call for 'a quick iteration for demonstrative purposes'.
The staffer thinks he's 'doing his job', his boss lets him, but the business objectives are totally off.
>"But the business objective may call for 'a quick iteration for demonstrative purposes'."
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.
Is anybody surprised by this? A boss who can do your job can:
- Fill in when the team is busy. Ever seen the manager at McDonald's flipping burgers or frying fries? Some goes for any other manager, sometimes, they have to step into the code or read legal docs, or operate the machines.
- Provide a perspective that's likely to be relevant to you. He knows what it was like doing your job, and has a good guess as to where it's going. As opposed to simply imagining what you do.
- Understand push-back. A boss who isn't an expert will require explanation that an experienced boss will not. "We can't add this feature because it breaks our database schema". "Uhm what's a database schema?". Only so many times you can hear that from someone who supposed to be deciding things before you lose faith.
- Guess what the team wants. Better experience -> better guesses. Even if the boss hasn't done the work for a while.
- Give feedback beyond "work completed/not". Because they can see where the hurdles are before you complete, and they have an understanding of how big the problems you've solved are on the way to completion.
Looking at my experience, anytime I worked with someone who didn't have the technical understanding, the worst drops in morale happened when I felt something was obvious, but the person needed it explained. It would have been fine for a new staffer to ask, or a graduate, but not a decision maker.
The main annoyance was the issue of where costs could be cut. Some people I've worked with seemed to think that just by asking enough questions, some piece would show up that could be cut from the solution with no harm. And so they'd keep asking around about whether this-or-that was "really" necessary. And perhaps when you're not an expert you can't come up with new pieces or processes, so your line of questioning is inevitably towards slimming whatever is already there.
246 comments
[ 3.6 ms ] story [ 436 ms ] threadThis is one of those great discoveries that is hardly surprising and makes you wonder why it hadn't be seen before.
Honestly some of my worst work experiences were getting jerked around by a superior who completely failed to understand the work required to do my job.
When I worked in bigco as an analyst, the director and even managers were from a different era. The better ones knew excel to some extent but had no idea how to do sql or even excel automation which was a large part of what the analysts were required to do. Part of this is a rapid almost stepwise change in the work that is done, part of it is due to tech companies recruiting from a diverse set of industries.
In other industries like law, finance and accounting, most people start at the bottom and slowly work upwards so the skillset is more of a continuum up the hierarchy so it is feasible that your bosses can still do your job.
It used to be the same in other industries but that is fast changing. For instance, the top level accountants will have been studying at a time where bookkeeping was literally done in paper books...
Study of management and processes is not without merit, and the rants against MBAs can be one dimensional by not recognizing the benefits. But if that was all that it took, then the economy wouldn't "waste" medical doctors or highly skilled engineers in administrative functions.
Though MBAs have certainly been growing in popularity over the past few years.
It's not constant across the board, as there are plenty of IT companies that seem to be doing a decent job at promoting engineers. But then I read a lot of people here talking about "up or out" views of engineers who are above a certain age. It's complicated.
That makes sense to me actually, since you need to have a high level understanding of how businesses work and what stuff the C-suite needs to be doing in order to understand how to value a business.
The C-suite might be the one place where the "generic management skills" might actually be really useful. But middle management and day to day supervisory functions? You can't manage what you don't know, and if you don't understand the processes of the people you're managing you're blind.
It's when you put a recent MBA grad with 0 domain knowledge as the manager of these people where problems start.
And again, with the accountants. The crusty 60 year old accountant will still be able to read a report generated by a fresh college grad. He could even open the books and spot problems. Issues arise when you put someone who isn't an Accountant in charge of the other accountants.
More importantly, what he values in the team (for when it comes to promotions) is also likely to be off. And hence, you can end up in a situation where you don't get promoted despite being very good at your job.
Well, the traditional view of "management" is that it's a distinct job from "doing". Therefore, so the thinking goes, there is a distinct difference in skillsets, and thus the manager should be good at the managing bit, and the doer should be good at the doing bit.
The reality is that in order to effectively manage, you have to understand what the doers are actually doing.
Interestingly, this relates to a topic that came up yesterday about product managers (who are not "managers" in a traditional sense). Every time I see complaints about PMs, the root cause often starts with the PM not understanding how software is built and how developers work. Thus they disregard practical technical realities. Those folks describe as a "good" PM are often those with a technical background... who could, as it happens, do your job if needed.
There is an important distinction. An effective manager should understand the general process and what can be time sinks, but they don't have to understand extremely specific details of what each worker is working on at any given time. For example, a manager of a software team doesn't need to understand the idioms of the programming language used by the team or even be that effective of a programmer. Some of my best managers have been ex-software devs that understood architecture, requirements distillation, etc really well but wrote the ugliest code you would ever see. :)
Some of the worst bosses I had were technical people who had been promoted to upper management and couldn't let go of the tech stuff. My attitude towards them was that if they wanted to code then they could take a demotion (and give up those huge equity grants) and get down in the trenches. Otherwise they could STFU.
While this may be necessary it is definitely far from sufficient. Especially in academia, where my wife works, I've seen countless examples of people whom are perfectly competent research scientists becoming scarily incompetent managers.
I'd also claim the following: sometimes doers have to manage up or laterally. In that sense, a good doer must have some of the skills of a good manager, just as the reverse is true...
Actually it is not. One of the best bosses I ever had had no clue what I was doing. He was smart enough to admit that he didn't know how to do my job. He was excellent at his job though: figuring out who were good people and removing roadblocks from their way. He identified a few good programmers to do the technical interview part while he focused on are the people he was hiring good fits for the people he already had.
If you cannot have a great manager who will get out of your way, then a manager who understands what you are doing means at least when he tells you to do something it was probably what you were going to do anyway.
The worst boss I've ever seen took some programming classes as a door into management - he knew enough to be dangerous when telling programmers what to do, but not enough to be helpful.
Well, the HBR studies cited, here, indicate a correlation between a manager who could do their direct report's job and job satisfaction of that direct report.
It does not claim that this is necessary for direct report job satisfaction, only that it makes it more likely.
So, my comment could have been better phrased as:
The reality is that in order to effectively manage, it helps if they understand what the doers are actually doing.
If you cannot have a great manager who will get out of your way
I claim that knowing how to "get out of your way" is a necessary but not sufficient skillset in a "great" manager. Understanding how you do your job will better enable a manager to remove impediments and provide you with the right environment (both physical and technical) and right motivators to help you perform even better.
No one would claim that a football coach should try to handle the ball themselves (as per the manager you described in your last paragraph). But a coach that just stands back and lets the players play is only doing half their job (at best).
What you need is someone who will take care of the employees and jump on grenades of distraction so they can focus on their job. But you also have to have enough context to step back and say, "hmm... doing this would be best for the greater good - my team should take a look at this." It doesn't need to be the ability to do it themselves, but they have to have some.
A CEO, like Jeff Immelt of GE, cannot possibly know how to do all of the jobs of all of the people in the entire company. Yet, he somehow does a good job of leading GE.
For revolutionary products (truly revolutionary) the big picture person may be crucial.
The other dimensions, like detecting bullshit, help team members overcome insecurities, have courage to make impopular decisions, these are orthogonal but very important too, I think.
But this doesn't satisfy the original assertion, right? The article specifically references deep expertise. Taking some programming classes is not that.
I also had a boss who was very technical, but not a great politician or manager. It was nice being able to discuss the tech-side of things with him, but he didn't know how to get shit out of my way so I could get the job done. Nice guy, but I'd never want to work for him again.
I think a good boss knows their limitations, whether they be technical, political, managerial, etc. and knows how to delegate to the right people.
It became a symbiotic relationship where we'd bring business decisions to him, and he'd bring technical decisions to us.
OTOH, there's a certain amount of reassurance when you're working under someone who is much better at what you do than you are. You know you'll always have a resource you can grab if you find yourself up against a wall, and it allows you to respect that person even more.
So I understand why the conclusion would be what it is, but I agree with you wholeheartedly about not needing to "understand what the doers are actually doing" to be a good manager.
If the manager is technical and you raise a legitimate concern they know and understand the concern. If the manager isn't and doesn't trust the doers they will assume they are trying to get away with something or are lazy.
Honestly, I have a hunch most of this distinction comes down to trust between both parties.
I've had managers that were highly technical and it's a great experience to be able to learn technical skills from your manager. I've also had managers that were not technical with respect to the technology used on the project (i.e. couldn't do what the doers were doing) but they understood this, trusted us to get the job done, and it worked out. Both were very pleasant experiences.
Now, I've had non-technical AND non-trusting managers before and it was a miserable experience.
I'm a software engineer, and hiring managers has been a problem at every company I've worked at. You want someone who has written software earlier in their career, and has a degree in software engineering or similar. In other words, people who have chosen to spend a lot of time with computers -- devices that are very logical and literal.
But you also want someone who has good people skills. In other words, someone who chooses to spend a lot of time organizing other people, maybe was on the yearbook club in high school, that sort of thing.
And you don't want their knowledge of software construction to not be too out of date. So you want someone at a very specific point in their career, i.e. a few years after giving up coding.
Not sure I agree with that. A lot of todays best practices and workflows (and the tech to go with it), especially considering team and release management, simply weren't around or at least widespread even twenty years ago. You know, stuff like CI, TDD, DVCS etc. etc.
Are any of these concepts particularly difficult to understand for a seasoned developer?
I have a really hard time imagining that a C and SVN expert couldn't learn how to use git "well enough" in an afternoon, and effectively within a few days, for example.
In particular, the freaking author of git is an 80's C programmer and SVN expert...
Uh, and you know, just the creator of the Linux kernel...
Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn.
Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :)
And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
Of course, those cases are getting rare, but remember, we're talking about the statement "I think the fundamental principles of software engineering haven't changed a whole lot since [the 80's]".
SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing.
Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose.
In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop.
No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...
The way to get it back is thus: No non-developers ever manages a developer. This is how doctors keep their scam going.
I'm not quite convinced. My best bosses have been extremely hands off and my worst one was a techie through and through.
People have all different values and making absolute statements about them is folly.
Everyone understands these things fundamentally, but they pretend like they don't because we've set up a farcical structure and told them to play along or lose their well-being.
It's obvious that everyone wants a leader who has been in substantially similar shoes and done an acceptable job. That's the only way to have the credibility to boss someone around. That HBR pretends this instinctive truth is a revelation is typical of the haughtiness that makes people hate the bourgeoisie.
Humans are evolved to stay in fixed family units that expand only by marriage and child birth and contract only by death. The permanence afforded there allows humans to cooperate while also behaving naturally. The survival benefits of remaining in the tribe easily surpass emotional/personal benefits that could be had by fracturing off. There is no credible fear that expressing your feelings or otherwise behaving naturally will get you fired from your tribe.
It turns out people are quite fickle, and that if circumstances don't compel them to work together, lots of things get broken quickly. The modern corporation is a poor stand-in for the tribe.
Well, as you know, things aren't true or factual until Science™ has confirmed it as such with a statistically significant quadruple-blind placebo trial. After all, many anecdotes from employees that they are happier with a competent and capable leader most certainly do NOT equal data.
There could possibly be some outside factor, like a competent and capable leader ensures the water-cooler filter is actually being changed on a monthly basis, which is really the reason for all that employee happiness.
I've always wondered if I can start a mgmt consulting company that exclusively focuses on doing Science™ that researches facts that are already known to be true to just about everyone outside the skeptical academic bubble. Just sit back and let the grant money roll in while I spend it producing papers and managerial books on things like "Can more advisers help your plans succeed?" or just about any other applied statement from the Biblical book of Proverbs.
So, it is likely that people were happy on successful teams. This will be a post-hoc explanation for why they were successful. Which will also be a post-hoc for why the members are happy.
I want to give this research the benefit of the doubt. So, please take my post as an overly pessimistic view of the landscape. Hopefully this will help persuade me otherwise.
Such a great show. I rewatch it about once a year. Really wish it had at least one more season, though.
There are virtually no any other meaningful rewards than the paycheck.
It pays the bills, which is about the only reason i have this job anyway.
The most important skill my boss can have is the ability to sweet talk his boss.
* The developers they're managing.
I feel like this often happens due to one or more of: a) the senior management chain was similarly not coached and so they wouldn't recognize a management failure if it bit them in the arse, b) the evaluation structures in place aren't suited to evaluating management types so bad management is "invisible" (e.g. skip level feedback), or c) there's an expectation that if you promote someone into management because they were a strong staff member at the line level, that they'll just automatically excel as a manager, too.
I suspect there are a lot of bad managers out there that could've avoided their fate with early intervention...
If Elon Musk decided to head a major grocery chain I wouldn't stop to consider whether his lack of experience in retail groceries mattered much. But maybe it does?
Really interesting to see the analogy extend to sports, too. Professional sports teams, even successful ones, are almost universally run (coaches, GMs, etc.) by people who didn't play at a high level. Without actually pulling the numbers up, I'd estimate with high probability that the number of "all-stars" either managing or running teams is countable on one hand.
I mean, hell, this year's superbowl is being lead by two coaches who played D3 football, and one GM who played football for a Canadian university. One of said coaches is pretty universally considered one of the greatest coaches of all time.
For the most part these coaches/GMs absolutely could not do the job of the players on the field, nor could they ever.
In contrast, there's the "professional manager" archetype, who Musk is definitely not.
About 20% of the coaches in the NFL have played in the NFL.
However, what makes a person a great player doesn't make them a great coach. Usually the best players are insanely gifted at the physical level.
In technical fields it's not uncommon for managers to ask people to do things that are literally impossible.
The VPE doesn't have to be a software engineer, just a decent people manager with enough tech background to not be completely lost when the line manager informs them that we need to make room for a couple extra weeks of maintenance in the schedule next year because our vendor is changing their API format and we'll need to rebuild the integration. (The line manager is the one who needs to understand what the engineer means when s/he says that the vendor is discontinuing their SOAP API in favor of a RESTful JSON API.)
Domain knowledge (groceries, space flight, whatever) is important to a degree for an exec involved in strategy decisions. But they need domain knowledge related to the current shape of the market and the pros and cons of currently available solutions - not the technical details of how those solutions work.
Obviously a coach can't replace a player on the field, that's primarily because playing is more important and pays better than coaching at the top level, so no sports star wants to be "promoted" to a coach, they will coach once they can no longer play. And even then, being a coach is not necessarily the life goal for super-rich star athletes. It's a downgrade from what they used to be in their prime.
The opposite is probably true for a salesperson.
E.g., "employees are far happier when they are led by people with deep expertise in the core activity of the business." Well, I have deep experience in IT and building websites, but I'm not a great programmer and I have had devs reporting to me who were concerned about that (so I've worked on supporting them in other ways).
For one, it takes a certain level of competence to be able to differentiate between good and bad work. If your boss can't tell the difference between the two, workers will be rewarded/punished/promoted/fired based on some other metrics, which are likely to be unfair or even arbitrary.
Another, is that bosses and managers are responsible for providing guidance. If you have two ways to do something and aren't sure which is best, it's natural to go to your manager for advice. If you get the feeling that the advice you get is worthless (or even harmful), then you'll feel lost and unsupported.
And finally, in many organizations, the boss sets priorities. If he doesn't understand the work, he is likely to have unrealistic or actively harmful expectations. And you'll feel like you're wasting your time.
All of these things are terrible for morale.
Maybe it's simply a question of different semantics, but I've never worked at a place where my boss was in charge of making technical decisions. That is always done by whatever senior engineer is in charge of that particular project.
Certainly that's been my experience.
A company that doesn't hire MBAs is one I want to work for.
Can you point to all the successful companies that make a conscious effort to not hire MBAs? Tough slog. Maybe these companies know something you don't?
But any company that eliminates candidates based simply off their degree is no company I want to work for.
At my last offfice job the programmers doing graphics/OpenGL stuff got way more respect than the web developers.
A lot of people that don't know what you do will assume it's simple enough.
It's just not worth their time. That's why they never learned to do it.
For instance, I used to think sales and marketing were easy until I had to do it.
If your boss thinks his/her adolescent nephew can do your job, then he probably doesn't understand it and views it as a low skill position.
https://www.wikiwand.com/en/Scientific_management
This is not true for a creative/synthesis/multi-functional/unconstrained design process.
I've been basing my career on acquiring skills/knowhow on being unique in my ability to synthesize different crafts together with a defined worldview (similar to a Meta Model in NLP).
Having a boss be able to do my job has often led to bike-shedding & lack of space to explore novel ideas. Since I have taken on clients that aren't able to build what I build, I have had room to perfect my craft & my process wilst learning how to communicate with others who do not share my knowledge.
It's been more satisfactory to find people that share my worldview but don't necessarily share my skillset. It's kindof like a tribe of ideology or spirit.
"Using these three measures of supervisor competence, we found that employees are far happier when they are led by people with deep expertise in the core activity of the business."
Ramsay's temper and abusiveness are legendary but people who work for him tend to stay with him for a long while; probably no correlation to subsequent success, I admit. That was the crux of my comment: the trade-off of putting up with a lot of quirks vs. learning things that you cannot learn anywhere else. Some people find the learning experience overrides the quirks to a certain point of personal tolerance.
A staffers perception of the competence of their boss may mostly be a function of how much they like their boss.
Also - staffers may have no ability to judge the competence of a boss.
Example: boss is highly technical, nice, gives you good feedback, stays 'out of your hair' - and 'let's you do your job'.
Problem: you're all way behind schedule, and he's afraid to be unpopular by steering you and the team in the right direction. From a management perspective, he's failing, and causing the whole company to fail.
They often do. The biggest indicator is one you touched on... 'let's you do your job'. A good manager sets clear but fair expectations, and then works to shield you from roadblocks so you can get the job done as promptly as possible. In my experience it's easy to see this in action.
But unless you've been a director level person - with 'managers of people' working for you, it's easy to see how a 'well liked boss, who lets's their workers do their jobs' is often not the best manager.
Team staffers may think their job is to do ABC, but really it's XYZ. A dev may think it's his job to write 'quality software'. But the business objective may call for 'a quick iteration for demonstrative purposes'.
The staffer thinks he's 'doing his job', his boss lets him, but the business objectives are totally off.
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.
- Fill in when the team is busy. Ever seen the manager at McDonald's flipping burgers or frying fries? Some goes for any other manager, sometimes, they have to step into the code or read legal docs, or operate the machines.
- Provide a perspective that's likely to be relevant to you. He knows what it was like doing your job, and has a good guess as to where it's going. As opposed to simply imagining what you do.
- Understand push-back. A boss who isn't an expert will require explanation that an experienced boss will not. "We can't add this feature because it breaks our database schema". "Uhm what's a database schema?". Only so many times you can hear that from someone who supposed to be deciding things before you lose faith.
- Guess what the team wants. Better experience -> better guesses. Even if the boss hasn't done the work for a while.
- Give feedback beyond "work completed/not". Because they can see where the hurdles are before you complete, and they have an understanding of how big the problems you've solved are on the way to completion.
Looking at my experience, anytime I worked with someone who didn't have the technical understanding, the worst drops in morale happened when I felt something was obvious, but the person needed it explained. It would have been fine for a new staffer to ask, or a graduate, but not a decision maker.
The main annoyance was the issue of where costs could be cut. Some people I've worked with seemed to think that just by asking enough questions, some piece would show up that could be cut from the solution with no harm. And so they'd keep asking around about whether this-or-that was "really" necessary. And perhaps when you're not an expert you can't come up with new pieces or processes, so your line of questioning is inevitably towards slimming whatever is already there.