Hacker News new | past | comments | ask | show | jobs | submit login
Employees are happier when led by people with deep expertise (hbr.org)
756 points by reactor on Jan 25, 2017 | hide | past | web | favorite | 238 comments

At a unicorn I was working at, MBAs were being hired to be engineering managers. I did not see a single engineer promoted to management, it was mostly all MBAs. The few I had direct contact were really useless at helping engineers out, all I ever heard from them was "Just get it done.". If I asked for help, they'd say "Well who else is gonna do it then?".

I felt demoralised and lost some of my confidence. But the company was bleeding talent at the engineering level, plenty of engineers called out this crap and asked the CEO for answers. CEO would make excuses and not do much. Now the company is not doing well at all, even the senior leadership is leaving in droves, the CEO has even been replaced, the valuation has also declined quite a bit.

I am not in silicon valley, so not sure about there but over here, it seems to be a trend to have MBAs in all management positions above engineering and even CTOs of startups who are MBAs.

I had no interest in an MBA until I saw this trend. Now I am seriously considering that route, because it seems there is a serious glass ceiling. Doing an MBA might be necessary for me to move up the ranks.

One of my in-laws is a geologist who works for the oil companies, and he tells me in that industry almost all the big executives are engineers. Since he's been in the news, take Rex Tillerson. His degree is in engineering.

Or take any of "the professions": law, accounting, medicine, business consulting, engineering firms. In all those cases you have "partners" who have moved into sales and management. Sometimes they are even still practicing too. Also I get the impression their management is more about giving expert direction to their team, rather than watching Gantt charts.

Also when I read Skunk Works by Ben Rich, it sounded like the upper management had come up through engineering.

So I don't think management-by-MBAs is necessarily the right thing for tech workers. The more you consider programming to be "knowledge work", the more it seems like managers should be experts in the field. Of course they will need to learn new skills---to lead, to manage, to design products, to sell, to hire, to budget, to read financial statements, etc.---but having that technical background seems very important.

My hypothesis is that the MBA degree is largely valued by other people with MBA degrees, so you have pockets of high MBA concentration that grow within specific businesses. MBA's hire other MBA's, but also encourage their most promising subordinates to get MBA's.

> My hypothesis is that the MBA degree is largely valued by other people with MBA degrees, so you have pockets of high MBA concentration that grow within specific businesses.

I have a friend who got a specialist business degree and then got an MBA. I don't really recall him ever really talking about what he studied or learned during the MBA, but he did talk a lot about networking. A lot of the program consisted of taking many foreign "educational" trips all over the world (networking with classmates) and then access to the alumni network was supposed to help you get a job. It really sounded more like a high-class job placement club than an educational pursuit. If that's how it actually is, I can totally see how a business can get colonized by MBAs once one gets his foot in the door.

My friend himself is a good guy, but a couple of his classmates are some of the shallowest people I've ever met.

I have an undergrad in computer engineering, and an MBA from a top-10 or top-5 (depending who you ask) school. I learned a LOT from it, even though my experience after my undergrad degree was mostly in business.

Businesses, finance markets are far more complex than people usually think, and if you like to learn, an MBA is a great way to build a solid base for being a product manager, or a director who actually understands the sides of the company: how products are made, how they are sold/monetized/etc. and how to manage the overall structure of the company.

Sadly, I know a lot of great product managers, directors, etc. who are former engineers and have little understanding of competitive strategy, market forces, economics, marketing & finance.

In terms of learning, I took a generalist approach, but focused mostly on strategy & game theory, finance and technology. Here's some of the key things I learned, which I actually use frequently:

- Overconfidence bias: we usually think we're better than the average on something we know how to do (driving) and worse than the average in something we don't (juggling), even if almost nobody knows juggling and everyone knows how to drive

- No alpha (aka can't beat the market): you can only consistently beat the market if you're far better at financial analysis than a lot of people who do it every day all day. So don't bother trying.

- Value chain vs. profits: you'll find that most of the excess profits in the value chain of a product will be concentrated in the link that has the least competition

- Non-linearity of utility functions: the utility of item n of something is smaller than item n-1. Also, the utility of losing $1 is smaller than (1/1000) utility of losing 1000. This explains insurance and lotteries: using linear utility function, both have a negative payout, but they make sense when the utility function isn't linear

- Bullwhip effect in supply chain: a small variation in one link of the supply chain can cause massive impacts further up or down as those responsible for each link overreact to the variation (also explains a lot of traffic jams)

- Little's law: in supply chain (and a lot of other fields): number of units in a system = arrival rate * time in the system

Sadly, a lot of people in my class weren't that interested in learning, and focused solely on the networking and entertainment parts of the MBA.

Hate to be blunt, but first of all, the things you pointed out are really common knowledge/common sense, and secondly, most of these are not necessary to be an engineering manager at all. 'No alpha' is something that even Warren Buffet has been talking about, and it doesn't impact any EM's job day to day.

You'd be surprised how many great engineers I know don't actually follow that, either by believing they can pick stocks better than the market (false) or by thinking that you can derive economic profit simply by doing the same as everyone else in an industry.

There is a major difference between "knowing something" and having it ingrained in your thinking process so it happens seamlessly.

You don't need this to be an engineering manager, but you need this to be a good engineering manager. Knowing and dealing with your own (and other people's) biases, understanding how power works in organizations, how different pieces of an organization interact and how the products you are building impact the financials of the company are basic requirements (but not enough) to be a good engineering manager.

