Employees are happier when led by people with deep expertise
hbr.org
hbr.org
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.
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.
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.
What?
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...
Do you write?
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.
Outstanding.
It's all about signals.
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.
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.
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.
Good engineers don't necessarily mean good managers
Unfortunately, the article neither publishes the dataset, nor goes into it in much depth.
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.
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.
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.
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.
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.
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.
Awesome reply.
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).
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.
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.
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.
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.
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.
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.
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.
You can't do real work without real experience.
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.
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.
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).
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.
Both management styles help the gears turn, but with the latter method you end up with more friction between the gears.
Just because he was an engineer doesn't mean he has any deep skills.
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.
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.
Disclaimer: am an individual GE stock holder so that may color my view here.
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.
When I worked in bigco as an analyst, the director and even managers were from a different era. The better ones knew excel to some extent but had no idea how to do sql or even excel automation which was a large part of what the analysts were required to do. Part of this is a rapid almost stepwise change in the work that is done, part of it is due to tech companies recruiting from a diverse set of industries.
In other industries like law, finance and accounting, most people start at the bottom and slowly work upwards so the skillset is more of a continuum up the hierarchy so it is feasible that your bosses can still do your job.
It used to be the same in other industries but that is fast changing. For instance, the top level accountants will have been studying at a time where bookkeeping was literally done in paper books...
Study of management and processes is not without merit, and the rants against MBAs can be one dimensional by not recognizing the benefits. But if that was all that it took, then the economy wouldn't "waste" medical doctors or highly skilled engineers in administrative functions.
Though MBAs have certainly been growing in popularity over the past few years.
It's not constant across the board, as there are plenty of IT companies that seem to be doing a decent job at promoting engineers. But then I read a lot of people here talking about "up or out" views of engineers who are above a certain age. It's complicated.
That makes sense to me actually, since you need to have a high level understanding of how businesses work and what stuff the C-suite needs to be doing in order to understand how to value a business.
The C-suite might be the one place where the "generic management skills" might actually be really useful. But middle management and day to day supervisory functions? You can't manage what you don't know, and if you don't understand the processes of the people you're managing you're blind.
It's when you put a recent MBA grad with 0 domain knowledge as the manager of these people where problems start.
And again, with the accountants. The crusty 60 year old accountant will still be able to read a report generated by a fresh college grad. He could even open the books and spot problems. Issues arise when you put someone who isn't an Accountant in charge of the other accountants.
More importantly, what he values in the team (for when it comes to promotions) is also likely to be off. And hence, you can end up in a situation where you don't get promoted despite being very good at your job.
Well, the traditional view of "management" is that it's a distinct job from "doing". Therefore, so the thinking goes, there is a distinct difference in skillsets, and thus the manager should be good at the managing bit, and the doer should be good at the doing bit.
The reality is that in order to effectively manage, you have to understand what the doers are actually doing.
Interestingly, this relates to a topic that came up yesterday about product managers (who are not "managers" in a traditional sense). Every time I see complaints about PMs, the root cause often starts with the PM not understanding how software is built and how developers work. Thus they disregard practical technical realities. Those folks describe as a "good" PM are often those with a technical background... who could, as it happens, do your job if needed.
There is an important distinction. An effective manager should understand the general process and what can be time sinks, but they don't have to understand extremely specific details of what each worker is working on at any given time. For example, a manager of a software team doesn't need to understand the idioms of the programming language used by the team or even be that effective of a programmer. Some of my best managers have been ex-software devs that understood architecture, requirements distillation, etc really well but wrote the ugliest code you would ever see. :)
Some of the worst bosses I had were technical people who had been promoted to upper management and couldn't let go of the tech stuff. My attitude towards them was that if they wanted to code then they could take a demotion (and give up those huge equity grants) and get down in the trenches. Otherwise they could STFU.
While this may be necessary it is definitely far from sufficient. Especially in academia, where my wife works, I've seen countless examples of people whom are perfectly competent research scientists becoming scarily incompetent managers.
I'd also claim the following: sometimes doers have to manage up or laterally. In that sense, a good doer must have some of the skills of a good manager, just as the reverse is true...
Actually it is not. One of the best bosses I ever had had no clue what I was doing. He was smart enough to admit that he didn't know how to do my job. He was excellent at his job though: figuring out who were good people and removing roadblocks from their way. He identified a few good programmers to do the technical interview part while he focused on are the people he was hiring good fits for the people he already had.
If you cannot have a great manager who will get out of your way, then a manager who understands what you are doing means at least when he tells you to do something it was probably what you were going to do anyway.
The worst boss I've ever seen took some programming classes as a door into management - he knew enough to be dangerous when telling programmers what to do, but not enough to be helpful.
Well, the HBR studies cited, here, indicate a correlation between a manager who could do their direct report's job and job satisfaction of that direct report.
It does not claim that this is necessary for direct report job satisfaction, only that it makes it more likely.
So, my comment could have been better phrased as:
The reality is that in order to effectively manage, it helps if they understand what the doers are actually doing.
If you cannot have a great manager who will get out of your way
I claim that knowing how to "get out of your way" is a necessary but not sufficient skillset in a "great" manager. Understanding how you do your job will better enable a manager to remove impediments and provide you with the right environment (both physical and technical) and right motivators to help you perform even better.
No one would claim that a football coach should try to handle the ball themselves (as per the manager you described in your last paragraph). But a coach that just stands back and lets the players play is only doing half their job (at best).
What you need is someone who will take care of the employees and jump on grenades of distraction so they can focus on their job. But you also have to have enough context to step back and say, "hmm... doing this would be best for the greater good - my team should take a look at this." It doesn't need to be the ability to do it themselves, but they have to have some.
A CEO, like Jeff Immelt of GE, cannot possibly know how to do all of the jobs of all of the people in the entire company. Yet, he somehow does a good job of leading GE.
For revolutionary products (truly revolutionary) the big picture person may be crucial.
The other dimensions, like detecting bullshit, help team members overcome insecurities, have courage to make impopular decisions, these are orthogonal but very important too, I think.
But this doesn't satisfy the original assertion, right? The article specifically references deep expertise. Taking some programming classes is not that.
I also had a boss who was very technical, but not a great politician or manager. It was nice being able to discuss the tech-side of things with him, but he didn't know how to get shit out of my way so I could get the job done. Nice guy, but I'd never want to work for him again.
I think a good boss knows their limitations, whether they be technical, political, managerial, etc. and knows how to delegate to the right people.
It became a symbiotic relationship where we'd bring business decisions to him, and he'd bring technical decisions to us.
OTOH, there's a certain amount of reassurance when you're working under someone who is much better at what you do than you are. You know you'll always have a resource you can grab if you find yourself up against a wall, and it allows you to respect that person even more.
So I understand why the conclusion would be what it is, but I agree with you wholeheartedly about not needing to "understand what the doers are actually doing" to be a good manager.
If the manager is technical and you raise a legitimate concern they know and understand the concern. If the manager isn't and doesn't trust the doers they will assume they are trying to get away with something or are lazy.
Honestly, I have a hunch most of this distinction comes down to trust between both parties.
I've had managers that were highly technical and it's a great experience to be able to learn technical skills from your manager. I've also had managers that were not technical with respect to the technology used on the project (i.e. couldn't do what the doers were doing) but they understood this, trusted us to get the job done, and it worked out. Both were very pleasant experiences.
Now, I've had non-technical AND non-trusting managers before and it was a miserable experience.
I'm a software engineer, and hiring managers has been a problem at every company I've worked at. You want someone who has written software earlier in their career, and has a degree in software engineering or similar. In other words, people who have chosen to spend a lot of time with computers -- devices that are very logical and literal.
But you also want someone who has good people skills. In other words, someone who chooses to spend a lot of time organizing other people, maybe was on the yearbook club in high school, that sort of thing.
And you don't want their knowledge of software construction to not be too out of date. So you want someone at a very specific point in their career, i.e. a few years after giving up coding.
Not sure I agree with that. A lot of todays best practices and workflows (and the tech to go with it), especially considering team and release management, simply weren't around or at least widespread even twenty years ago. You know, stuff like CI, TDD, DVCS etc. etc.
Are any of these concepts particularly difficult to understand for a seasoned developer?
I have a really hard time imagining that a C and SVN expert couldn't learn how to use git "well enough" in an afternoon, and effectively within a few days, for example.
In particular, the freaking author of git is an 80's C programmer and SVN expert...
Uh, and you know, just the creator of the Linux kernel...
Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn.
Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :)
And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
Of course, those cases are getting rare, but remember, we're talking about the statement "I think the fundamental principles of software engineering haven't changed a whole lot since [the 80's]".
SWE's desiderata then was to become an engineering process, where components were marshalled into a formal blueprint, and only THEN did implementation begin. And when implementatione ended, only THEN did testing begin. And only pro TESTERs do the testing. And only pro librarians did the project configuring and building and SCCS control and S/W maintenance and releasing.
Much of today's SWE is subsumed by the choice of programming tools, esp the language: its innate constraints its object model, its hierarchical library interdependence, and the sundry constraints & guidelines these impose.
In 1985 there was a LOT of discussion of how to introduce more proscriptive programming models as ways to shape how programmers think and design and implement. Today most of that discussion is moot, since most prog. languages implicitly enforce most of that (implementation) proscription. And where voids exist (as in design), language convention and idiom (and community bias) tend to step in to constrain choice to shape thought and close the loop.
No, I think SWE has changed enormously since the antedeluvian world views that wrought the invention of Ada or Beck's first writing on Agility. Perhaps for S/W devs under age ~50, who grew up in the mature world of OOPLs, unit testing, and 'Agile uber alles', that form of SWE seems to be inviolate and have existed since time began, perhaps discovered on clay tablets in an ancient Ark. But no...
The way to get it back is thus: No non-developers ever manages a developer. This is how doctors keep their scam going.
I'm not quite convinced. My best bosses have been extremely hands off and my worst one was a techie through and through.
People have all different values and making absolute statements about them is folly.
Everyone understands these things fundamentally, but they pretend like they don't because we've set up a farcical structure and told them to play along or lose their well-being.
It's obvious that everyone wants a leader who has been in substantially similar shoes and done an acceptable job. That's the only way to have the credibility to boss someone around. That HBR pretends this instinctive truth is a revelation is typical of the haughtiness that makes people hate the bourgeoisie.
Humans are evolved to stay in fixed family units that expand only by marriage and child birth and contract only by death. The permanence afforded there allows humans to cooperate while also behaving naturally. The survival benefits of remaining in the tribe easily surpass emotional/personal benefits that could be had by fracturing off. There is no credible fear that expressing your feelings or otherwise behaving naturally will get you fired from your tribe.
It turns out people are quite fickle, and that if circumstances don't compel them to work together, lots of things get broken quickly. The modern corporation is a poor stand-in for the tribe.
Well, as you know, things aren't true or factual until Science™ has confirmed it as such with a statistically significant quadruple-blind placebo trial. After all, many anecdotes from employees that they are happier with a competent and capable leader most certainly do NOT equal data.
There could possibly be some outside factor, like a competent and capable leader ensures the water-cooler filter is actually being changed on a monthly basis, which is really the reason for all that employee happiness.
I've always wondered if I can start a mgmt consulting company that exclusively focuses on doing Science™ that researches facts that are already known to be true to just about everyone outside the skeptical academic bubble. Just sit back and let the grant money roll in while I spend it producing papers and managerial books on things like "Can more advisers help your plans succeed?" or just about any other applied statement from the Biblical book of Proverbs.
So, it is likely that people were happy on successful teams. This will be a post-hoc explanation for why they were successful. Which will also be a post-hoc for why the members are happy.
I want to give this research the benefit of the doubt. So, please take my post as an overly pessimistic view of the landscape. Hopefully this will help persuade me otherwise.
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.
- 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.
For one, it takes a certain level of competence to be able to differentiate between good and bad work. If your boss can't tell the difference between the two, workers will be rewarded/punished/promoted/fired based on some other metrics, which are likely to be unfair or even arbitrary.
Another, is that bosses and managers are responsible for providing guidance. If you have two ways to do something and aren't sure which is best, it's natural to go to your manager for advice. If you get the feeling that the advice you get is worthless (or even harmful), then you'll feel lost and unsupported.
And finally, in many organizations, the boss sets priorities. If he doesn't understand the work, he is likely to have unrealistic or actively harmful expectations. And you'll feel like you're wasting your time.
All of these things are terrible for morale.
Maybe it's simply a question of different semantics, but I've never worked at a place where my boss was in charge of making technical decisions. That is always done by whatever senior engineer is in charge of that particular project.
"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."
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.
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.
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.
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.
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.
So they resort to success/motivational lingo without ever doing anything, hoping their BS is gonna blind the higher management until they retire.
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.
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.
Now I like to think that I can bend those systems to my will as well. :)
Good luck with your small business endeavors.
If Elon Musk decided to head a major grocery chain I wouldn't stop to consider whether his lack of experience in retail groceries mattered much. But maybe it does?
Really interesting to see the analogy extend to sports, too. Professional sports teams, even successful ones, are almost universally run (coaches, GMs, etc.) by people who didn't play at a high level. Without actually pulling the numbers up, I'd estimate with high probability that the number of "all-stars" either managing or running teams is countable on one hand.
I mean, hell, this year's superbowl is being lead by two coaches who played D3 football, and one GM who played football for a Canadian university. One of said coaches is pretty universally considered one of the greatest coaches of all time.
For the most part these coaches/GMs absolutely could not do the job of the players on the field, nor could they ever.
In contrast, there's the "professional manager" archetype, who Musk is definitely not.
About 20% of the coaches in the NFL have played in the NFL.
However, what makes a person a great player doesn't make them a great coach. Usually the best players are insanely gifted at the physical level.
In technical fields it's not uncommon for managers to ask people to do things that are literally impossible.
The VPE doesn't have to be a software engineer, just a decent people manager with enough tech background to not be completely lost when the line manager informs them that we need to make room for a couple extra weeks of maintenance in the schedule next year because our vendor is changing their API format and we'll need to rebuild the integration. (The line manager is the one who needs to understand what the engineer means when s/he says that the vendor is discontinuing their SOAP API in favor of a RESTful JSON API.)
Domain knowledge (groceries, space flight, whatever) is important to a degree for an exec involved in strategy decisions. But they need domain knowledge related to the current shape of the market and the pros and cons of currently available solutions - not the technical details of how those solutions work.
Obviously a coach can't replace a player on the field, that's primarily because playing is more important and pays better than coaching at the top level, so no sports star wants to be "promoted" to a coach, they will coach once they can no longer play. And even then, being a coach is not necessarily the life goal for super-rich star athletes. It's a downgrade from what they used to be in their prime.
The most important skill my boss can have is the ability to sweet talk his boss.
* The developers they're managing.
I feel like this often happens due to one or more of: a) the senior management chain was similarly not coached and so they wouldn't recognize a management failure if it bit them in the arse, b) the evaluation structures in place aren't suited to evaluating management types so bad management is "invisible" (e.g. skip level feedback), or c) there's an expectation that if you promote someone into management because they were a strong staff member at the line level, that they'll just automatically excel as a manager, too.
I suspect there are a lot of bad managers out there that could've avoided their fate with early intervention...
https://www.wikiwand.com/en/Scientific_management
This is not true for a creative/synthesis/multi-functional/unconstrained design process.
I've been basing my career on acquiring skills/knowhow on being unique in my ability to synthesize different crafts together with a defined worldview (similar to a Meta Model in NLP).
Having a boss be able to do my job has often led to bike-shedding & lack of space to explore novel ideas. Since I have taken on clients that aren't able to build what I build, I have had room to perfect my craft & my process wilst learning how to communicate with others who do not share my knowledge.
It's been more satisfactory to find people that share my worldview but don't necessarily share my skillset. It's kindof like a tribe of ideology or spirit.
The opposite is probably true for a salesperson.
Such a great show. I rewatch it about once a year. Really wish it had at least one more season, though.
Certainly that's been my experience.
A company that doesn't hire MBAs is one I want to work for.
Can you point to all the successful companies that make a conscious effort to not hire MBAs? Tough slog. Maybe these companies know something you don't?
But any company that eliminates candidates based simply off their degree is no company I want to work for.
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.
Or maybe I suck at my job and I don't know it!
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.
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).
No wonder Amazon is kicking their ass, and their last few product launches were nothing short of a disaster.
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.
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.
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.
A better title would be "businesses aren't truly agile until their leaders have deep expertise."
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.
At my last offfice job the programmers doing graphics/OpenGL stuff got way more respect than the web developers.
A lot of people that don't know what you do will assume it's simple enough.
It's just not worth their time. That's why they never learned to do it.
For instance, I used to think sales and marketing were easy until I had to do it.
If your boss thinks his/her adolescent nephew can do your job, then he probably doesn't understand it and views it as a low skill position.
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.
Curious to see how competence is objectively measured in this case.
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).
Which is it?
Looking back, this is the actual reason why I left my previous jobs.
A staffers perception of the competence of their boss may mostly be a function of how much they like their boss.
Also - staffers may have no ability to judge the competence of a boss.
Example: boss is highly technical, nice, gives you good feedback, stays 'out of your hair' - and 'let's you do your job'.
Problem: you're all way behind schedule, and he's afraid to be unpopular by steering you and the team in the right direction. From a management perspective, he's failing, and causing the whole company to fail.
They often do. The biggest indicator is one you touched on... 'let's you do your job'. A good manager sets clear but fair expectations, and then works to shield you from roadblocks so you can get the job done as promptly as possible. In my experience it's easy to see this in action.
But unless you've been a director level person - with 'managers of people' working for you, it's easy to see how a 'well liked boss, who lets's their workers do their jobs' is often not the best manager.
Team staffers may think their job is to do ABC, but really it's XYZ. A dev may think it's his job to write 'quality software'. But the business objective may call for 'a quick iteration for demonstrative purposes'.
The staffer thinks he's 'doing his job', his boss lets him, but the business objectives are totally off.
Most developers I've worked with are smart enough to know quick hacks are fine in small doses, but if they become the norm you end up with a great deal of technical debt, which can ultimately cripple the productivity of a company.
From the perspective of managers who aren't familiar with technical debt, the 'quick win' is always going to seem like the best option. It's up to the development team to strike a balance between 'the quick way' and 'the right way', and whilst some managers may get frustrated on the occasions when 'the right way' wins out, in the mid to long term they benefit too, though they may not understand why.