>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.
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.
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...
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...
> Are any of these concepts particularly difficult to understand for a seasoned developer?
Depending on the personality of the developer: Absolutely. And most of the time it's not about the ability to understand, but the willingness to learn.
Yeah, it's a cliché, the old fart, set in their ways, "get off my lawn!1". I know, I'm guilty of it myself sometimes . :)
And it's one thing to learn some tech well enough to use it, and still another to grok the concepts and its ramifications, to actually get the whole picture of concepts, procedures and tools currently available to you, to be of help in higher-level planning and strategic decision-making. You know, all the stuff bosses are paid for. :)
Why does my boss have to know anything about that? The technical lead or senior developer(s) for each project should be the ones making decisions about those sorts of implementation details.
How do you figure? Why should my boss care about unit test frameworks and the relative merits of various TDD strategies. If he has some useful advice from previous projects then great. But otherwise, as long has we aren't having major problems, I don't expect him to interfere with those sorts of decisions. And if we are having major problems I expect him to sit the relevant people down and go "look, we're having too many regression bugs. Whatever you are doing with regards to testing isn't working, so let's come up with something better".
It's not about specific unit test frameworks or TDD strategies. It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
It's about the fact that thirty years ago, for all intents and purposes, there was no such thing as "unit test frameworks" or "test driven development".
Even if your boss has manged to get to today without even hearing about these concepts, hopefully there are other people on the team that have. And those people will decide on a testing strategy for the project. If your boss understand the details of that decision or not is isn't that important. What's important is that he lets the best people in room make the decision. Now if your boss decides to override and ignore those people, then that can be a problem, but that is problem due to a lack of managerial and people skills, not a problem due to a lack of technical skills.
That's cute.
Too bad when the project timeline doesn't fit, the teams themselves don't fit, etc. etc. Yeah, team members can decide all they want when they don't have any resources to work with, because the primary strategic decisions didn't account for the workflows people had in mind. And yes, I've seen that happen to otherwise great managers (who took the blame and readily admitted their lack of experience with the (then) new techniques and accommodate planning accordingly - but by then it was rather late in the project...).
Of course, those cases are getting rare, but remember, we're talking about the statement "I think the fundamental principles of software engineering haven't changed a whole lot since [the 80's]".
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.
This is also one of those "discoveries" that raises the suspicion hairs on the back of my neck. Survivor bias will play large into this. In particular, people often assume teams that failed had failed members. That goes up to the leadership.
So, it is likely that people were happy on successful teams. This will be a post-hoc explanation for why they were successful. Which will also be a post-hoc for why the members are happy.
I want to give this research the benefit of the doubt. So, please take my post as an overly pessimistic view of the landscape. Hopefully this will help persuade me otherwise.
And, as I can attest first hand along with more than a couple other employees, a highly incompetent boss can result in talent fleeing and the collapse of an entire functioning team responsible for millions in project bids annually.
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.