Agree to disagree I suppose. Engineers have the technical skills to look into basic financial and budgeting, and there are financial planning guys involved in big projects to do the really in depth stuff if required. A degree will not fix their unwillingness to learn, MBAs can be earned by going through the motions of the coursework. It happens in more technical degrees all the time.

As for the power dynamics stuff, firms in other professional fields do it all the time, and they don't seem to care about MBAs at all.

Lastly, a lot can be learnt on the job too. Maybe, statistically, engineers are more unlikely to show interest in this stuff, and that makes an MBA a "signal" that this person is interested in management.

It's a bloody expensive signal though, and it just saddens me that my career options and advancement might be limited because of it.

> Engineers have the technical skills to look into basic financial and budgeting, and there are financial planning guys involved in big projects to do the really in depth stuff if required.

If by "technical skills" you mean "being able do to math", you're as far away from finance as "pressing keys on the keyboard" is from "coding".

You don't need a degree to be an engineer, and you don't need a degree to be in "management". But that's not the point.

Book please. Link please. More please.

Awesome reply.

Most of the content was cases, with some parts of books, for example:

Biographies of Robert Moses and LBJ by Robert Caro - we used this for studies of power in organizations. We'd read parts of it and understand where these people would get their power from, how they would yield it, and so on.

A lot of it is hard to learn without discussions and debate, trying and getting it wrong, and figuring out where you got it wrong. Even some of the things I mentioned are never stated like that during the course, you kinda build that along the way (such as the link of the value chain example).

Can't these things be learned by reading?

Yes, they can, but you can only create "muscle memory" by practice. And practice includes reading cases, trying to figure things out and getting it wrong, discussing how to do it and so on.

You can read a hundred books about coding, but until you actually try, you don't really know anything.

So a technical background with an MBA can be a killer combination. You know how things work across the company, and that gives you a huge edge over everyone else.

That's fair!

Micro-/macroeconomics and computer science (queueing theory) could cover most of the key items ... but people would need to understand the connections / generalizations / limitations. Perhaps MBAs make it obvious with case studies and in-class debates.

I have BS in EE, went into software development and got an MBA after becoming a software manager. The two most impactful subjects that really changed the way I think were Queuing Theory and Real Options Valuations.

You don't need an MBA to learn about these yourself, but without an MBA I probably would have come across Queuing Theory (in the form of Kan Ban), but likely never Real Options Valuations.

So if anybody here is considering an MBA, look into both subjects and see if another half a dozen or so similar and related topics might be interesting to you.

Virtually everything can be learned by reading.

I am pretty sure you couldn't learn whitewater kayaking or downhill skiing from reading.

You can learn an incredible amount about those through reading, though it's slower than just doing it so most people don't.

As in all things for which you can be awarded a degree: yes.

Progressive political views work the same way.

As a more obscure example at a former nationwide financial services employer I was the only WAN engineer ever hired on to the team who wasn't involved in a specific niche of IPSC competitive handgun shooting. I got hired only because I was ex-military and the VP assumed I had experience with the 1911 platform (actually we had M9 by then) so I'd join the team once the paychecks rolled in.

Its an expression of human nature in general.

You don't think any of the skills needed to manage people or businesses can be taught in school?

I feel very fortunate that one of my cofounders has an MBA. We'd be much worse off if I had to build financial models and negotiate contracts and motivate the team myself.

Having an MBA obviously doesn't automatically qualify you to manage a dev team (nor does being a good engineer), but speaking from my first hand experience, the skills have value.

I think the ability to manage either people or businesses varies all over the map, and between techies and MBA's, maybe it's like a pair of overlapping distributions. For managing people, I think that there are both positive and negative skills, and I'm not sure MBA's learn exclusively one kind in the absence of the other. Stack ranking and open plan offices had to have come from somewhere.

Negotiating contracts is win-lose, so it's at best a coin toss.

I could see certain tasks being performed by someone who has shown a motivation to learn how, such as making business plans, schedules, and contracts. The MBA's at my workplace are certainly busy. But it could be selection bias: People with MBA's are selected from among people who want to learn those skills.

In big oil, most execs have a degree in engineering but they go up the ranks after they got their MBA's, look at Rex's replacement --> https://en.wikipedia.org/wiki/Darren_Woods

Unlike programming/software engineering most engineering managers in other domains have other work to do than just approve leaves/vacations and forward emails.

You can't do real work without real experience.

Tillerson's predecessor Lee Raymond (who had a far bigger impact on the industry) had a PhD in chemical engineering.

