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