I think the conclusions miss the mark slightly and focus on a symptom of good bosses: they care about tasks from a state of understanding what is required to do them well, they have empathy for the challenges, and respect for the talent in completing them. Obviously the easiest way to get to this perspective is to experience it first-hand, hence the correlation between those who could do the job and being good managers of the job, but I don't see this as a requirement, just a common path.
I also don't see this a refutation that we shouldn't hire good engineers into management, rather we shouldn't do this blindly and as the single criteria. My best managers were all top quartile engineers but probably not top 5-10%, because they also cared about the non-technical requirements that a good manager needs to cover, and this inevitable consumes focus, effort and time that your best engineers don't want to allocate.
I'm a relatively new engineering manager (~3 years) and wrote about the traits of a good development manager from my perspective here:
> probably not top 5-10%, because they also cared about the non-technical requirements that a good manager needs to cover
It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.
From my perspective, as a relatively new technical manager who also spent years as an engineer working with technical managers, it's not only about empathy but also about having a thorough understanding of, or at least an accurate intuition around the subject matter. When I was working as an engineer, what I often found frustrating about working with non-technical managers is that they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project, or are relevant to the work, and often the team is led down a more difficult path than is necessary because requirements are set in the wrong terms.
I think it's possible to compensate to some degree with empathy and people skills, but it's hard to compete with having the experience and speaking the language.
> It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.
I see this sentiment or implication that technical skills and people skills are somehow mutually exclusive often, even on here which is crazy. I think this stems from some broader trope that people are "balanced" like RPG characters or something, e.g. nerd vs. jock or artist vs. scientist, salesman vs. accountant, etc. The reality is that people who achieve in one area are more likely to achieve in others. If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.
> The reality is that people who achieve in one area are more likely to achieve in others.
Aptitude is in general going to be either uncorrelated or positively correlated across different areas, but time invested is going to be negatively correlated. Hence the stereotype of nerds with poor social skills: building social skills takes time and effort, and time and effort spent on building those skills is time and effort not spent on, eg, improving your programming ability.
Of course, people who have off the charts aptitude will be in the top percentiles across the board. But you're not going to find too many organizations staffed entirely by those people.
The savant/nerd engineer with poor social skills is a troupe which does exist, but so is the manager who washed out of the developer track because they couldn't keep up on the technical side, and they're not a better manager than they were a developer but those failures are harder to quantify.
I think even that "poor social skills nerd" engineer trope might be partially an example of Berkson's Paradox [1]. You have to have serious technical chops to compensate for a lack of social skills, and it's hard to see all of the people with weak social skills who aren't engineers.
Yes, you make some good points here but I would argue that in most organizations that skills that make for effective engineering are aligned well with those required for managing. At a certain point, reinvesting into programming ability sees diminishing returns and ROI on e.g. mentorship, task planning and delegation out-paces improvement in technical skills dramatically. Of course, this is not universal and there are specialties, domains, and organizations that require technical competency and competitiveness above all else, but I don't think that's the general case for most engineers.
It's fun to be a "star player" developer, but in terms of maximizing your own individual potential, you're always going to be able to produce more value by leading people than by your own output alone.
There are some technical mountains to climb which require superlative engineering talent, but in terms of impact it's hard to compete with a leader who is able to coalesce a team or organization effectively towards a single goal.
> At a certain point, reinvesting into programming ability sees diminishing returns and ROI on e.g. mentorship, task planning and delegation out-paces improvement in technical skills dramatically.
True, but this may not be seen as relevant to the individual if they enjoy engineering more than those other things.
> But you're not going to find too many organizations staffed entirely by those people.
The number you are looking for here is zero, at least for organizations of any size. With a bunch of luck and money you can put a small team together like this; otherwise they are just too scarce.
They might. But it could easily take a few years, during which time they'll very likely be a mediocre to poor manager.
Expecting someone with five years of engineering experience to become an effective manager overnight - often with no training or mentorship at all - makes as much sense as expecting an intern to operate at the same level as a senior on Day 1.
Even really smart people with multiple talents need more of a warm up than that. And most people are neither that smart nor that talented.
But that's true of non-technical people too right? So the question is if you as an organization are considering investing a year or two to develop a manager, why not start with a subject matter expert?
Hopefully it is never an overnight switch and the engineer's career goals are respected. Any non-shite company is going to have engineers taking on leadership responsibilities at various levels they are comfortable with before turning them full loose.
In some companies, like Gore Industries, and other employee owned entities the engineers and operations people organically select their own supervisors by consensus and set pay democratically. I have been in environments that did that without explicit structure even, and it was very productive. Unsurprisingly,none of those were publicly traded.
> If someone figured out how to be a good engineer, they can probably figure out how to be a good manager, too, if they wanted.
The "if they wanted" part is key. It's hard to become extremely good at something unless you really enjoy doing it. I'd imagine that most people who are top engineers would rather be doing engineering than anything else. If you make them a manager, they're going to enjoy that less and not be as good at it -- but a lot of people get pressured into becoming managers nonetheless.
The cool part about being a technical manager is that you can expand the scale of what you are capable of. So for instance if you ever had an idea like "if only I had infinite time and infinite energy I would do X", you can build a team which has the tools to provide that.
If your goal is to have an impact, you have to be lucky to do this as an engineer. There has to be a structure around you which converts your work into value. As a manager it's much more reliable that you can be the person to create that structure.
> I'd imagine that most people who are top engineers would rather be doing engineering than anything else.
Really? I love software development, but I don't think just churning out random CRUD software based on some specs is very interesting. A lot nicer to solve problems of your customers, see how the product makes them happier and think about ways to improve their user experience.
If the top engineers at your company are churning out random CRUD software from specs, you may want to reconsider where you're working.
Good engineering is about understanding the problems of your customers, designing software that solves these problems, and improving their user experience.
I agree, when I was working with small companies this kind of thinking was all too common: Can we make a Twitter clone in a week? “Yes it’s just a backend and a frontend.” Vs “with support for 187 million active users? Which level of accessibility? Will we have a cloud provider? Media upload support? Redundancy? What kind of login functionality? Do we have support if they loose their email account? Why are you looking at me like that? You know what: no we can’t do it. No I don’t care that your grandson thought anyone can do it”.
The v1 isn't the hard part of building a competitor to Twitter. The hard part is scaling the user base, getting funding to keep the site running and being able to grow it.
heh in the consulting world it's pretty common to be in a situation of "i signed a contract to deliver a twitter clone in a week, here's the kickoff date. get started."
You can replace it with an in-house customer chat, if you feel the example is contrived.
But my point is, everything looks easy if you look at it shallowly, managers without professional programming experience will look at the problem from that angle.
The best will be able to help, the worst will have this shallow look and expect the moon by morning.
I agree, knowledge matters. It is pipe dream to think that empathy and people skills are enough for manager (or anyone) to compensate for lack of knowledge. Lack of technical knowledge does not imply neither peoples skills nor empathy. Technical knowledge does not imply lack of either
Moreover, I found that non-technical managers had often trouble in empathy and people skills departments. I think that a lot of issues stemmed from non-technical manager having basically inferiority complex, confusing disagreement with disrespect, being unable to distinguish between mistake and lie. Moreover, not understanding culture technical people tend to create or even not being aware that there is such a thing as difference of culture.
The cultural difference is a big thing - non-technical management in my experience value completely different things, ends up insulting engineers or otherwise creates difficult situations. All of that then implies that I as a programmer suddenly have to deal with interpersonal issues that manager created or is unable to deal with.
The thing is, the choice is not between non-technical person with people skills and technical without. The choice is between person with technical knowledge and one without, where the one without them has also disadvantages in peoples skills.
> having a thorough understanding of, or at least an accurate intuition around the subject matter.
> they often work on the wrong set of parameters. Discussions often revolve around details which are not really important to the success of the project,
There's a fairly large gap between those two positions. Personally, I'm a fan of a manager that knows enough to discuss the topic with me, but they don't need to know enough to analyze the problem itself. I want to be able to explain to my manager what the problem is, what the various solutions are, and which one I think is best and why. If they can understand all that, that's enough for me.
I agree with this up to a point. It’s been valuable to me as an IC, and I feel it’s a value I provide when the problem is so hard there isn’t a clear solution.
It’s nice to be able to say, “what do you think I should do?” as an IC, and nice to be able to analyze the problem if necessary as a manager.
On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.
> On the other hand if nobody knows what to do with a hard problem, everyone gets stressed out about it.
Those are the problems that it's the developer's job to figure out, in my opinion. If the manager can figure out the problem and solution but the developer cannot, then the dynamic is backwards (or the manager is actually a dev/tech lead, not a project/product manager). Or it's a totally different team structure than I'm used to.
The reason I think it's good to have a product/project manager who can get down to this level if needed is that it increases the scope of possible solutions. With a strict division between tech and product, typically the solution space is bounded by the product requirements. But if you have a product manager who is able to operate on the level of implementation details, you can adapt the requirements in ways which are better on both a user side and implementation side.
It shouldn't be the norm that a manager is operating on the level of implementation details, but it is good if they can understand them, because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
> because maybe they have more levers than the development team has access to in terms of unblocking a tricky issue.
I think I understand the disconnect here. From my point of view it's the manager's job to figure out what problem the client is trying to solve. It's the developer's job to figure out what the possible solutions are, and recommend what they think is the best one. As a developer, I expect to be in the meetings with the clients long before the solutions are chosen.
>top-tier engineers are not generally qualified in terms of non-technical requirements
It's just that both sets of somewhat orthogonal skills are less likely to reside in one person.
An analogy from baseball is why are pitchers generally lousy hitters (even pre-DH)? Did they get less practice? Probably. But it's also the case that (again even pre-DH) any ability to do more than lay down a bunt was absolutely a nice little bonus but their job 1 and 2 and 3 is pitching the ball.
On the other hand, even the best fielding shortstop in the league still needs to have a half-way decent batting average, even if they can get away with a lower one than other positions.
This analogy is interesting because it kind of proves you're both 'right', depending on the environment.
In middle/high school, there is often 'that kid' who _is_ the best at all skills - they are the pitcher, they bat cleanup, they do everything.
In the pros, though, that's virtually unheard of these days, because the amount of time it takes to specialize in a skill sufficiently to make it to the majors is so extreme it precludes you from being able to do that for multiple skills, with rare exceptions.
Not disagreeing with you, or at least I don't intend to, but I definitely remember playing against 'that kid' when I played baseball in middle and high school. Same analogy for the kid who's great at several sports in HS but has to specialize to get the DI scholarship or go pro, etc.
>it's not only about empathy but also about having a thorough understanding of, or at least an accurate intuition around the subject matter.
I read the OP with a very different takeaway than what you may have inferred. I did not get the impression they were saying empathy and technical skills are mutually exclusive. By saying their best managers were in the top quartile, they are implying they were technically competent but not necessarily the most competent in a single domain.
Yes and it can go especially poorly when you have a "problem oriented" person on the team:
1. Manager proposes low quality requirements
2. Problem oriented team member points out a flaw in the requirements which is orthogonal to the actual goal of the feature/team/organization
3. Endless discussion around this one detail
4a. Manager changes the requirements just to end the debate, in a way which sacrifices the core goal and weakens the product/team/organization when there is a simpler solution available to reach the core goal
OR
4b. Manager accepts an extremely complicated solution which maintains the specific requirement which was not required to reach the core goal in the first place, thereby risking the timeline
Oof. The number of 4b's I've had to deal with in my career...
What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.
A couple approaches I have seen which can be effective are:
- Call attention to the timeline and frame things in terms of specific tradeoffs: "Yes we can do A, but that means we won't have the time/resources to do B"
- Propose an incremental approach. I.e. "There are some technical challenges with achieving A+B+C, so what if we start with A, and then asses the best way to reach B and C."
With the incremental approach, I think this can help avoid the stakeholder feeling like they lost something, and 9 times out of 10 once you give them A they will find out that's all they needed in the first place, and they don't end up asking about B+C again.
little bit of caution on "Yes we can do A, but that means we won't have the time/resources to do B" - this, along with Agile method of squeezing work every two weeks will lead to simply mediocre quality hacked together deliverables and accumulation of technical debt.
Sometimes you need to spend time upfront and do it properly from the beginning, otehrwise the software quickly can become unmaintainable
> It sounds like you're saying that top-tier engineers are not generally qualified in terms of non-technical requirements, and I don't know that this assertion is justified.
True, but your top-10% engineer who's also a top-10% manager is going to be 10x rarer and harder to find.
And so will you then become a gradually worse leader as some of those engineering skills start to atrophy? The unfortunate truth is that you won't have the focus time to do large scale engineering tasks any more, unless you neglect your leadership responsibilities.
To be honest, I would love to work for a place that implements self management even half hartedly. My understanding is that Valve is like that. Valve may not make things on the schedule that people want them to - but no one can deny that their quality is supreme.
My perception is that valve has suffered some negative experiences due to bad actors interacting with its radically libertarian labour practices. I don't have insider knowledge, so I could be wrong, but this is the sense I have gotten reading articles over the years about how the IP for VR was handled for instance
No I don't keep a curated list of every random article I have ever read to offer hand-picked readings to strangers on the internet, but search engines exist if it's something you're interested in looking into.
Hey, why so passive aggressive? I've already read quite a bit on Valve googling it, just thought you might have some specific insightful article or thread in mind.
My first reaction was to disagree, but then I tried to remember the embodiment of 'not-ideal' manager and, in my mind at least, they are basically everything I am not, or at least not want to be.
Arguably my best manager had a graphic design and UI background. Where they excelled was having worked directly with software developers and non technical people for a decade they could understand the relevant tradeoffs without getting into the weeds.
However, former software developers where generally much better the deeper and more relevant their technical background. Seemingly because they understand what to prioritize, but perhaps it’s was simply easier to communicate with them.
A quote I stole from some conference talk that i think of all the time as a manager: "You become the manager you wish you had, you need to become the manager your reports wish you had."
I have come to the conclusion that management is not a profession. Engineering, law, medicine, teaching are professions, that is, occupations that require considerable training or study. Manager is a role in a team that requires you not to be deficient in social and organizational skills.
In settings where the people being managed are professionals, I have come to think that there should be a vote of no confidence option where a majority vote of the team can immediately remove the manager.
> there should be a vote of no confidence option where a majority vote of the team can immediately remove the manager.
Like in a band. Best projects I've worked on have been like bands. Each engineer skillfully playing their instrument, while the manager secures the gigs, promotes the band, listening and acting on feedback from the members.
My metaphor for my current team is a basketball team. Each player knows their role, how to pass the ball to the right person at the right time, and the team collectively adapts to challenges in real time. The manager's role is to look at the big picture, get the team the resources they need to succeed, and make strategic decisions to allow the team to succeed.
it's the opposite really, a good manager is rare because being a good manager is very very hard and takes an enormous amount of both study and experience. Being a good manager is like being a therapist for a dozen people with deadlines on mental health. The soft skills required cannot be acquired from reading the documentation.
But I think the parent comment's point is that this can be a very challenging job. A good manager's task is to absorb the chaos of the outside world, and give the team a calm, structured workflow. It's easy to see where a manager is failing, but if they're doing their job right their work is invisible.
Is somebody with empathy somebody with empathy or a pushover? The problem is the existence of architecture astronauts. How is a manager without technical skill going to distinguish between an engineer pointing out a real problem that needs some work versus the utterings of the architecture astronaut who is going to create an overly complex architecture just because he can get away with it?
I was personally taught by the store manager of a supermarket how to sweep the floor and of course that built respect for him and the organization. (e.g. he knew how to do every little task like sweep the floor, cut meat in the deli, bake bread, etc.)
The (now retied) director of the art museum at Cornell could be seen out in his suit passing out pamphlets for an exhibition together with students promoting clubs and concerts.
Go to the exhibition and he'll personally give a talk about the art that will help you appreciate anything from a suit of Samurai armor to Mark Lombardi's conspiracy diagrams. It's nice to see the top guy, who performs like a top guy, doing the simple work.
When I was in my teens, I got my first "real" job. It was working at a service station.
The station was a part of a chain of dozens. The owner was a well-known local multimillionaire. For whatever reason, he happened to be at my station on my first day at work.
He and I spent over an hour pumping gas, checking oil, doing an oil change, patching tires, and so forth.
I learned a lot more than simply how to work at a service station that day. I continued working at that station for over a year. Never saw the guy again. As I recall, when I started he had stores over half-a-dozen states.
I love this story and the owner is exemplifying the moral behavior I'd want to if I were in that place... However,
> Never saw the guy again.
It doesn't scale. If you have the knack to build a company like that, eventually you won't be able to touch the front lines of what your company is doing. Hopefully, having that type of leadership at the top creates emulation all the way down, but still, it rings of "die a hero or live long enough to become the villain"
The legend scales infinitely. You don't have to pump every gallon of gas, or write every line of code. But if everyone knows that you can, will, and often do...
At a certain point, you've got to stop pumping the gas. You want the company to outlive you. Gas needs to get pumped after you're gone. You fade into the background and replace yourself; others carry on your legacy. You cash out and ski six days a week or whatever.
Edit: some legends are bullshit. Scale that up and it's called "toxic culture".
I’m not quite sure that is true. If I believe that he’s pumping gas every day I’ll be happy. Whether he actually does so is irrelevant (as long as I don’t know, right).
If you are a leader in a field, and you have forgotten or no longer can do the work at the very lowest levels (for example, even something simply like mopping), you have lost an expertise that made you valuable in the first place.
One day a few years ago as I was walking into the Kirkland, WA Costco, I noticed a familiar-looking older guy pushing a line of shopping carts in from the parking lot. It was James Sinegal, then CEO of Costco.
A 'good' sea captain will also exhibit this trait and step in to perform tasks of necessity.
Since safety at sea comes in large part from 'simple work' being done rigorously, it is heartening to see the top man wiping down a slick deck to prevent the chance of accidents.
Don't forget the pirates/privateers of the caribbean. Captain was elected and removed at will by the crew. They freed slaves and distributed "wages" according to the level of contribution. The crews were diverse as hell. And they established a republic in Nassau...hundreds of years before the United States was formed. Of course, the companies (ships crew) robbed people and could be murderous at times, but the same could be said of "legitimate" less egalitarian companies of the time.
There is a dichotomy here. If an individual contributor is unclear whom they report to or what the product strategy is, then seeing the CTO contribute to numpy is not comforting.
As you say:
> It's nice to see the top guy, who performs like a top guy, doing the simple work.
The more junior you are, the more likely it is that not only can your boss do your job, they can do it better than you can. The more senior you become, the less likely that is to be the case.
How many CEOs could do all of the CFO, COO, CTO, and General Counsel's jobs? Zero.
How many programming team leads can do the junior programmer's job? Basically/hopefully all of them.
I think the point is not "your boss should be able to do your job better than you can", but "in a pinch, your boss would be able to step in and fill your role if needed".
Even in the case you gave, a good CEO might be able to do that. When you are at the C level, whatever the role is, you're probably going to mostly have to be good at stakeholder management, strategic thinking, listening to your peers and the people working under you and taking good decisions based on the inputs available. A good CEO should be able to step in and apply those skills outside of their domain of expertise, even if they are not going to be the best CFO/CTO in the world.
Technically, it means "your boss should be able to make decisions based on an informed understanding of what the work entails." Without that, management decisions are going to be based on who plays golf with whom, or most shiny consultant or marketer who crosses the threshold.
I've spent some time employed by organizations whose decisions are disconnected from day-to-day reality; train wrecks are fun to watch, but they get less fun when it's your job to ride the train into the brick wall.
The more senior you become, the more you should focus on being one of the leaders yourself instead of staying in individual-contributor mode. If that means you outstrip your own boss's expertise it might mean less personal satisfaction for you (been there done that) but can still improve satisfaction for the team as a whole.
This is not at all my experience (except CFO which has responsibilities not only on paper but in real life, where blame can’t be transferred) but I’m willing to chalk it up to culture differences.
Basically the more you see yourself as a “manager that facilitate work” the easier it is to go higher and the less expertise you need (social expertise exempted). Need something done? Hire someone to do it!
Is there a specialist under you that isn’t replaceable? Better keep him in his position!
I really wish we had what you seem to have though.
I think it's probably hard to rank them but being CFO also requires specific hard skills that you can't improvise on
A good COO will also have specific experience and therefore hard skills and easily outclass a general manager that's just winging it... but some operations are simpler than others, so the requirements associated with any of these C-level roles (including CFO and GC) are really on a spectrum
"This suggests that received wisdom about what makes a good boss may need some rethinking. It’s not uncommon to hear people assert that it’s a bad idea to promote an engineer to lead other engineers, or an editor to lead other editors. A good manager doesn’t need technical expertise, this argument goes, but rather, a mix of qualities like charisma, organizational skills, and emotional intelligence. Those qualities do matter, but what our research suggests is that the oft-overlooked quality of having technical expertise also matters enormously. ... 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."
This ... it is a total fantasy to think that the leader(s) of a company are somehow aware of all of the work that is entailed by every job in the company. For really small companies, or junior employees with a line manager, that may be true.
But as you said, the more senior you become, things completely change. There isn't a CEO in the world that could do all of the jobs they hire other executives to do (finance, sales, tax/accounting, HR, marketing, technology, operations, legal). It's impossible.
>There isn't a CEO in the world that could do all of the jobs they hire other executives to do (finance, sales, tax/accounting, HR, marketing, technology, operations, legal). It's impossible.
Impossible, yet accomplished by thousands and thousands of small business owners every month.
2-person startups often have someone called a CTO.
Similarly, a small business owner might call themself a CEO.
Neither is wrong per-se, but when we're talking about CEOs who have hired a team of executives to run their company, it's most reasonable to assume that GP was not talking about such a small business.
For sure, for very small companies or small/junior teams who have a line manager.
This also doesn't quite acknowledge that even if you can do all of those functions [in a small business or one-person company] it does not mean you're actually good at those jobs.
It's hard to manage if you don't have a clue about what you're managing. Every estimate looks equally realistic to you. You can't tell lies from the truth. Your own sense of other's performance is limited to easily faked "symptoms" of working hard, like spending a lot of time, or talking in meetings. You don't have to be good at the jobs beneath you to manage them, you just need a clue.
> Impossible, yet accomplished by thousands and thousands of small business owners every month.
It's an appealing thought, but really they are doing a different job. Vast majority of those thousands of small business owners couldn't effectively step into one of those roles at even a mid-sized corp, let alone all of them.
It's likely that they can do any one of them well (whichever function they came from), but not all of them. They can probably do a passable job at some other one, which means that for at least half of those executives, they have a boss who can't do their job.
Is worst nightmare the new normal? Various levels of management often handwave away a task because they understand its function at a high level. True quality management requires a deeper understanding of what it is you're managing.
I understand the function of creating, launching, and orbiting a satellite geosynchronously to do GPS so it's easy, right? Yea, not so much.
I'm a firm believer that you need to understand everything at least one layer deeper than high level functional descriptions so you can start to reason about the difficulty or amount of skill needed to accomplish something. You understand the real problems (even if only at the surface) and know where opportunity lies. With a pure functional perspective many current managers have, you simply can't reasonably manage and plan and are instead a glorified resource scheduler with whims.
I'll take it up a notch: all of the above + doesn't lift a finger and finds faults at everything you do. Add a bit of colonial superiority complex and its recipe for a job from hell.
And focuses most of their time and energy into brown nosing. Zero respect in either direction and an adversarial relationship by design any time you need resources from the company/higher-ups. /shudder
Another nightmare is needing your boss' help & not getting it because your boss simply chooses not to help. Early in my dev career I ended up w/ an smart, unhelpful manager. They were the only person in the company w/ Scala experience, and I needed to touch a Scala service as a fairly green developer. I asked my boss for help, and was denied. I later found out that my boss had recommended against hiring me during my interview, and I was still placed on their team. I did not like that job & quit after a few months.
Having said that, I am possibly a bit like your boss. I am a major bottleneck to my employees, and they struggle to overcome technical skill gaps between their knowledge and what they need to work on. Frequently I find they are blocked for days or weeks and when I finally get to sit down or spend time with them, their problem is sometimes solved within minutes. Sometimes I resent it because it's clear to me with some basic effort in learning new skills, they could get over these humps but they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help. It's really alien to me because as a young developer I would never have done that, I would just keep acquiring knowledge until I solve it (possibly taking a lot of time). While I'd never outright deny a direct request for help, I will often redirect where I think they can figure out the problem themselves with some investment in their own learning - "you need to learn about X, do some reading and tutorials, I think that will help", etc.
I am curious if you would have advice? Assume you can't solve the problem of actually getting your bosses' help (they simply have too many responsibilities to be helping at a micro level), how could one develop a culture of self-learning and proactive responsibility to progress things?
As their boss, could you ask them to document their problem, in something like Slab, to the point where it is clear what they are requesting (like a good, or great, request on Stack Overflow, rather than "I'm stuck"). Then they tag you, you do the minimum to pass it back to them (in the hope they can take it from there).
You then have documentation for the next guy.
Optionally, you could put an interim step where someone else on the team is given the chance to advance it; might keep it from your doorstep. But I don't know if that'd help in your situation!
I've assumed that the problem is with them, not you, as that's how you wrote it. But if you have (possibly) set a tone where their solutions work but not as well as yours and are switched because it's not done as well as you'd do it, then it's on you (possibly?)! :-)
That's a metaphor - of course you shouldn't treat your reports like children. But if they possess the following attitude, it's on you as the manager to let them know that it's not an acceptable practice on your team.
> they seem to take an attitude that if they hit something they don't already know, it's perfectly reasonable to stop progressing it and just declare they need help
This advice doesn't stand on its own; you'll need both more specific tactics and a broader strategy for dealing with the situation (providing tooling or scaffolding for improving their behavior). But the fact of the matter is that everything else you do for them won't matter if you condone this behavior - which you are, by allowing it to keep happening.
PS I am an engineer-turned-manager and this is easily the least favorite part of the job for me as I get used to it. But it is ultimately your responsibility to do so, and you are impeding your own ability to improve as a manager the longer you resist doing it.
thanks! (not just to you, but the other reply-ers).
Yes it is quite the learning exercise to get used to all of this and know where to be drawing lines, when to reinforce boundaries and when to let things go. What I am realising is that my threshold for giving direct feedback is way too high. I keep trying, instinctively to achieve outcomes indirectly - but way too often it doesn't work or even backfires and breeds more of the behavior I don't want.
I'm wondering if it would help to align incentives and motivations. I feel like right now it's possible your team members are not motivated to solve these problems. It seems like it might even be fine to be blocked for days or weeks. Not fine to you of course, but there doesn't seem to be a feedback loop right now. Note, I'm making assumptions here based on what you said.
What I like to do is to find the win-win for both me and my team members. If there's no reason for them to do better, why should they? Maybe you can get an understanding of what motivates them. Is it improving as an engineer? Better compensation? Getting promoted? I would imagine all of these are fairly easy to align with a goal of decreasing blocked time from weeks to hours. That's a huge difference in time!
I guess a lot of it comes down to what you expect of your employees. If you expect them to figure out it for themselves, and you give them enough time to do it, then maybe it's OK. If you are constantly demanding everything & offering nothing, then you have a problem.
My advice is that if you know what someone needs to work on, and they don't, just frikkin' say it. Don't wait until they are burned & trying to drag a merge request across the finish line. Also invest in tooling & processes that encourage people to figure things out & generally do better (which may be simply don't give them excuses to do worse).
This seems to the be the norm in tech companies, however I'm not saying it's an easy challenge to solve, since it seems unfeasible that everyone should know how do the coding/engineering job. Inevitably managers have to decide at some point to get off that bus, so to speak, and focus more on management skills, sacrificing the time needed to keep up with tech skills.
Working for an expert engineer is fun because their expectations are in line with reality, and they don't compel you to solve problems in stupid ways or in the wrong order, because they know how things should work. In any case they understand when to help and when to delegate to you.
Working for a bad engineer is the worst. They criticize smart or elegant solutions because they differ from the stupid way they would have done it. They try to dictate how everything is done because they think they know how, when all they really know is how to fuck things up.
Working for a smart person from a completely different discipline is fun. Say if you are programming CGI special effects for a movie director. They have respect for your different expertise and defer to you when needed. They find joy in your work because to them it's a kind of magic. They don't tell you to solve problems in stupid ways or the wrong order because it's not their area. It's fun that they request impossible tasks sometimes, because working out how to get close to the impossible dream they are imagining is how you get to do your best most innovative work.
Working for a inexperienced person from a different field is also fun. Although they don't know much, they know that, and won't dictate how your job should be done. They will still have appreciation of your expertise. They probably have unrealistic ideas about how long things take, and what is possible, but as long as they are willing to be guided, the project can still turn out OK. Their lack of knowledge of what's possible or how things normally work often leads them to come up with crazy new ideas, and working out how to make those real is my favorite thing.
The boss "should" be able to do most of your job BUT they Should not need/want to. Good bosses understand the word "delegation" and that is what it takes to build a real team and company. I am a boss and I can do most of my team's work (whether efficient or not) but I don't want to because I have higher priority things to do to get the most out of my time. For example, I can code but I don't (well mostly). I have a team of developers. I focus more on customers (existing and prospective). But then again, I have customer support folks who help with daily requests so that I am not answering every support question myself. Can I ? You bet. Would I ? Not if I want to scale my company further. If shit hits the fan, sure I will talk to a customer but I trust my team to take care of them before it gets to me.
Not saying that this is true in your case but I have seen this too often that managers think they can code just because they did it 10 years ago. It's surprisingly hard to write good code when you are not in practice.
The part that really matters is that you can empathize with the work that is being done. The more distance you have between you and actually ever doing that kind of task, the less that empathy is. It’s the same as with customers — if you never do the user studies, you will not understand even if you once did.
1. “Leaders must always set the highest standard. In a summer campaign, leaders must always endure their share of the sun and the heat and, in winter, the cold and the frost. In all labors, leaders must prove tireless if they want to enjoy the trust of their followers.”
2. "There is small risk a general will be regarded with contempt by those he leads, if, whatever he may have to preach, he shows himself best able to perform."
My direct boss, yes, absolutely he could do everything I do and perhaps even do it better. His mind is brilliant for being able to see the big picture and know the potential pitfalls. When I spitball ideas at how to solve a problem, he seems 5 steps ahead. With that said, he plays a different role. He is more like the arbiter between business and engineering. And I like him having that role.
With that said, I actually DO NOT want my C-suite to have coding prowess. I prefer them to be gifted in their areas. I love knowing that our CEO is one heck of an inspiring guy but I don't want him meddling in engineering. I'm sure he's smart enough that he could figure it out, but that would be a waste of his talent. Right now, his brilliance is evident in the people he's put into leadership. They're all experts of their domain. This frees him up to do more CEO things (like get our next round of funding)
My thinking has always been that great a manager should be able to go “one step down” and still do a competent but necessarily great job at any role that reports directly to them.
The CEO certainly shouldn’t be expected to have the skills of every expert across the entire organization. But if they were to be the executive in charge of Marketing/Sales/Engineering/whatever they’d ideally do a passable job. Now that is kinda unreasonable at the very top (CFOs and CLOs are very specialized roles) but from the VP level down it works out quite often.
> With that said, I actually DO NOT want my C-suite to have coding prowess. I prefer them to be gifted in their areas...This frees him up to do more CEO things (like get our next round of funding)
I think you're missing one thing here that makes it a little more analogous to your boss: not only should the CEO and your boss be good at their own jobs (e.g. securing funding), they should be good at their reports' jobs as well (just like yours is). Expertise that is 3+ layers down the org chart is completely irrelevant, of course, as you point out.
There are executive situations where there's a lot of specialized knowledge one level below where this doesn't quite work, but that should garner lots of extra attention.
In Japanese, 'Jyozu', the word for "good at doing ___", is the same as the word for "likes to do ___". I think the idea that these two distinct English concepts are in fact the same is very interesting.
Perhaps a significant effect is that people with deep expertise tend to be much more passionate about their job, because without passion they could not have developed deep expertise.
This is no surprise really. Any major company promotes managers from within unless they have a lot of industry experience. A bank manager would have a hard time being a manager at any FANNG company (on the engineering side at least) no matter how good they are with people...you have to have at least some in depth understanding of what the company and department does.
The best engineers don't usually make the best managers either because they have a hard time giving up control. Good managers let their staff do their jobs and give them the tools needed to excel (including mentoring and coaching).
I was actually looking forward to giving up some control as I became a manager. Unfortunately, we haven't hired anybody to fill the day to day void I left so I'm still doing my old job + now managing a small team.
You might have to be comfortable letting the void exist, and let your managers deal with the resulting failure. If you continue doing two jobs without escalating the issue, your employer is getting a great deal and has no incentive to correct the situation.
Get a linkedin login and start looking. Seems like recruiting either are focused on other teams, or don't have enough context. Both of those can be helped by you doing some lead generation.
what are u looking for exactly, a good place to attract talented developers is to post jobs on some slack workspaces, many programming languages/frameworks have dedicated slack work spaces where enthusiast developers like to hang out.
i find that people in smaller communities have richer technical skills and often are easier to work with
At GE the aviation engineers were the only ones that really seemed happy. They were all working under grey beard engineers who were by far the least pretentious managers. Everyone else was under someone from the encient GE Taylorist philosophy of "a good manager can run anything." Very painful uphill battle on anything because you literally had to translate everything into a message that informed them of how it was going to make them look good and advance their career. They simply don't understand or care about the work/product/customer. You could literally build amazing shit with a lot of support from colleagues etc and it didn't interest them because they had no foundation to recognize the potential. If you did manage to have one or two of your managers (I had five-ish) that did see the impact potential the rest of the hierarchy or "matrix" would smother it. Not to mention the clueless (horizontal) scrum masters.
Steve Jobs was probably the best team builder in tech (and maybe business) history with Apple v1, NeXT, and then Apple v2 and he learned this lesson well.
"We went through that stage at Apple where we thought, ‘Oh, we’re going to be a big company, let’s go out and hire professional management.’ We went out and hired a bunch of professional management; it didn’t work at all. Most of them were Bozos. They knew how to manage, but they didn’t know how to DO anything.
If you are a great person, why do you want to work for somebody you cannot learn anything from? And you know what’s interesting - you know what the best managers are? They are the great individual contributors who never ever wanted to be a manager, but decide they have to be a manager because no one else is able to do as good job as them."
I do think you can get the worst managers that way as well, and jobs at some points was one of the worst. You do need empathy and ways of handling underperformers that is not screaming at them hoping things will get better.
Not only that, but if tech matters to the company, and it increasingly does these days, the broader organization really needs to have some technical savvy in order to avoid a bunch of anti-patterns that are running wild in non-tech savvy organizations:
* Setting bad expectations with stakeholders and customers
* Taking on bad opportunities, committing the organization to unnecessary technical debt for no monetary gain
* Fracturing teams across competing opportunities
* Top down decrees issued from abstraction that causes organizational thrashing
* Decisions made in abstraction with no understanding of the stubborn technical constraints that block fruition
I don't know - in my experience as a programmer, when I work for somebody that's never worked as a programmer, they tend to estimate based on how long they wish something would take (which is usually an hour, two max). Ex-programmers turned managers who still code from time to time are far more realistic about how long something might take to complete.
> Ex-programmers turned managers who still code from time to time are far more realistic about how long something might take to complete.
Is that they had huge egos and thought they could do everything in much less time than I could, or would just "put in the time to make sure it was done when it had to be"
So nah, I prefer not having ex programmers as my manager.
I have my supervisor and my lead I work under. My lead fortunately is very good and understanding of these things, but he also is kind of like that as well.
My supervisor has absolutely no clue and just wants updates; thats all.
What if.. your boss doesn't know how to do your job, BUT he knows the requirements around it?
E.g. I am an amateur coder. Anyone who has typed 3 pages of code without looking up on a book or a website, is x100 better than me. If someone decides to make me the leader of coders, I won't tell them "I command you to use this syntax over that paremeter (?)" (coz I'm like Jon Snow.. I know nothing), but I WILL tell them to a) take daily backups/use version control, b) write comments on your code, c) do daily huddles, d) sit in pairs and review each other's code, e) some bright ideas/suggestions that THEY will make, f) I will bust my ... and try to study as many books/blogs/resources to learn the area (and managing coders better), g) I will talk to as many coders (young and old) as I can to understand them and their needs better.
Does that make me a good coder? Hell no! I didn't mention "read Java" in any of my aformentioned example. Will this make me a good manager? Well I have managed OTHER teams in & around IT.. why not coders? They are people too!
How do you “know the requirements around it” if you can’t code?
Imagine managing a team of diamond cutters and not being able to cut diamonds yourself... you would only recognize poorly cut diamonds after they had been cut and you would have no idea of how to help your team improve with specific recommendations and guidance.
I personally like your management style just based off of how your wrote that. I respect it a ton and as long as you give me the time and understand where my skills may or may not be at, I thrive in that environment. I try to give myself goals, but when things are ambiguous, it's very hard to do that. So long as you get that and that coding is just like any art form: It's done when it's done. You can't magically make a pot by smashing clay; you can't make the mona lisa by just tossing on paint. Since programming is logical, it requires a different way of thinking and often times it's as creative as an art form. Demanding it gets done by "X" is ignoring the fact that not everybody is Da Vinci.
From my personal experience, when people wish their manager was more technically capable, it indicates some management failure.
I am currently managed by a person who although has a technical background but for a long time is only doing management, so definitely can't do my job. And it is totally fine, because he's not making any technical decisions, these are made by technically excellent people.
Examples of management failures that I have seen on the other hand involve product managers and/or people with sales attitude playing product designers or solution engineer's roles. That doesn't end well and creates a lot of conflict between the management and the technical people.
combine this with Putt's law, and you understand hell.
"Technology is dominated by two types of people,
those who understand what they do not manage
and those who manage what they do not understand."
Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion."
with incompetence being "flushed out of the lower levels" of a technocratic hierarchy,
ensuring that technically competent people remain directly in charge of the actual technology while
those without technical competence move into management.
I couldnt agree more. A previous boss held a company wide meeting and everyone laid out their yearly goals. When he got to his it was something like establish channel partnerships. Very wishy washy and difficult to measure. I knew almost at that moment that I wasnt going to be at the company at the end of that year. He had decided his job was now to manage rather than do the job the rest of us were doing.
At a certain point that may be effective but we were not at that point.
From my experience you don’t need a manager to necessarily be an expert in their field, but it certainly does help.
When a manager lacks the expertise then what it comes down to is how much a manager is, 1. Willing to work hard to gain the necessary knowledge to be effective in their job, 2. Listen to their subordinates on matters they are less knowledgeable about and displaying a deep interest in truly understanding it.
What I have noticed is that if a non expert manager is not willing to do these two things what usually happens is they become yes men/women for upper management. They will agree to commitments that the team can’t necessarily meet (or in some cases will require them to work overtime), other times they will make the team cut corners or do things that are going to create a lot of problems down the road. When it comes to cleaning up the mess that was created, they have already moved onto to their next role leaving the clean up to their old reports and the next manager.
A manager that is an expert in the field they work in can do just as much damage as a non expert manager when they micro manager everything leaving little opportunities for growth.
Part of the problem is that a manager brought in without any relevant experience will often see their job as an exercise in making numbers bigger- they will attempt to cut costs and increase revenue in the short term without understanding which costs are really important or what the revenue is based on. This leads to brief increases in profit margins followed by customers fleeing to the competition, which the manager responds to with another round of cost cutting.
Even worse, the lack of deep understanding means that the manager cannot distinguish good ideas from bad ones, and often cannot distinguish talent from bluster, leading to poor hiring decisions and directionless leadership.
Everyone knows that putting a untrained business major in charge of a squadron of soldiers would end badly. He might be able skate by until they got into combat, maybe, but after that they wouldn’t listen to him for long. But for some reason we think that putting an mba in charge of an engineering team is a good idea.
People also prefer people of their own race, gender, age group, etc. It would be remarkable if they didn’t prefer people of the same educational and work experience.
Having had some absolutely horrible managers in tech the worst usually are the ones with lower technical expertise. The reason being is mainly related to understanding scope of work and the complexities of said projects.
That being said I also have had other really bad managers who were star IC's that were promoted to mgmt as they really had no where else to go in their career. These managers usually are clueless on dealing with people and other teams.
Given the right support, I've seen lower-knowledge managers really do well. I think a lot of the worse situations I've seen were when someone didn't realize their technical judgement was inapplicable or rusty, and that they needed to defer to their experts.
This is tricky, of course -- for low-level managers with typical engineer IC reports especially, it's super common for them not to have a single report whose judgement they can trust.
Deep expertise is absolutely crucial to properly scope projects, get the right requirements from stakeholders, understand level of effort and understand dependency trees. Basically ensuring that the objectives and work are well defined and the right engineers are working on the right pieces of it. I've seen projects fail for O(years) because the managers are not sufficiently technical to do this properly.
Since two of the measures of boss competence are entirely employee-rated the causality is likely to run both ways. i.e. regardless of their actual technical skill in your field and management abilities as assessed by others you are less likely to appraise your boss as competent at their own job and capable of doing your job if you're unhappy about the work they have asked you to do.
Personally, I would never work for a manager that had no skills other than "management" skills. I've been in a few organizations where every manager is hired from the outside and installed and they have no expertise in the area or the product itself. I've quit those companies quickly.
Like the Senate, you often need someone who can break ties. A team with an even number of technical people can get deadlocked on a decision. If the boss can’t or won’t step in, it can make for a miserable experience.
If I've learned anything from watching the Senate, it's that 51/49 doesn't drive forward progress. Those 49 will do everything in their power to undermine the 51.
If you find your team deadlocked on decisions and you think the way forward is to find a tie-breaking vote, I have bad news for you.
Work is not a democracy but some difficult decisions have to be. I think a lot of the time the arrow points the other way. A boss who can’t or won’t make decisions when pushed to do so also creates an environment where deciding is difficult.
Often all it takes is a qualitative comment that one could mistake for leadership, and the guy who won’t be accountable for any decisions is not leading anybody.
Yeah. Making a decision is the first step, but the life of the decision after it's made is vitally important. You can look at Congress getting stuff passed with split votes, but you can also see the other side digging in to undermine the decision. The Affordable Care Act is an example; it passed, it was implemented, but the Republicans are in court every month with a new challenge.
I think you want to aim for consensus building that doesn't have half of the stakeholders spending 100% of their time to get your decision reversed, basically. Maybe it's impossible to build a consensus, and you have to act. That's the value in the tie-breaking vote, and that's what Congress does. But we shouldn't try to model getting things done at work as an epic battle between Blue and Red. That level of polarization is toxic. Maybe Congress can't fix that problem, because they represent 328,000,000 people, but we can aim for something better in a smaller group.
Isn't this obvious? Just think about the converse: "employees are less happy when led by people who don't know anything about the matter at hand." Doesn't strike me as very insightful.
I think we should deconflict managers from leaders. Managers are people who facilitate employees' productivity and HR matters, whereas leaders trail-blaze priorities, philosophy, and mentor towards the actual work. The issue is trying to make a senior leader into both a leader and a manager, when these are very different skillsets and both take a great deal of time. IMO, it's better to do like Google by having managers that aren't micromanaging tasks but are there to provide assistance.
tl;dr: Let the leaders lead and the managers manage. It's nice when one person can do both well, but that's an unreasonable expectation for the amount of work involved.
I think this sentiment only applies to line level tech managers, where it's likely conceivable for that manager to be close to the work done by subordinates.
If you got higher in the org, the focus of managers become more strategic and process oriented, with stronger alignment with the business side of things.
Is anyone else so jaded because of bad managers that they don’t want to be managed? That’s how I feel. I’ve seen great engineer manager projects and tasks themselves, and the only use for a manager was to advocate for the promotion
I wonder if part of this includes a possible correlation between deep expertise and enthusiasm/passion for the subject matter, which is passed on throughout the team.
Clickbaity and utterly misleading title. I expected very different content, but I agree with the gist of the article, in that the boss must be highly competent at *his* job, know what he's talking about and stay grounded in reality.
The title of the post was changed after I submitted this comment. Earlier it was something like "if your boss could do your job, you're usually happier".
Anecdote: in one of the law firms whole departments were sent to LWOP due COVID-19 and department heads had to do all the work themselves. They found out that they are perfectly capable of singlehandedly doing the job of the whole department.
My take: if your boss can do your job, you're not needed.
> My take: if your boss can do your job, you're not needed.
If your boss can do your work, has the time to do your work (eg there isn't enough work), the work doesn't need to be done in parallel, and can do similar quality work, and is willing to do that work, you're not needed.
That's the takeaway, without oversimplification, which makes sense.
Agreed. If not, you could just as well have said "If a colleague can do your job, you're not needed."
It's actually an interesting point that. Oversimplified a bit, I feel there are two different ways that people measure their worth in the workplace. There is "no one else can do what I do" and then there's "I make sure that everything I do can be done by someone else".
> If a colleague can do your job, you're not needed.
I can program in ASM, since I did it in college. That's a different assertion from "if a colleague can do your job, you're not needed". ASM programmers are still needed. Also, there's the whole "making a baby in 1 month with 9 wombs doesn't work".
Then that boss is failing to scale his/her team properly. It's not really a point of pride if one person can singlehandedly replace all their reports, imo.
Seems like those department heads are bad at scaling up their department's services to adequately utilize the resources at their disposal. They're probably arrogant pricks who make everything flow through them anyway, meaning they're the bottleneck that caused the slowdown in the first place.
My boss can code better than I do, but he doesn't have the time, he's got CTO stuff to do instead. So I code and he CTOs, and everything tuns out well.
I also don't see this a refutation that we shouldn't hire good engineers into management, rather we shouldn't do this blindly and as the single criteria. My best managers were all top quartile engineers but probably not top 5-10%, because they also cared about the non-technical requirements that a good manager needs to cover, and this inevitable consumes focus, effort and time that your best engineers don't want to allocate.
I'm a relatively new engineering manager (~3 years) and wrote about the traits of a good development manager from my perspective here:
https://www.codeleadmanage.com/articles/20200204-four_qualit...