If you watch Noam Chomsky's 'Requiem for the American Dream' on Netflix it talks about how the heads of all these companies used to be engineers but at some point all the finance/MBA type of people started dominating these positions. This also happened in Washington and now essentially the whole world is owned/run by Finance/MBA types who focus on short term earnings instead of value creation.

Focus on is maybe slightly missing the point, they may not even have the background to appreciate or imagine the possibility of value creation that is not in their area of expertise. So certain possibilities are essentially invisible to those companies. It's made worse because it's the large successful corporations that actually have the resources to fix problems that few other players can even imagine (even with venture funding....).

So those companies (and the market, and society) may miss out on fundamental exploration and expansion of real-world productivity. Perhaps, this is a contributor in the curious drop in economic productivity despite, in theory, so much availability of new technology.

At points during the last decade, 40 pct of profits were made by the Finance sector. And companies like GE can make a billion dollars by lobbying for tax loopholes rather than creating new products. So this seems like the type of stuff they focus on.

GE gets too sweet of a tax deal, but out of many corporations to choose as an example, I don't think my comment applies as strongly to GE. Though they do work with financial matters, they've been backing away from finance as a central profit center, and refreshing their technology core (as exemplified by their divestment of a banking asset). Recently, GE is focused make strong investments in R&D and actually have been on a bit of a binge buying up many startups with advanced manufacturing capabilities. So they seem to have a strong technical vision that they're building towards.

Disclaimer: am an individual GE stock holder so that may color my view here.

When I worked outside of SV, I saw the same thing. Several engineers went off to schools nearby to get MBAs just so their careers could improve.

Once in SV though... I rarely see this. When you get an MBA, it's a huge signal to an employer that you accomplished something, and no amount of bad management can ignore that you were issued an MBA. I think job hopping in SV can accomplish the same type of signal.

> When you get an MBA, it's a huge signal to an employer that you accomplished something


That you bring some core competencies to the table that are actionable [1]. That you can calc the ROI on data-driven paradigm shifts [1]. That you can ensure there are enough boots on the ground to manage customer expectations. That you can peel the onion on our go-to markets and incentivize monetizable synergies leading to win-win solutions [2].

That you have become an irreplaceable employee, that you're a girl who gets up early, a girl who stays up late, a girl with uninterrupted prosperity, who uses a machete to cut through red tape, with fingernails that shine like justice, and a voice that is dark like tinted glass.

She is fast and thorough and sharp as a tack. She's touring the facility and picking up slack.

A girl with a smooth liquidation, a girl with good dividends.

A girl with a short skirt and a lonnnnng jacket [3].

[1] MBA jargon watch, pg 1, 2: http://www.johnsmurf.com/jargon.htm, http://www.johnsmurf.com/jargon2.htm

[2] 89 Business Cliches That Will Get Any MBA Promoted: http://www.forbes.com/sites/ericjackson/2012/06/19/89-busine...

[3] Cake - Short Skirt and Long Jacket : http://www.azlyrics.com/lyrics/cake/shortskirtlongjacket.htm...


I think I just had a flashback to some meetings where my EM would spout this jargon endlessly.

30,000 ft view indeed. No wonder the basic stuff never got fixed, when you're head's in the stratosphere, even a tornado on the ground doesn't seem to matter.

I think it's also of nonzero importance that an MBA ups the likelihood that you understand those terms of business art. As much as it pains me to stump for the MBA, being able to effectively communicate these concepts is important, and having an MBA doesn't preclude having been an engineering superstar with deep knowledge.

Comment started out good, then started to flag, then it went to the moon.


This might be the best comment I have ever read on HN.

This is the best comment on HN.

Paging @shit_hn_says after a 6 month hiatus...

Comment of the year.

Do you write?

Ha, thanks for inspiring me with your terse "What?" that made me laugh!

So much upvote.

I think the key word here is something.

Well, it's a signal, the meaning of which is up to the recipient.

It's all about signals.

Receiving an MBA.

This is the problem that remains unsolved for many businesses.

Good engineers don't necessarily make good managers. So they hire MBA's to be managers, but a MBA doesn't correlate to being a good manager either, in fact there is a chance that they may be a worse manager - because they don't do anything in particular (related to products that is).

So really when it comes down to it, hire managers who are good at managing people/processes and have some kind of real experience in your product or service. And in lieu of that hire a good manager who is smart and can pick it up, way down the line is hire a manager by their degree - if thats all they have going for them you are probably in for a painful ride.

Also a MBA is great if you pair it with a engineering background, but also be concerned about executives (CEO,etc) that can't sniff out people in their organization who would be a good manager regardless of background - some people have knack for management, like any other natural talent.

While I can't speak for what happened at this company. I think the problem is not "MBAs or engineers being managers" rather them not being good listeners.

And that is the point the HBR article is also missing. In my previous job, I had manager (ex-engineer) who would often say - "I don't even understand what are you talking about". But he would always listen patiently to us and even spend some of his personal time after office or weekends on google trying to understand the issue in depth. If he came across articles/links he thought could help us, he would email us. If he couldn't do that, he always approached the upper management to provide us training or help as required.

while in my recent job I had a manager (ex-engineer) who tried his best to come across as someone with "deep expertise". He would often google topics we wanted to discuss with him. The end result wasn't pretty. Lot of times he would make an assertion that he read somewhere that the design we were presenting was unworkable. Example: while talking about a design on "messaging queues" (MQ) using RabbitMQ he insisted on using Microsoft Outlook. It can handle so much daily load of message (email) volume he said.

That clearly isn't an example of a manager with deep technical expertise, its a poor engineer who has been promoted and is faking it. By the measures in the study he would not have counted as a deep knowledge engineer.

Just because he was an engineer doesn't mean he has any deep skills.

That's the difference between a manager trying to be the grease between all the gears of the team, and a manager who wants to provide a little extra force himself on every gear.

Both management styles help the gears turn, but with the latter method you end up with more friction between the gears.

I think the latter manager is a somewhat common example of a poor engineer who escapes engineering by moving to management, but then also makes a poor product/people manager to. Not that you have to be good at one to be good at the other, but some people just aren't good at either.

I suspect you're right.

The reason for the phenomenon this article is about is that deep expertise correlates with being a good listener when an engineer is describing a problem. But it isn't a necessary condition.

Agreed. The best manager I have had was non technical but at the end of the day he knew that his job was to defer to us on technical matters and make sure that there was nothing hindering us from getting things done, while ours was to get things done and making sure that we kept him updated on progress and blockers.

I know a bunch of mid-level guys that have part time MBAs that never really used them.

I think if you really want to be a leader/manager there are lots of opportunities to do so already. If you dont like being the boss, an MBA wont help you magically change you into a different person on a different (better) career track.

It does provide some useful skills for people that want to be managers, but most people I know that did the MBA just kept their same jobs and were happy to do so.

If you really want to be a top manager you might benefit.

Why don't you name the company?

Unless there is personally identifying information about you somewhere in your comment history, your comment would be so much more helpful with useful examples, especially for people that are familiar with the actual company.

Just my 2 cents.

It's flipkart.

Sounded very much like an Indian company. But I'd rather see OP mention the company name :)

Not sure if I should directly name. You can google my info and quickly find out which startup it is.

I have been lucky in my career to become an engineering leader/manager without having to go and get an MBA. But I still have the same concerns for continuing the climb up that proverbial ladder: what if I want to become the head of a large department? what if I want to become a CTO?

The raw truth of the matter is that it seems that having an MBA is likely the same litmus test as having a B.S. in computer science. Perhaps one can skirt around that requirement if they have a PhD in a particular subject matter that is the new sexy thing. But I still question if I should simply get an MBA, or focus on getting a PhD in research I am actually interested in.

Get the doctorate. Don't feed the trend if you don't want it to grow.

The MBA would probably be cheaper and definitely less of a commitment, especially an executive MBA.

Te reverse this trend, engineers really need to look at management as an important function. I don't see lawyers and doctors doing MBAs to move into management positions, but somehow, many engineers have this tendency of looking askance at management. That leaves the field open for outsiders to swoop in.

I think the aversion that most engineers have to management, is that software development is already a very nebulous beast. Actually delivering a solution that is called a "success" is often a slippery moving target. Being the one who is responsible for the project's success is even scarier.

You could say the same about a big legal case or a surgery. In both cases, lives can be on the line. Here it's just code.

It became scary for me when I saw extremely poor leadership that disregarded everything from Andy Grove's high output management. Forget that, I went through a series of YC lectures where speakers covered how startups should mature into companies, and even those simple management techniques were not being used.

In Silicon Valley it is rare that an engineering manager would have an MBA. And at Google or Facebook, they would more likely have a PhD than an MBA.

> I am not in silicon valley, so not sure about there but over here

From what I've seen here there are "product managers" and "engineering managers" and they have very different responsibilities (tho I don't fully understand the former yet).

I've never seen an MBA engineering manager before.

People have an uncanny affinity for the familiar. A company founded by MBA graduates will likely have a preference for more MBA graduates. Engineers prefer engineers. Use that to guide your selection process, but I've tried to find companies that value a balance.

I currently work under an MBA manager. It is very frustrating. Deadlines are unrealistic, micromanagement is the norm, and if things don't go according to their deadlines they threaten.

Sounds like a place run by people who owed a lot of favors

Do you want to move up? Don't you feel that becoming a manager (as opposite to individual contributor) will make you loose touch with the tech?

Unavoidably, but is "becoming a manager" the only definition of "moving up?"

Not at an employer you want to be at long term.

Unfortunately, the answer is "yes." I have avoided doing that and the only way I moved "up" was first to move around, then to move into a consulting firm, then finally to my own corporation that is also a consulting firm. Is that a viable career trajectory? I have made it work, but I long ago gave up the idea that I would be anything except an "independent contributor." I did look at jobs like "architect" but those jobs are holding pens for people who couldn't cut it as developers but had enough company knowledge to want to keep around. I don't know what most architects do all day, I've never had one actually help accomplish anything. They like meetings and conferences and overeating, it seems.

Tech is a badly broken field in terms of career advancement. For a long time it made me very jaded. But I'm rich now, so I could give a shit.

Maintaining contact with tech (as in engineering) may not be the success criterion.

There's a specific qualification called a Masters of Engineering Management. Maybe it needs to be more common.

I have one, but it isn't valued much by employers over here. They'd rather hire an experienced manager or a straight MBA. It was a very good experience though and I hope it will serve in the future.

It's now being discontinued at the university I studied and prospective students are now directed to the MBA program (I actually can get the MBA with a few more hours and paying a lot more money since I already have 95% of the coursework).

From what I have heard, engineering management is neither engineering nor management. :)

You should consider entrepreneurship. Climbing a corporate ladder is only one path to "success".

>> I did not see a single engineer promoted to management

Good engineers don't necessarily mean good managers

Being an engineer does not necessarily make you a bad manager though.

They don't, but my experience is more than half are good managers. The best ones I've found delegate by challenging their teams, but also follow up regularly on both an individual and team level. Even mediocre managers can be upgraded to effective managers if they're willing to learn from effective managers.

The goal post is not "good manager". It is just "better than non-technical managers"

isn't the entire point of this article the opposite?

I think the point is that having some level of technical skills is important, but I don't think it alone will let you be a good manager.

Unfortunately, the article neither publishes the dataset, nor goes into it in much depth.

Yeah sounds like Zenefits sucked.

MBAs are mostly worthless people that get churned out of business schools and have no ability for independent thought. What did you expect?

>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.

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.

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.

Actually it is not.

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.

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 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.

> 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 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.

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.

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.

>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...

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.

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 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.

If management was a science, 98% of the managers would not be able to understand it.

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.

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.

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.

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...

Sounds like the approach then was waterfall. If only we could apply the level of rigor and professionalism you describe to Agile...

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.


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...

> 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...

> 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. :)

A lot of todays best practices and workflows...

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.

Those aren't mere "implementation details". Those are aspects that influence the whole process, up to strategic decisions.

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]".

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.

Which I think can be compensated for if the manager focuses on just that, more humane issues. Of course, this can be done badly...

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.

It must have been somewhat surprises for you to have gone through it several times.

I'm not quite convinced. My best bosses have been extremely hands off and my worst one was a techie through and through.

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 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.

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.

Lets not forget- every lousy software architect needs a demolition crew to clean up behind him. ;)

I agree with you that I want to work with/for those sorts of people. I disagree that I want them as my boss.

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.

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.

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.

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.

All of these things are terrible for morale.

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.

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.

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."

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.

Amazon still has pockets of very deep expertise with highly technical leaders that make for very productive and profitable teams. I've personally worked with some OR and Economics teams that consistently deliver exceptional results for the bottom line. And I know that many of Amazon's best businesses have come (originally) from organizations like these: AWS, Kindle, Echo, etc.

But it very quickly is moving away from that idea and toward a world in which MBAs with half baked ideas that don't pass basic sanity checks are allowed to commit to impossible (P=NP!) ideas on behalf of their teams. And it destroys morale: nobody wants to work on a project that is known from the start to be impossible to deliver as specced. So they churn out.

And when you talk to the goon that is in charge of it all, the problem always magically seems to be that they can't hire fast enough.

It works both ways. In my first job I had the most intelligent and insightful boss I've ever encountered but I was too young and cocky to notice and the same went for my coworkers. We insulted him behind his back, ignored his suggestions to improve our work, ignored the fact that he was a truly interesting person who had some incredible stories to tell (his background was consumer electronics and radio comm's systems) and it wasn't until I left the company, travelled, grew wiser and older that I realized we as a team made him a pretty unhappy person and he wound up leaving the company to take a more junior role to save his sanity. The only reason he couldn't get rid of us was he wasn't respected by the owner of the (quite small) company and thus no real power beyond supervision. Work went out the door on time so everything was dandy.

Be careful judging others abilities through the lens of your own role in a company. Now that I've had two managerial roles I can see things from his perspective and often long to take a job where I'm simply judged on my own work rather than the sum of a collective.

Right now I am 36. I had a team- and tech-lead position for the first time in my carreer back when I was 28. All other programmers loved me (except 2 slackers who hated being asked for statuses, even if it was twice a month). QA was much better than before, frontenders were happy to receive clear directions and tasks while having some freedom in choosing designs. The devs from other teams loved interacting with me, I almost always had something interesting to share on how I do things, people were learning from me.

Things were swell. It was an extremely positive environment.

But I got demoted 7 or so months later simply because the other managers hated me. I didn't talk about charts showing increased amount of tickets per sprint resolved, about increased productivity, about how to make people more efficient via some BS measures that never really work (except maybe in a Chinese factory or in a pyramid-scheme marketing organization?). I knew how to make my people efficient and I was doing it. On the managerial meetings I was bored to tears and eventually I just told everybody in the room (including the CEO) -- "People. Why are we here on this meeting? I only see this as an excuse for everybody to congratulate themselves on how awesome you are. Speaking of which (at this point I pointed at 2 other managers) the only thing you ever managed to do was impede me by imposing waiting in inter-team communication for weeks while your devs are telling me they are idle and have nothing to do -- and you're also criticising my managerial techniques no matter the fact that in this 150+ people organization my team is the only one not behind schedule". Or something like that.

Needless to say, I got demoted -- and left the place -- shortly after.

Thinking of it 8 years later, I'd absolutely do the same but I'd use even more brutal language.

Management needs less BS. It doesn't deserve its current breed of slackers who licked bottoms most of their conscious lives to get to such a position and then they figured they'll unofficially retire at 40 while officially leeching salaries into their 60s (read: show up at the job but practially do nothing).

As any human system, inertia and credentialism are a huge problem. This has to change.

This is just my perspective. I've been in (increasingly) challenging engineering leadership roles over the past 5 or so years.

When I first started, I felt exactly like you do. That my job was to enable and empower my engineering team to build awesome product and that all the "management" stuff was a huge waste of time.

I received some advice from my boss that I was missing 50% of the job. You're being paid and expected to do the engineering leadership side on top of being the interface with the company for progress and business objectives. Any talented engineer with a modicum of people skills can usually do a halfway decent job of leading a small team to build a product, but it takes some business acumen to understand how your team fits into the bigger operating environment of your business.

That was the skill they expected you to bring to the table, and you not only despised it, you blew up at them in a meeting.

Granted, that company may very well have had a terrible meeting process and been looking at all the wrong KPIs for how things should work. But knowing how to positively influence that process inside the environment and doing so in a political way that preserves culture and existing team dynamics is crucial.

I hope you give that type of role another shot. The world needs better engineering leaders that can help businesses understand the value of a strong engineering culture.

Appreciate the feedback, thank you.

I had a pretty good idea on what was expected of me even back then. Truth be told, I would have cultivated the more business-oriented skills with time if the management environment wasn't so full of self-congratulatory practices and people patting themselves on the back -- while all of them know perfectly well they contributed no more than $500 to their employer's bottom line at the end of the month.

I plan on doing a small business of mine so I have no choice -- I will learn everything necessary from this point of view with time.

But in that particular environment I didn't care about helping those people at all. They were all there because the job was stable, well-paid and expected almost nothing of them. The CEO was an idiot who bought a very cheap "success lingo" all the time. These people didn't want any changes; that meant they had to work more which was the exact thing they were strongly against (and were sabotaging everyone who tried to introduce a more positive change like myself and one girl who was leading team of designers and frontenders).

Thank you for your kind words. Even being strongly dismissive of my own abilities (which IMO is important if one wants to always evolve and improve himself) I believe I would indeed be a valuable addition to a managerial roster but quite frankly, I don't want to be involved in politics and fighting with people who despise change.

I had to trick my brain into just enjoying it as a strange engineering discipline. I like to go through life imagining everything as a system to be programmed, so to me, business politics was just a different type of system in a programming language I had yet to learn.

Now I like to think that I can bend those systems to my will as well. :)

Good luck with your small business endeavors.

You often hear the idea that all business cares about is the "bottom line". I don't think that's true. IME, all businesses care about is ego with a heavy correlation to the bottom line. IME management doesn't care if they are making money, as long as they look like they are making money. Often the best way to look like you are making money is to make money, but sometimes it's easier to manipulate data sets...

That's exactly my point. "Fake till you make it" was their motto... for their entire carreers (lol).

So they resort to success/motivational lingo without ever doing anything, hoping their BS is gonna blind the higher management until they retire.

Although I was never demoted (I left), I completely see where you're coming from.

When I was a manager, I stripped away red-tape and created an environment which I felt gave engineers room for self-improvement - particularly if I could see that they were smart and ambitious and needed to be stretched. Since then I've been freelancing, however a few of my ex-colleagues from way back have told me that I was one of the best managers they'd had. The simple reason for this was that I'd concentrated on making sure they enjoyed their job.

Perhaps they were just being nice, but I know I've had similar experiences. The managers that I've enjoyed working with have always been the type that would remove menial work (this doesn't include hoarding all of the opportunities for high-level decision making which is a massive red-flag) and help you find opportunities to learn or explore the kind of work you're passionate in.

Non-technical managers often see somebody that's good at what they do as a resource that must be overseen and exploited for as much work output as possible. Bean-counting ensues and that person finds that they have next to no autonomy which causes them to resent their job and eventually leave.

>> Non-technical managers often see somebody that's good as a resource that must be overseen and endlessly exploited for as much work output as possible. Bean-counting ensues.

This is probably a highly subjective opinion, but IMO such people lack emotional intelligence -- not only technical expertise, or any idea on WHAT does it mean to actually work if you will.

I know this is less than flattering statement but it has been my face-to-face experience with such people. They were completely unable to execute casual human interaction outside of work, and I believe both phenomena (that plus the un-empathic view on their subordinates) are tightly linked together.

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.

Hiring MBAs at tech companies as managers directly managing engineers has not proved to be effective. MBAs have traditionally worked in finance, oil and other Wall Street companies and everyone thought that bringing in MBAs to tech world (partially pushed by investors) would be a good idea. As with any new experiment, you just have to wait and let the time decide the results. And it has been few good years now since MBAs have flooded tech industry and as many like minded engineers have experienced, MBAs with no technical background are a bust as your decision making managers. Sure they can thrive at duties such as managing supply chain management of a large tech companies such as Apple or Amazon. Or dealing with international clients where your "prized" skills such as charisma, emotional intelligence and thinking on the feet matters.

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 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.

>> Professional sports teams, even successful ones, are almost universally run (coaches, GMs, etc.) by people who didn't play at a high level.

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.

Did Elon Musk have a lot of experience in self-driving cars or space rockets before Tesla?

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.

obligatory Elon Musk SpaceX tour: https://www.youtube.com/watch?v=xahiWQQKw7Y

He has a degree in physics, which is the fundamental science behind cars and rockets (and batteries and heat management, etc).

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.

Maybe not experience, but he certainly had passion and interest in space. I don't think you could have consider him uninformed on the subjects.

Also an excellent point!

The study is about employee happiness, not about company success.

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.

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...

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.

Successful managers need both people and technical skills. That is why it isn't an easy job.

Actually technical skills and then people skills and in that order.

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.

* The developers they're managing.

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.

He just needed to learn to let go a little trust the people who work for him.

This may be true for an developer/administrator/maintainer in a "Scientific Management" (Taylorism) design process.


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.

By the same token, you're probably more likely to be happy at work if your boss knows nothing of your job, rather than a little.

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"...

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).

The opposite is probably true for a salesperson.

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.

Except the scientists, I don't think he could replicate their job. Otherwise, I can see it.

Such a great show. I rewatch it about once a year. Really wish it had at least one more season, though.

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.

So does this mean 'professional managers' are the root of most unhappiness at work?

Certainly that's been my experience.

A company that doesn't hire MBAs is one I want to work for.

>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.

May be all,the company needs to publish the number of MBA they have it will be easy to decide.

Me too

I'll throw in an alternative perspective:

I don't care so much about expertise, but about just raw intelligence.

Talk to a really smart person about your engineering problem, and even if they are not an engineer they will give you good advice.

Ditto for sales, marketing, etc.

I've always been happy when I can tell the person that is managing me is a few steps ahead of me, allows me to learn from them and actually makes my job easier.

To me, it's only a bonus if they can do my job better.

A really smart person would probably admit that they weren't the best person to deal with a problem outside of their own area of expertise.

Considering this is HN, I'll stick to the software/hardware field. While there is some truth to this, I disagree with the assertion that in order for a manager to be good, he "should be able to do your job". I fully agree that a manager for a technical team should have a technical background, and more specifically in the same broad field as the employee. Taking my own case, I am a scientific software developer, with lots of experience in Python, C etc. But as a manager of a team of software developers in different fields, I have no clue how to do web application development or devopsy type stuff, JavaScript, Kubernetes, Go and the like, which we use as well. However I hope I can still be a good manager because I understand the process of software development, I understand people and their needs (technical needs, motivational needs, professional development needs etc), and I can recognize good people when I see them, who can be leaders in their respective technical roles and mentors to others.

Or maybe I suck at my job and I don't know it!

I agree, but this is very tricky in the software development industry where things change so quickly. I went from senior to leading a team of 5 people. As soon as I started to lead, my technical skills started to atrophy. I've now switched companies and dropped back down to a Senior position because I need to build my skills back up. How do you navigate this?

If you know fundamentals things do not change that quickly. True paradigm shifts (such as FP) that require ground up revisit of internalized knowledge happen at a fairly stately pace.

It seems many take the negative perspective of this finding - anecdotes about moments where management "doesn't get it" and tying that back to their lack of technical expertise.

What's missing from the discussion is the underlying foundation of the finding: in an average case, if your manager has technical expertise in your field, you're likely to learn a lot from them - that learning (and growth) is a major driver of job satisfaction. It creates closer relationships through shared understanding/experiences as well.

I'd also argue that simply being able to do the job and not developing the team in technical expertise yields similar job satisfaction as not having deep technical expertise at all.

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).

I guess I have to be a little bit contrarian. Of course we want our managers to have good technical fluency and to not have to have everything explained to them. It's necessary but insufficient. The skill set of a good manager is different from the skill set of a good individual contributor. I've worked with way too many engineering managers who were great engineers but needed a lot of coaching in order to manage well. At lots of tech companies, you get managers this way: Roger is "smarter than the average bear" and we want to reward smart people, and the only promotion we know is management, so congratulations: Roger is now a manager! Go manage people, Roger! Go understand the business implications of your team's work. Go communicate effectively with execs. Go write a project plan. It's not that Roger is stupid--far from it, its that he is now in a role that requires a totally different skill set.

If you're talking about Flipkart, then it's not really a tech company as much as it is a retail company these days. So it is expected to have more MBAs in important positions, or in places where they can prioritize like an MBA.

No wonder Amazon is kicking their ass, and their last few product launches were nothing short of a disaster.

I think that startups are particularly susceptible to this, everyone else is sharing stories of MBA's in charge of software dev, but it happens in other areas as well.

I do work in performance marketing (very data driven, analytics, testing, etc.) and the new Chief Marketing Officer was someone from a big ad agency. He had worked with some really big names and bragged constantly about how he had had an ad play in the SuperBowl, etc.

Which was all great, but none of those skills translated down to a budget 1000X less than what he was used to dealing with. He was unprepared to think about things like a website's "Devcenter" as having a purpose beyond a branding exercise.

He wasn't a bad person or actually incompetent, but he didn't have the deep expertise in startup marketing that it would take to really see them succeed.

Oh my gosh, that's all I've wanted for years: a boss who knew at least as much as I did. Trying to persuade -- to be an agent of positive change or even just get anything done -- is all but impossible when you have to explain everything to someone before you can even begin a dialogue.

Well, yeah.

It's not that they can do the work (they shouldn't), it's that they can better relate to the people they're leading. They know, for example, that asking engineers to complete an arbitrary development task in two weeks without regard to scope, value or other work is completely unreasonable. They've been there. Managers without that experience (or even knowledge of that experience) can never relate, so when their managers ask for a thing and ask that it be done in two weeks (because we're doing "Agile"), they'll more than likely pass the buck down.

But as long as businesses are run by professional C-executives that don't even understand the business they're managing, this will be a problem.

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.

When leaders don't have expertise, we burn time educating them on fundamentals just to orient them on a decision that needs to be made.

A better title would be "businesses aren't truly agile until their leaders have deep expertise."

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.

A manager should be just a facilitator.

Our department manager at a previous company that I've worked for had economic background, while we were a Perl dev department. Basically, his job depended on our productivity, while our job depended on his ability to win projects. We had to trust each other that we were doing our jobs properly.

While we made sure he could make the customers happy with our work, he screened us from interactions with pesky customers and got us all we needed so we can focus entirely on the projects.

I worked with him for 5 years and we've been totally happy.

I actually think you get more respect if your boss (or his nephew) can't do your job.

At my last offfice job the programmers doing graphics/OpenGL stuff got way more respect than the web developers.

If your boss can do your job, then he understands its technical realities and the problems you may be facing.

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.

You would think so, but that's mostly not the case in practice.

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.

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.

Is it really about whether your boss can do your job or not, or whether your boss thinks your job is difficult or not?

A leader has to lead, it does not matter if the leader knows or does not know how to do the team's job. Those MBAs were not leaders, as simple as that.

However, a company does not need a lot of MBAs to function, 1 or 2 should be enough, dedicated to improve the business in general. That unicorn was very sick.

From the comments: "I'd bet a lot of workers who are unhappy for other reasons end up judging their supervisor to have low technical competence, making causality hard to determine."

Curious to see how competence is objectively measured in this case.

In my opinion, if the people who work with someone consider them incompetent, they likely are. I would even go so far to say that the opinion of coworkers might be the best predictor of someone's competence, better than any "objective" measure.

At least if the people you're asking are themselves competent in the skill they are judging (asking the dev team whether someone is good at sales might not be predictive).

So people like it better when the people in charge know what they're talking about. But people keep putting the ones that tell them what they want to hear in charge. And the two sets don't usually overlap much.

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.

Having worked with a boss who had never done our work, and one who had, I can assure everyone: There's a world of a difference!

First it states that business knowledge is most important. Than it states that deep tech knowledge is most important.

Which is it?

I think there's 2 different questions: Which one makes people happier? Which one makes people more successful? I was at a company where a CEO with deep experience in our field effectively stepped aside as they hired a CEO with deep experience in business. A lot of people didn't like it, even though the old CEO stayed around and was very involved. But looking back, the new CEO helped the company do very well. As I stated in a different comment, you need a balance. You need technical leadership and business leadership, and sometimes they need to be different people working together on the same team.

“People don’t quit bad jobs, they quit bad bosses"

Looking back, this is the actual reason why I left my previous jobs.

This is core to human leadership and has been detailed as far back as ancient Greece.

i think managers should be good at observing and linking cause to consequence. and use that experience to make good decisions. in the future we might be able to replace managers with AI.

There's probably some CAP theorem of management

So with Donald Trump as prez, I guess we're all gonna be very unhappy...

especially when they are flying on a plane.

this is a good article!

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact