Is engineering management bullshit?(makeartwithpython.com)
makeartwithpython.com
Is engineering management bullshit?
https://www.makeartwithpython.com/blog/is-engineering-management-bullshit/
424 comments
I work with a lot of technical founders who struggle to accept the inevitable truth that taking the time to specify, coordinate, and resource what they want to do leaves no time to be the one doing any of those things. They eventually solve this problem by hiring other engineers to focus on the implementation step while they keep everything on the straight and narrow. When the company grows and they run out of time to directly supervise every engineer an engineering manager is born.
Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities then our company won't make money to pay anybody to write code. It's not chicken and egg, it's cart and horse.
If you don't want to become a marketing expert as well as a product design expert for the sake of doing all these things simultaneously consider being glad others are taking things off your plate and coordinating work without you so you can focus on writing code.
Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities then our company won't make money to pay anybody to write code. It's not chicken and egg, it's cart and horse.
If you don't want to become a marketing expert as well as a product design expert for the sake of doing all these things simultaneously consider being glad others are taking things off your plate and coordinating work without you so you can focus on writing code.
I think that a helpful abstraction is that writing code is just one of many "levers" that one can deploy to transform one's ideas into a massively impactful, scalable system. Writing specifications, unblocking colleagues, and building team culture are equally powerful and often provide even more leverage. And if it's 10x better leverage, even if you're a slightly less efficient manager than you were a coder, that can still result in a net enhancement in your team's ability to turn ideas into reality. Of course, this won't be for everyone, and one's enjoyment of the day-to-day is perhaps even a larger factor. But if what you enjoy is seeing things come alive, it can be worth taking the plunge into uncharted waters.
Over the first 10 years of a an engineers career they might only be exposed to a few different management roles. It's possible that the manager isn't fulfilling the actual role so what you have left with is just the distraction.
Regardless if the manager is helping the team they almost always drain resources to aggregate information that they can synthesize upstream. It's a system that is so fragile it's not hard to see why we have an industry full of people that experience this.
Regardless if the manager is helping the team they almost always drain resources to aggregate information that they can synthesize upstream. It's a system that is so fragile it's not hard to see why we have an industry full of people that experience this.
I think you'r point is that people with 10 or fewer years of experience (which I think is many people in this thread based on the comments) might have a sample bias issue that stems from working around fewer total managers and fewer companies, where those companies also may be worse than average at selecting managers? I would agree that there are probably plenty of people who fit that mold given the state of our industry recently.
As for "draining resources" to do whatever reporting they need to do I don't think I understand what is fragile about it or why it would be anything other than necessary. It's like log aggregation/introspection, you do it because you want to see what's going on at a lower level without dealing with the minutia of every point of data.
To this end as engineers we design code that fills management roles all the time in our systems, and we understand perfectly why their role is needed but sometimes fail to realize that human systems are analogous. Nobody is arguing why a load balancer can be an important part of a system, or the values provided by ORMs, but here we are arguing about what managers do in a complex human system.
As for "draining resources" to do whatever reporting they need to do I don't think I understand what is fragile about it or why it would be anything other than necessary. It's like log aggregation/introspection, you do it because you want to see what's going on at a lower level without dealing with the minutia of every point of data.
To this end as engineers we design code that fills management roles all the time in our systems, and we understand perfectly why their role is needed but sometimes fail to realize that human systems are analogous. Nobody is arguing why a load balancer can be an important part of a system, or the values provided by ORMs, but here we are arguing about what managers do in a complex human system.
or the values provided by ORMs
I'll point out that the world is pretty diverse and there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer. There's an interesting phenomenon that it seems like a lot of folks manage to build up reasonably long careers while only running into one side of this divide or the other and not even realize that the verdict on ORMs isn't a settled fact where one choice is always right.
Perhaps it's similar with engineering management and we should be having a more nuanced conversation.
I'll point out that the world is pretty diverse and there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer. There's an interesting phenomenon that it seems like a lot of folks manage to build up reasonably long careers while only running into one side of this divide or the other and not even realize that the verdict on ORMs isn't a settled fact where one choice is always right.
Perhaps it's similar with engineering management and we should be having a more nuanced conversation.
> there are actually lots of people who think that ORMs were a mistake and lots of people who think that using them is always a no-brainer.
This doesn’t mean that both groups are right though.
This doesn’t mean that both groups are right though.
I would argue that neither group is right. Both are myopic and only see things from a limited perspective.
Ironic. Correctness is indeed a curse on the few.
I see that the phrase "draining resources" can be taken to only mean a net negative. I was attempting to state that it takes time away from the team for the manager to function. That manager could see positive or negative returns on the time it took.
I still think there's an issue here just from the phrasing. "Taking time away from the team" implies that the team has better things to be doing. A manager isn't stealing a team's time by aggregating information to share upstream. A good manager is keeping the team aligned and informed so that they're working on the right thing at the right time. If the manager isn't there, the team needs to do that work, or be potentially wasting their time.
I see this as a rephrasing for a bias towards the management. Obviously a manager can completely waste the time of the team and company. Anecdotally I've had more managers do this than not that reported to me. I have been lucky with the people I've reported to myself especially earlier in my career.
>it takes time away from the team for the manager to function.
I think a more accurate take is that it can "drain resources" from the individual to provide a net positive impact to the team (ideally). The problem with a lot of the cynical takes here is they appear to be only considering the perspective of the individual.
It's like the idea that if somebody stops by my office to ask a question; it's great for them to get an answer, but a detriment to me because it interrupts my work. If all I cared about was personal productivity, I would lock my door but the overall team productivity would likely suffer. A good manager puts together a system/culture that balances all those competing goals to the betterment of the team.
I think a more accurate take is that it can "drain resources" from the individual to provide a net positive impact to the team (ideally). The problem with a lot of the cynical takes here is they appear to be only considering the perspective of the individual.
It's like the idea that if somebody stops by my office to ask a question; it's great for them to get an answer, but a detriment to me because it interrupts my work. If all I cared about was personal productivity, I would lock my door but the overall team productivity would likely suffer. A good manager puts together a system/culture that balances all those competing goals to the betterment of the team.
> they almost always drain resources to aggregate information
Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.
Took a 5min break? Move the damn story over to done. Got stuck and seeking clarity but are blocked? Leave a quick comment.
If your manager has to ask what’s going on, you’re not communicating enough.
Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.
Took a 5min break? Move the damn story over to done. Got stuck and seeking clarity but are blocked? Leave a quick comment.
If your manager has to ask what’s going on, you’re not communicating enough.
Sure, but none of this is free. That's all extra work that has to happen. The fact that I'm doing it in "down time" doesn't make it free, I have a million other things I could theoretically do at any given down time.
Not to say this work is necessarily not worth the cost, but it absolutely costs something.
Not to say this work is necessarily not worth the cost, but it absolutely costs something.
Of course, the managers don't rely on the ticketing system either, because not enough people are super diligent about updating the tickets.
> Here’s an idea: Provide this information before they have to ask, when it’s convenient for you. Like between tasks.
Sometimes that's all the manager wants, and the team lets them down. Sometimes the team takes hours estimating work that no one can reliably estimate, because management wants a burndown chart to feel good about, even though the last n burndown charts were wildly inaccurate.
As with any situation, issues happen at every level. What's unique to managers, though, is that they combine overwhelming power on the team with zero accountability to the team. Obviously when something goes wrong the team is going to be mad about it.
Sometimes that's all the manager wants, and the team lets them down. Sometimes the team takes hours estimating work that no one can reliably estimate, because management wants a burndown chart to feel good about, even though the last n burndown charts were wildly inaccurate.
As with any situation, issues happen at every level. What's unique to managers, though, is that they combine overwhelming power on the team with zero accountability to the team. Obviously when something goes wrong the team is going to be mad about it.
That is technically an idea.
> Engineers who don't appreciate the role of the product/marketing/management layers don't seem to understand that if they had to take on those responsibilities it would leave them with no time left over to write any code. If nobody takes on those responsibilities
Spending on marketing is like building and maintaining a nuclear arsenal in this respect: It is to everyone's detriment (yes, everyone) but if the competition does it, you must also.
Spending on marketing is like building and maintaining a nuclear arsenal in this respect: It is to everyone's detriment (yes, everyone) but if the competition does it, you must also.
Oh please, there's a reason why those comments exist - because more terrible managers exist than those "good ones" that you allude do. I would posit a guess that most, if not all, engineers on HN have had to live through at least one terrible manager that has soured/tainted the position. Speaking for myself, I've lived through many and it's a miserable experience to be under these people.
Nobody is saying that the functions of these roles aren't necessary, they're saying that the people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all.
Nobody is saying that the functions of these roles aren't necessary, they're saying that the people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all.
That’s silly. Managers exist on the same spectrum as any other role. Most are about average. Some are better, some are worse. Same with engineers themselves.
These articles are undoubtedly written by people who have never been managers themselves, and frankly just don’t have any idea what the job is for. Which is fine - everyone starts that way. But to then assume the job is useless is classic sign of imaturity.
> Nobody is saying that the functions of these roles aren't necessary
That’s literally the premise of the article posted.
These articles are undoubtedly written by people who have never been managers themselves, and frankly just don’t have any idea what the job is for. Which is fine - everyone starts that way. But to then assume the job is useless is classic sign of imaturity.
> Nobody is saying that the functions of these roles aren't necessary
That’s literally the premise of the article posted.
Maybe these articles are written by people who have never been managers themselves. I'd also posit that most of the defense of the position comes from managers. Do you not recognize the irony in this?
I'm sure you're aware of what they say: Its difficult to get someone to understand something when their paycheck depends on it. Do you have the self-awareness to recognize that this, alone, is a huge reason why managers immediately come to the defense of their position?
I've been in the industry for 20 years now. I've worked with good EMs; I've worked with bad EMs; I've been an EM (less often). That spectrum isn't even relevant to the underlying assertion that the core definition of the role is invalid. Its extremely rare to work with an EM whose entire scope of responsibilities wouldn't be more productively served by a peer PM. The only advantage to an EM title is in the organizational power structure, which is far too often leveraged to abuse their reports by trading quality output and mentorship for more working hours, burnout, and Jira graphs.
I'm sure you're aware of what they say: Its difficult to get someone to understand something when their paycheck depends on it. Do you have the self-awareness to recognize that this, alone, is a huge reason why managers immediately come to the defense of their position?
I've been in the industry for 20 years now. I've worked with good EMs; I've worked with bad EMs; I've been an EM (less often). That spectrum isn't even relevant to the underlying assertion that the core definition of the role is invalid. Its extremely rare to work with an EM whose entire scope of responsibilities wouldn't be more productively served by a peer PM. The only advantage to an EM title is in the organizational power structure, which is far too often leveraged to abuse their reports by trading quality output and mentorship for more working hours, burnout, and Jira graphs.
This is interesting. What, in your opinion, should the core definition be (if anything)? And how is that eroded when tasked to an engineering manager vs. a project manager?
One of the major issues I have with the article is they lean heavily on the "creative work can't be managed like manufacturing widgets" train of thought. It feels to me that they define developers as artists when the article is about engineering. I think those are different roles are different. Even though both require a certain amount of creativity/subjectivity, it's a mistake IMO to conflate the two.
One of the major issues I have with the article is they lean heavily on the "creative work can't be managed like manufacturing widgets" train of thought. It feels to me that they define developers as artists when the article is about engineering. I think those are different roles are different. Even though both require a certain amount of creativity/subjectivity, it's a mistake IMO to conflate the two.
A Project Manager is a non-executive role. They facilitate the flow of information that keeps a project on track, including reporting progress up.
A Technical Lead, Design Lead, and/or Product Lead is the final arbiter of executive decisions about how a project will be completed.
A Coach meets regularly with ICs to help debug workflows and interpersonal issues.
A Manager signs paychecks, and takes responsibility for the work actually getting done professionally, reporting to HR when it’s not and taking action on behalf if The Company when needed. They are the legally responsible person for the things happening underneath them in the org chart. In an ideal week they do nothing at all.
Engineering Managers tend to do some combination of all of these things, usually most of them poorly since that’s way too much work for a single individual.
A Technical Lead, Design Lead, and/or Product Lead is the final arbiter of executive decisions about how a project will be completed.
A Coach meets regularly with ICs to help debug workflows and interpersonal issues.
A Manager signs paychecks, and takes responsibility for the work actually getting done professionally, reporting to HR when it’s not and taking action on behalf if The Company when needed. They are the legally responsible person for the things happening underneath them in the org chart. In an ideal week they do nothing at all.
Engineering Managers tend to do some combination of all of these things, usually most of them poorly since that’s way too much work for a single individual.
Thanks, that's an good breakdown. I'm curious, is this an ideal or a pragmatic approach? At first blush, I understand the distinctions but it feels more like a theoretical organization rather than a real one. I've personally never worked in an org with all those roles so, as you say, they tend to get mashed together.
It does seem like there would be a naturally pressure to lump together the roles. I suspect that if your ideal week happens too much (where the manager does nothing at all), executives would question why they're needed.
It does seem like there would be a naturally pressure to lump together the roles. I suspect that if your ideal week happens too much (where the manager does nothing at all), executives would question why they're needed.
In my opinion it’s a pragmatic approach. When these roles get lumped together it creates conflicts of interest that have materially adverse effects on productivity.
That said, you’re right most companies will hire 50 engineers and 10 managers before they hire a single coach or project manager. Or allow IC leads to make their own decisions. So for those companies it’s theoretical. :)
But these roles all exist. You’ll find job listings on LinkedIn for all of them. So they’re happening somewhere!
That said, you’re right most companies will hire 50 engineers and 10 managers before they hire a single coach or project manager. Or allow IC leads to make their own decisions. So for those companies it’s theoretical. :)
But these roles all exist. You’ll find job listings on LinkedIn for all of them. So they’re happening somewhere!
Not the GP but it's nigh on impossible for an EM to do their job. Roughly speaking they are supposed to be the voice of developers/engineering. But since they are not hands on the code they don't know the reality of the code base and so can't be an effective advocate. Ultimately they end up being a relayer of messages.
I think the role needs to exist but it's not a per team role. You need one for every 4 teams or so. They're there to build the teams, make sure they're running right, and do the high level resource allocation. Day to day management of the team should be a collaboration between a lead developer and a product owner.
I think the role needs to exist but it's not a per team role. You need one for every 4 teams or so. They're there to build the teams, make sure they're running right, and do the high level resource allocation. Day to day management of the team should be a collaboration between a lead developer and a product owner.
Maybe part of the problem is there is no consensus on what an EM "should" be doing. Note that the comment above this one gives a much different synopsis of the role.
I think Software Development is far more creative than you give it credit. Let me list a few realities of modern software development:
1) You give a spec to ten different engineers. You'll get ten wildly different solutions, from decisions within a single programming language, to different programming languages, to microservices and serverless.
2) So: make the spec more specific to reduce the variability. Now an engineer has to write the spec; and we're back to square one where the spec is just an expression of how they would develop it. You give it to ten engineers, and you still get ten different solutions; but maybe less variable.
3) Of those ten solutions, most will fail in weird ways, because software breaks. That's what software is known for; breaking. Its hard, probably impossible, to write reliable software, and we're on a deadline, so like 30+% of the team's time is spent just on operations.
4) Of those ten solutions, most will fail to account for some edge case, because the spec didn't cover that edge case, because (reasons). Well, file a followup ticket.
Those bullet points represent so much variability in how the future will play out that any ability to "manage" it is an exercise in futility. Add in interruptions, add in PTO, add in cross-team coordination, incidents, every day longer that a project takes reduces the accuracy of estimates substantially; that can't be managed (well).
That's why product engineering is fundamentally a creative effort. Maybe not like Art or Music; I liken it to more like, well, video game development (which, you know, people write code in so its really confusing to me why Culture considers that creative but not typical software development, I guess its because they produce something Pretty and Fun).
Video games have deadlines. They have business demands. Customers. Product-market fit. Roadmaps. Coordination. Massive, massive variability in implementation. Massive unknowns about what the final product will look like. Massive technical problems involved in bugs, performance, optimizations, maintenance, different platforms.
Here are five careers pages for major video game studios. Seriously, go to all of them, and tell me how many positions they have open for "Manager of People Who Do Traditionally Creative Things": [1] [2] [3] [4] [5]. Its not many, if any. They have roles like this, for sure, but they're not phrased or labeled from the perspective of "Writer Manager"; they're phrased as Lead Writer.
And the critical point there is maybe one involved in the hierarchy and power relationship. But more importantly, its background! The Lead Writer WAS a Writer. That's experience in the domain of the people you're leading; that helps massively in every responsibility this role should have. Timelines? Hella. Roadmapping? Heck yeah. Mentorship? The forbidden word that big tech managers hate.
But Tech is a weird microcosm where EMs are just Managers. The best EMs have an IC background, but many job postings list ZERO requirement to that effect [6], and ask any Engineer-turned-EM: They ain't doing much Engineering anymore. That's not just a benign anomaly; its a problem with how our industry builds companies. And we sit around twiddling our thumbs wondering why engineers hop jobs every year or two; its because, well, the pay is probably better, but also because its a coin flip on whether your manager is actually good, or just some guy that talks good.
Hypothetically, what is a better path forward? Get rid of "Engineering Management". The team has a Lead Developer, who is legally or whatever, the person who "manages" the team (there's that word again, KILL IT WITH FIRE). That role is a peer to PMs, POs, Designers, etc. That role requires a long history of actually doing engineering; and still does it, at least from a high level (meetings are necessary and, yeah, its hard for Engineers-Turned-EMs to find time to code; but writing/reviewing specs, PRs, mentoring the team by helping them debug problems, I'm salivating at the idea of having a manager like this).
[1] https://www.insomniac.com/careers/
[2] https://sms.playstation.com/careers
[3] https://www.valvesoftware.com/en/ (kind of interesting that their home page is their open roles. hiring like crazy! no managers).
[4] https://www.epicgames.com/site/en-US/careers/jobs?keyword=ma...
[5] https://www.respawn.com/careers
[6] https://stripe.com/jobs/listing/engineering-manager-payment-...
1) You give a spec to ten different engineers. You'll get ten wildly different solutions, from decisions within a single programming language, to different programming languages, to microservices and serverless.
2) So: make the spec more specific to reduce the variability. Now an engineer has to write the spec; and we're back to square one where the spec is just an expression of how they would develop it. You give it to ten engineers, and you still get ten different solutions; but maybe less variable.
3) Of those ten solutions, most will fail in weird ways, because software breaks. That's what software is known for; breaking. Its hard, probably impossible, to write reliable software, and we're on a deadline, so like 30+% of the team's time is spent just on operations.
4) Of those ten solutions, most will fail to account for some edge case, because the spec didn't cover that edge case, because (reasons). Well, file a followup ticket.
Those bullet points represent so much variability in how the future will play out that any ability to "manage" it is an exercise in futility. Add in interruptions, add in PTO, add in cross-team coordination, incidents, every day longer that a project takes reduces the accuracy of estimates substantially; that can't be managed (well).
That's why product engineering is fundamentally a creative effort. Maybe not like Art or Music; I liken it to more like, well, video game development (which, you know, people write code in so its really confusing to me why Culture considers that creative but not typical software development, I guess its because they produce something Pretty and Fun).
Video games have deadlines. They have business demands. Customers. Product-market fit. Roadmaps. Coordination. Massive, massive variability in implementation. Massive unknowns about what the final product will look like. Massive technical problems involved in bugs, performance, optimizations, maintenance, different platforms.
Here are five careers pages for major video game studios. Seriously, go to all of them, and tell me how many positions they have open for "Manager of People Who Do Traditionally Creative Things": [1] [2] [3] [4] [5]. Its not many, if any. They have roles like this, for sure, but they're not phrased or labeled from the perspective of "Writer Manager"; they're phrased as Lead Writer.
And the critical point there is maybe one involved in the hierarchy and power relationship. But more importantly, its background! The Lead Writer WAS a Writer. That's experience in the domain of the people you're leading; that helps massively in every responsibility this role should have. Timelines? Hella. Roadmapping? Heck yeah. Mentorship? The forbidden word that big tech managers hate.
But Tech is a weird microcosm where EMs are just Managers. The best EMs have an IC background, but many job postings list ZERO requirement to that effect [6], and ask any Engineer-turned-EM: They ain't doing much Engineering anymore. That's not just a benign anomaly; its a problem with how our industry builds companies. And we sit around twiddling our thumbs wondering why engineers hop jobs every year or two; its because, well, the pay is probably better, but also because its a coin flip on whether your manager is actually good, or just some guy that talks good.
Hypothetically, what is a better path forward? Get rid of "Engineering Management". The team has a Lead Developer, who is legally or whatever, the person who "manages" the team (there's that word again, KILL IT WITH FIRE). That role is a peer to PMs, POs, Designers, etc. That role requires a long history of actually doing engineering; and still does it, at least from a high level (meetings are necessary and, yeah, its hard for Engineers-Turned-EMs to find time to code; but writing/reviewing specs, PRs, mentoring the team by helping them debug problems, I'm salivating at the idea of having a manager like this).
[1] https://www.insomniac.com/careers/
[2] https://sms.playstation.com/careers
[3] https://www.valvesoftware.com/en/ (kind of interesting that their home page is their open roles. hiring like crazy! no managers).
[4] https://www.epicgames.com/site/en-US/careers/jobs?keyword=ma...
[5] https://www.respawn.com/careers
[6] https://stripe.com/jobs/listing/engineering-manager-payment-...
Everything you've said can be related to any other engineering discipline. Think of how many mechanical ways your car can break. Or a building can degrade. They have creative ways of dealing with that too. But do we insist that automotive or architectural design can't be managed? The distinction is other disciplines have managed away a lot of those failures through the constraining the design alternatives to standards and best practices (and sometimes regulatory codes). In other words, software feels like it's more creative because it's less well managed. So to say it can't be managed because it's more creative is circular logic.
What you've really illustrated is that software is hard. Engineering is hard. The distinction is that other engineering disciplines have had a much longer time to codify good practice. I bet if you went into, say steam engine design in the mid-1800s, it would feel a lot more creative than today. For a variety of reasons, software development is not nearly as good at implementing standards and to go into all of them would be a digression. However, I think the distinction that we disagree on is that it's due to anything inherently different in software. I'd make the case that software is easier in some respects (e.g., it doesn't display wear out failure modes) and harder in others (e.g., it tends to have more interface failures). I'm saying it feels more creative because it's less well managed. If you've ever worked in a heavily regulated sector like safety-critical software, it definitively feels less creative than a CRUD web-app development effort for this very reason.
I personally think part of the issue is that EM becomes a career-track that can start immediately out of school. It's similar to the change in MBA programs. The better MBA schools used to require that you have worked in industry for about a decade before even applying; now it seems like most schools offer a management track without necessarily having any experience. The result is a self-selection for people who want to manage without necessarily having a concrete understanding of what they are managing.
What you've really illustrated is that software is hard. Engineering is hard. The distinction is that other engineering disciplines have had a much longer time to codify good practice. I bet if you went into, say steam engine design in the mid-1800s, it would feel a lot more creative than today. For a variety of reasons, software development is not nearly as good at implementing standards and to go into all of them would be a digression. However, I think the distinction that we disagree on is that it's due to anything inherently different in software. I'd make the case that software is easier in some respects (e.g., it doesn't display wear out failure modes) and harder in others (e.g., it tends to have more interface failures). I'm saying it feels more creative because it's less well managed. If you've ever worked in a heavily regulated sector like safety-critical software, it definitively feels less creative than a CRUD web-app development effort for this very reason.
I personally think part of the issue is that EM becomes a career-track that can start immediately out of school. It's similar to the change in MBA programs. The better MBA schools used to require that you have worked in industry for about a decade before even applying; now it seems like most schools offer a management track without necessarily having any experience. The result is a self-selection for people who want to manage without necessarily having a concrete understanding of what they are managing.
> I'd also posit that most of the defense of the position comes from managers. Do you not recognize the irony in this?
That’s not irony. That’s someone with no domain expertise saying something and then someone with domain expertise refuting it.
If I, a casual baseball fan, made a claim about umpires being useless in baseball and then an umpire came in to explain otherwise, that would not be irony.
I’m also not an EM, though I have been one in the past.
I don’t understand your point about PMs. You’re saying that the responsibilities of an EM should be that of a PM. So you’re just arguing for a name change? Or something else?
That’s not irony. That’s someone with no domain expertise saying something and then someone with domain expertise refuting it.
If I, a casual baseball fan, made a claim about umpires being useless in baseball and then an umpire came in to explain otherwise, that would not be irony.
I’m also not an EM, though I have been one in the past.
I don’t understand your point about PMs. You’re saying that the responsibilities of an EM should be that of a PM. So you’re just arguing for a name change? Or something else?
Don't know if that is what they're suggesting, but I would suggest:
owner/board -> worker teams (up to 5 individuals) -> team helper (this is the previous manager role)
Edit: I will also add that it's strange, the more experience I have of incompetent managers, the more I'm told I don't understand them!
owner/board -> worker teams (up to 5 individuals) -> team helper (this is the previous manager role)
Edit: I will also add that it's strange, the more experience I have of incompetent managers, the more I'm told I don't understand them!
> I don’t understand your point about PMs. You’re saying that the responsibilities of an EM should be that of a PM. So you’re just arguing for a name change? Or something else?
Well, its not just a name change, but generally Yes.
The biggest thing is from the Org Hierarchy perspective. I want to preface what I'm about to say to be perfectly clear: This is not true in every company.
EMs have the final say on resourcing for code-related tasks; but poor understanding of the code, systems, etc because the Lead/Senior devs live there. EMs have the final say on product decisions from PO/PMs under them; but a poor understanding of the product because the PO/PMs/etc breathe that. EMs have the final say on designs; but a poor understanding of UX because the designers have that.
The best EMs always have some background in one of the roles I outlined above. They come from an IC background, they were due a promotion, burned out in the IC role, ran out of promotions in the IC track, whatever.
But in many situations the role of an EM becomes a mediocre mashup where the one thing they're actually good at is navigating the politics of org hierarchies; or if you want to be Business Proper, call it Communication. Ask any high school guidance councilor where "Communications" lands on the list of Valuable College Degrees and you'll get a pretty consistent answer. But: EMs somehow escaped this destiny, because tech has a weird distortion field on incomes right now.
Here's the sinister part: Because EMs hold power over everyone who reports to them, its common to see turf wars over responsibilities. Example: "We don't need to hire for a PM, I'm doing that". That's why it isn't just a simple name change; its their fundamental place in an org hierarchy that can make the role a net drag on an organization. Orgs hire them without a tactile definition on the responsibilities of the role [1]; just extrapolate "manage the engineers" to three paragraphs and call it good. You'll do roadmap planning (in collaboration with senior leadership and the PMs). You'll help prioritize incoming work from different stakeholders (in collaboration with the PMs, Customers, and Engineers). You'll help build the team (in collaboration with Recruiting). You'll mentor the engineers (but, we don't require any engineering background, so how you'll do this well is anyone's guess).
The role doesn't actually DO anything valuable; again, at best, the person has IC experience and can carve out a niche that's a hybrid of that IC experience and more coordination/communication. But at average, they're a message bus that attends meetings and parrots messages from someone that actually matters to someone else that actually matters [2].
[1] https://stripe.com/jobs/listing/engineering-manager-payment-...
[2] https://www.youtube.com/watch?v=m4OvQIGDg4I
Well, its not just a name change, but generally Yes.
The biggest thing is from the Org Hierarchy perspective. I want to preface what I'm about to say to be perfectly clear: This is not true in every company.
EMs have the final say on resourcing for code-related tasks; but poor understanding of the code, systems, etc because the Lead/Senior devs live there. EMs have the final say on product decisions from PO/PMs under them; but a poor understanding of the product because the PO/PMs/etc breathe that. EMs have the final say on designs; but a poor understanding of UX because the designers have that.
The best EMs always have some background in one of the roles I outlined above. They come from an IC background, they were due a promotion, burned out in the IC role, ran out of promotions in the IC track, whatever.
But in many situations the role of an EM becomes a mediocre mashup where the one thing they're actually good at is navigating the politics of org hierarchies; or if you want to be Business Proper, call it Communication. Ask any high school guidance councilor where "Communications" lands on the list of Valuable College Degrees and you'll get a pretty consistent answer. But: EMs somehow escaped this destiny, because tech has a weird distortion field on incomes right now.
Here's the sinister part: Because EMs hold power over everyone who reports to them, its common to see turf wars over responsibilities. Example: "We don't need to hire for a PM, I'm doing that". That's why it isn't just a simple name change; its their fundamental place in an org hierarchy that can make the role a net drag on an organization. Orgs hire them without a tactile definition on the responsibilities of the role [1]; just extrapolate "manage the engineers" to three paragraphs and call it good. You'll do roadmap planning (in collaboration with senior leadership and the PMs). You'll help prioritize incoming work from different stakeholders (in collaboration with the PMs, Customers, and Engineers). You'll help build the team (in collaboration with Recruiting). You'll mentor the engineers (but, we don't require any engineering background, so how you'll do this well is anyone's guess).
The role doesn't actually DO anything valuable; again, at best, the person has IC experience and can carve out a niche that's a hybrid of that IC experience and more coordination/communication. But at average, they're a message bus that attends meetings and parrots messages from someone that actually matters to someone else that actually matters [2].
[1] https://stripe.com/jobs/listing/engineering-manager-payment-...
[2] https://www.youtube.com/watch?v=m4OvQIGDg4I
The power dynamic between managers and those they manage is the differentiator. Sure it's a spectrum but half of that spectrum (from average to god awful) have power over your career/work, to your detrement.
> Sure it's a spectrum but half of that spectrum (from average to god awful) have power over your career/work, to your detrement.
It is always your responsibility to advocate for yourself, your career, and your work.
If you are an engineer you should view your manager as a marginal value add only. Some managers add more value to your career than others, for sure, but it's still marginal relative to the effect that YOU have on your career. If you find yourself on a team with a truly bad manager who is having a negative affect on your career, get out...but this is truly a rare occurrence in my experience.
It is always your responsibility to advocate for yourself, your career, and your work.
If you are an engineer you should view your manager as a marginal value add only. Some managers add more value to your career than others, for sure, but it's still marginal relative to the effect that YOU have on your career. If you find yourself on a team with a truly bad manager who is having a negative affect on your career, get out...but this is truly a rare occurrence in my experience.
If your manager is only adding a marginal value to your career it is time to have a conversation with them. A manager that isn't advocating for their team isn't a good manager at all. They're something else.
A manager can only add marginal value to your career. ONLY.
You spend 40+ hours a week on you and your career. Your manager spends a small fraction of that directly on your career.
100% agree that they need to be advocating for you/your team, finding the right projects for you/your team, etc, etc. But at the end of the day your career is your responsibility, and it's only a fraction of your manager's responsibility.
You spend 40+ hours a week on you and your career. Your manager spends a small fraction of that directly on your career.
100% agree that they need to be advocating for you/your team, finding the right projects for you/your team, etc, etc. But at the end of the day your career is your responsibility, and it's only a fraction of your manager's responsibility.
I'm not sure I agree here, because the manager has the ability to impact all those other hours.
A good manager helps remove the hurdles that will make those 40+ hours immensely more productive. A bad manager adds to those hurdles, potentially whittling productive hours to nothing.
A good manager helps remove the hurdles that will make those 40+ hours immensely more productive. A bad manager adds to those hurdles, potentially whittling productive hours to nothing.
> You spend 40+ hours a week on you and your career. Your manager spends a small fraction of that directly on your career.
If your manager has little more leverage than you do, that's true. In many orgs, managers have considerably more leverage than their reports, and their help is mandatory to get some things (promotions, pay increase, access to conferences and trainings, changing teams, passing messages up the chain or laterally, support for escalation, etc).
The only trump card the report has is leaving, but they pay for that by losing all the social capital acquired at the current company.
If your manager has little more leverage than you do, that's true. In many orgs, managers have considerably more leverage than their reports, and their help is mandatory to get some things (promotions, pay increase, access to conferences and trainings, changing teams, passing messages up the chain or laterally, support for escalation, etc).
The only trump card the report has is leaving, but they pay for that by losing all the social capital acquired at the current company.
This view makes it seem that the manager is compensated directly by the team.
Thats assuming the average is net neutral to your career/work.
The average engineering manager may be a net benefit, or a net detriment. The rest we can extrapolate from there.
The average engineering manager may be a net benefit, or a net detriment. The rest we can extrapolate from there.
I do think that this is fair and it is a reason why bad managers stand out so much in people's minds. I think that making it feasible for a team to fire its own manager would be generally a good thing.
But this has little to do with the argument that management as a concept itself is self serving bullshit.
But this has little to do with the argument that management as a concept itself is self serving bullshit.
Why? If most managers are useless that means most in the role aren't actually helping or doing anything yet the world seems to go on. Why have that role then? If you can have someone who is a negative in that role, then you can get rid of it.
> If most managers are useless
Big IF. Even worse-than-average managers are not useless. To have a truly useless manager is an extreme rarity.
> means most in the role aren't actually helping or doing anything
You're painting a broad spectrum of people on a binary scale. A bad manager is maybe 30% as useful as a great manager. But 30% useful is still better than not existing.
> If you can have someone who is a negative in that role, then you can get rid of it.
By this logic every job is useless. Any role can have someone bad at it.
Big IF. Even worse-than-average managers are not useless. To have a truly useless manager is an extreme rarity.
> means most in the role aren't actually helping or doing anything
You're painting a broad spectrum of people on a binary scale. A bad manager is maybe 30% as useful as a great manager. But 30% useful is still better than not existing.
> If you can have someone who is a negative in that role, then you can get rid of it.
By this logic every job is useless. Any role can have someone bad at it.
Idk if its that big of an "if". People who are ending up as managers are rarely highly trained in the job or receiving a ton of support. Often just attracting bad personalities. Its always someone who wants to do something different then engineering, they become a manager. Imagine if we hired engineers because someones friend thought it sounded interesting and they had to do all their learning on the job.
> By this logic every job is useless. Any role can have someone bad at it.
Its not really the same because there's only one manager. If i had redundant managers maybe then a couple bad ones could get by. bad engineers have a tons of checks to prevent them being a real drain. theres no code review for a manager.
> By this logic every job is useless. Any role can have someone bad at it.
Its not really the same because there's only one manager. If i had redundant managers maybe then a couple bad ones could get by. bad engineers have a tons of checks to prevent them being a real drain. theres no code review for a manager.
> People who are ending up as managers are rarely highly trained in the job or receiving a ton of support.
> Often just attracting bad personalities.
> Its always someone who wants to do something different then engineering, they become a manager.
You are saying these things as though they are simple truths that I am just supposed to accept. But I do not.
People who end up as managers are selected for their potential and receive lots of support, more often than not.
Often attracting great personalities since the job is about interfacing with people, more often than not.
It's always someone who wants to do management, whether or not they want to continue engineering, more often than not.
> Imagine if we hired engineers because someones friend thought it sounded interesting and they had to do all their learning on the job.
Yea, sounds terrible. It's a darn good thing we don't hire engineers or managers like this.
> Often just attracting bad personalities.
> Its always someone who wants to do something different then engineering, they become a manager.
You are saying these things as though they are simple truths that I am just supposed to accept. But I do not.
People who end up as managers are selected for their potential and receive lots of support, more often than not.
Often attracting great personalities since the job is about interfacing with people, more often than not.
It's always someone who wants to do management, whether or not they want to continue engineering, more often than not.
> Imagine if we hired engineers because someones friend thought it sounded interesting and they had to do all their learning on the job.
Yea, sounds terrible. It's a darn good thing we don't hire engineers or managers like this.
im saying things based on my experience, but if yours is different and you see high quality and effective managers being created from engineers thats cool. can i send a resume over?
> managers are selected for their potential and receive lots of support
This support im questioning. Its all on the job training. I went to business school, i actually have a business degree. I didn't leave that school feeling like i should manage or lead. The "training" is on the job, the people who teach are your small peer of manager peers and maybe some corporate style training. Corporate training has never been effective from what I have seen.
> managers are selected for their potential and receive lots of support
This support im questioning. Its all on the job training. I went to business school, i actually have a business degree. I didn't leave that school feeling like i should manage or lead. The "training" is on the job, the people who teach are your small peer of manager peers and maybe some corporate style training. Corporate training has never been effective from what I have seen.
I don't agree. There is a good line in the book "Impro" about good and bad teachers. It says that we think of "good teachers" as providing a lot of some substance called "education" while "bad teachers" provide only a little. In fact bad teachers can and often do not only fail to provide education but actively make students less educated by, for instance, teaching wrong ideas, punishing arbitrarily, etc etc. The same is true of managers. They can easily drop below zero and start to have a negative impact on productivity and their employees.
This is very true. I've seen a single bad manager destroy an entire wing of an engineering organization in a couple of months. This person wasn't even a particularly mean or bad person, and had apparently been a successful middle manager for Pac Bell in their previous role. But they had no feel for the team they had taken over at all, and tried to impose a new structure all at once (basically boiled down to all of the senior devs were now technical project managers and wouldn't be coding). Everyone left within a couple of weeks.
I think this is the sign of inexperience/immaturity.
What you're describing is a universal aspect of life. From parents, to teachers, to managers all the way back to chieftains of prehistoric tribes there have been power differentials between people and the more competent person has not always been the more powerful.
What you're describing is a universal aspect of life. From parents, to teachers, to managers all the way back to chieftains of prehistoric tribes there have been power differentials between people and the more competent person has not always been the more powerful.
And we're honing in on the pain point of that aspect of life. I'm not having a revelation here, I'm lamenting the fact with my peers on a site dedicated to technology/engineering.
I think what you're describing isn't inexperience or immaturity; its idealism in the idea that competent people should hold power.
The world may not work like that, but it isn't immature to fight for it.
The world may not work like that, but it isn't immature to fight for it.
I have been a manager and a manager of managers and I think we really do not have good data on whether not "management" as a profession in software engineering really adds value. We're bad at quantifying the value of engineers, and we're worse at quantifying the value of managers.
There are definitely a wide range of non-engineering skills required to produce good software but that doesn't automatically justify the existence of a dedicated engineering manager role in most or even any teams.
There are definitely a wide range of non-engineering skills required to produce good software but that doesn't automatically justify the existence of a dedicated engineering manager role in most or even any teams.
I can justify it quite easily. Take it away and see what happens.
I don't think its possible to just take it away and see what happens, because organizations build the concept of EMs into their entire culture.
As an example: I worked in a Big Tech org where the only way to get anything from another team was an org hierarchy jump. ICs could reach out directly; ignored. Some teams didn't even have a way to reach out to them. You had to go EM, then maybe a Director, then it filters down, and maybe a day, maybe a week later, you'd get an email introduction. It doesn't have to be like this, no one even decided it should be like this, but because they had the hierarchy that's how the culture evolved.
The better comparison is to look at companies who don't have that role, or define that role significantly differently from the traditional Big Tech definition. There are many; of course, not as many as the latter. And just like companies who do have the role traditionally defined, there are success stories and there are failure stories. To me, the more I've read up on those stories, the more I've realized how pointless the role is.
Or, maybe more accurately; how much of the role's responsibility is really to be a crutch for bad culture, bad upper management, bad hiring practices, bad interviewing, etc. That ain't totally pointless, but if you're also flipping a coin on the quality of each EM you hire, and moreover the coin is rigged because we don't even have an industry standard definition for what defines success in the EM role in the best cases; there are better ways of reaching the same destination.
But, you know, most of the time those better ways require an ounce of Trust from senior leadership, and that's like pulling water from desert sand.
As an example: I worked in a Big Tech org where the only way to get anything from another team was an org hierarchy jump. ICs could reach out directly; ignored. Some teams didn't even have a way to reach out to them. You had to go EM, then maybe a Director, then it filters down, and maybe a day, maybe a week later, you'd get an email introduction. It doesn't have to be like this, no one even decided it should be like this, but because they had the hierarchy that's how the culture evolved.
The better comparison is to look at companies who don't have that role, or define that role significantly differently from the traditional Big Tech definition. There are many; of course, not as many as the latter. And just like companies who do have the role traditionally defined, there are success stories and there are failure stories. To me, the more I've read up on those stories, the more I've realized how pointless the role is.
Or, maybe more accurately; how much of the role's responsibility is really to be a crutch for bad culture, bad upper management, bad hiring practices, bad interviewing, etc. That ain't totally pointless, but if you're also flipping a coin on the quality of each EM you hire, and moreover the coin is rigged because we don't even have an industry standard definition for what defines success in the EM role in the best cases; there are better ways of reaching the same destination.
But, you know, most of the time those better ways require an ounce of Trust from senior leadership, and that's like pulling water from desert sand.
There's not a ton of consistency across even relatively similar-looking tech companies in my experience, so you really should expect your mileage to vary. My N=3 large tech companies in my career is not so much better than your N=1 example, but it does allow me to say that these things are not consistent at all, with some notable exceptions, usually constrained by employment law.
Devs: "Overworked? Too many disparate responsibilities? Not being able to write enough code? No team cohesion? This is a systemic failure of leadership, start interviewing for other positions."
Devs: "We, as software developers, are underappreciated! People only pay attention to us when things go wrong!"
Also Devs: "Managers are so useless lmao"
Devs: "We, as software developers, are underappreciated! People only pay attention to us when things go wrong!"
Also Devs: "Managers are so useless lmao"
I like this caricature but remember that, since this is not a regulated industry, there are many different personalities, and those who think this way don’t succeed for long.
What happens is that an otherwise productive engineer has to step up and perform the role, but without any recognition of the extra responsibilities or any reduction in expectations of their individual contributions.
So then they find a job somewhere else and another otherwise productive engineer has to step up.....
Meanwhile the other engineers continue on blissfully unaware, patting themselves on their backs for how they don't need to be managed.
So then they find a job somewhere else and another otherwise productive engineer has to step up.....
Meanwhile the other engineers continue on blissfully unaware, patting themselves on their backs for how they don't need to be managed.
I've seen this happen in smaller teams; it can work well! Productive teams and skilled engineers can manage their own workload. Not all of them want to do that, so that needs to be taken into account, but it can work spectacularly.
I've also seen it work poorly. We've already established that there are good and bad EMs; there's good and bad in everything. That doesn't justify the role of the EM!
I've also seen PMs do this. This is the far more common situation, and it works! Workload planning ends up being a collaborative effort on the team, with the senior engineers holding domain knowledge over operations, maintenance, architecture, implementation, while PMs/Designers/etc hold domain knowledge over the business, customers, etc. Work once in an environment like this; well, at least a good one; and it will make anyone and everyone question why EMs exist at all. There's no room for them. They wouldn't contribute anything even if they were added to the mix.
I've also seen it work poorly. We've already established that there are good and bad EMs; there's good and bad in everything. That doesn't justify the role of the EM!
I've also seen PMs do this. This is the far more common situation, and it works! Workload planning ends up being a collaborative effort on the team, with the senior engineers holding domain knowledge over operations, maintenance, architecture, implementation, while PMs/Designers/etc hold domain knowledge over the business, customers, etc. Work once in an environment like this; well, at least a good one; and it will make anyone and everyone question why EMs exist at all. There's no room for them. They wouldn't contribute anything even if they were added to the mix.
And no extra agency and no extra authority. I've been in that spot, had the best 4 months of my life (lack of authority was painful). Then 2 clueless managers were hired above me.
I've been at my current job for 12 years. For my first three years, I had no manager [1]. I then did an internal transfer to development, and had a 'meh' manager [2]. He burned out after a few years. The next manager I had was great. Technically, he shouldn't have been our manager as he was a director at the company, but due to financial politics, the company couldn't hire a manager for us. He just told us what we needed to do and otherwise, let us developers alone to do the voodoo that we do. He was eventually let go and one of the other developers on our team was promoted to manager. He too, was great, just telling us what to do, and trusting us to do the voodoo that we do. He retired. My current manager (from the company that bought us out) is bad. Enterprise development being shoved down our throats, not only telling us what to do, but how to do it.
So, in my mind, a good manager will tell the team what to do, listen to them, and let them do the how. Next up is no management---in my experience, I knew what needed to be done, and got it done. It was great, but I realize that was a bizarre case that normally doesn't apply everywhere, but because of the nature of the work I did, only a few other people actually knew the work involved. The 'meh' manager didn't hurt, but really didn't help. And bad management, well ... let's just say a bad manager can really damage a company.
Until bad management showed up, our team always delivered on time, had smooth deployments, very few bugs in production, and otherwise, was not a source of issues for anyone. Now, we've missed multiple deadlines, horrible deployments, bugs in production and our customer, The Oligarchic Cell Phone Company, is very pissed. And it's not the sole fault of my current manager, but of upper management in general.
[1] I was initially hired in QA to test the call processing side of our product (the bit that happens when a call is placed). The existing QA manager only knew how to QA the cell phone handsets, not the call processing server side. I knew next to nothing about the cell phone handsets. It was clear the QA manager was not a good fit for me.
[2] He wasn't great. I don't think he was as bad as some other employees said he was. He was a developer who was forced into a management role.
So, in my mind, a good manager will tell the team what to do, listen to them, and let them do the how. Next up is no management---in my experience, I knew what needed to be done, and got it done. It was great, but I realize that was a bizarre case that normally doesn't apply everywhere, but because of the nature of the work I did, only a few other people actually knew the work involved. The 'meh' manager didn't hurt, but really didn't help. And bad management, well ... let's just say a bad manager can really damage a company.
Until bad management showed up, our team always delivered on time, had smooth deployments, very few bugs in production, and otherwise, was not a source of issues for anyone. Now, we've missed multiple deadlines, horrible deployments, bugs in production and our customer, The Oligarchic Cell Phone Company, is very pissed. And it's not the sole fault of my current manager, but of upper management in general.
[1] I was initially hired in QA to test the call processing side of our product (the bit that happens when a call is placed). The existing QA manager only knew how to QA the cell phone handsets, not the call processing server side. I knew next to nothing about the cell phone handsets. It was clear the QA manager was not a good fit for me.
[2] He wasn't great. I don't think he was as bad as some other employees said he was. He was a developer who was forced into a management role.
I've worked in a place without eng managers, product managers, scrum masters, various MBA people, you know... all those employees that a certain segment of HN thinks are useless. It was just Sales and Software Engineering, and the CEO, to whom everyone reported. It was the worst job I've ever had.
Developers just developing, without interference from evil managers and clueless PMs! Amazing! The ideal work environment for the genius bootstrappy engineer! Sounds like heaven, right? It was not. It was total chaos.
1. Nobody knew what they should be doing and what were priorities. Someone from sales would run downstairs and say "I just sold Foo to a giant customer! You need to build Foo now!!" and everyone would go off and start building Foo. Then the CEO would fly in and ask "Why are you not building Bar? I'm personally interested in Bar, please show some results! Oh, and any product changes need to be personally approved by me now. Byeeeeee (gets on his plane again)". So developers kept developing but had no idea what to develop.
2. Joel Test[1] was 0 out of 12. Since it was just developers developing, nobody had time to write a spec, or set up source control, or design a build/release process. Those were icky tasks that stupid PMs and managers did. Developers want to develop. So the software engineering process was a clown show. Releases to customers were always late, and when they happened they were built directly from an engineer's workstation (they would just find a tree that actually built without errors, and that was the release).
3. If the software failed in the field for a customer, and this happened constantly, there were no useless support staff to talk with that customer, do basic tier 1 and 2 support, diagnose, and so on. Customers simply got angry, and since it was just developers developing, they had nobody to call and rage at, so they'd call the CEO. Then CEO mad. CEO would make a developer fly out to the customer's site with a laptop and debugger to pacify the customer. Now, that particular developer wasn't developing and was sad.
4. Things like career growth, mentorship, training, learning new best practices, none of that existed. It was just developers developing, so there really was no knowledge transfer or any distinction between junior, senior, staff, and so on. Nobody's job was to set these things up, so it never happened. There were no levels so no concept of promotion. If you wanted a raise, you'd go to the CEO who would just say no. That was basically your career development.
So yea, go find a place without managers and MBAs and let me know how it goes.
1: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
Developers just developing, without interference from evil managers and clueless PMs! Amazing! The ideal work environment for the genius bootstrappy engineer! Sounds like heaven, right? It was not. It was total chaos.
1. Nobody knew what they should be doing and what were priorities. Someone from sales would run downstairs and say "I just sold Foo to a giant customer! You need to build Foo now!!" and everyone would go off and start building Foo. Then the CEO would fly in and ask "Why are you not building Bar? I'm personally interested in Bar, please show some results! Oh, and any product changes need to be personally approved by me now. Byeeeeee (gets on his plane again)". So developers kept developing but had no idea what to develop.
2. Joel Test[1] was 0 out of 12. Since it was just developers developing, nobody had time to write a spec, or set up source control, or design a build/release process. Those were icky tasks that stupid PMs and managers did. Developers want to develop. So the software engineering process was a clown show. Releases to customers were always late, and when they happened they were built directly from an engineer's workstation (they would just find a tree that actually built without errors, and that was the release).
3. If the software failed in the field for a customer, and this happened constantly, there were no useless support staff to talk with that customer, do basic tier 1 and 2 support, diagnose, and so on. Customers simply got angry, and since it was just developers developing, they had nobody to call and rage at, so they'd call the CEO. Then CEO mad. CEO would make a developer fly out to the customer's site with a laptop and debugger to pacify the customer. Now, that particular developer wasn't developing and was sad.
4. Things like career growth, mentorship, training, learning new best practices, none of that existed. It was just developers developing, so there really was no knowledge transfer or any distinction between junior, senior, staff, and so on. Nobody's job was to set these things up, so it never happened. There were no levels so no concept of promotion. If you wanted a raise, you'd go to the CEO who would just say no. That was basically your career development.
So yea, go find a place without managers and MBAs and let me know how it goes.
1: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
> 2. Joel Test[1] was 0 out of 12.
Sorry, but then you and your colleges were not senior enough to handle an environment like this. This is not a question of missing management, but also missing (technical) leadership.
While I do not know if it would have solved all your problems, you can make this environment better, without adding a management layer in between.
Sorry, but then you and your colleges were not senior enough to handle an environment like this. This is not a question of missing management, but also missing (technical) leadership.
While I do not know if it would have solved all your problems, you can make this environment better, without adding a management layer in between.
I can't speak for everyone, but I would not argue against PMs or Senior Leadership.
There are two critical differentiators in the role of an EM: power over those managed, and the bias toward management over productive output. The people who predominately fill those roles are those who are good at management, not those who are good at production (and, by the way, the "good EMs" which DO exist are generally people with a history as an IC, and treat the role more as a PM).
There are two critical differentiators in the role of an EM: power over those managed, and the bias toward management over productive output. The people who predominately fill those roles are those who are good at management, not those who are good at production (and, by the way, the "good EMs" which DO exist are generally people with a history as an IC, and treat the role more as a PM).
> nobody had time to [...] set up source control
Now wait, how do developers develop without source control?
As an individual contributor, I consider a number of things in that paragraph good practice. Specs, say. But source control? That's just so fundamentally basic that I lack vocabulary to express how essentially important I consider it to be. How does a team get anything done without one?
Now wait, how do developers develop without source control?
As an individual contributor, I consider a number of things in that paragraph good practice. Specs, say. But source control? That's just so fundamentally basic that I lack vocabulary to express how essentially important I consider it to be. How does a team get anything done without one?
Can you design an organisation in which has managers, which would fall apart entirely if you took them away? Yes absolutely.
I'm not sure this really demonstrates that they added value so much as they just prevented value from getting subtracted by other dysfunctional parts of the organisation.
I'm not sure this really demonstrates that they added value so much as they just prevented value from getting subtracted by other dysfunctional parts of the organisation.
I've worked for months while they hired a new manager, and we just had less meetings.
Conversely, I had to attend more meetings when I didn't have a manager, because they were no longer there to act as a filter/shield for the chaff around the corn of what I needed to know.
What do you need to know from your manager exactly?
Majority of my assigned work is coming from my project lead.
Presumably someone was still managing you (e.g. there was someone for you to go to if you wanted to book time off, ask for a pay rise, etc)?
Vacations are booked through a booking system, pay raises are negotiated by a union, so not an issue.
Mind if I ask where you’re from? Even in highly unionized Scandinavia I’ve never seen software devs (specifically) join unions to any larger extent, let alone negotiate salary through them.
I imagine bikeshedding galore lol.
Exactly this.
> Managers exist on the same spectrum as any other role. Most are about average. Some are better, some are worse. Same with engineers themselves.
I do understand what OP said somewhat though. Mostly due to Peter's principle, thus, managers are not "about average" but "mostly incompetent". It is easier to promote people managers than ICs in growing organization, hence it is easier to play out Peter's principle in real life for people managers.
I do understand what OP said somewhat though. Mostly due to Peter's principle, thus, managers are not "about average" but "mostly incompetent". It is easier to promote people managers than ICs in growing organization, hence it is easier to play out Peter's principle in real life for people managers.
The key that I think makes all the difference is to treat moving to management as not a promotion, but just a change to a different career track. Same as if the person went into design or any other non-engineering role.
Remember that the Peter principle only applies to people who’ve peaked and who are in roles with some meaningful promotion path remaining. It doesn’t apply to someone who’s working their way up the ranks and is currently an engineering manager. It also doesn’t apply to someone in that role in a small-to-midsized company where there’s nowhere further to be promoted without buying out the owner.
The Peter Principle is just an idea someone had (and intended to be satire) and not an actual factual reflection of the way the world works.
The fact that it's satire doesn't make it untrue.
Not just that. The fact that it's satire means it's at least somewhat true.
However if the satyrical speaker did not believe that they had a duty of care to the truth, then it is bullshit[1].
[1] Prof. Harry Frankfurt, On Bullshit. http://www2.csudh.edu/ccauthen/576f12/frankfurt__harry_-_on_...
[1] Prof. Harry Frankfurt, On Bullshit. http://www2.csudh.edu/ccauthen/576f12/frankfurt__harry_-_on_...
Not really, that does not follow. It is possible to speak the truth by accident.
It is also possible to arrive safely at your destination via reckless driving.
It is equally incorrect to assume that someone who speaks "without a duty of care to the truth" is saying something true or false, if given no other information.
Indeed. It is just something someone said once, not necessarily wise to reach other conclusions from.
It does seem to be a reflection of how the world works though. Most promotions risk being promoted to your level of incompetence because they are happenstance. They mostly occur either when you're joining a new company or someone leaves/company is growing which makes room.
Being promoted because you are excelling in your position and taking on responsibilities of the one above is the rarest main reason from what I have seen.
Being promoted because you are excelling in your position and taking on responsibilities of the one above is the rarest main reason from what I have seen.
> Most are about average
Surely you meant to communicate something different here and not a mathematical impossibility.
Do you mean most fall within 1 standard deviation of the average? That still means half the managers you encounter would be below the average quality assuming a normal distribution (which it’s clearly not - skills tend to follow the power law).
Most engineers are actually decidedly quite bad at software development itself for what it’s worth. The equivalent of a first level line manager is typically a first level engineer (not always but usually). Good managers get promoted to manage managers / multiple teams which dilutes their qualities (they now have to train other managers to be good). So think about whether you’d put a very junior engineer in charge of a project and what kind of results that might have, especially since if the manager is actually good they’ll be promoted away whereas an IC who’s hood is simply given more responsibility on the project but the role doesn’t change too much.
Surely you meant to communicate something different here and not a mathematical impossibility.
Do you mean most fall within 1 standard deviation of the average? That still means half the managers you encounter would be below the average quality assuming a normal distribution (which it’s clearly not - skills tend to follow the power law).
Most engineers are actually decidedly quite bad at software development itself for what it’s worth. The equivalent of a first level line manager is typically a first level engineer (not always but usually). Good managers get promoted to manage managers / multiple teams which dilutes their qualities (they now have to train other managers to be good). So think about whether you’d put a very junior engineer in charge of a project and what kind of results that might have, especially since if the manager is actually good they’ll be promoted away whereas an IC who’s hood is simply given more responsibility on the project but the role doesn’t change too much.
Really unclear what point you are trying to make. But yes my intention of using the word "about" average and not "exactly" average was to communicate that most people hover somewhere around the middle. If you want to get really specific and get into stddevs, be my guest.
"Most people" cannot be above average. That's an information free statement.
[deleted]
> Most are about average.
That is not how averages work. It depends on the distribution.
That is not how averages work. It depends on the distribution.
It's most likely a bell curve
To answer your nitpick with a nitpick, averages can work that way. Do you know the distribution of engineering managers well enough to say that most aren't "about average"? GP was making a claim about engineering managers.. not about all averages.
But regardless, that's missing the point. The point is that the distribution of engineering manager quality is likely pretty similar to that of any other role. So claiming that "there are way more bad engineering managers than good ones" seems likely to be untrue unless you also believe that about nearly any other engineering/management/product position.
But regardless, that's missing the point. The point is that the distribution of engineering manager quality is likely pretty similar to that of any other role. So claiming that "there are way more bad engineering managers than good ones" seems likely to be untrue unless you also believe that about nearly any other engineering/management/product position.
> To answer your nitpick with a nitpick,
> averages can work that way. Do you know
> the distribution of engineering managers
> well enough to say that most aren't
> "about average"?
Sorry it hit a sore spot; especially in a community such as this we should at least try to speak accurately regards statistics.
That's not what I'm saying. The OP is stating that it holds for averages. It doesn't. It might in this case but we don't have the stats.
The statement just doesn't make sense - you can say exactly the same about a random value. It will hold in some cases. Average too. However it will not hold in all cases.
Sorry it hit a sore spot; especially in a community such as this we should at least try to speak accurately regards statistics.
That's not what I'm saying. The OP is stating that it holds for averages. It doesn't. It might in this case but we don't have the stats.
The statement just doesn't make sense - you can say exactly the same about a random value. It will hold in some cases. Average too. However it will not hold in all cases.
> Managers exist on the same spectrum as any other role.
Anecdotally, I've met a lot more people who don't want to manage (again) than people who don't want to be ICs. I think that indicates a different "spectrum" of humanity.
Anecdotally, I've met a lot more people who don't want to manage (again) than people who don't want to be ICs. I think that indicates a different "spectrum" of humanity.
> Managers exist on the same spectrum as any other role.
I think it doesn't help that you'll find about 1 manager for 8-10 engineers. The same spectrum, but lower raw numbers, might give an exaggerated impression of mediocrity.
I think it doesn't help that you'll find about 1 manager for 8-10 engineers. The same spectrum, but lower raw numbers, might give an exaggerated impression of mediocrity.
The 'average' manager may indeed be a net-negative, much like the average car crash.
> frankly just don’t have any idea what the job is for
We know what the job is for, but maybe there's no actual value there.
Do doctors have managers? Do lawyers have managers? No, they might report to some administrative body, but they mostly work on contract or in teams. The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'
What engineers need is low-level clerical people to handle the day to day comms with others outside the org. We don't need managers, unskilled labor needs managers.
> frankly just don’t have any idea what the job is for
We know what the job is for, but maybe there's no actual value there.
Do doctors have managers? Do lawyers have managers? No, they might report to some administrative body, but they mostly work on contract or in teams. The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'
What engineers need is low-level clerical people to handle the day to day comms with others outside the org. We don't need managers, unskilled labor needs managers.
> Do doctors have managers?
Yes. If a doctor is working in a hospital, there are most certainly managers. Obviously not "technical" managers in that they're doctors themselves or the doctor's "boss" but in that there are managers who are co-ordinating workforce, priorities, staffing, supplies etc etc. This is very much a thing and is more broad than engineering managers but is an incredibly important task so the daily admin work does not come to a doctor who is probably prioritising saving lives and helping people
> The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'
This is incredibly demeaning of people in hospitals who actually have to do these jobs. There's a massive amount of work required here and it is by no means "clerical". When "customers" literally have their lives in a doctor's hands, the complexity increases hundredfold. There's legal sensitivities, paperwork, spending, collections and so much more stuff involved and this is not even counting the kinds of things they need to do which involves interfacing with patients and their kin about sensitive matters. This is not simply "admin work". This is critical, life saving stuff
Yes. If a doctor is working in a hospital, there are most certainly managers. Obviously not "technical" managers in that they're doctors themselves or the doctor's "boss" but in that there are managers who are co-ordinating workforce, priorities, staffing, supplies etc etc. This is very much a thing and is more broad than engineering managers but is an incredibly important task so the daily admin work does not come to a doctor who is probably prioritising saving lives and helping people
> The 'communicate with customers' nonsense is delegated to lower-paid clerical staff, not 'managers.'
This is incredibly demeaning of people in hospitals who actually have to do these jobs. There's a massive amount of work required here and it is by no means "clerical". When "customers" literally have their lives in a doctor's hands, the complexity increases hundredfold. There's legal sensitivities, paperwork, spending, collections and so much more stuff involved and this is not even counting the kinds of things they need to do which involves interfacing with patients and their kin about sensitive matters. This is not simply "admin work". This is critical, life saving stuff
Are managers of doctors saying ridiculous things like you need to only seem patients 30 and up this week, or your not diagnosing enough strep throat.
Assuming there is an analogue between a very clinical and technical field like development and an incredibly volatile and human field like medicine is futile. They don't have many of the same problems we do
Instead they have to force doctors to break bad news to patients' relatives or do it themselves, get signatures from both parties for procedures, coordinate in/out patient streams, listen to doctors demand equipment and medicines and face upper management denying them their requests and tons of other such bullshit. Medical insurance and its intricacies is a whole big ball game that they have to constantly play with so that's fun
Instead they have to force doctors to break bad news to patients' relatives or do it themselves, get signatures from both parties for procedures, coordinate in/out patient streams, listen to doctors demand equipment and medicines and face upper management denying them their requests and tons of other such bullshit. Medical insurance and its intricacies is a whole big ball game that they have to constantly play with so that's fun
I have plenty of friends in the medical field and yes you hear stuff like this all the time. “Thirty and up” because maybe there is an underserved community. “Not diagnosing enough strep throat” because maybe there is a recently discovered epidemic and doctors hadn’t been testing for that.
People who have a high level view can direct the folks down in the trenches quite productively.
People who have a high level view can direct the folks down in the trenches quite productively.
> People who have a high level view can direct the folks down in the trenches quite productively.
This shouldn't be middle managers. technical leader is better for that or most senior on the team. An actual leader on the team.
This shouldn't be middle managers. technical leader is better for that or most senior on the team. An actual leader on the team.
I don't think "hospital administration" is really an analogy that helps your argument since the growth of that sector has a significant share of the blame for rising healthcare costs and all kinds of other issues. Some level of support and oversight is needed but it seems to frequently grow to the point where it becomes a net negative.
If you consider interns and residents doctors (which they are), it's not a wild leap of imagination to consider attendings "medical managers".
> Yes. If a doctor is working in a hospital, there are most certainly managers.
Maybe some places. In the US, most doctors are independent providers for hospitals, they don't have a traditional 'manager'. Outside of a hospital setting, this is also true.
> This is not simply "admin work". This is critical, life saving stuff
It may be, but it's lower skill work delegated to people that are subordinate to doctors, not their managers.
Maybe some places. In the US, most doctors are independent providers for hospitals, they don't have a traditional 'manager'. Outside of a hospital setting, this is also true.
> This is not simply "admin work". This is critical, life saving stuff
It may be, but it's lower skill work delegated to people that are subordinate to doctors, not their managers.
> In the US, most doctors are independent providers for hospitals, they don't have a traditional 'manager'
You are putting a round peg in a square hole. As I already stated, these are not the kind of managers we see in development where your manager is your "boss". Even as independent providers, doctors will have someone they are interfacing with who will see to the admin and other work so they are focused on medicine. Less than half of all practicing doctors in hospitals in the US are independent. Most of them are employed by the hospital. You are grievously misunderstanding the role of the "manager" here. There are certainly far fewer managers in independently practicing medical facilities like clinics but that's because the volume is far lower and the doctors themselves wear many hats
> but it's lower skill work delegated to people that are subordinate to doctors
Again, this is very insulting to the people working these roles. They are not "subordinate" and the work in not "low skill". These are parallel roles to doctors. Leaving this kind of work to doctors would result in a failure of the medical profession in its entirety because of the sheer volume and sensitivity of it
You are putting a round peg in a square hole. As I already stated, these are not the kind of managers we see in development where your manager is your "boss". Even as independent providers, doctors will have someone they are interfacing with who will see to the admin and other work so they are focused on medicine. Less than half of all practicing doctors in hospitals in the US are independent. Most of them are employed by the hospital. You are grievously misunderstanding the role of the "manager" here. There are certainly far fewer managers in independently practicing medical facilities like clinics but that's because the volume is far lower and the doctors themselves wear many hats
> but it's lower skill work delegated to people that are subordinate to doctors
Again, this is very insulting to the people working these roles. They are not "subordinate" and the work in not "low skill". These are parallel roles to doctors. Leaving this kind of work to doctors would result in a failure of the medical profession in its entirety because of the sheer volume and sensitivity of it
> As I already stated, these are not the kind of managers we see in development where your manager is your "boss".
We're talking about the kind of managers software engineers have. Doctors don't have those kind of managers, that's entirely my point.
> Again, this is very insulting to the people working these roles. They are not "subordinate".
They are definitely subordinate in any patient-care scenario. Anyway, I feel like you're missing the point of the analogy, analogies aren't perfect, and you know well what I meant.
If you want to argue lawyers and doctors have managers, fine, give engineers that kind of a manager. IMO, these are subordinate clerical people.
We're talking about the kind of managers software engineers have. Doctors don't have those kind of managers, that's entirely my point.
> Again, this is very insulting to the people working these roles. They are not "subordinate".
They are definitely subordinate in any patient-care scenario. Anyway, I feel like you're missing the point of the analogy, analogies aren't perfect, and you know well what I meant.
If you want to argue lawyers and doctors have managers, fine, give engineers that kind of a manager. IMO, these are subordinate clerical people.
You are simply refusing to accept the fact that doctors have managers and are simply labelling it "clerical". It is in no way simply clerical at all. These are people they report to regularly, who help manage their schedules, help with career growth, set priorities and targets, interface with upper management to avoid cruft coming down, dispel distractions to force their focus on what matters and so on. I will strongly state once again that this is in no way, shape, or form "secretarial". Often times, for junior doctors, they are most definitely superiors. The reason for the change in power balance from engineering organisations is because doctors have the significantly more challenging aspect that they are dealing with human lives so managers tend to stay out of their way more but their role is not diminished
Your analogy is bad only because you have no idea what you're talking about. Technical people need managers because technical people will do things other than their actual jobs and I say this very frankly as a developer. It is remarkable how similar doctors and engineers can be in that they are lost if left to their own devices. Just as an experienced engineer will wear many hats and can manage themselves, experienced doctors also successfully set up their own practices where they can manage themselves. But a good hospital manager can literally save and change lives
Your analogy is bad only because you have no idea what you're talking about. Technical people need managers because technical people will do things other than their actual jobs and I say this very frankly as a developer. It is remarkable how similar doctors and engineers can be in that they are lost if left to their own devices. Just as an experienced engineer will wear many hats and can manage themselves, experienced doctors also successfully set up their own practices where they can manage themselves. But a good hospital manager can literally save and change lives
I'm not sure that's true.
Many lawyers do work on separate projects: Alice drafts my will, Bob handles your divorce, etc. Since these can usually proceed independently, there's not much to manage. However, bigger cases/projects usually do have a structure: someone, perhaps a partner, interacts with the client, develops a strategy, and delegates its implementation to associates.
Likewise, the doctor who manages your blood pressure in a private practice is fairly independent. On the other hand, hospitals, especially teaching ones, often incredibly hierarchical, with med students at the bottom and layers of interns, residents, chief residents, fellows, and attending, with a department chair on top. Attendings can treat patients individually, but they also oversee the work of the more junior staff; they're even called "supervising physicians" in some places.
If any project has more than a few people, I'm not sure how a "team" can proceed without at least a de facto organize/leader, and if that leader spends most of their time leading....well, that's a manager.
Many lawyers do work on separate projects: Alice drafts my will, Bob handles your divorce, etc. Since these can usually proceed independently, there's not much to manage. However, bigger cases/projects usually do have a structure: someone, perhaps a partner, interacts with the client, develops a strategy, and delegates its implementation to associates.
Likewise, the doctor who manages your blood pressure in a private practice is fairly independent. On the other hand, hospitals, especially teaching ones, often incredibly hierarchical, with med students at the bottom and layers of interns, residents, chief residents, fellows, and attending, with a department chair on top. Attendings can treat patients individually, but they also oversee the work of the more junior staff; they're even called "supervising physicians" in some places.
If any project has more than a few people, I'm not sure how a "team" can proceed without at least a de facto organize/leader, and if that leader spends most of their time leading....well, that's a manager.
The important distinction is:
A partner in a law firm, who oversees a large case, is a lawyer. A doctor overseeing med students, etc. is .. a doctor.
These are competence and seniority hierarchies. That is very often not the case for eng. managers (and so inherently more dubious and less useful).
Try telling a surgeon, that his new supervisor is basically a glorified clerk, who will tell him what to do and in what timeframe. Having worked with doctors, I can vividly imagine a hilarious scene.
A partner in a law firm, who oversees a large case, is a lawyer. A doctor overseeing med students, etc. is .. a doctor.
These are competence and seniority hierarchies. That is very often not the case for eng. managers (and so inherently more dubious and less useful).
Try telling a surgeon, that his new supervisor is basically a glorified clerk, who will tell him what to do and in what timeframe. Having worked with doctors, I can vividly imagine a hilarious scene.
Doctors have professional bodies that they can be removed from, same with lawyers, and accountants, and any number of professional associations. But the big differentiator is that largely these professionals do their work solo. They may need to consult with peers from time to time, but their day-to-day bread and butter is their own. Software development is not solo for the vast majority of devs. They need order and the ability to be directed to create a piece of the larger pie.
This is from a 20 year dev who's spent a few of those in management, but enjoys development more.
This is from a 20 year dev who's spent a few of those in management, but enjoys development more.
> Do doctors have managers?
LMAO. Yes. They are doctors who went into management.
LMAO. Yes. They are doctors who went into management.
Isn’t that true for everything though? More bad devs exist than good one? I guess a manager could make the same claim that devs are making his life miserable.
Yeah, it goes both ways. Worse is when someone thinks that they're this magical unicorn that is always right when they're in fact more often wrong and correspondingly makes trouble for everyone else. They make you out to be the enemy when you're not. It's horrible when that person is a manager. But it's also horrible when that person is a developer. Or any other role. I've managed people that you just have to let go, after trying every method known to man, you can't fix their fundamental psychology and neuroticism. Some people are just broken and organizations unfortunately are not equipped to deal with that (would be nice if every organization could have an in-house psychiatrist, but that's not the reality we have).
I will concede this though. When that bad person is a manager, EVERYONE on the team can suffer, the entire culture can suffer. When that person is just a team member, others on the team can usually figure out how to just avoid that person so that the problem can be compartmentalized. Better still, a good manager will not tolerate the bullshit because they know that it can poison the team if not handled properly. When that person is a manager, there's no avoiding the problem and team policies and culture will be poisoned accordingly so that the best people leave and nothing good is left.
I will concede this though. When that bad person is a manager, EVERYONE on the team can suffer, the entire culture can suffer. When that person is just a team member, others on the team can usually figure out how to just avoid that person so that the problem can be compartmentalized. Better still, a good manager will not tolerate the bullshit because they know that it can poison the team if not handled properly. When that person is a manager, there's no avoiding the problem and team policies and culture will be poisoned accordingly so that the best people leave and nothing good is left.
Isn’t that true for everything though? More bad devs exist than good one?
It wouldn't surprise me to learn that a large number of users in this community have actually worked in a bubble of tech outside the norm where most devs were actually pretty solid overall. A developer who is truly incompetent (not just mediocre) would have a very hard time even getting hired at a FAANG or similar, let alone stick around very long.
It wouldn't surprise me to learn that a large number of users in this community have actually worked in a bubble of tech outside the norm where most devs were actually pretty solid overall. A developer who is truly incompetent (not just mediocre) would have a very hard time even getting hired at a FAANG or similar, let alone stick around very long.
Be careful with the echo chamber you Want to believe in vs what it is. There’s plenty of incompetent people at FAANG or in HN.
Actually I've developed the wisdom to realize that 90% of people are not good at what they do for a living. They don't have that job because they're talented at it, they have it because they needed a job.
Its true, but I think the impact is what matters. Even a below average dev produces output; it may be substantially less than a great dev, it may not be of the highest quality, they may require more hands-on reviews and mentorship from other devs on the team, but its still producing output. In comparison, a bad manager can invert the productive output of a team or individuals on that team; high attrition rates, high quiet-quitting rates, prioritizing the wrong things, interrupting work such that little gets done, not playing defense, etc etc etc.
The "old" saying (well, I've heard it said a few times) is: bad software (probably) won't kill your business. There's a litany of examples to this effect. However, bad management will, with increasingly leveraged effects the further that bad management is from the line worker.
The "old" saying (well, I've heard it said a few times) is: bad software (probably) won't kill your business. There's a litany of examples to this effect. However, bad management will, with increasingly leveraged effects the further that bad management is from the line worker.
Bad developers write code that has a negative impact on team prouctivity. e.g. by insisting on a wildly overcomplicated implementation or writing poor tests and being aggressive to anyone that questions them, or being highly negative about some decision or other to the point where the team are not sure if that person is in charge or their manager is.
They can also pester everyone with mountains of trivia in PRs and refuse to change anything in their own and so on and on.
My own boss says "the main thing is to hire nice people - everything else can be improved" and that changed my perspective a lot. I think he's right.
A bad EM can do more damage of course. :-)
They can also pester everyone with mountains of trivia in PRs and refuse to change anything in their own and so on and on.
My own boss says "the main thing is to hire nice people - everything else can be improved" and that changed my perspective a lot. I think he's right.
A bad EM can do more damage of course. :-)
But the worst thing ever is when a bad dev gets promoted to the position of a dev manager or a tech lead. Armed with “knowledge” and “experience,” and now with a degree of authority, they would put their weight on everything they touch. The damage will be immense (but no one would care).
So now we’re including actual engineers in this perpetual rant against management, now? Is it only engineers whose sole job is to write code given a spec who are valuable? At what level of seniority is a job “useless” or worse?
Bad devs do not have reports they would have authority over. Bad EMs do.
The power dynamic is completely different. Managers have the ability to hire/fire, guide technical decisions (usually for the worse) and set the tone for the team since its "their" team. The team itself has very little recourse over a bad manager.
They can quit. I promise you as a manager I spend at least half my time trying to keep developers happy and engaged because losing even one of them will cost the team way, way more in productivity than indulging somebody who wants to implement a perhaps-overengineered solution.
I don't know how it is everywhere, but in my neck of the woods good developers are hard to recruit and expensive to lose - they have a lot of leverage and they know it.
I don't know how it is everywhere, but in my neck of the woods good developers are hard to recruit and expensive to lose - they have a lot of leverage and they know it.
I've met devs who don't have the self-confidence to leave their current job under a terrible manager because they don't want to go through the equally terrible interview loops. They're stuck in some kind of purgatory.
But a manager is something you progress into. How did bad people progress into it?
This is actually pretty consistent across companies: being the most senior person around when the last manager leaves. Sometimes it's a senior dev, sometimes a PM, heck I've seen it be somebody from the UX org. The path of least resistance is a quick promotion from within. As many of us have experienced this leaves us with a non-zero amount of managers who are both unqualified and uninterested in their role, but accept it for status (you're supposed to get promotions after X years right?) and pay reasons.
what people don't undertand (and that included me, when I did the change) is that being a manager is a totally different job than being a developer. you can be an extremely good developer, but be a lousy manager. there are different skills needed for those roles and not all of them are transferable. when you transition from a senior developer, you don't transition into a senior manager, you start from zero. it helps to be a good dev, but it's not a guarantee for success.
This is a common misconception and it is exactly how "bad people" progress into a role where they aren't a match. It is an entirely different role. Most engineering managers come from an engineering background and rely on the learned experiences of that job in order to be successful.
There are oodles of terrible managers. There are oodles of terrible everything and we definitely remember the bad experiences more than the good experiences. Especially since a lot of what a good manager does (deflect distractions, ensure consistent prioritization, hire people who don't suck) makes it seem like nothing is actually happening.
A very large number of people really are saying that these roles aren't necessary. Larry Page famously fired all of the managers at Google at one point in the past. I regularly see people say that zero management at all would be preferable, both for startups and megacorps. Heck, the article itself is about this very idea.
A very large number of people really are saying that these roles aren't necessary. Larry Page famously fired all of the managers at Google at one point in the past. I regularly see people say that zero management at all would be preferable, both for startups and megacorps. Heck, the article itself is about this very idea.
Sturgeon’s Law: 90% of everything is crap. This applies to managers and to engineers. Turn your argument around and ask what happens when good managers have to deal with crappy engineers, because there are a lot of crappy engineers too. (And note especially that engineers can be bad on many axes. It’s possible for people with excellent technical skills to bring negative value to the organization due to poor attitude or poor communication, among other things.) Do you want good managers to judge you and assume that you’re a bad engineer just because they’ve had to manage some other bad engineers? Bad engineers also taint the role and lead to a certain earned reputation.
But if everyone projects their worst fear on the role, then we’re all stuck making assumptions, being pessimistic, and missing the good people because we’re blinded by our stuck ideas incorrectly generalizing individual people to their roles. If we can’t stop to see the good things and what does work, then functioning together is difficult and it drags down the team.
What value do you see in good management, and what makes a good manager in your experience?
But if everyone projects their worst fear on the role, then we’re all stuck making assumptions, being pessimistic, and missing the good people because we’re blinded by our stuck ideas incorrectly generalizing individual people to their roles. If we can’t stop to see the good things and what does work, then functioning together is difficult and it drags down the team.
What value do you see in good management, and what makes a good manager in your experience?
I'm a PM, and I've had to live through a fair number of god awful engineers. It's miserable to work with them, too.
I don't malign the profession because I've had bad experiences. Engineers should be smart enough to know that experiencing a bad manager, or even a few bad managers doesn't mean that " people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all."
That's just being irrational and salty.
I don't malign the profession because I've had bad experiences. Engineers should be smart enough to know that experiencing a bad manager, or even a few bad managers doesn't mean that " people who live in these roles are overall bad, don't know how to effectively execute these tasks and present an aura of superiority over the technical roles when they're providing very little value at all."
That's just being irrational and salty.
I’ve had to work with a lot more terrible engineers than terrible manages.
A lot of the time, what makes someone good or terrible in their role is maturity and professionalism.
A lot of the time, what makes someone good or terrible in their role is maturity and professionalism.
I don’t know. I think what some people complain about here when they talk about bad management has nothing to do with management. Most seems to complain they have to do reporting which is not fun. While that’s generally true I wouldn’t call that bad management.
I had a relatively bad (inexperienced and overwhelmed would be truer) manager once when I was still doing engineering years ago. I know he was bad because I had to do a significant part of his job for him notably regarding smoothing interpersonal issues in the team and cross-team communication in the org. I don’t see most people here complaining they have to do too much management.
I had a relatively bad (inexperienced and overwhelmed would be truer) manager once when I was still doing engineering years ago. I know he was bad because I had to do a significant part of his job for him notably regarding smoothing interpersonal issues in the team and cross-team communication in the org. I don’t see most people here complaining they have to do too much management.
>because more terrible managers exist than those "good ones" that you allude do.
The irony is that I've heard the same said about engineers. It's easy to take the cynical point of view, but probably not wise or accurate. Like the OP, in my experience the people making those types of claims tend to have an overly simplistic view of the problem.
The irony is that I've heard the same said about engineers. It's easy to take the cynical point of view, but probably not wise or accurate. Like the OP, in my experience the people making those types of claims tend to have an overly simplistic view of the problem.
'more terrible managers exist than those "good ones" that you allude do'
This is quite hyperbolical. A person can have a life experience of "mostly bad manager", but that does not mean "most managers are bad" or that "most people have experienced bad management".
I've been 16 years as a professional software engineer. I would not describe anyone to whom I was a direct report as "bad manager". Quite contrary, I've been quite happy with most of them. This does not mean a life without conflict or misunderstanding, of course.
Statistically, bad management is of course a non-neglible problem, but the above makes the situation sound hopelessly pathological.
This is quite hyperbolical. A person can have a life experience of "mostly bad manager", but that does not mean "most managers are bad" or that "most people have experienced bad management".
I've been 16 years as a professional software engineer. I would not describe anyone to whom I was a direct report as "bad manager". Quite contrary, I've been quite happy with most of them. This does not mean a life without conflict or misunderstanding, of course.
Statistically, bad management is of course a non-neglible problem, but the above makes the situation sound hopelessly pathological.
> I would posit a guess that most, if not all, engineers on HN have had to live through at least one terrible manager that has soured/tainted the position.
FWIW, all my engineering managers have been great.
> Oh please, there's a reason why those comments exist - because more terrible managers exist than those "good ones"
I guess that's just your experience? Just because you've had a few bad apples doesn't mean all engineering managers are terrible.
> present an aura of superiority
Sounds like you're just projecting your experience onto other folks.
FWIW, all my engineering managers have been great.
> Oh please, there's a reason why those comments exist - because more terrible managers exist than those "good ones"
I guess that's just your experience? Just because you've had a few bad apples doesn't mean all engineering managers are terrible.
> present an aura of superiority
Sounds like you're just projecting your experience onto other folks.
I'd wager the percent of terrible managers is the same as that of terrible engineers. We all have worked with such coworkers at some point in our careers. Yet no one ever turns around and says "the engineering role is bullshit", simply because that would invalidate their own careers.
Eningeers get tons of actually effective training and schooling. Alot of people probably spent at least 4 years in school learning a science where there are right and wrong answers. It's easy to evaluate engineers. Most managers seemed to get to that role by accident, or because they knew the right person. I think there's way more underperforming managers. Managers aren't going to school for years, even when they do the degree they come out with feels useless.
[deleted]
One of my least favorite things about being on the technical side of things is this overarching smug sense of superiority that every other role is bullshit and doesn't do anything of real value. Or that other roles are malicious and/or incompetent and if engineers got their way the product would be perfect and free of defects of errors. e.g: "Don't blame the developers for X, we only put it in because of product or sales!"
Well product or sales probably don't like stuffing the product with ads, they only put it in there because you like collecting a paycheck every month.
Well product or sales probably don't like stuffing the product with ads, they only put it in there because you like collecting a paycheck every month.
Good way to bash that down is to ask 'would you want their role?' It makes them stop and think what does that person really do and they usually do not want to do it at all.
I think that often engineers hold the view that the role in question doesn’t need to exist. And some roles are just welfare for MBAs.
I guess they have read "Bullshit Jobs".
I've never personally felt that race-to-the-bottom capitalism would generally allow for such parasitic drains on productivity, but then again, if you're hiring on past contributions only, how would you as a non-expert in sales/marketing/etc know what makes efficiency?
I don't think your view is anywhere near as common as you think it is, but maybe in your immediate peer group there's some self-selecting cause for believing so.
I don't think your view is anywhere near as common as you think it is, but maybe in your immediate peer group there's some self-selecting cause for believing so.
I didn’t say it was my view, just what I’ve seen in expressed by others.
This was the question I asked myself that totally changed how I thought about sales and marketing people.
I cannot do sales, I do not want to do sales, but if I want a job someone needs to do sales. To me sales looks like an awful job, but some people really get a kick out of it and I'm glad they do because otherwise I would earn a lot less than I do.
We love to think that "if we build it they will come" but the reality is very different, and most of us work for companies that would struggle to grow without some form of sales or marketing operation, no matter how good the product might be.
I cannot do sales, I do not want to do sales, but if I want a job someone needs to do sales. To me sales looks like an awful job, but some people really get a kick out of it and I'm glad they do because otherwise I would earn a lot less than I do.
We love to think that "if we build it they will come" but the reality is very different, and most of us work for companies that would struggle to grow without some form of sales or marketing operation, no matter how good the product might be.
> To me sales looks like an awful job
You meet new people. They tell you about their problems. You explain to them how your product can alleviate them. You work on finding a common position regarding what you could bring at which price. When it works, you get a big cheque. It’s pretty fun really.
You meet new people. They tell you about their problems. You explain to them how your product can alleviate them. You work on finding a common position regarding what you could bring at which price. When it works, you get a big cheque. It’s pretty fun really.
I think the outbound cold calling side of it was the bit that never appealed.
Once that connection has been made I can definitely see the attraction.
Once that connection has been made I can definitely see the attraction.
That is a terrible argument. Would you want to be the office elevator boy? I like to be useful so of a role would be useful I would want to do it even less.
As for what I think about managers: unsure, I have been a manager, worked under many managers (most of them bad) but I am still not sure if mangers should exist or be replaced with another role.
As for what I think about managers: unsure, I have been a manager, worked under many managers (most of them bad) but I am still not sure if mangers should exist or be replaced with another role.
I don't want the janitor's role either, but that person isn't in charge of me. Engineering managers are glorified secretaries. We should replace them with actual secretaries that are subordinate to engineers.
My best experiences with managers were ones that did that. Just let me work and help me if I need it. I'll reach out if I do.
That's not a manager, that's a secretary, which is my point. Engineering groups don't need managers, they need lead engineers and clerical staff, similar to a group of lawyers or doctors.
Managers jobs are typically kind of like a secretary but more. But more of a jack of all trades. Making sure the budget is correct for this year so we can hire the right amount of people (accountant). Jim on the third row needs a lot more hand holding than usual because his wife is in chemo (HR). Going to the upper management to make sure that 3 of your co-workers get the recognition they deserve (cheerleader). Sitting in that 3 hour meeting working out who is going to pay for that feature the sales guys must have (negotiator). Plus a dozen other things. If that position did not exist you know who would be doing that? You and all of your coworkers would. Are a lot of people bad at that? Yep. But some are good too.
The point of my question is to make people stop and think about the chesterton's fence of why is that position there. For example your janitor example. Extremely well defined position. Most people do not want it (including yourself).
The point of my question is to make people stop and think about the chesterton's fence of why is that position there. For example your janitor example. Extremely well defined position. Most people do not want it (including yourself).
You think lawyers and doctors don't have people to manage them?
The reason most engineers don't have secretaries is because we usually prefer doing the same thing with automation and scripts.
The reason most engineers don't have secretaries is because we usually prefer doing the same thing with automation and scripts.
I'm curious what difference you see between a "manager" and a "lead engineer".
A manager often isn't even an engineer, and a lead engineer often doesn't have a manager role.
Edit: To clarify lead engineer, they have authority over technical decisions, not people management.
Edit: To clarify lead engineer, they have authority over technical decisions, not people management.
One of the best things I ever did was run a business on my own very early on.
I was terrible at it. Forced to actually contact customers I had no clue what to do. I had no idea how to price things. I communicated terribly and drove away initial customers.
I learned a healthy respect of other positions in a company, because when I tried them I had to accept they were actually hard.
I was terrible at it. Forced to actually contact customers I had no clue what to do. I had no idea how to price things. I communicated terribly and drove away initial customers.
I learned a healthy respect of other positions in a company, because when I tried them I had to accept they were actually hard.
Instead of an ad-hominem attack against a strawman, can you actually address the points made by these people you're labeling as professionally immature and unwilling to understand these non-engineering roles? Can you actually provide anything that illustrates your point at all? Just calling us all immature children does nothing to change my mind; it only makes me think you're defensive because you know deep down that your role is actually truly worthless bullshit. How many hours per day do you spend in meetings?
Every other part of a business runs on politics (i.e. bullshit). If you don’t want to be dealing with that 100% of the time, you need someone else to do it for you. And they will necessarily have to expose you to some of it, sometimes, to get info from you so they can communicate what’s going on to the rest of the business. Without the rest of the business doing what they do, you have nowhere to work.
And sorry, unlike a program you’re writing, you don’t have any say in how the logic works (or doesn’t). The rules are set and you’re in the system. You might be able to find some variations in other companies.
And sorry, unlike a program you’re writing, you don’t have any say in how the logic works (or doesn’t). The rules are set and you’re in the system. You might be able to find some variations in other companies.
You clearly only read the first third of the (admittedly) somewhat roundabout and meandering commentary. I know because your comment was what I was thinking until about a third of the way through, when I realized that that was not at all what this person is saying.
He only read the headline and now we're all discussing his feelings instead of reading the article which is about something else entirely. I recommend anyone still following this dysfunctional thread to go ahead and read it.
Being younger and 'technical' it's easy to feel as if you're a linchpin to the whole process and everything else is peripheral (This happens in every department though btw). I think everyone should try their hand at starting a business or launching a product (technical or non-technical). You will be amazed the labor and efforts that go into even the most mundane things and you will quickly be wishing you could hire on someone to help manage your product/project, help you market and network, help you find out which forms you need to fill out for taxes you didn't realize you needed to pay, what these terms actually mean, how to find capital, etc, etc, etc. If your product takes off I would guarantee you aren't going to hire an engineering manager to 'analyze' your engineers in order to optimize them as much as you are wanting someone to keep up with day-to-day issues and priorities so you don't have a dozen engineers sheering yaks or you aren't spending an inordinate amount of time dealing with a dozen engineers individual issues while trying to run a business and allocate yourself in a dozen other directions. Like you mention you become a lot more happy when you realize the tremendous efforts people on your team make (there are always exceptions) that may or may not be in your department.
I think these comments come mostly from engineers who have just started their software engineering journey or somewhere in their early stages. When you are at that stage, your odds of coming across an inspiring figure in other areas are very low, unless you have a natural proclivity to other areas in your life.
As you grow, you do realize that software engineering is a piece in the overall puzzle and you mellow down and start to learn the interfaces with other functions. Even then your superiority bias won't away but will mellow down for sure. This is simply because your success as a mid-senior engineer is no longer a function of just your engineering skills. Its a function of how well you can sell your ideas, how you can articulate your messaging so that every other function can work with you, how do you get buy-in from competing parties etc. But again, engineers will brush these aside as 'politics' unrelated to software engineering :)
As you grow, you do realize that software engineering is a piece in the overall puzzle and you mellow down and start to learn the interfaces with other functions. Even then your superiority bias won't away but will mellow down for sure. This is simply because your success as a mid-senior engineer is no longer a function of just your engineering skills. Its a function of how well you can sell your ideas, how you can articulate your messaging so that every other function can work with you, how do you get buy-in from competing parties etc. But again, engineers will brush these aside as 'politics' unrelated to software engineering :)
When I was just starting out as an engineer, I was very interested in what management was doing. I went to every town-hall type meeting I could, every business planning meeting, every financial meeting. I really wanted to be steeped in it to understand the role.
Year after year after year I learned again and again that there's something truly toxic about middle-management and up. It's like the higher you go, the worse the air gets, and your brain starts to get clouded and fuzzy. Technical people stay in their roles for decades and get better and better over time; management plays musical chairs where they change roles every 2 or 3 years. The new role has almost nothing to do with their old role. If you saw a whole group of people randomly switch every couple years between being an Aerospace Engineer, then a Software Engineer, then an Environmental Engineer, then a Structural Engineer, you'd rightly go: wow, all these engineering jobs must be super easy! They just throw anybody into those roles. They don't take any time to learn, etc. etc. So why, when people randomly switch every couple years between product manager, director of operations, financial director, project manager, sales manager, director of internal innovation, director of digital growth, director of New-Techy-Buzzword -- why do you not conclude the same thing? All those jobs are stupid and worthless, clearly, because they come and go with the wind, and anyone in the mid-to-upper-management sphere can take on any of those roles. Clearly they require no training. Clearly they are not hard. Having an MBA degree does not qualify you to do all of those roles, unless those roles have absolutely nothing to them. Note that I intentionally excluded anything having to do with "legal" in there, because that's an actual job that takes an actual expert.
My long-winded point is that I did the exact opposite of what you claim. I used to believe that software engineering is a piece in the overall puzzle and that all these other functions are an important part. But I learned, time and time and time again, that the primary driving force in corporate America is the Principal Agent Problem and that all these roles are just titles to be shuffled around among those in the Business Caste for their own personal benefit. Entire companies are nothing more than pawns in the game these guys (and it is mostly men) are playing with each other, jockying for the most impressive-sounding titles, extracting as much money as they can from the public sector into their own pockets. If they're actually doing their job well, they're losing at the game. You have to switch jobs every couple years to keep up.
Year after year after year I learned again and again that there's something truly toxic about middle-management and up. It's like the higher you go, the worse the air gets, and your brain starts to get clouded and fuzzy. Technical people stay in their roles for decades and get better and better over time; management plays musical chairs where they change roles every 2 or 3 years. The new role has almost nothing to do with their old role. If you saw a whole group of people randomly switch every couple years between being an Aerospace Engineer, then a Software Engineer, then an Environmental Engineer, then a Structural Engineer, you'd rightly go: wow, all these engineering jobs must be super easy! They just throw anybody into those roles. They don't take any time to learn, etc. etc. So why, when people randomly switch every couple years between product manager, director of operations, financial director, project manager, sales manager, director of internal innovation, director of digital growth, director of New-Techy-Buzzword -- why do you not conclude the same thing? All those jobs are stupid and worthless, clearly, because they come and go with the wind, and anyone in the mid-to-upper-management sphere can take on any of those roles. Clearly they require no training. Clearly they are not hard. Having an MBA degree does not qualify you to do all of those roles, unless those roles have absolutely nothing to them. Note that I intentionally excluded anything having to do with "legal" in there, because that's an actual job that takes an actual expert.
My long-winded point is that I did the exact opposite of what you claim. I used to believe that software engineering is a piece in the overall puzzle and that all these other functions are an important part. But I learned, time and time and time again, that the primary driving force in corporate America is the Principal Agent Problem and that all these roles are just titles to be shuffled around among those in the Business Caste for their own personal benefit. Entire companies are nothing more than pawns in the game these guys (and it is mostly men) are playing with each other, jockying for the most impressive-sounding titles, extracting as much money as they can from the public sector into their own pockets. If they're actually doing their job well, they're losing at the game. You have to switch jobs every couple years to keep up.
[deleted]
Instead of actually reading the article and critiquing what the author wrote, you've taken it personally and really just haven't provided any valid points.
The last 2 paragraphs of your comment can be applied to your behavior actually.
The last 2 paragraphs of your comment can be applied to your behavior actually.
If you have something to explain about the roles of non-eng professions, then do so. All this post does is argue how you’re more mature and superior to everyone else in the thread (without explaining exactly how that is, or giving any particular insight).
RTFA before commenting please
Your comment added nothing because it was responding to a straw man rather than the article itself.
Your comment added nothing because it was responding to a straw man rather than the article itself.
You are right. Running a business is nuanced and smart people are required for it.
Imo, the real problem is that engineering work is disproportionately difficult compared to management and yet, management gets recognition, visibility and power to control engineer lives. This happens in every step. Engineering interviews are insanely harder than management, engineering promos are opaque and need grinding for years as opposed to management promos in growing companies and these days, senior engineers have to manage politics as well. Engineering managers are not useful in any way but yet, get higher compensation and recognition. Why?
The only manager that engineers like are those who have previously been strong engineers themselves. It's the earned respect that lets people be ok with bosses. Not titles themselves. Certainly not people management or glorified assistants managing spreadsheets for upper levels.
Imo, the real problem is that engineering work is disproportionately difficult compared to management and yet, management gets recognition, visibility and power to control engineer lives. This happens in every step. Engineering interviews are insanely harder than management, engineering promos are opaque and need grinding for years as opposed to management promos in growing companies and these days, senior engineers have to manage politics as well. Engineering managers are not useful in any way but yet, get higher compensation and recognition. Why?
The only manager that engineers like are those who have previously been strong engineers themselves. It's the earned respect that lets people be ok with bosses. Not titles themselves. Certainly not people management or glorified assistants managing spreadsheets for upper levels.
As someone who has switched between management and IC work, I’ve found management to be much, much more difficult to do well. Management should be managing people, which is much harder than managing code.
Perhaps this is why there are so many bad examples. The job is nearly impossible to do exceptionally well.
Perhaps this is why there are so many bad examples. The job is nearly impossible to do exceptionally well.
But in fuzzy disciplines like management you're allowed not to do well. Engineers are fighting with the law of physics. You can't bullshit your way out of a formula or a bug in your code. Thus when bad managers demand that you do x by end of the day/week/month they put an insane amount of pressure on you because there's only one way out. You have to crack the code, you must figure the problem out.
Therefore technical people develop a special sort of humility, reminded everyday of their errors by the law of physics, that bad managers who fail forward never do.
Therefore technical people develop a special sort of humility, reminded everyday of their errors by the law of physics, that bad managers who fail forward never do.
> Engineers are fighting with the law of physics. You can't bullshit your way out of a formula or a bug in your code
I mean, structural engineers are fighting physics. Software engineers, generally, are fighting information theory. FWLIW, I spent 15 years as a (quite successful) programmer with a lot of bullshittery going on about what code works. Have you never shipped buggy code and played it down b/c of time constraints or you were just tired or not motivated or realized this bit doesn't actually need to be perfect?
That's actually why I switched to being a people manager - I was a mediocre programmer that people thought was exceptional because I was good at the b.s. I find people management much more difficult to do well, and much more rewarding when growing junior eng into senior eng compared to shipping a bit of code.
I mean, structural engineers are fighting physics. Software engineers, generally, are fighting information theory. FWLIW, I spent 15 years as a (quite successful) programmer with a lot of bullshittery going on about what code works. Have you never shipped buggy code and played it down b/c of time constraints or you were just tired or not motivated or realized this bit doesn't actually need to be perfect?
That's actually why I switched to being a people manager - I was a mediocre programmer that people thought was exceptional because I was good at the b.s. I find people management much more difficult to do well, and much more rewarding when growing junior eng into senior eng compared to shipping a bit of code.
I think the critical point is: You've done both. I don't know you, but I will go out on a limb and say: having that history as an IC makes you a better EM; one of the good ones I hope.
Great EMs have that experience; and it makes their/your job way harder because now you understand, at a deep enough level, what the people you manage are going through. When product reqs come across the desk of an IC-turned-EM, they can feel that gut punch immediately: "fuck, this is going to be so hard, that system is so legacy, and Sarah is super overloaded right now because she's the only one with any experience on the message bus transformer converter ingester"
Management track EMs actually do have it easier, because they get to think in the discrete world of tickets and human resources.
At a high enough level in any company: senior leadership needs to think about the world as perfectly discrete like that, because there's so much other bullshit going on that worrying about the specifics of the message bus transformer converter ingester would drive them off a cliff. But EMs aren't that. But many, many EMs think like that, and a big part is the incentive structure of their career path; their boss thinks like that, and their boss's boss thinks like that, so if I want to have my boss's boss role one day I need to think like that.
The strawman side of what I'm arguing is: "Well, you're just describing a bad EM". But the whole point is that that's quickly becoming the average in the industry, and that average is starting to define the role. Career-track management who get promotions, then write the hiring reqs for their replacements, and every other EM below them, combined with a massive shortage of engineering talent meaning companies need to define a different bar for their EM hiring reqs anyway.
Great EMs have that experience; and it makes their/your job way harder because now you understand, at a deep enough level, what the people you manage are going through. When product reqs come across the desk of an IC-turned-EM, they can feel that gut punch immediately: "fuck, this is going to be so hard, that system is so legacy, and Sarah is super overloaded right now because she's the only one with any experience on the message bus transformer converter ingester"
Management track EMs actually do have it easier, because they get to think in the discrete world of tickets and human resources.
At a high enough level in any company: senior leadership needs to think about the world as perfectly discrete like that, because there's so much other bullshit going on that worrying about the specifics of the message bus transformer converter ingester would drive them off a cliff. But EMs aren't that. But many, many EMs think like that, and a big part is the incentive structure of their career path; their boss thinks like that, and their boss's boss thinks like that, so if I want to have my boss's boss role one day I need to think like that.
The strawman side of what I'm arguing is: "Well, you're just describing a bad EM". But the whole point is that that's quickly becoming the average in the industry, and that average is starting to define the role. Career-track management who get promotions, then write the hiring reqs for their replacements, and every other EM below them, combined with a massive shortage of engineering talent meaning companies need to define a different bar for their EM hiring reqs anyway.
I have seen many (extremely smart too) engineers cry at work, but never managers. Make of it what you will.
People with emotional issues aren't as likely to be promoted into management. Management is often way more stressful as you're getting dumped on from above, from peer managers, and all the negative feedback from devs all at the same time (plus needing to actually facilitate getting things built). Maybe you work at some poor company that can't promote devs high enough so they're forced into some form of management role to get a promotion. Those companies suck because they steal good IC talent for roles they're less suitable/valuable for, and causes the company to have perverse incentives to over bloat their management pool than necessary.
>> People with emotional issues aren't as likely to be promoted into management.
And engineers who don’t invest in their work emotionally are not usually the best
>> Maybe you work at some poor company that can't promote devs high enough so they're forced into some form of management role to get a promotion.
How does this follow from what I said? Also, I have a bit of experience so it’s not one company
And engineers who don’t invest in their work emotionally are not usually the best
>> Maybe you work at some poor company that can't promote devs high enough so they're forced into some form of management role to get a promotion.
How does this follow from what I said? Also, I have a bit of experience so it’s not one company
I've worked at several big corps and the managers are the ones who take all the stress. I would never ask one of my team (or one of my colleagues) to work to the point where they cried - this is a negative signal.
> Perhaps this is why there are so many bad examples. The job is nearly impossible to do exceptionally well.
I believe that the job is nearly impossible to do well. Which leads a lot of people to suspect that the role of Engineering managers is badly defined. Which leads to all the complaints above. Nobody is happy with the current org structure.
I believe that the job is nearly impossible to do well. Which leads a lot of people to suspect that the role of Engineering managers is badly defined. Which leads to all the complaints above. Nobody is happy with the current org structure.
Spot on. The fact that engineers keep having to learn things continuously for years, decades treading through anywhere from technically difficult issues to bad documentation, mostly on their own time for fear of falling behind, while running to honor daily and hourly deadlines and being imaginative, smart and personable at work is insane. Atleast managers get to rely on their experience that adds up while engineers jump through languages frameworks and libraries while attending leet code interviews is crazy. But peasant, get back to work and no quiet quitting for you, and you are a lower form of life is the prevalent attitude among many managers. There are good managers, most of them technical like you said, a smaller portion among them have empathy
As someone who's spent 25 years straddling the IC/EM line in companies of all sizes, I can tell you unequivocally that management—especially engineering management—is not easier.
I think it's fair so say that gross incompetence is easier to recognize in a programmer than a manager, especially to the untrained eye. It's also true that a well-functioning team may be easy to run and the manager shouldn't have to do much except not fuck it up.
But at any kind of scale, all problems are people problems, and there are never ending systematic dysfunctions and organizational problems. Everyone can be making a valid claim to doing their job, yet the output is nowhere near what it could be. These types of problems can be difficult to diagnose and extremely difficult to unsolvable at the high end. One must be technical enough to understand the details, able to zoom out and understand how costs of various paths interact with UX, operations, security and other concerns, and then say the right things in the right venues to nudge people in the right direction while also maintaining the morale and agency of all the ICs who do the actual work.
It is brutally difficult, and the reason most EMs are bad is not out of malice or sociopathic tendencies (though I will say the emotional toll is high for non-sociopaths which is probably one reason they are disproportionately represented in management and executive leadership).
I think it's fair so say that gross incompetence is easier to recognize in a programmer than a manager, especially to the untrained eye. It's also true that a well-functioning team may be easy to run and the manager shouldn't have to do much except not fuck it up.
But at any kind of scale, all problems are people problems, and there are never ending systematic dysfunctions and organizational problems. Everyone can be making a valid claim to doing their job, yet the output is nowhere near what it could be. These types of problems can be difficult to diagnose and extremely difficult to unsolvable at the high end. One must be technical enough to understand the details, able to zoom out and understand how costs of various paths interact with UX, operations, security and other concerns, and then say the right things in the right venues to nudge people in the right direction while also maintaining the morale and agency of all the ICs who do the actual work.
It is brutally difficult, and the reason most EMs are bad is not out of malice or sociopathic tendencies (though I will say the emotional toll is high for non-sociopaths which is probably one reason they are disproportionately represented in management and executive leadership).
When it comes to managers, it's hard not to say their role is BS for many of us. I've never had a truly good manager (19 in 10 years). Many of their perceptions don't match with mine or the other team members.
A good manager is often invisible. If you forgot they were there, you were either lucky that everything in the org was going right (or was so far away it didn't matter), or they were really good at shielding you from the fact that everything was not going right (and making it seem like that didn't matter). :)
They've all been very visible.
"...actual smart people can make real contributions in non-engineering roles."
Can they? Certainly. Do they? Well, not as often as you might like.
I used to work for a government contractor who had what I liked to think of as a "butts in seats" strategy. The contractor got paid by taking something like 50% off the top of what the customer paid for the employees (back when I was a contractor in industry, that was more like 15% but that is neither here nor there). The "complexity and nuance" that goes into running that business for a maximal profit involves keeping the direct customers happy---and they're managers, not users---while having as many employees as possible. You need to ride the line between leaving money on the table and having so much broken that higher levels of the customer start to get upset. Laying down narratives is a very important part of that process.
This isn't, however, limited to government contracting. I've ridden quite a few projects into the ground in industry because the goals and incentives of Product Managers, Program Managers, etc., were not aligned with the goal of a successful project simply because there are many ways to be a successful manager and a track record of successful products is not the easiest.
Yes, they were all smart people. Many were even likable, skilled leaders. But if your goal as an engineer is to be part of a successful product and not to be a well-rewarded part of a successful manager's organization, then you will not be happy. Is that what you mean by "professional immaturity"?
Can they? Certainly. Do they? Well, not as often as you might like.
I used to work for a government contractor who had what I liked to think of as a "butts in seats" strategy. The contractor got paid by taking something like 50% off the top of what the customer paid for the employees (back when I was a contractor in industry, that was more like 15% but that is neither here nor there). The "complexity and nuance" that goes into running that business for a maximal profit involves keeping the direct customers happy---and they're managers, not users---while having as many employees as possible. You need to ride the line between leaving money on the table and having so much broken that higher levels of the customer start to get upset. Laying down narratives is a very important part of that process.
This isn't, however, limited to government contracting. I've ridden quite a few projects into the ground in industry because the goals and incentives of Product Managers, Program Managers, etc., were not aligned with the goal of a successful project simply because there are many ways to be a successful manager and a track record of successful products is not the easiest.
Yes, they were all smart people. Many were even likable, skilled leaders. But if your goal as an engineer is to be part of a successful product and not to be a well-rewarded part of a successful manager's organization, then you will not be happy. Is that what you mean by "professional immaturity"?
It's hard to identify failing managent, especially from the top looking down, and the burden of management failures fall on those below them. This leads to a lot of frustration and blog posts like this, wondering if all managent is bullshit.
It seems really unfair to a developer, who thinks "if I screw up the entire company halts, if you screw up I have to work harder". And so the developer can't shake the feeling that management is bullshit.
It seems really unfair to a developer, who thinks "if I screw up the entire company halts, if you screw up I have to work harder". And so the developer can't shake the feeling that management is bullshit.
I bet you read the title only, and not the article.
There is way-way more to it than the title. Nowhere did the author reduce the contribution of non-engineering roles.
An excellent read!
There is way-way more to it than the title. Nowhere did the author reduce the contribution of non-engineering roles.
An excellent read!
What may look like cynicism at first is actually just fair criticism. It does not lack maturity, rather the opposite given it has some thoughtful research and examples of why EM can be in fact bullshit.
There’s a lot of roles needed to build a product. As the engineering load grows, the engineers have less time to handle those other duties themselves as much as we might like to.
When that happens, other people have to be involved to take over.
There are real requirements to communicate with other parts of the business, customers, coordinate who is doing what and triage what is needed when.
So generally, I agree with you that the mindset isn’t a great one.
At the same time, there are methodologies that aim to alleviate exactly this problem by ensuring engineers directly control more than they often do.
Scaled Agile (SAFe) is my favorite because of two core tenets.
1. There are 2 backlogs, one managed by product/business and one managed by dev/ops/arch. Going into planning, capacity allocations are given to each (usually 70-30 product dev). Priority among those backlogs is entirely handled by the group managing it.
2. PI Planning where backlog items are presented from each group and dev is responsible for planning out those priorities over the next 8-12 weeks in the manner that they believe is best. Everybody who could potentially answer questions that devs have is present with their schedules cleared to streamline the decision making process. Plans are discussed with management, risks assessed and finally agreed on.
I love this process. It gets everybody on the same page as far as who is doing what, when and why. It reduces friction and lets devs focus for 2-3 months at a time without a directional shift.
Planning from product is focused on the next PI instead of the constant “we have to drop everything and work on X now!” situations that so often happen.
I wish more orgs would adopt it. I hear so often about devs stuck in orgs claiming to do so that aren’t actually doing any of the things that make it great and it’s frustrating.
When that happens, other people have to be involved to take over.
There are real requirements to communicate with other parts of the business, customers, coordinate who is doing what and triage what is needed when.
So generally, I agree with you that the mindset isn’t a great one.
At the same time, there are methodologies that aim to alleviate exactly this problem by ensuring engineers directly control more than they often do.
Scaled Agile (SAFe) is my favorite because of two core tenets.
1. There are 2 backlogs, one managed by product/business and one managed by dev/ops/arch. Going into planning, capacity allocations are given to each (usually 70-30 product dev). Priority among those backlogs is entirely handled by the group managing it.
2. PI Planning where backlog items are presented from each group and dev is responsible for planning out those priorities over the next 8-12 weeks in the manner that they believe is best. Everybody who could potentially answer questions that devs have is present with their schedules cleared to streamline the decision making process. Plans are discussed with management, risks assessed and finally agreed on.
I love this process. It gets everybody on the same page as far as who is doing what, when and why. It reduces friction and lets devs focus for 2-3 months at a time without a directional shift.
Planning from product is focused on the next PI instead of the constant “we have to drop everything and work on X now!” situations that so often happen.
I wish more orgs would adopt it. I hear so often about devs stuck in orgs claiming to do so that aren’t actually doing any of the things that make it great and it’s frustrating.
Interestingly Musk fired the entire Marketing / PR department. Hasn’t seemed to affect Tesla quite yet.
I love how you also snuck Scrum master in there, a role no one needs. Project managers are also often shoved into places they’re not needed (I’ve generally found them to be a net negative vs having the manager be responsible for it).
I love how you also snuck Scrum master in there, a role no one needs. Project managers are also often shoved into places they’re not needed (I’ve generally found them to be a net negative vs having the manager be responsible for it).
this is just personal and professional immaturity. bonecrusher2102's empty comment does not respond to any of the arguments in the blog post. instead it's repeating the same tired prejudice that the commenter inhibits against anyone who is trying to articulate a critique of business management. i really hope bonecrusher is able to grow out of this mindset. they'd be a lot happier and more productive
I don’t discount the importance of Managers. The thing I struggle with is Engineers trying to do the job of Manager without having any training or even really identifying as a manager. They still think their job is to supervise technical decisions.
Meanwhile there are numerous process and personnel challenges that go completely ignored, because these Engineering Managers think their primary responsibility is as some kind of overseer preventing employees from doing their jobs wrong.
I would love if software companies started hiring dedicated, trained Managers. But that doesn’t seem like a thing they do. Instead they just promote an Engineer to Engineering Manager and hope for the best.
Meanwhile there are numerous process and personnel challenges that go completely ignored, because these Engineering Managers think their primary responsibility is as some kind of overseer preventing employees from doing their jobs wrong.
I would love if software companies started hiring dedicated, trained Managers. But that doesn’t seem like a thing they do. Instead they just promote an Engineer to Engineering Manager and hope for the best.
This sounds like a generalization to me.
During my time writing software professionally I've had good, bad, and neutral managers.
I've found most of my good managers at companies that produce software as a product. These managers were technically trained and rose to their management roles through working as engineers at other companies. In two cases these managers were actually the CTO.
Most of my bad managers have been at companies that rely on software to facilitate their business, but do not consider software to be their business. These managers knew little about software and our teams were usually bloated by non-technical roles and often unproductive. Every idea ultimately had to be passed through engineers for validation / refinement and engineering became a very constrained resource.
Neutral management is where I would place most of my managers. They don't really aid in or detract from my productivity. They're there and doing things (even if those things are not always visible to me). They demonstrate enough value to dispell the feelings of: "If you weren't here then we could hire another engineer to actually work on this problem".
That said, you are 100% correct that if I didn't think about these things at all then I'd be much happier. After all, happiness is reality minus expectation.
During my time writing software professionally I've had good, bad, and neutral managers.
I've found most of my good managers at companies that produce software as a product. These managers were technically trained and rose to their management roles through working as engineers at other companies. In two cases these managers were actually the CTO.
Most of my bad managers have been at companies that rely on software to facilitate their business, but do not consider software to be their business. These managers knew little about software and our teams were usually bloated by non-technical roles and often unproductive. Every idea ultimately had to be passed through engineers for validation / refinement and engineering became a very constrained resource.
Neutral management is where I would place most of my managers. They don't really aid in or detract from my productivity. They're there and doing things (even if those things are not always visible to me). They demonstrate enough value to dispell the feelings of: "If you weren't here then we could hire another engineer to actually work on this problem".
That said, you are 100% correct that if I didn't think about these things at all then I'd be much happier. After all, happiness is reality minus expectation.
This is most accurate to my experience as well. While I don't think it's helpful to disparage management as a whole, I do think it's beneficial to talk about where bad management exists, why, and how frequently. On the flip side, people talking as if bad management doesn't exist or is some minority I think are forgetting not every SWE works in the valley at a FAANG or bootstrapped to-be-unicorn company.
I believe the take you see is mostly coming from enterprise developers that have witnessed the immense inefficiency and waste of larger organisations. The solution to a non-engineering savvy manager in such organization is to add more people and more frameworks.
Mind you - to "them", these "dreaded MBAs", the development organization is a problem, often regarded as cost, and development is done by... developers. Sometimes the developers is the actual problem and they have gradually sunk the software in to a unmaintainable swamp of crappy code and debt - but this is a competency and hiring problem. It will not be solved by any framework or project manager. But you need the competency in your leadership to understand what's what and this is missing from pretty much any large org I've set foot in. The high functioning teams is these settings are more a stoke of luck, and they often have to utilize guerrilla tactics to keep delivering value.
I've seen my fair share of global CIO's talking us through cloud and blockchain, never have to actually deliver and move on to the next company or fancy role.
I've seen CIO/CTO not trusting developers and believing no-code and citizen development to be the end all. Guess what - more unmaintainable crazy stuff
I've seen large organizations falling in to the "one system" trap on all levels, even trickling down to the software teams - a dedicated 8 person jira team for the whole org! What could possibly go wrong.
I've also witnessed amazing autonomous development teams that move at amazing speed with quality. In these settings you have management that understands the process of supporting a business with valuable code.
Most of the time IMO it's the business themselves that cause a lot of the problems facing developers by not understanding that it's they who own the processes getting digitized.
They buy software from vendors, staff up a project team to integrate, fire and forget. This "fire and forget" project mentality is what accumulates in a shitty org, and shitty orgs start from the top.
If you haven't read "Turn the ship around" it embodies all of this. This condensed video is really worth a look:
https://www.youtube.com/watch?v=psAXMqxwol8
Mind you - to "them", these "dreaded MBAs", the development organization is a problem, often regarded as cost, and development is done by... developers. Sometimes the developers is the actual problem and they have gradually sunk the software in to a unmaintainable swamp of crappy code and debt - but this is a competency and hiring problem. It will not be solved by any framework or project manager. But you need the competency in your leadership to understand what's what and this is missing from pretty much any large org I've set foot in. The high functioning teams is these settings are more a stoke of luck, and they often have to utilize guerrilla tactics to keep delivering value.
I've seen my fair share of global CIO's talking us through cloud and blockchain, never have to actually deliver and move on to the next company or fancy role.
I've seen CIO/CTO not trusting developers and believing no-code and citizen development to be the end all. Guess what - more unmaintainable crazy stuff
I've seen large organizations falling in to the "one system" trap on all levels, even trickling down to the software teams - a dedicated 8 person jira team for the whole org! What could possibly go wrong.
I've also witnessed amazing autonomous development teams that move at amazing speed with quality. In these settings you have management that understands the process of supporting a business with valuable code.
Most of the time IMO it's the business themselves that cause a lot of the problems facing developers by not understanding that it's they who own the processes getting digitized.
They buy software from vendors, staff up a project team to integrate, fire and forget. This "fire and forget" project mentality is what accumulates in a shitty org, and shitty orgs start from the top.
If you haven't read "Turn the ship around" it embodies all of this. This condensed video is really worth a look:
https://www.youtube.com/watch?v=psAXMqxwol8
The complaint about OKRs - using only specific meazurements to destroy the ability to decide/agency to land actual outcomes/results - seemed pretty spot on. It's not even engineering managers necessarily; knowledge working orgs in general, and, in my view, it's not immature to grumble about, it's immature orgs that ruin their best potential, that dont get knowledge work & actively obstruct it.
Having these ideas in mind, particularly backed up by some good background as is present here - some discussion on knowledge work, Peter Drucker quotes - is context orgs ought to try to be aware of, prevent from happening.
Sad to see such a well written well explained article reduced to "grow out of their mindset" antagonism. There's not any argumentation in this rebuttal, just personal badmouthing & berating. The conflict described is real, but apparently people who feel tensions & dissonance of it all are all just "immature".
Having these ideas in mind, particularly backed up by some good background as is present here - some discussion on knowledge work, Peter Drucker quotes - is context orgs ought to try to be aware of, prevent from happening.
Sad to see such a well written well explained article reduced to "grow out of their mindset" antagonism. There's not any argumentation in this rebuttal, just personal badmouthing & berating. The conflict described is real, but apparently people who feel tensions & dissonance of it all are all just "immature".
I think it's part of the common "I'm surrounded by idiots" attitude of the many jerks in our industry.
I agree. It feels like half of programming posts are just the same 10 topics discussed over and over
Yes we know management metrics can't predict every end date, we know agile doesn't solve every problem, we know blockchain is a solution without a problem, we know code complete and the mythical man month are some of the best programming books.
Yes we know management metrics can't predict every end date, we know agile doesn't solve every problem, we know blockchain is a solution without a problem, we know code complete and the mythical man month are some of the best programming books.
It looks like you've read the headline and decided to get angry.
My pet problem is not with those roles, they are needed, it is with the overpaying of those roles and downplaying of the requirement of actual engineers and thus lowering their standing an payment. An engineering manager should in my view never earn more than the rest of the team and where I live they do earn more by default.
What is your take then? You seem to have been offended but don't provide any counterpoints
The real issue is that in most software engineering teams, these roles are better done by a SWE who is good at X than somebody who exclusively does X, but especially at big companies the person doing X doesn't really understand software engineering.
Nope. They most typically result from the fact that "you mostly can't learn business or management in school," period.
There is no meaningful correlation between title, schooling, and/or effectiveness in management.
There is no meaningful correlation between title, schooling, and/or effectiveness in management.
This mindset exists in every occupation. And it's always superficially true.
Everything would grind to a halt if it weren't for people who do X. Everybody else exists because X people are doing X.
Everything would grind to a halt if it weren't for people who do X. Everybody else exists because X people are doing X.
In fairness, the Agile Manifesto is about pushing developers to work directly with the business people and each other in order to cut out the 'middlemen' you speak of. Each of the twelve principles highlight areas where developers need to pick up the slack when product/program/project management is cut out of the picture.
For better or worse, this is what we, as an industry, have adopted and a generation has grown up not knowing any better.
For better or worse, this is what we, as an industry, have adopted and a generation has grown up not knowing any better.
Here's the thing. At the end of the day all of the "complexity and nuance" of running a business doesn't matter. The only way you even get to execute on that is if you're flanked by good engineers.
All roads lead to the engineer. Bad managers can be worked around. Mindless PMs can be worked around. But if every engineer at apple suddenly stopped working there would be real economic consequences. If managers and PMs stopped working they'd be replaced by engineers who are by and large more capable at adaptation anyway. Engineers should hold all the power. In most orgs management exists to prevent what is effectively an artificial union forming among engineers. Most, I'd argue even 99%, of engineers do not want to be sitting in meetings and spending 9 hours a day building CRUD. Without the guy cracking the whip over your head you wouldn't. I wouldn't. Anyone wouldn't. The power dynamic favors managers - hence all the hate.
MBAs take a lot of flak because much like the kid engineer coming out of school who believes he's legitimately God's gift to man the MBA does the same. The difference? The MBA controls your salary, whether you keep your job, whether you get your job, the direction of the company, the marketing of the product, the features that will be worked on, the finances of the company, etc. The MBA holds legitimately all power that is not engineering. As such, by generalizing and blaming "the MBA" you are more right than wrong on who is the real problem. I believe most engineers should go back for their MBA. Not to get better at business but to understand their enemy. An entire career is boiled down to a few excel formulas.
Do you know what makes me happy? Not even knowing my manager exists. Not even knowing my PM exists. In my a little over 10 year career I can name two managers and one PM that actually made a fundamental difference to me. I'd be infinitely happier if PMs and managers were replaced by robots that let me do my job and enjoy what I do. Instead, even something as trivial as "I'd like an extra day to optimize this because I can see it having problems under load" needs to be "scoped" and "talked about", then it needs to be "put into a future sprint", then it needs to be "pointed", "tagged", "etc". This is borderline tyranny to someone who is creative. Only a spreadsheet monkey sees value in this nonsense because at the end of the day I'm right (because I built it) but I won't be given time to do it until it breaks (because the MBA), when it does I will be on pagerduty and probably hearing about it (from my manager), and then I will need to ask for time and a meeting will be called to discuss and do JIRA nonsense (by the PM). You see? As an engineer it's always my fault. Even when I'm right. Who are the people who will arrive at my desk to blame me? Them.
All roads lead to the engineer. Bad managers can be worked around. Mindless PMs can be worked around. But if every engineer at apple suddenly stopped working there would be real economic consequences. If managers and PMs stopped working they'd be replaced by engineers who are by and large more capable at adaptation anyway. Engineers should hold all the power. In most orgs management exists to prevent what is effectively an artificial union forming among engineers. Most, I'd argue even 99%, of engineers do not want to be sitting in meetings and spending 9 hours a day building CRUD. Without the guy cracking the whip over your head you wouldn't. I wouldn't. Anyone wouldn't. The power dynamic favors managers - hence all the hate.
MBAs take a lot of flak because much like the kid engineer coming out of school who believes he's legitimately God's gift to man the MBA does the same. The difference? The MBA controls your salary, whether you keep your job, whether you get your job, the direction of the company, the marketing of the product, the features that will be worked on, the finances of the company, etc. The MBA holds legitimately all power that is not engineering. As such, by generalizing and blaming "the MBA" you are more right than wrong on who is the real problem. I believe most engineers should go back for their MBA. Not to get better at business but to understand their enemy. An entire career is boiled down to a few excel formulas.
Do you know what makes me happy? Not even knowing my manager exists. Not even knowing my PM exists. In my a little over 10 year career I can name two managers and one PM that actually made a fundamental difference to me. I'd be infinitely happier if PMs and managers were replaced by robots that let me do my job and enjoy what I do. Instead, even something as trivial as "I'd like an extra day to optimize this because I can see it having problems under load" needs to be "scoped" and "talked about", then it needs to be "put into a future sprint", then it needs to be "pointed", "tagged", "etc". This is borderline tyranny to someone who is creative. Only a spreadsheet monkey sees value in this nonsense because at the end of the day I'm right (because I built it) but I won't be given time to do it until it breaks (because the MBA), when it does I will be on pagerduty and probably hearing about it (from my manager), and then I will need to ask for time and a meeting will be called to discuss and do JIRA nonsense (by the PM). You see? As an engineer it's always my fault. Even when I'm right. Who are the people who will arrive at my desk to blame me? Them.
> If managers and PMs stopped working they'd be replaced by engineers who are by and large more capable at adaptation anyway.
It's funny how these ultracapable genius engineers don't just start their own company free of these bullshit manager and PM roles and just steamroll the competition, isn't it?
It's funny how these ultracapable genius engineers don't just start their own company free of these bullshit manager and PM roles and just steamroll the competition, isn't it?
A few reasons:
1. They would rather be building cool things than doing all the other things involved in running a company. Nobody said managers are doing literally nothing, just that they're generally not very good and they really don't deserve or earn the authority they have. Their role is a support role, like a typist or a document manager or something. They should be considered basically secretaries to the engineers, so your question is "why don't the engineers all go become secretaries then?". Not to bash secretaries, but rather to give you the point that their authority comes not from what they do, but rather from the caste they were born into and/or the college they graduated from.
2. Many of them would go and start their own (likely very successful) companies, if doing so weren't a gated community open only to either (A) those who already have lots of connections and lots of family money to fall back on as a safety net if they fail, and (B) those who are willing to subsist on dry Top Ramen and live out of their car for years while they devote 100% of their time to their startup. Most of the good engineers out there have responsibilities like kids and/or mortgages, because it takes a long time to become a good engineer. And most people aren't born into the "business caste" that starts companies and becomes high-level managers at companies in the US.
3. They do. When it does happen, they become wildly successful and do completely fucking steamroll the competition, because the competition actually truly veritably is garbage run by chucklefucks who are only there because they were born into the Business Caste.
1. They would rather be building cool things than doing all the other things involved in running a company. Nobody said managers are doing literally nothing, just that they're generally not very good and they really don't deserve or earn the authority they have. Their role is a support role, like a typist or a document manager or something. They should be considered basically secretaries to the engineers, so your question is "why don't the engineers all go become secretaries then?". Not to bash secretaries, but rather to give you the point that their authority comes not from what they do, but rather from the caste they were born into and/or the college they graduated from.
2. Many of them would go and start their own (likely very successful) companies, if doing so weren't a gated community open only to either (A) those who already have lots of connections and lots of family money to fall back on as a safety net if they fail, and (B) those who are willing to subsist on dry Top Ramen and live out of their car for years while they devote 100% of their time to their startup. Most of the good engineers out there have responsibilities like kids and/or mortgages, because it takes a long time to become a good engineer. And most people aren't born into the "business caste" that starts companies and becomes high-level managers at companies in the US.
3. They do. When it does happen, they become wildly successful and do completely fucking steamroll the competition, because the competition actually truly veritably is garbage run by chucklefucks who are only there because they were born into the Business Caste.
The real reason is a lot of us are risk adverse. We’ve seen startups go bad many times. It seems easier to work a mediocre but relatively high paying job, save, and invest.
They do. In fact, the top 3 tech companies started this way. So I guess you're right!
Avoid confusing sales with managers. Most "genius engineers" still need
money, and they still need that fabled creature known as the salesman
who can convince someone to pay for a software system he doesn't need.
They don't want engineers to unionize because the first thing they'd do is pause feature work and fix all the tech debt.
> fix all the tech debt.
lol, okay, maybe before you have a couple $50k/yr revenue customers that rely on that legacy/tech-debt to run their business.
ask windows/office devs or linux kernel devs how often they get to fix all that tech debt.
lol, okay, maybe before you have a couple $50k/yr revenue customers that rely on that legacy/tech-debt to run their business.
ask windows/office devs or linux kernel devs how often they get to fix all that tech debt.
> much like the kid engineer coming out of school who believes he's legitimately God's gift to man
(other people doing stuff, inducing mild amounts of accountability)
> This is borderline tyranny to someone who is creative.
> most engineers should go back for their MBA. Not to get better at business but to understand their enemy.
That's an incredibly adversarial attitude severely lacking in self-reflection and empathy. It's really tough to work with people wound so tight. Having been a manager, if I were yours, I'd be working on helping you grow up a bit, and if that didn't work, I'd be helping you find a different role that was more suited to your...ahem...creativity. A role far away.
(other people doing stuff, inducing mild amounts of accountability)
> This is borderline tyranny to someone who is creative.
> most engineers should go back for their MBA. Not to get better at business but to understand their enemy.
That's an incredibly adversarial attitude severely lacking in self-reflection and empathy. It's really tough to work with people wound so tight. Having been a manager, if I were yours, I'd be working on helping you grow up a bit, and if that didn't work, I'd be helping you find a different role that was more suited to your...ahem...creativity. A role far away.
It's weird you assume I openly post this where people know my face.
I play ball at work because if I play ball I continue to make enough money where at the end of the day I don't care. I'm fully capable of reading a room and know full well the consequences of stepping out of line. Frankly a manager "helping you find empathy" strikes me as a form of indoctrination.
But thank you for the deep psychological analysis. Frankly I'm glad you're not my manager because the saccharin nature of your psuedo intellectual post would probably have me quitting anyway. It's always the "empaths" who are the first to fire the shots across the bow in the face of valid (albeit direct) criticism.
I play ball at work because if I play ball I continue to make enough money where at the end of the day I don't care. I'm fully capable of reading a room and know full well the consequences of stepping out of line. Frankly a manager "helping you find empathy" strikes me as a form of indoctrination.
But thank you for the deep psychological analysis. Frankly I'm glad you're not my manager because the saccharin nature of your psuedo intellectual post would probably have me quitting anyway. It's always the "empaths" who are the first to fire the shots across the bow in the face of valid (albeit direct) criticism.
I'm only going by the words that you wrote. You come hot out of the gate and people's reaction to that validates your internal drama where everyone's an enemy. But all we're talking about is your feelings at this point, so I'll just stop because that tangle really does escape me.
If you click the link, you'll find that the article features text below the headline that deals with literally none of those things.
The MBA is for people who want to skip right to "being in charge" without having to learn how to actually do anything first.
The scary part is, if you went to a selective enough school, it kinda works.
The Ivy League undergrad -> elite MBA -> management consulting -> C-suite pipeline is especially frightening.
The scary part is, if you went to a selective enough school, it kinda works.
The Ivy League undergrad -> elite MBA -> management consulting -> C-suite pipeline is especially frightening.
My issue with the converse is that being a good engineer and understanding how to do things doesn't necessarily make you a good manager. I've worked in plenty of orgs where they don't treat leadership as a skill unto itself and assume just because you're a good engineer, you'll be good at managing an engineering team.
I think if you have to pick a base for leadership, doing the thing you're managing other people in is probably the best.
The worst in my opinion is finance-- it's like driving using the rear view mirror. No business has ever succeeded or failed because their accounting was really tip top.
The worst in my opinion is finance-- it's like driving using the rear view mirror. No business has ever succeeded or failed because their accounting was really tip top.
No doubt, I just think too often leadership is looked at as an afterthought to the skill they are managing? It's akin to the Peter Principle. Just because you are a good developer does not mean your skills translate to great leadership.
People would laugh at the idea of a good leader being thrust into a SWE role based solely on their leadership skills. Yet we often think transitioning from a SWE to a leader is just picked up. I'm asserting that they are different skillsets. Will being a good developer help lead a team of SWE? Absolutely, but that alone doesn't provide the requisite knowledge and skills to perform a manager role, but we often think that's the bulk of what's necessary.
People would laugh at the idea of a good leader being thrust into a SWE role based solely on their leadership skills. Yet we often think transitioning from a SWE to a leader is just picked up. I'm asserting that they are different skillsets. Will being a good developer help lead a team of SWE? Absolutely, but that alone doesn't provide the requisite knowledge and skills to perform a manager role, but we often think that's the bulk of what's necessary.
Heh, a bit harsher than I would have stated it but I can't help but agree. Of course, 30 years ago, I would have disagreed with you. Probably in a few decades the author of the article will agree with you too! So there's that.
Managment offers an escape route to people who struggle with tech competency. Just grind it out for a few years a dev, then transition into management.
This is a standard formula for years and i've seen many many people follow this.
[deleted]
[deleted]
How are you reconciling your take against the actual content of the article?
> It's just personal and professional immaturity.
Not so sure about that. In the beginning of my career I looked up greatly to a lot of people in these roles. The older I get the more that has faded. Truth is I can do their jobs fine, but they can’t do mine; yet they have a tendency to look down on me.
(I’m in Sweden though, and the MBAs still have a very strong grip on the Nordics. Might be a different social dynamic in the US.)
Not so sure about that. In the beginning of my career I looked up greatly to a lot of people in these roles. The older I get the more that has faded. Truth is I can do their jobs fine, but they can’t do mine; yet they have a tendency to look down on me.
(I’m in Sweden though, and the MBAs still have a very strong grip on the Nordics. Might be a different social dynamic in the US.)
That was very well said, but with a few word changes could be used to support anything.
[deleted]
Some of you people strawman like a murder of crows is attacking your field.
Coordination is necessary. Communication is valuable. Running a business is complex. Product managers do valuable work. Designers do valuable work. QA does valuable work. Leadership does valuable work. Engineers do valuable work.
The core of an EXTREME number of complaints about modern professional software development lies in the pervasiveness of Career Management; and EMs are an extremely attractive entrypoint for people into this kind of track, who have no experience in any of the IC-facing roles, yet now they're managing ICs.
Just go look at the vast majority of job postings for EMs. The requirements are extremely bare on actual, hard engineering experience; maybe you see the last requirement read something like "built an app in java or c++", and it never gets covered in the interviews.
You can't manage a role you haven't held, I will die on this hill. Senior leadership is fucking hard; that takes specialized skills, MBAs maybe, a little bit of crazy as well. EMs are not that, and anyone who tells you what EMs do is remotely as specialized as what the people higher up do is probably an EM. At their best, EMs should have an engineering background (or at least PM/PO; having worked with engineers as peers); they should know what it takes to build modern software systems from the inside; they should know how to mentor. At their worst, EMs who don't know any of this, but know management, spend their days as a Jira parrot and can make the lives of the people they manage miserable.
Its actually astounding to me that this is controversial, and that people don't recognize that the only reason companies change the requirements bar for EM positions is because, if they made the bar what I describe, that candidate would also make a great engineer; and companies are short engineers, not short "people who manage people". Its not out of some grand design that the best managers live on the management track. Many, many other specialized disciplines don't do what Big Tech does. The tracks for Engineers and Engineering Managers shouldn't be separate; they should be one track. But Big Tech companies don't want their engineers leaving the IC role, so they make do; and the irony of it all is all this does is lower the average quality of EMs in the org, which causes engineers to leave anyway; just to competitors.
That's why Engineering Management is bullshit. It doesn't have to be. Much of what that role does is necessary; its just overwhelmingly filled by the wrong people, who then morph the role into some bastardization of what it should be, get promoted, then write the job spec for their replacement.
[1] https://stripe.com/jobs/listing/engineering-manager-payment-...
[2] https://careers.google.com/jobs/results/77396557743170246-en...
[3] https://boards.greenhouse.io/cloudflare/jobs/3135805?gh_jid=...
Coordination is necessary. Communication is valuable. Running a business is complex. Product managers do valuable work. Designers do valuable work. QA does valuable work. Leadership does valuable work. Engineers do valuable work.
The core of an EXTREME number of complaints about modern professional software development lies in the pervasiveness of Career Management; and EMs are an extremely attractive entrypoint for people into this kind of track, who have no experience in any of the IC-facing roles, yet now they're managing ICs.
Just go look at the vast majority of job postings for EMs. The requirements are extremely bare on actual, hard engineering experience; maybe you see the last requirement read something like "built an app in java or c++", and it never gets covered in the interviews.
You can't manage a role you haven't held, I will die on this hill. Senior leadership is fucking hard; that takes specialized skills, MBAs maybe, a little bit of crazy as well. EMs are not that, and anyone who tells you what EMs do is remotely as specialized as what the people higher up do is probably an EM. At their best, EMs should have an engineering background (or at least PM/PO; having worked with engineers as peers); they should know what it takes to build modern software systems from the inside; they should know how to mentor. At their worst, EMs who don't know any of this, but know management, spend their days as a Jira parrot and can make the lives of the people they manage miserable.
Its actually astounding to me that this is controversial, and that people don't recognize that the only reason companies change the requirements bar for EM positions is because, if they made the bar what I describe, that candidate would also make a great engineer; and companies are short engineers, not short "people who manage people". Its not out of some grand design that the best managers live on the management track. Many, many other specialized disciplines don't do what Big Tech does. The tracks for Engineers and Engineering Managers shouldn't be separate; they should be one track. But Big Tech companies don't want their engineers leaving the IC role, so they make do; and the irony of it all is all this does is lower the average quality of EMs in the org, which causes engineers to leave anyway; just to competitors.
That's why Engineering Management is bullshit. It doesn't have to be. Much of what that role does is necessary; its just overwhelmingly filled by the wrong people, who then morph the role into some bastardization of what it should be, get promoted, then write the job spec for their replacement.
[1] https://stripe.com/jobs/listing/engineering-manager-payment-...
[2] https://careers.google.com/jobs/results/77396557743170246-en...
[3] https://boards.greenhouse.io/cloudflare/jobs/3135805?gh_jid=...
0xedd(3)
> the complexity and nuance that goes into running a business
Unfortunately one of the side effects of having something so important also be so complex, hard to reason about, and hard to prove causation for, is that there are a lot of empty suits attracted to an area where it's hard to disprove that they contributed, but a lot of money to be made if they can convince the right people that they did.
By definition we can't know how many are genuinely hardworking contributors, how many are parasites, and how many are somewhere in the middle (e.g. did some good work but is phoning it home these days, got lucky but misattributed their own success so now just doles out bad advice). Claiming that only one of these three groups exists is of course naive - but when running into people who have a different perspective or make different claims, it's worth keeping in mind that the subset of these groups they've run into might differ from your own.
Unfortunately one of the side effects of having something so important also be so complex, hard to reason about, and hard to prove causation for, is that there are a lot of empty suits attracted to an area where it's hard to disprove that they contributed, but a lot of money to be made if they can convince the right people that they did.
By definition we can't know how many are genuinely hardworking contributors, how many are parasites, and how many are somewhere in the middle (e.g. did some good work but is phoning it home these days, got lucky but misattributed their own success so now just doles out bad advice). Claiming that only one of these three groups exists is of course naive - but when running into people who have a different perspective or make different claims, it's worth keeping in mind that the subset of these groups they've run into might differ from your own.
>Here, we see engineers reduce the contributions of such common roles as: Product Manger, Program/Project Manager, Scrum Master, Marketer
Cow dung is common too, but not necessarily useful. Maybe for manure...
Most actual work happens despite those roles, not because of them... Or even against them - and is dilluted, sabotaged, rushed, and crapped upon all the time by the decisions of the roles above.
If you meant "software production needs this role", then no. Software production (from Xerox Parc to the Linux kernel) can be just fine without them.
If you meant "a modern corporate bureucracy needs those roles to make a product", then maybe, but that's part of the reason those enterprise products are shitty.
Cow dung is common too, but not necessarily useful. Maybe for manure...
Most actual work happens despite those roles, not because of them... Or even against them - and is dilluted, sabotaged, rushed, and crapped upon all the time by the decisions of the roles above.
If you meant "software production needs this role", then no. Software production (from Xerox Parc to the Linux kernel) can be just fine without them.
If you meant "a modern corporate bureucracy needs those roles to make a product", then maybe, but that's part of the reason those enterprise products are shitty.
I think you're being as disingenuous as TFA.
There are just as many useless managers as there are useless reports. The reason you see so many 'managers suck' posts is because they're in a position of authority over the talent they manage. That's all.
Management shouldn't mean authority, it should be like HR or IT, a support role.
There are just as many useless managers as there are useless reports. The reason you see so many 'managers suck' posts is because they're in a position of authority over the talent they manage. That's all.
Management shouldn't mean authority, it should be like HR or IT, a support role.
Who should be held responsible for engineering projects or initiatives that require more than one engineer? Who should be tasked with originating and prioritizing and staffing such projects?
The technical team leader. Staffing is management/HR at the behest of and under the direction of the team lead.
Most of the "engineering managers" I've had to work under have been utter bullshit. Didn't learn anything from them (technically or in regards to leadership) and were there merely to check a box, play babysitter and/or sit in meetings all day that had zero impact on our work streams.
The few who did have impact (1) were skilled engineers in their own right and were able to translate that into more management, (2) understood that managing down is much more important than managing up and (3) knew how to say "no" to upper management effectively. Those are very few and far in-between imo.
The few who did have impact (1) were skilled engineers in their own right and were able to translate that into more management, (2) understood that managing down is much more important than managing up and (3) knew how to say "no" to upper management effectively. Those are very few and far in-between imo.
> sit in meetings all day that had zero impact on our work streams
maybe the manager was busy in meetings all day in order to ensure you had zero impact on your work streams :)
the role of an EM in a large organisation is in large part to be an "enterprise abstraction layer", ensuring the people in the team(s) can work in a way that is as close as possible to what they could do in a startup/solo project
maybe the manager was busy in meetings all day in order to ensure you had zero impact on your work streams :)
the role of an EM in a large organisation is in large part to be an "enterprise abstraction layer", ensuring the people in the team(s) can work in a way that is as close as possible to what they could do in a startup/solo project
>> the role of an EM in a large organisation is in large part to be an "enterprise abstraction layer", ensuring the people in the team(s) can work in a way that is as close as possible to what they could do in a startup/solo project
I worked for a guy like that. Sometimes technical decisions would bubble up and I'd get mad that he wouldn't resolve them but push them back down. I started to think he didn't do much of anything. Turns out he spent most of his time in higher level meetings finding out what projects were coming and ensuring we were properly staffed and projects got scheduled reasonably. He'd go into a meeting uninvited because "this project doesn't involve software" only to discover that there would be a software component to the project and make sure that was covered. Turns out once I knew what he was actually doing I'd say he was one of the more effective managers I've worked for. Things usually ran smoothly and random shit never dropped from other parts of the company unexpectedly. He did zero engineering (but he had previously), and most of what he did was unseen to us. Life was good because we lived behind an invisible shield.
I worked for a guy like that. Sometimes technical decisions would bubble up and I'd get mad that he wouldn't resolve them but push them back down. I started to think he didn't do much of anything. Turns out he spent most of his time in higher level meetings finding out what projects were coming and ensuring we were properly staffed and projects got scheduled reasonably. He'd go into a meeting uninvited because "this project doesn't involve software" only to discover that there would be a software component to the project and make sure that was covered. Turns out once I knew what he was actually doing I'd say he was one of the more effective managers I've worked for. Things usually ran smoothly and random shit never dropped from other parts of the company unexpectedly. He did zero engineering (but he had previously), and most of what he did was unseen to us. Life was good because we lived behind an invisible shield.
Appreciate you sharing this anecdote. There's multiple archetypes of "successful" managers (i.e. meaning different ways of being useful, not success in terms of kudos or promotions or whatever), and the one you highlight is what I think of as the base/foundational value that a manager should provide (i.e. that one is able to create the quality of "smoothness"). Then, a truly exceptional manager, may also be a technical leader, may also contribute architecture or code, may also be a star recruiter/attractor/retainer of talent, etc. But IMO those are add-on's, and a base manager should first keep the ship on course first.
The quiet enterprise professional, preventing fires and course-correcting to avoid "random shit" or missed requirements, just very non-sexy/non-glorious work, and a pretty literal example of, "if you do your job right, then no one will notice you did anything at all."
The quiet enterprise professional, preventing fires and course-correcting to avoid "random shit" or missed requirements, just very non-sexy/non-glorious work, and a pretty literal example of, "if you do your job right, then no one will notice you did anything at all."
You did a great job describing quality management
It's like good infrastructure, if you don't notice it and you can proceed through your life with minimum distractions, that means it's working as intended.
It's like good infrastructure, if you don't notice it and you can proceed through your life with minimum distractions, that means it's working as intended.
This is an excellent comment that really does distill down what an EM is supposed to be.
As someone who's been on all sides of this (currently an EM, been a tech lead and an individual contributor in the past), I really think there is a lack of understanding among large parts of the tech community about what engineering managers do. A good manager's first and primary responsibility is to reduce chaos for their team. In an ideal world you won't even know I'm here, because I am shielding you from all the stuff that is going on further up in the company and clearing out obstacles so that you can work without interference.
Good managers reduce chaos, bad managers create chaos. In my experience, engineering managers are a lot like all other employees: you have a few outstanding performers, a significant number of average/acceptable/mediocre managers, and some number of pretty bad ones. The difficulty comes in knowing which type you have, and often that only becomes clear when a manager leaves. Either a new EM makes things better, or things get dramatically worse because a good EM is no longer helping the team.
It's like that Futurama episode where Bender meets God: "When you do things right, people won't be sure you've done anything at all."
As someone who's been on all sides of this (currently an EM, been a tech lead and an individual contributor in the past), I really think there is a lack of understanding among large parts of the tech community about what engineering managers do. A good manager's first and primary responsibility is to reduce chaos for their team. In an ideal world you won't even know I'm here, because I am shielding you from all the stuff that is going on further up in the company and clearing out obstacles so that you can work without interference.
Good managers reduce chaos, bad managers create chaos. In my experience, engineering managers are a lot like all other employees: you have a few outstanding performers, a significant number of average/acceptable/mediocre managers, and some number of pretty bad ones. The difficulty comes in knowing which type you have, and often that only becomes clear when a manager leaves. Either a new EM makes things better, or things get dramatically worse because a good EM is no longer helping the team.
It's like that Futurama episode where Bender meets God: "When you do things right, people won't be sure you've done anything at all."
Playing gatekeeper is an extremely common symptom of someone with imposter syndrome on a power trip.
I think you're right, but I think you're stopping short of recognizing that maybe this is a reason why so many ICs have issues with the EM role. If the role of an EM is to be a Shield Against Complexity for the team, then two things are induced to happen more frequently:
1) The EM looks up far more often than down.
2) The ICs miss out on collaboration which could be critically valuable to their projects, careers, and broader understanding of the business.
But that's the average! Some EMs pat themselves on the back and say "look at all these meetings y'all didn't have to attend, so you could focus and get the good work done all day" when in reality they didn't do anything remotely near the title of their role: Engineering Management. Managing the Engineers; not managing project dependencies, not managing leadership, not managing politics, but leading the people who report to them.
Great engineers swim in that complexity; and great EMs expose their team to (the relevant parts of) it.
1) The EM looks up far more often than down.
2) The ICs miss out on collaboration which could be critically valuable to their projects, careers, and broader understanding of the business.
But that's the average! Some EMs pat themselves on the back and say "look at all these meetings y'all didn't have to attend, so you could focus and get the good work done all day" when in reality they didn't do anything remotely near the title of their role: Engineering Management. Managing the Engineers; not managing project dependencies, not managing leadership, not managing politics, but leading the people who report to them.
Great engineers swim in that complexity; and great EMs expose their team to (the relevant parts of) it.
That abstraction layer doesn't add value IMO, it modifies the message like a game of telephone.
Buffering, filtering, and mapping information has value. If that consumes a full day, every day, it can no longer be broadcast to every engineer.
It’s a nuanced thing. An EM should share accurate context, filter distractions, and deliver it in the most effective way for that team.
There’s also the shielding aspects in dysfunctional organizations which is a whole other thing.
It’s a nuanced thing. An EM should share accurate context, filter distractions, and deliver it in the most effective way for that team.
There’s also the shielding aspects in dysfunctional organizations which is a whole other thing.
it's more like protecting the team from being shut because some asshole somewhere managed to convince an exec that there was overlap with their team, or raising warnings when some product idiot has a new idea that's obviously going to end up having a last-minute dependency on the team, hustling to get licences to use Circle instead of Jenkins or whatever, etc
So middle managers are important because upper managers are fucking awful? That's the idea? We need the middle-management tier because of the upper-management tier? And why is the upper-management tier there? To protect middle-management from the C-tier? I think you're kinda making our point here.
100%. And all of the above are necessary because customers and investors are the fucking worst.
Ok, that’s how the world works, do we stick our fingers in our ears and pretend we can ignore it? Or do we embrace it and accept the rules of the game?
Ok, that’s how the world works, do we stick our fingers in our ears and pretend we can ignore it? Or do we embrace it and accept the rules of the game?
I have a kind of motto/heuristic: if everyone is wrong, you're the problem
> Ok, that’s how the world works, do we stick our fingers in our ears and pretend we can ignore it? Or do we embrace it and accept the rules of the game?
Imagine having this attitude about literally any other widespread problem.
"Ok, everyone is spewing methane and carbon dioxide into the atmosphere. Do we close our eyes and ignore it, or do we join them and roll coal? LET'S BURN SOME FUEL BOYS"
"Ok, everyone is dumping toxic waste into the river. Do we just ignore it and keep drinking, or do we embrace it and just chuck our own toxic waste in there?"
"Ok, everyone is eating each other in Satanic canniablistic rituals. Do we just pretend it's not happening and go about our day, waiting to be eaten? Or do we fire up the grill and go on a hunt!?"
Um, how about a third option: we be vocal about how the problem is an actual problem and work together toward fixing it?
Imagine having this attitude about literally any other widespread problem.
"Ok, everyone is spewing methane and carbon dioxide into the atmosphere. Do we close our eyes and ignore it, or do we join them and roll coal? LET'S BURN SOME FUEL BOYS"
"Ok, everyone is dumping toxic waste into the river. Do we just ignore it and keep drinking, or do we embrace it and just chuck our own toxic waste in there?"
"Ok, everyone is eating each other in Satanic canniablistic rituals. Do we just pretend it's not happening and go about our day, waiting to be eaten? Or do we fire up the grill and go on a hunt!?"
Um, how about a third option: we be vocal about how the problem is an actual problem and work together toward fixing it?
IME, The managers who believe this tend to hide too much information from their team. The team doesn't have enough context as a result, and is in the dark re. what's really expected of them by higher-ups.
If you have to have people sitting in meetings all day just to avoid corporate crap to clutter you devs' work than you have a bit problem in the upper layer of the organization. Best solution is to leave.
Your last paragraph is basically the gist of it. Managers who make an impact are recognized as such by their team. They manage the team to do their best work possible.
The model of manager as a babysitter is, I think, what happens when an organization gets to a certain size. Once the organization gets big enough, management becomes a vehicle for bureaucratic surveillance. At that size, an organization uses managers to give a human face to bureaucratic machinations.
The model of manager as a babysitter is, I think, what happens when an organization gets to a certain size. Once the organization gets big enough, management becomes a vehicle for bureaucratic surveillance. At that size, an organization uses managers to give a human face to bureaucratic machinations.
> understood that managing down is much more important than managing up and (3) knew how to say "no" to upper management effectively.
Wait, saying "no" to upper management _is_ managing upwards. If you have a high performing team you can damned near ignore them as long as you're paying attention to what matters to them so that you can manage up effectively and keep bullshit off their place. If you have a team that needs a lot of help then yes, you have to focus on managing "down" -- but that's the less common scenario in my experience.
I suspect you're defining "managing up" as "brown-nosing" -- which is just managing up ineffectively. Being good at managing up and out is honestly the bulk of the job at most organizations; engineers can usually just do their thing.
Wait, saying "no" to upper management _is_ managing upwards. If you have a high performing team you can damned near ignore them as long as you're paying attention to what matters to them so that you can manage up effectively and keep bullshit off their place. If you have a team that needs a lot of help then yes, you have to focus on managing "down" -- but that's the less common scenario in my experience.
I suspect you're defining "managing up" as "brown-nosing" -- which is just managing up ineffectively. Being good at managing up and out is honestly the bulk of the job at most organizations; engineers can usually just do their thing.
I didn't say that there is no managing up, only that managers should be focused on managing down while simultaneously pushing back against top-down bullshit. I've usually seen managers just focusing on the later (whether it's ass kissing, career gunning or from bullshit) while neglecting their team.
The big secret is most engineers would be better off moving into management ASAP. It pays better, less intellectually demanding, and is far easier than claimed. Management failures are often pinned to their direct reports.
If they needed to play the babysitter, then you know why they were there...
Same, I've had exactly one EM who wasn't bullshit and he matched your criteria perfectly.
I’ve been on both sides. I spent a few years as an engineering manager. The majority of my career as a software developer. It’s not a bullshit job.
It’s sometimes a bullshit management job. Like working for the benefit of engineers on your team who view your role as bullshit. And dealing with negotiating between marketing, sales, founders, and being the voice for engineering. There’s a lot of bullshit there some times.
I appreciate good managers. It’s a tough job. You don’t always know the right thing to say but when you get it wrong people really make you pay for it. It takes resolve and pragmatism to step in front and take the brunt of responsibility for the teams output and shining the light of success on your team and away from yourself.
It’s sometimes a bullshit management job. Like working for the benefit of engineers on your team who view your role as bullshit. And dealing with negotiating between marketing, sales, founders, and being the voice for engineering. There’s a lot of bullshit there some times.
I appreciate good managers. It’s a tough job. You don’t always know the right thing to say but when you get it wrong people really make you pay for it. It takes resolve and pragmatism to step in front and take the brunt of responsibility for the teams output and shining the light of success on your team and away from yourself.
I've also been on both sides, and I think that it is sometimes a bullshit job. I've spent a few years as a BS EM and a few years as a legit one. Your EM role might be bullshit if...
- You're managing fewer than four reports.
- You were previously a low-performing engineer & you find it easier to hide your lack of technical competency in the management track.
- You spend a lot of your time in broadly-attended meetings about topics on which you are not a direct decision-maker.
It's easier to coast as a bullshit EM than as a bullshit engineer because your impact is one step removed. When an engineer ships a bug-ridden mess, they get pinged by QA/product/whoever. When a manager hires an engineer who ships bug-ridden messes, the manager rarely faces consequences. When a manager lacks the backbone to put folks dragging down a team on a PIP, they're rarely called on it. When a manager lacks the backbone to advocate for their best engineers, those engineers leave and the EM gets to interpret for their boss "why" the engineer left. I doubt many say, "because I failed to advocate for their career" or "because they were sick of me misinterpreting the technical situation my team is in."
So engineering management is an attractive field for engineers who are technically incompetent, and by definition those folks are poorly equipped to manage technical teams.
- You're managing fewer than four reports.
- You were previously a low-performing engineer & you find it easier to hide your lack of technical competency in the management track.
- You spend a lot of your time in broadly-attended meetings about topics on which you are not a direct decision-maker.
It's easier to coast as a bullshit EM than as a bullshit engineer because your impact is one step removed. When an engineer ships a bug-ridden mess, they get pinged by QA/product/whoever. When a manager hires an engineer who ships bug-ridden messes, the manager rarely faces consequences. When a manager lacks the backbone to put folks dragging down a team on a PIP, they're rarely called on it. When a manager lacks the backbone to advocate for their best engineers, those engineers leave and the EM gets to interpret for their boss "why" the engineer left. I doubt many say, "because I failed to advocate for their career" or "because they were sick of me misinterpreting the technical situation my team is in."
So engineering management is an attractive field for engineers who are technically incompetent, and by definition those folks are poorly equipped to manage technical teams.
Engineers that have to do management and paperwork stuff cry that they're so busy with paperwork that they can't engineer. So management hires a guy for them and they cry about how that guy doesn't do anything.
The core problem sounds like the bullshit paperwork you allude to which is unnecessary and adds time to projects but provides leadership a fake status used to drive other decisions.
And yet it seems nearly every organization of meaningful scale has a large amount of this “cruft.”
Why don’t we see companies that “simply don’t” add this cruft, and accordingly sail off into orbit under propulsion of their own excellence?
Why don’t we see companies that “simply don’t” add this cruft, and accordingly sail off into orbit under propulsion of their own excellence?
Most importantly because most organizations just copy what everyone else does.
They're afraid of trying anything different than the status quo and don't want to risk it. "Nobody ever got fired for buying IBM", right? Same stuff, different context. Nobody ever got fired for copying Google, Spotify, Twitter, <insert hyped company name here>.
This is the unfortunate truth IMO. Organizations rather get the known "cruft" instead of taking a chance to innovate.
Companies, especially early on, can't afford to innovate on many areas and this is a bet they simply don't want to make.
Now, ask developers if they were less or more efficient when their managers left for a month or more. Every single one I've ever asked was way more productive, happy and surprisingly even upper management was happier because status updates had one less layer of telephone.
They're afraid of trying anything different than the status quo and don't want to risk it. "Nobody ever got fired for buying IBM", right? Same stuff, different context. Nobody ever got fired for copying Google, Spotify, Twitter, <insert hyped company name here>.
This is the unfortunate truth IMO. Organizations rather get the known "cruft" instead of taking a chance to innovate.
Companies, especially early on, can't afford to innovate on many areas and this is a bet they simply don't want to make.
Now, ask developers if they were less or more efficient when their managers left for a month or more. Every single one I've ever asked was way more productive, happy and surprisingly even upper management was happier because status updates had one less layer of telephone.
> Nobody ever got fired for copying Google, Spotify, Twitter
This. I see it over and over. People are thinking that copying management practices of successful companies is going to make them successful too. But it only works if those practices are what made the likes of Google successful. And it's not: Google is famous for it's search engine, not for it's managers. It's also famous for it's graveyard of failed projects. Somehow smartest people in the world created the most hated frontend framework.
Having infinite power doesn't typically create good leaders, it creates dictatorships.
Do you think having infinite money naturally leads to good management practices?
This. I see it over and over. People are thinking that copying management practices of successful companies is going to make them successful too. But it only works if those practices are what made the likes of Google successful. And it's not: Google is famous for it's search engine, not for it's managers. It's also famous for it's graveyard of failed projects. Somehow smartest people in the world created the most hated frontend framework.
Having infinite power doesn't typically create good leaders, it creates dictatorships.
Do you think having infinite money naturally leads to good management practices?
In my opinion this is because big companies do not want change. They are already big companies. They already won. They care more about understanding how they won / are winning so that they can perpetuate it and extract small percentage increases each quarter. Big things move slow. If you try and move part of them too fast they might break away and potentially endanger the remaining whole.
Because organizations of 'meaningful scale' should be separated down into organizations that do their piece well.
The reason we don't do that, is because we haven't gotten past being in a famine, zero sum mentality where hoarding power/resources is seen as obviously well and good.
The reason we don't do that, is because we haven't gotten past being in a famine, zero sum mentality where hoarding power/resources is seen as obviously well and good.
We do; you just aren't looking.
Its REALLY important to note the macroeconomics of our current climate. Tech is so, so, so rich right now. There's so much money flowing around that we just brute force our way through every problem. Cruft doesn't matter. Too crufty? Hire someone else to do that cruft. Split that cruft off into another team, that's growth and now my title is Director. Woah, don't touch that cruft, that's my cruft and I'm a Director, I'll die on my paycheck to defend that cruft.
Conway's Law: organizations design systems that mirror their own communication structure.
A Correlate to Conway's Law: in capitalist systems, an organization's communication structure is a mirror of its macroeconomic climate. Rich economic climates breed excess.
I'd posit that if you normalized the Y axis on the graphs "amount of time employees at tech companies spend on paperwork" and "the US M2 money supply", they'd correlate pretty well over the past thirty years. If you take the position that's a coincidence, or that the correlation doesn't imply causation in this case... just wait to see what happens to all that previously critical paperwork, pushed by previously critical people in indispensable roles, when the latter graph flatlines or inverts.
Its REALLY important to note the macroeconomics of our current climate. Tech is so, so, so rich right now. There's so much money flowing around that we just brute force our way through every problem. Cruft doesn't matter. Too crufty? Hire someone else to do that cruft. Split that cruft off into another team, that's growth and now my title is Director. Woah, don't touch that cruft, that's my cruft and I'm a Director, I'll die on my paycheck to defend that cruft.
Conway's Law: organizations design systems that mirror their own communication structure.
A Correlate to Conway's Law: in capitalist systems, an organization's communication structure is a mirror of its macroeconomic climate. Rich economic climates breed excess.
I'd posit that if you normalized the Y axis on the graphs "amount of time employees at tech companies spend on paperwork" and "the US M2 money supply", they'd correlate pretty well over the past thirty years. If you take the position that's a coincidence, or that the correlation doesn't imply causation in this case... just wait to see what happens to all that previously critical paperwork, pushed by previously critical people in indispensable roles, when the latter graph flatlines or inverts.
Because they employ humans and humans are flawed.
That bullshit paperwork was probably created by a manager in the first place. It's a self replicating problem.
I'm in a IDC role now where I do basically zero paperwork other than writing my own pull request notes. It's incredible. Can confirm that all paperwork I did in the past was nonsense and created by managers.
I do both and IMO it's pretty great. Having a good understanding of both business and software is a huge enabler for making excellent decisions.
Basically I've got skin in the game over the entire product, not just my silo.
Basically I've got skin in the game over the entire product, not just my silo.
Being in Engineering Management, I agree 1000%.
My advice to anyone feeling the pains of that article ... work for smaller companies. The 'operational overhead' of smaller companies is much much smaller.
Let me add, ive spent a lot of time thinking about what advice to give my children about their first job in real world. As someone in management, here is my advice to them:
Don't choose your first job based on salary, title, or company prestige. All of those can and will come with time. Choose your first job based on who you will be reporting to and what type of person they are. Will they understand you? Will you understand them? Will they support you? Can you trust them?
The spirit of this advice is that if you have a bad boss, most likely your day, each day, most likely will suck. Sure, twice a month your check will look nice, or maybe your business card will have impressive branding on it, but will you be happy? My wife gave me an article once, it was something like "you spend 1/3 of your waking life at work". Don't hate 1/3 of your waking life. Enjoy it. I believe the best way to enjoy each and every day of work is to have a boss that gets you, supports you, and empowers you.
My advice to anyone feeling the pains of that article ... work for smaller companies. The 'operational overhead' of smaller companies is much much smaller.
Let me add, ive spent a lot of time thinking about what advice to give my children about their first job in real world. As someone in management, here is my advice to them:
Don't choose your first job based on salary, title, or company prestige. All of those can and will come with time. Choose your first job based on who you will be reporting to and what type of person they are. Will they understand you? Will you understand them? Will they support you? Can you trust them?
The spirit of this advice is that if you have a bad boss, most likely your day, each day, most likely will suck. Sure, twice a month your check will look nice, or maybe your business card will have impressive branding on it, but will you be happy? My wife gave me an article once, it was something like "you spend 1/3 of your waking life at work". Don't hate 1/3 of your waking life. Enjoy it. I believe the best way to enjoy each and every day of work is to have a boss that gets you, supports you, and empowers you.
I'll just rewrite this paragraph and it will answer the question for the author:
An experienced engineering manager anticipates the secondary effects of every change, and weighs tradeoffs between a multitude of approaches in solving problems. By continuously modeling software systems, the organization they work for, and customer behavior, the most effective managers readjust their approach to problems daily.
This is a great example of what good engineering managers do because after a certain size of a project, one person can't build while also keeping all the downstream externalities in their head.
But wait! Microservices and self documenting APIs will fix all this right?
Nope - people and process management is as important here as it is on a car assembly line.
To adulterate a quote from James Madison:
If [programmers] were [perfect robots], no [management] would be necessary.
An experienced engineering manager anticipates the secondary effects of every change, and weighs tradeoffs between a multitude of approaches in solving problems. By continuously modeling software systems, the organization they work for, and customer behavior, the most effective managers readjust their approach to problems daily.
This is a great example of what good engineering managers do because after a certain size of a project, one person can't build while also keeping all the downstream externalities in their head.
But wait! Microservices and self documenting APIs will fix all this right?
Nope - people and process management is as important here as it is on a car assembly line.
To adulterate a quote from James Madison:
If [programmers] were [perfect robots], no [management] would be necessary.
Knowledge workers have to manage so much of their own workflow that they should be treated like managers. Developers starting their careers should be trained on how to manage their own work.
I have worked in an automotive assembly plant, I have read about the rise of scientific management and later the Toyota Production System. In a physical system, you have to respect the production environment and the product. If there is an oil leak or fire hazard you must address that if you want to continue producing.
In knowledge work, the factory is inside someone's mind. They have to be ready, willing, and able to manage their own mind. They have to bring that to the job. It is also imperative that management methods do not damage that production environment. Fear, shame, frustration, and anxiety can all shut down that factory. Some of those emotions can be used to force production, but that is like running a motor over it's torque and power spec - you can do it for a while but you're damaging components that you can't see and it will have to be replaced or rebuilt before it's stated service life. Also we're talking about humans not machines. Humans can choose to leave.
I have worked in an automotive assembly plant, I have read about the rise of scientific management and later the Toyota Production System. In a physical system, you have to respect the production environment and the product. If there is an oil leak or fire hazard you must address that if you want to continue producing.
In knowledge work, the factory is inside someone's mind. They have to be ready, willing, and able to manage their own mind. They have to bring that to the job. It is also imperative that management methods do not damage that production environment. Fear, shame, frustration, and anxiety can all shut down that factory. Some of those emotions can be used to force production, but that is like running a motor over it's torque and power spec - you can do it for a while but you're damaging components that you can't see and it will have to be replaced or rebuilt before it's stated service life. Also we're talking about humans not machines. Humans can choose to leave.
The best manager I've had described his job as "working for developers". Like a shared assistant that acts as the communication point for stakeholders, gladhands needy customers, completes rfps/security questionnaires/other paperwork, finds talent, etc. Seems like any other position - a great manager is priceless / a bad one is pernicious
I think a lot here miss the main point of the article.
Managers used to be smarter than their subordinates, so they could steer the work.
With knowledge work, as soon as you turn manager, you're away from the knowledge. That means all of a sudden your subordinates are smarter than you.
So where does that leave the manager? Well, as the article also kind of concludes, the manager is now at the service of the team. Big difference!
Instead of coordinating and guiding the work, the manager now has to make sure the path is clear for the team to do their job. The manager deals with all the bullshit so the team doesn't have to.
This also means that it will be hard for you to notice a great manager, but easy to notice a bad one.
Managers used to be smarter than their subordinates, so they could steer the work.
With knowledge work, as soon as you turn manager, you're away from the knowledge. That means all of a sudden your subordinates are smarter than you.
So where does that leave the manager? Well, as the article also kind of concludes, the manager is now at the service of the team. Big difference!
Instead of coordinating and guiding the work, the manager now has to make sure the path is clear for the team to do their job. The manager deals with all the bullshit so the team doesn't have to.
This also means that it will be hard for you to notice a great manager, but easy to notice a bad one.
> you're away from the knowledge. That means all of a sudden your subordinates are smarter than you.
This is incorrect in a subtle but important way: Being closer to "the knowledge" as you put it, doesn't change how smart you are, it changes how well informed/up to date you are. That being said, it's always better to hire people smarter than you if you can :)
Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize.
To some degree this is zero sum, and reflects where you spend your time. Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned.
This: > it will be hard for you to notice a great manager, but easy to notice a bad one.
is very true. The corollary is that as an IC you often perform much better in a high functioning team with a good or great manager, but it's easy/comfortable to believe this is mostly yourself.
This is incorrect in a subtle but important way: Being closer to "the knowledge" as you put it, doesn't change how smart you are, it changes how well informed/up to date you are. That being said, it's always better to hire people smarter than you if you can :)
Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize.
To some degree this is zero sum, and reflects where you spend your time. Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned.
This: > it will be hard for you to notice a great manager, but easy to notice a bad one.
is very true. The corollary is that as an IC you often perform much better in a high functioning team with a good or great manager, but it's easy/comfortable to believe this is mostly yourself.
> Similarly, being closer to "the knowledge" tends to make you poorly informed about other important aspects of your business, almost unavoidably. This information is often critical to actual success, more than IC's/engineers often realize.
But the question is here the same: is the manager most informed to take the decisions? I would expect the functional analyst to know most about the domain and what is required, and the sales or business development people about how to extract money out of the customer. In all cases, I think the experts of all fields are at the lowest level.
> Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned.
I agree that the vision needs to come from the top downwards. That means "where do we want to go", but the "how will we do this", is in my opinion all the people at the lowest levels.
As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
But the question is here the same: is the manager most informed to take the decisions? I would expect the functional analyst to know most about the domain and what is required, and the sales or business development people about how to extract money out of the customer. In all cases, I think the experts of all fields are at the lowest level.
> Done well, a good EM will be an interface between the goals (from above) and capabilities (from below) and keeping them aligned.
I agree that the vision needs to come from the top downwards. That means "where do we want to go", but the "how will we do this", is in my opinion all the people at the lowest levels.
As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
> is the manager most informed to take the decisions?
Often, yes. Or at least knows who is, and how to put it to them.
Put another way, the domain experts are usually the best people to describe the tradeoffs but often don't have a sufficiently broad view to make the decisions. Obviously this isn't universal - one key skill in engineering management is empowering your team to make all the decisions they can most usefully make, and facilitating their input to the ones they can't.
> As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
I think this really misses the point. With a great manager, a team will fire on all cylinders; rarely is this true without at least a good one (exceptions made for small, experienced teams in certain circumstances). You are describing more of a project manager "hat", which sometimes is worn by an engineering manager, but need not be.
Often, yes. Or at least knows who is, and how to put it to them.
Put another way, the domain experts are usually the best people to describe the tradeoffs but often don't have a sufficiently broad view to make the decisions. Obviously this isn't universal - one key skill in engineering management is empowering your team to make all the decisions they can most usefully make, and facilitating their input to the ones they can't.
> As for capabilities, a great manager will present what needs to be done to the team, and the team will decide what effort will be required.
I think this really misses the point. With a great manager, a team will fire on all cylinders; rarely is this true without at least a good one (exceptions made for small, experienced teams in certain circumstances). You are describing more of a project manager "hat", which sometimes is worn by an engineering manager, but need not be.
Whenever I feel like my management is not sufficiently technical or experienced I think of the construction foreman. I imagine what things would be like if you could become a foreman without ever learning construction yourself. How would that work?
Software development at some companies often seems like that. The person in the position of leadership is instead led (at the expense of productivity) by the people they're meant to lead.
Of course this would never be allowed in a field where there are serious non-reversible consequences of negligence stemming from a lack of knowledge.
I feel like this is largely a phenomenon local to software development.
Software development at some companies often seems like that. The person in the position of leadership is instead led (at the expense of productivity) by the people they're meant to lead.
Of course this would never be allowed in a field where there are serious non-reversible consequences of negligence stemming from a lack of knowledge.
I feel like this is largely a phenomenon local to software development.
I'm reminded of football coaches. Some of them used to play football, but even then were rarely superstar players. They definitely can't suit up and take over for a missing player - yet they're held responsible for the wins and losses more than the players themselves, and the players have incredible respect and deference for what they do.
I still feel football coaches bring more expertise on the table. They handle the strategy used and which player does what.
For software development, those things should be in the hands of the developers and architects.
For software development, those things should be in the hands of the developers and architects.
>I think a lot here miss the main point of the article.
People are very, very clearly reacting to the headline and making the same comments we've seen 1000 times before.
It's a shame since the article itself is interesting and could stimulate actual novel conversation, but the chance for that is gone.
People are very, very clearly reacting to the headline and making the same comments we've seen 1000 times before.
It's a shame since the article itself is interesting and could stimulate actual novel conversation, but the chance for that is gone.
The purpose of engineering management is to create a buffer between the engineers and the a’holes, who, if permitted to manage the engineers directly, would drive them from the company. This is a critical, but not full-time job, as evinced by the fact that most engineering managers are themselves engaged in technical issues.
The main goal to staying employed as one is to push down priorities from above.
i've seen some pretty dysfunctional orgs, but none that has been that bad. a bit of diplomacy, a bit of corner cutting, a bit of bullshitting, some inflated sizings, a bit of politics, and you can buy the team enough time to clean up, get organised, and get back in shape
yes, an enterprise abstraction layer
Engineering management (when done right) has some key benefits
- protect the team from bullshit corporate politics / micromanagement (pad the team estimates with a buffer / push back on management unrealistic expectations)
- help team member fulfill their potential and grow outside their comfort zone
- give the team credit when credit is due (help shy people be seen etc)
- promote good people (and fire toxic / bad performers that drag the team down)
- help the team prioritize / prevent going into rabbit holes
- help the team get to decisions faster
- hire good people
- provide training
- provide budget / enable / arrange fun activities (offsite / hackathons)
- ensure inclusive environment (give room for introverts to speak their mind in a non awkward way / make sure not only extroverts are speaking in meetings by splitting to smaller groups / doing activities that are async e.g. writing ideas anonymously via virtual post it notes etc)
All of this can be done by a good peer or mentor, doesn't have to be a manager, but it sure helps if your manager is also a mentor.
- protect the team from bullshit corporate politics / micromanagement (pad the team estimates with a buffer / push back on management unrealistic expectations)
- help team member fulfill their potential and grow outside their comfort zone
- give the team credit when credit is due (help shy people be seen etc)
- promote good people (and fire toxic / bad performers that drag the team down)
- help the team prioritize / prevent going into rabbit holes
- help the team get to decisions faster
- hire good people
- provide training
- provide budget / enable / arrange fun activities (offsite / hackathons)
- ensure inclusive environment (give room for introverts to speak their mind in a non awkward way / make sure not only extroverts are speaking in meetings by splitting to smaller groups / doing activities that are async e.g. writing ideas anonymously via virtual post it notes etc)
All of this can be done by a good peer or mentor, doesn't have to be a manager, but it sure helps if your manager is also a mentor.
I think part of problem here is that there's a notion of a generic right answer to these questions and that typically the "right answers" are those that get passed down from the enterprise world.
I've worked at companies with no managers and it's worked fine. At one place I worked we basically just had a sales teams, an engineering team and a CEO. There were no managers. The sales people raised tickets for bugs and requests for features that would make their lives easier, these would then get a glance over and approval by either a lead dev or the CEO and someone would pick up the ticket. As engineers we would also raise tickets when we identified areas of the system we could improve.
This worked really well and it was an extremely efficient way to work for us but what we gained in efficiency we lacked in accountability and scalability. But when you're a company with less than 50 employees neither matters too much.
For large enterprises and public companies there's clearly far more value in having managers and various other non-engineers roles. For one as an engineer I literally don't want to be responsible for any big non-technical decisions in large companies which provide critical products and services. But in larger companies there's just far more value in having a clear hierarchy of accountability.
That said, I do think a lot of small companies think they need managers when they don't. And I think the reason they believe they need these roles is just because that's how it's done in the larger corps.
To some extent this might be a matter of personal preferences too. I tend to like working independently and quite like being given fuzzy requirements. I know I've worked with some devs who prefer working with well defined requirements and get uncomfortable when making decisions that haven't been formally approved. Depending on your engineers and culture the value of managers might vary.
I've worked at companies with no managers and it's worked fine. At one place I worked we basically just had a sales teams, an engineering team and a CEO. There were no managers. The sales people raised tickets for bugs and requests for features that would make their lives easier, these would then get a glance over and approval by either a lead dev or the CEO and someone would pick up the ticket. As engineers we would also raise tickets when we identified areas of the system we could improve.
This worked really well and it was an extremely efficient way to work for us but what we gained in efficiency we lacked in accountability and scalability. But when you're a company with less than 50 employees neither matters too much.
For large enterprises and public companies there's clearly far more value in having managers and various other non-engineers roles. For one as an engineer I literally don't want to be responsible for any big non-technical decisions in large companies which provide critical products and services. But in larger companies there's just far more value in having a clear hierarchy of accountability.
That said, I do think a lot of small companies think they need managers when they don't. And I think the reason they believe they need these roles is just because that's how it's done in the larger corps.
To some extent this might be a matter of personal preferences too. I tend to like working independently and quite like being given fuzzy requirements. I know I've worked with some devs who prefer working with well defined requirements and get uncomfortable when making decisions that haven't been formally approved. Depending on your engineers and culture the value of managers might vary.
> I know I've worked with some devs who prefer working with well defined requirements and get uncomfortable when making decisions that haven't been formally approved.
A thing I teach to younger folks: no one likes making decisions, but that's where money comes from.
A thing I teach to younger folks: no one likes making decisions, but that's where money comes from.
An effective manager cares for their team, their work, and its effect beyond the immediate organization.
I agree with this take, but with a whopping great caveat - the 'team' is far bigger than the manager's direct reports. Once you accept that the team includes people like product leads, QA, and the leadership team then you start to understand why engineering management is hard. You're trying to get the best work out of your dev team of course, but you're also wrangling a whole bunch of things that intentionally make the dev team's life more difficult, whether that's discussions about the broad direction for the team to go in relative to the wider scope of the business, or the minute little nitpicky bugs that QA won't let slide.
I agree with this take, but with a whopping great caveat - the 'team' is far bigger than the manager's direct reports. Once you accept that the team includes people like product leads, QA, and the leadership team then you start to understand why engineering management is hard. You're trying to get the best work out of your dev team of course, but you're also wrangling a whole bunch of things that intentionally make the dev team's life more difficult, whether that's discussions about the broad direction for the team to go in relative to the wider scope of the business, or the minute little nitpicky bugs that QA won't let slide.
In my experience a good chunk of engineering managers were simply the greedy engineers who did not want or were not able to contribute technically and preferred to jump into management for an easier life and higher pay. That worked out for many of them which is one of the reason for dysfunction at some large tech companies.
My experience with managers is they exist to put pressure on engineers for social reasons. They never do anything useful and within a short time I tend to resent their interference in my work, so I start fucking things up and generally slacking to screw their metrics up. If I could find a company that honestly wanted work done, they would just give me tickets and I'd power through them. But nobody cares about work, it's all this weird social game. I don't understand it.
Engineering management is not bullshit in my opinion. It is, and always been, an organization-specific role. This leads to the ambiguities that can be frustrating.
There are two distinct roles in an engineering organization: staffing, process and engineering resources (indirect), and product/project development and delivery (direct).
Relegating staffing, process and resource decisions to non-engineers (e.g. HR) is not the best solution. It takes experience and expertise to build a good staff and engineering culture. That is the job of engineering managers.
Do engineering managers act as mentors? Sure, and they can also provide technical input. But that’s just one of their many responsibilities.
Roughly 30 years ago, this same discussion was happening around something called a “matrix organization.” It was the same confusion of responsibilities under a different name.
Everything works fine when everyone stays in their lane (managers, I mean) and pushes in the same direction. It takes coordination, and it’s not something that people can reinvent on a daily basis.
In short: Make a plan for your organization, write it down, show it to everyone (over and over again like beating a drum) and then stick with it. For those who don’t comply, send them packing.
There are two distinct roles in an engineering organization: staffing, process and engineering resources (indirect), and product/project development and delivery (direct).
Relegating staffing, process and resource decisions to non-engineers (e.g. HR) is not the best solution. It takes experience and expertise to build a good staff and engineering culture. That is the job of engineering managers.
Do engineering managers act as mentors? Sure, and they can also provide technical input. But that’s just one of their many responsibilities.
Roughly 30 years ago, this same discussion was happening around something called a “matrix organization.” It was the same confusion of responsibilities under a different name.
Everything works fine when everyone stays in their lane (managers, I mean) and pushes in the same direction. It takes coordination, and it’s not something that people can reinvent on a daily basis.
In short: Make a plan for your organization, write it down, show it to everyone (over and over again like beating a drum) and then stick with it. For those who don’t comply, send them packing.
your reply echos my reply and working in a matrix organization. are there terrible managers -- yes, but in a well functioning organization with definitive role a manager should be as you describe and not what is written in the article.
what's crazy to me are all the comments here that echo what the article is saying where managers seem to be some sort of rulers and be all in an oganization, which would totally suck and i'm glad i don't work somewhere like that.
what's crazy to me are all the comments here that echo what the article is saying where managers seem to be some sort of rulers and be all in an oganization, which would totally suck and i'm glad i don't work somewhere like that.
Graeber's Bullshit Jobs is a good background context for this discussion. I feel most are replying about individually good and bad managers and taking a lot about our hierarchies for granted as the most productive formations for society. Maybe the hierarchy is only necessary when the workers have to be kept motivated without any financial upside to business outcomes they generate
In a well oiled org managers aren't needed. I know it because I've been part of one. It needs specialised skilled workers i.e., product owner, product designer, project manager, and engineers. There'll be a tech lead among engineers who will be point person for the project manager. That's it. At the top you need execs or business heads liaising with product owners and/or project managers.
Managers however become essential when this well oiled machine is thrown off by a sudden expansion of the team or when there's a chronic uncertainty about the work that's going to happen next month. Then you need whose who are good at navigating this chaos through networking, politics etc., to get the work done as well as making sure the team survives should the axe fall.
Managers however become essential when this well oiled machine is thrown off by a sudden expansion of the team or when there's a chronic uncertainty about the work that's going to happen next month. Then you need whose who are good at navigating this chaos through networking, politics etc., to get the work done as well as making sure the team survives should the axe fall.
all that means is that you're making either the tech lead or your project manager the engineering manager. whoever is between business and the engineers, saying yes/no to the former based on the needs of the latter, is the EM
These things always devolve into the Product Owner or the Project Manager are actually the Engineering Manager without the pay and/or authority.
Engineering management is only bullshit if the managers are not potential target users of the product, since a manager needs to deeply understand how the product gets experienced by its end users. Note that this does not mean that non-technical people cannot be engineering managers; it just means that they cannot manage technical products.
Thus, you cannot have effective nontechnical managers for products intended for technical people (e.g. IDEs, sysadmin tools, etc.), but technical managers for products intended for general audiences (e.g. email, office applications, etc.) are perfectly fine (and perhaps even better, since they provide a much needed nontechnical perspective to highly technical developers).
Thus, you cannot have effective nontechnical managers for products intended for technical people (e.g. IDEs, sysadmin tools, etc.), but technical managers for products intended for general audiences (e.g. email, office applications, etc.) are perfectly fine (and perhaps even better, since they provide a much needed nontechnical perspective to highly technical developers).
My manager joins our stand up and basically just says “had some meetings yesterday, have some more today”. No wonder why we think the job is BS
In the scrum guide, the scrum master is considered to have a management role. Although it's a management role, I don't believe it's a people management role. That's what the Engineering Manager does and ideally they wouldn't be attending the scrum.
I had a scrum master that literally did nothing. He tried to get me to do his work, like running planning poker, updating sprint status slides, and other assorted nonsense, while he literally phoned it in from his kid’s baseball game. I was the tech lead on the team and flat out refused. Eventually he got one of the more junior engineers to do it.
We fought that battle and lost
But anyway my point was that he does a bad job at communicating what he does for us.
But anyway my point was that he does a bad job at communicating what he does for us.
Thankfully most of the managers I've worked for were still doing or able to do the job of a senior/lead person of the team who they managed.
The few I have had who were not capable of that were really ineffective. They didnt know how to handle top performers. They didnt know how to help low performers. They become managers of micro bits of information that they collected and passed up to their manager so despite the results of their team they can say they were doing xyz.
It was hell. I always found they gave useless advice too. Have a work problem that isnt some type of personal problem? Well they cant help because they dont know/understand what you do or how to help.
The few I have had who were not capable of that were really ineffective. They didnt know how to handle top performers. They didnt know how to help low performers. They become managers of micro bits of information that they collected and passed up to their manager so despite the results of their team they can say they were doing xyz.
It was hell. I always found they gave useless advice too. Have a work problem that isnt some type of personal problem? Well they cant help because they dont know/understand what you do or how to help.
Same. The best engineering managers I’ve had were also very capable engineers.
I'd say: No, not at all!
Read about Admiral Rickover. He built the first practical nuclear submarine in the world, for the US navy, in record time of 3 years. He cleared bureaucratic hurdles, played the politics when needed, kept tight control, delved deep into the technicalities of the project, recruited and trained a large number of people into the program, and ultimately made the project successful.
Dig deeper into any other large scale projects, you'll find great engineering management. The Manhattan project is another example (It should be categorised mostly under engineering management & not scientific management, according to some of the members in the team).
Read about Admiral Rickover. He built the first practical nuclear submarine in the world, for the US navy, in record time of 3 years. He cleared bureaucratic hurdles, played the politics when needed, kept tight control, delved deep into the technicalities of the project, recruited and trained a large number of people into the program, and ultimately made the project successful.
Dig deeper into any other large scale projects, you'll find great engineering management. The Manhattan project is another example (It should be categorised mostly under engineering management & not scientific management, according to some of the members in the team).
I think there is a huge difference between managers who can get a project over the finish line and ones who can get multiple large projects over the finish line. I'm not saying that Admiral Rickover didn't/couldnt do that but many managers are effective at cracking the whip and making X happen but at the expense of their teams health which leads to burnout and turnover.
I'd also say military management is significantly different than civilian. If my manager tells me to jump I'm not going to say how high. I'm going to say why are you asking me to move its early and i havnt had coffee yet.
I'd also say military management is significantly different than civilian. If my manager tells me to jump I'm not going to say how high. I'm going to say why are you asking me to move its early and i havnt had coffee yet.
Rickover was near the top echelons of US navy for ~60 years, as far as I know. Definitely, he knows a thing or two about burnout and turnover. He executed many, many sophisticated projects throughout his life. That's why he had such a long & successful career. I'd recommend reading his book - The never-ending challenge of Engineering. In my readings, this has been the best book on Engineering management.
Secondly, about burnout and turnover. Let's discuss from an empirical standpoint. The number one proximal cause of turnover is lack of "commitment". There are longitudinal empircal studies which demonstrate this. Job satisfaction is important as well; however commitment dominates every other factor.
Hence, it is important for managers to generate commitment, one way or another. I believe from these aspects, Rickover truly understood engineers and technical folks... In fact, he went against the US military books, and emphasised Individual initiative and judgement, regardless of what the rulebooks said. In a way, Rickover was able to work around the navy rules to create sufficient commitment to get complicated jobs done.
Secondly, about burnout and turnover. Let's discuss from an empirical standpoint. The number one proximal cause of turnover is lack of "commitment". There are longitudinal empircal studies which demonstrate this. Job satisfaction is important as well; however commitment dominates every other factor.
Hence, it is important for managers to generate commitment, one way or another. I believe from these aspects, Rickover truly understood engineers and technical folks... In fact, he went against the US military books, and emphasised Individual initiative and judgement, regardless of what the rulebooks said. In a way, Rickover was able to work around the navy rules to create sufficient commitment to get complicated jobs done.
Author of the article here. I bought one of Rickover's books and am currently reading through it. Thanks for the recommendation.
However, Rickover was deeply against non technical people managing technical people in the organization. One is reminded of the Newton quote:
"Errors are not in the art but in the artificer"
"Errors are not in the art but in the artificer"
My take is like this: Engineering management works if EMs are good at their job.
According to this tweet: - Startups with managers 33% more likely to develop product innovations
- Firing a bad manager and replacing them with a top manager drops costs 5%, since you reduce turnover.
- In a car factory, replacing a bad manager with a top manager diminishes the hours needed to build a car by 30%.
- In the game industry - good managers means +22% in revenue
[1] https://twitter.com/emollick/status/1561408118906568704
According to this tweet: - Startups with managers 33% more likely to develop product innovations
- Firing a bad manager and replacing them with a top manager drops costs 5%, since you reduce turnover.
- In a car factory, replacing a bad manager with a top manager diminishes the hours needed to build a car by 30%.
- In the game industry - good managers means +22% in revenue
[1] https://twitter.com/emollick/status/1561408118906568704
> Startups with managers 33% more likely to develop product innovations
If the upside of managers is only 33%, they're probably not worth the added complexity/friction/expense !
If the upside of managers is only 33%, they're probably not worth the added complexity/friction/expense !
Maybe you are misunderstanding? This number would be the holy grail of any company. Unfortunately the claim made is pure nonsense :)
Put it that way. I pay you $100k to work in a fast-moving environment, or $130k to work in a bureaucratic environment. Which do you choose ?
(it's worse in a company as it's the shareholders who earn +30%, not you)
(it's worse in a company as it's the shareholders who earn +30%, not you)
30% improvement is a goldmine in any industry.
[deleted]
It's unfortunate we think of management as "keeping bullshit at bay".
I much prefer "clear the runway".
The great teams I've worked on, shared context oozes from the team and managers often don't know what that shared context is, but they protect it.
Once one studies complexity science, it becomes less "bullshit" and more "navigating complexity" and that's how i approach it.
You're gonna have a bad time in engineering if you think everything not engineering is BS.
I much prefer "clear the runway".
The great teams I've worked on, shared context oozes from the team and managers often don't know what that shared context is, but they protect it.
Once one studies complexity science, it becomes less "bullshit" and more "navigating complexity" and that's how i approach it.
You're gonna have a bad time in engineering if you think everything not engineering is BS.
I like to think that management is a noble profession if done right. I've seen a handful of examples over a 10+ year career thus far.
You get to empower people to be better versions of themselves everyday. What other job allows you to do that?
The reality however is that most EM jobs are in fact bullshit jobs. They usually have people who are simply managers/operators, not often leaders nor coaches. To summarize a people manager's job, it's two main things:
1) Get results
2) Grow & retain your people
The challenge is that many EMs are also "assholes" so both of these goals are hard to accomplish. They fit into an asshole category in itself:
- political assholes master the art of corporate politics but do nothing but take credit for everyone else's work.
- controlling assholes micromanage to the point of strangling creativity and joy out of their team while taking credit for others creative ideas and call them their own.
- asshole assholes are mean, jealous, and insecure jerks who find ways to lie and manipulate others for their gain.
- mission-driven assholes are people who are crazy passionate and trample over how things are "done around here" to see the mission succeed.
Note: I use the term "asshole" in reference to Tony Fadell's book "Build". It's a fun way to think about it.
Most engineering teams tend to optimize for the incentive of the engineering manager, not the whole team. It's winner-take-all. The good EMs are the ones who see through this and ensure their whole team is empowered at the potential cost of their own incentive. These EMs usually win-win in the long term.
You get to empower people to be better versions of themselves everyday. What other job allows you to do that?
The reality however is that most EM jobs are in fact bullshit jobs. They usually have people who are simply managers/operators, not often leaders nor coaches. To summarize a people manager's job, it's two main things:
1) Get results
2) Grow & retain your people
The challenge is that many EMs are also "assholes" so both of these goals are hard to accomplish. They fit into an asshole category in itself:
- political assholes master the art of corporate politics but do nothing but take credit for everyone else's work.
- controlling assholes micromanage to the point of strangling creativity and joy out of their team while taking credit for others creative ideas and call them their own.
- asshole assholes are mean, jealous, and insecure jerks who find ways to lie and manipulate others for their gain.
- mission-driven assholes are people who are crazy passionate and trample over how things are "done around here" to see the mission succeed.
Note: I use the term "asshole" in reference to Tony Fadell's book "Build". It's a fun way to think about it.
Most engineering teams tend to optimize for the incentive of the engineering manager, not the whole team. It's winner-take-all. The good EMs are the ones who see through this and ensure their whole team is empowered at the potential cost of their own incentive. These EMs usually win-win in the long term.
It's extremely odd to characterize all modern management as Taylorism from the outset. The post seems to be flogging a strawperson argument and concluding with a summary of what I think is a fairly broad consensus about what modern management of knowledge workers actually looks like: finding competent people, setting rich context and providing frequent and actionable feedback.
I know the rank & file almost universally consider management to be morons and how could anyone be so incompetent and stupid. Naturally, in the businesses I've run, I'd get regularly informed about how incompetent and stupid I am, and how a squirrel could do better.
Yet anyone can start their own business, and thus prove how much better they are. Some do (even though their employees think they're incompetent), most fail.
I remember in particular a woman who worked at Microsoft in the 1990s. We knew each other through mutual friends. She heaped ridicule on how I ran my business. I'd just bite my tongue. One day she quit Microsoft, having made a fortune in MSFT stock options. She invested it all in her startup. A year passed, and she lost it all.
While I gave her a lot of points for putting her money where her mouth was, it was a brutal lesson in how difficult running a business at a profit is.
Yet anyone can start their own business, and thus prove how much better they are. Some do (even though their employees think they're incompetent), most fail.
I remember in particular a woman who worked at Microsoft in the 1990s. We knew each other through mutual friends. She heaped ridicule on how I ran my business. I'd just bite my tongue. One day she quit Microsoft, having made a fortune in MSFT stock options. She invested it all in her startup. A year passed, and she lost it all.
While I gave her a lot of points for putting her money where her mouth was, it was a brutal lesson in how difficult running a business at a profit is.
One thing I've noticed repeatedly is that counter to the old adage "Success has many fathers, failure is an orphan", the opposite is almost always true. At every successful company I've worked at there's been probably 1 thing that drives the success, and a thousand things that hinder the success. But just that one thing driving success can overcome the thousand hinderances. It's because that one nugget of success is so strong, you can afford to fail in lots of other ways. The core driving success of a large company almost always spawns a load of other problems which would sink any smaller company, but it survives because the good outweighs the bad, and when the good is massive, the bad can be pretty enormous too.
The problem is, it's often almost impossible to really know what's driving th success. And by hacking away at the problems you can endanger the unique combination of things that drives success.
The problem is, it's often almost impossible to really know what's driving th success. And by hacking away at the problems you can endanger the unique combination of things that drives success.
Management is a generic role with many of the same tasks no matter what jobs the people they manage are doing. Engineering manager means you have the software engineering domain of problems which are highly technical in nature but coaching, reviewing people's work, planning work, hiring/firing/perf reviews, etc. are all things that have to get done.
Maybe a better corollary is managing surgeons? Highly technical work, highly paid, sometimes the manager won't be better than the people they manage or even be able to perform their role.
The way humans organize work is hierarchical. I view my role as manager is more servant leader, doing busy work dev stuff when I have time like patches, bugs, etc. and leaving "fun" feature/product work to the team. Make sure they have what they need to do their work (planning, filtering out nonsense, attending planning meetings, etc.) and get out of their way.
Maybe a better corollary is managing surgeons? Highly technical work, highly paid, sometimes the manager won't be better than the people they manage or even be able to perform their role.
The way humans organize work is hierarchical. I view my role as manager is more servant leader, doing busy work dev stuff when I have time like patches, bugs, etc. and leaving "fun" feature/product work to the team. Make sure they have what they need to do their work (planning, filtering out nonsense, attending planning meetings, etc.) and get out of their way.
Bell curves apply to every profession. There are a few truly terrible managers, a bunch of mediocre ones, and a few truly great ones. Same with developers, engineers, teachers, nurses, or whatever.
For someone in some profession 'A' at the top 5% of their peer group, everyone else seems incompetent by comparison. However, it's easy to ignore the incompetence of their own peer group. There are a few reasons for this. For example, if you're good at 'A' and someone is bad at 'A', you can more easily fill the gaps with your own knowledge and paper over that problem, which makes it seem less important. Similarly, highly skilled people tend to work in teams with other similarly skilled peers, etc...
However, when looking at random samples from profession 'B' (whatever that is), then the top-5%-at-A person will typically come across median 'B' people. That's just statistics.
So what does a top 5% at 'A' person think of median people in profession 'B', 'C', and 'D'? That they're all idiots and that their jobs are not as complex or meaningful as whatever 'A' is, of course!
Don't assume anything about what 'A' is. Could be engineering, science, finance, or whatever. The statistics is the same.
Management however gets significantly more flak than other professions, because they're forced onto employees. You don't generally get to choose your manager, you're assigned one. You don't get to fire your "superiors", even if they're clearly in the bottom 5% of the management profession and you're in the top 5% of your profession.
This is why you hear skilled engineers grumbling about bad management. So does every other skilled member of every other profession, including skilled managers, which have random managers above them!
For someone in some profession 'A' at the top 5% of their peer group, everyone else seems incompetent by comparison. However, it's easy to ignore the incompetence of their own peer group. There are a few reasons for this. For example, if you're good at 'A' and someone is bad at 'A', you can more easily fill the gaps with your own knowledge and paper over that problem, which makes it seem less important. Similarly, highly skilled people tend to work in teams with other similarly skilled peers, etc...
However, when looking at random samples from profession 'B' (whatever that is), then the top-5%-at-A person will typically come across median 'B' people. That's just statistics.
So what does a top 5% at 'A' person think of median people in profession 'B', 'C', and 'D'? That they're all idiots and that their jobs are not as complex or meaningful as whatever 'A' is, of course!
Don't assume anything about what 'A' is. Could be engineering, science, finance, or whatever. The statistics is the same.
Management however gets significantly more flak than other professions, because they're forced onto employees. You don't generally get to choose your manager, you're assigned one. You don't get to fire your "superiors", even if they're clearly in the bottom 5% of the management profession and you're in the top 5% of your profession.
This is why you hear skilled engineers grumbling about bad management. So does every other skilled member of every other profession, including skilled managers, which have random managers above them!
This reads to me like a spiteful piece due to a manager thinking this particular engineer was under performing, and maybe they were or maybe the manager is wrong.
To then declare that all engineering management is bullshit because measuring isn't a discrete number really makes me think less of the author.
I've had both good and bad managers, the good ones are able to identify dead weight, provide career growth and balance company needs against staff needs. The bad ones are yes men or never fire anyone.
Some of this may be company culture, I left my last job because firing people who didn't even show up to work was a 2 month process (amongst other culture problems).. HR only wanted discrete numbers in terms of performance, which to this articles point, is not 100% accurate.
Clearly some are able to measure, and sure its not a discrete number but its possible and currently its a skill, which is why most good managers are also engineers.
To then declare that all engineering management is bullshit because measuring isn't a discrete number really makes me think less of the author.
I've had both good and bad managers, the good ones are able to identify dead weight, provide career growth and balance company needs against staff needs. The bad ones are yes men or never fire anyone.
Some of this may be company culture, I left my last job because firing people who didn't even show up to work was a 2 month process (amongst other culture problems).. HR only wanted discrete numbers in terms of performance, which to this articles point, is not 100% accurate.
Clearly some are able to measure, and sure its not a discrete number but its possible and currently its a skill, which is why most good managers are also engineers.
Cool it a notch HN!
The article is not anti-management or 31337157
——
Summary Paragraph:
what is Engineering Managment’s Job?
We’ve touched upon a vague set of goals, but haven’t really settled on what an effective manager’s daily job really is.
Going back to Drucker, a manager’s job is to prepare people to perform, and to give them freedom to do so.
Creative people need psychological safety in order to perform. An effective manager provides this, along with coaching to help reports become more effective versions of themselves. This should then allow them to reap long term rewards.
An effective manager builds trust and space for their reports to execute, along with guidance for where their efforts will have the largest impact, helping them to continue growing in their career.
An effective manager cares for their team, their work, and its effect beyond the immediate organization. They are stewards first, realizing that much is beyond their control.
The ones who care are just trying to keep the bullshit at bay.
The article is not anti-management or 31337157
——
Summary Paragraph:
what is Engineering Managment’s Job?
We’ve touched upon a vague set of goals, but haven’t really settled on what an effective manager’s daily job really is.
Going back to Drucker, a manager’s job is to prepare people to perform, and to give them freedom to do so.
Creative people need psychological safety in order to perform. An effective manager provides this, along with coaching to help reports become more effective versions of themselves. This should then allow them to reap long term rewards.
An effective manager builds trust and space for their reports to execute, along with guidance for where their efforts will have the largest impact, helping them to continue growing in their career.
An effective manager cares for their team, their work, and its effect beyond the immediate organization. They are stewards first, realizing that much is beyond their control.
The ones who care are just trying to keep the bullshit at bay.
I would guess these pieces are usually written by people who sees one side of the story. In manufacturing, or maybe economy in general, states that there are 3 kinds of activity that create value, the idea, the manufacturer and the marketer. Of which the manufacturer has the lowest margin. My adaption of the smiling curve to software engineering is creation, maintenance and marketing.
There are engineers out there who sees themselves as "idea compiler" ,which is totally fine imo. Not everyone needs to see the "big picture". But the maintenance and marketing aspect of any software project is not to be underestimated. And it is beneficial to not undermine things that one doesn't understand. You don't know what you don't know. Keeping an open mind helps you to reduce the realm of unknown.
There are engineers out there who sees themselves as "idea compiler" ,which is totally fine imo. Not everyone needs to see the "big picture". But the maintenance and marketing aspect of any software project is not to be underestimated. And it is beneficial to not undermine things that one doesn't understand. You don't know what you don't know. Keeping an open mind helps you to reduce the realm of unknown.
[deleted]
As an engineering manager, I read and agree with this guy's critique. Coding is creative, uncertain, and vulnerable work, and if engineering managers are responsible for whatever leads to results (as he reads Drucker as saying, and which I agree is really our job), then yeah, everything he describes as hampering us in doing that job (tools like OKRs, the need to quantify results, etc. etc.) are all indeed real issues!
And if you look at how engineering management happens, at really any org big enough to have even one manager of engineers, I think you'll see this stuff really is a problem. But it's a problem because, well, organizations need to find some way to scale accountability over all of their members, which, when it faces the really tricky vulnerable and weird work of engineering, runs into these problems because of how incommensurate that work is with the tools it has to understand how it's going at scale.
When EMing is a bullshit job, it's because the engineering manager is so constrained by the bureaucratic needs of the organization that she cannot actually do the work that matters between the lines. Like when you've gotta manage up so much that you cannot find the room to support an engineer grappling with a novel and uncertain task? Well, the engineer suffers, rightfully blaming engineering management -- we were responsible for supporting them, and failed to do so.
As EMs, we have to ask ourselves what we wanna do. Do we wanna fit with what the org asks of us, or do we wanna do what we're responsible for: delivering results by supporting engineers as they do the scary, vulnerable work they do? When those things diverge, I think good managers discover ways to keep the people above them happy, while delivering on their responsibilities to their team. But they often do it despite, not because of, the organization they're serving.
I'd like to say it's as easy as just always focusing on results, as when they are delivered, the rest of the org will see that you know what's up! But no. If you just do that as an EM, you'll be fired, or passed over for promotions, or have your team cut from underneath you, or be told you're a better engineer than manager and demoted. Ultimately, your job is to do both: to deliver what the people above you say they need, and to help those who report to you.
The coda to this is that the people above you are also human, and also probably realize what they're asking of you is bullshit (if you're lucky). So if you're capable of dealing as humanely and vulnerably with those above you as much as your direct reports, you'll also win them over, and you'll win the cover from them to be able to do what matters with your team.
And if you look at how engineering management happens, at really any org big enough to have even one manager of engineers, I think you'll see this stuff really is a problem. But it's a problem because, well, organizations need to find some way to scale accountability over all of their members, which, when it faces the really tricky vulnerable and weird work of engineering, runs into these problems because of how incommensurate that work is with the tools it has to understand how it's going at scale.
When EMing is a bullshit job, it's because the engineering manager is so constrained by the bureaucratic needs of the organization that she cannot actually do the work that matters between the lines. Like when you've gotta manage up so much that you cannot find the room to support an engineer grappling with a novel and uncertain task? Well, the engineer suffers, rightfully blaming engineering management -- we were responsible for supporting them, and failed to do so.
As EMs, we have to ask ourselves what we wanna do. Do we wanna fit with what the org asks of us, or do we wanna do what we're responsible for: delivering results by supporting engineers as they do the scary, vulnerable work they do? When those things diverge, I think good managers discover ways to keep the people above them happy, while delivering on their responsibilities to their team. But they often do it despite, not because of, the organization they're serving.
I'd like to say it's as easy as just always focusing on results, as when they are delivered, the rest of the org will see that you know what's up! But no. If you just do that as an EM, you'll be fired, or passed over for promotions, or have your team cut from underneath you, or be told you're a better engineer than manager and demoted. Ultimately, your job is to do both: to deliver what the people above you say they need, and to help those who report to you.
The coda to this is that the people above you are also human, and also probably realize what they're asking of you is bullshit (if you're lucky). So if you're capable of dealing as humanely and vulnerably with those above you as much as your direct reports, you'll also win them over, and you'll win the cover from them to be able to do what matters with your team.
Did anyone here actually read the article? The author is not putting the usefulness of good engineering management into question. He is criticizing the culture around the organization of knowledge work. If the hat doesn't fit, don't wear it.
Clearly, 90% of the people commenting haven't read through the article and putting out their feelings by taking it personally instead of adding anything constructive.
One litmus test for a good manager that I found: do they ever make decisions that are optically bad?
If the answer is no, what do you think are the chances that optics are the main factor in their decision making process?
An example from personal experience: one of the downtime post-mortem action items that manager was pushing for was a complex alerting system (we already had a good amount of monitoring in place, but it didn't catch all issues).
The right action item should've been: we got extremely unlucky, but despite downtime we're not going to change anything, because likelihood of that happening again is extremely low.
It takes balls saying "this is a risk I'm willing to accept".
If the answer is no, what do you think are the chances that optics are the main factor in their decision making process?
An example from personal experience: one of the downtime post-mortem action items that manager was pushing for was a complex alerting system (we already had a good amount of monitoring in place, but it didn't catch all issues).
The right action item should've been: we got extremely unlucky, but despite downtime we're not going to change anything, because likelihood of that happening again is extremely low.
It takes balls saying "this is a risk I'm willing to accept".
From a technical perspective perhaps... from a fiscal perspective it is self justified.
Consensus planning is often expensive, error prone, and glacially slow.
Seen some groups end up navel-gazing in ivory towers, as their company collapsed. ;)
Consensus planning is often expensive, error prone, and glacially slow.
Seen some groups end up navel-gazing in ivory towers, as their company collapsed. ;)
The article was so much more interesting than the headline or other commenters seemingly commenting on the headline itself, I recommend people give it a read. It explores a lot more what would make a good manager and what does that mean and what is it supposed to be a good manager does.
> The minority of people who deliver results are drowned out by the people focusing on controlling the narratives. And for those who stick around, the operational overhead of the ineffective management only grows
> The minority of people who deliver results are drowned out by the people focusing on controlling the narratives. And for those who stick around, the operational overhead of the ineffective management only grows
I've become convinced recently that the role of an engineering manager is to act as a nanny for the engineers. Managers act as an intermediary between engineers and upper management and soften any blows that come from above. If something upsets an engineer, it's the manager's job to calm them down and tell them they're doing a good job and offer solutions to the engineer's problems. A happy engineer is a productive engineer.
> Scientific Management
There's the problem, right there.
I'll just leave it at that...
I was an engineering manager for 25 years.
I hated almost every minute of it, but I'm pretty sure that I was able to justify my existence (indeed, as I worked for a Japanese company, I had to do a weekly QCD report, and I called it my "Justify Your Existence Report").
Way too much to go into detail, but the post seems to be the usual "Post something inflammatory, and watch the clicks come in" kind of thing.
There's the problem, right there.
I'll just leave it at that...
I was an engineering manager for 25 years.
I hated almost every minute of it, but I'm pretty sure that I was able to justify my existence (indeed, as I worked for a Japanese company, I had to do a weekly QCD report, and I called it my "Justify Your Existence Report").
Way too much to go into detail, but the post seems to be the usual "Post something inflammatory, and watch the clicks come in" kind of thing.
In my experience Engineering management is essential. But most EM management sucks. Why?
Because in our industry management has no legal accountability. Nobody dies if a feature is half-assed. If the feature sucks they just create a ticket and assign it to a dev.
And because of that tech management has always been crowded with bullshit artists who promote other bullshit artists like them (which they have to, if not they would get exposed). And the story repeats over and over again.
Because in our industry management has no legal accountability. Nobody dies if a feature is half-assed. If the feature sucks they just create a ticket and assign it to a dev.
And because of that tech management has always been crowded with bullshit artists who promote other bullshit artists like them (which they have to, if not they would get exposed). And the story repeats over and over again.
when i think most people complain about managers it really is due to their oganization promoting very talented but absolutely socially awkward people into management positions.
there is probably a struggle in many organizations with bad managers, simply because in a typical technical organization the only mobility path for very smart people is to be promoted to a manager to bump up their pay/role in their company. many of these managers have no business being responsible for managing other people.
what a good manager should be is simply a good people person. being technical is not a requirement, a good manager when asked for technical question should be cognizant enough to realize their limitations and put the direct report in touch with a technical mentor.
a good manager should manage his resources within the direction of his organization and ensure they have the tool sets, support or anything else that the direct report need to successfully complete their task.
the engineers take tasks from project/program and the manager is there to ensure that the engineer has the bandwidth to support his tasks and milestones and has all the tools to complete those tasks.
there is probably a struggle in many organizations with bad managers, simply because in a typical technical organization the only mobility path for very smart people is to be promoted to a manager to bump up their pay/role in their company. many of these managers have no business being responsible for managing other people.
what a good manager should be is simply a good people person. being technical is not a requirement, a good manager when asked for technical question should be cognizant enough to realize their limitations and put the direct report in touch with a technical mentor.
a good manager should manage his resources within the direction of his organization and ensure they have the tool sets, support or anything else that the direct report need to successfully complete their task.
the engineers take tasks from project/program and the manager is there to ensure that the engineer has the bandwidth to support his tasks and milestones and has all the tools to complete those tasks.
I've been lucky to have a sequence of very good managers. Almost all of them changed roles back to Engineering within a couple years.
> ’ve yet to formalize a way of measuring how effective a developer is or isn’t.
This is generally not true. Although there's no etalon SWE in Paris Chamber, it is extremely easy to measure relative performance of engineers in one team.
Saying that, the article itself is off the point and very click-baity. It's a pity to see links like that on HN's first page.
This is generally not true. Although there's no etalon SWE in Paris Chamber, it is extremely easy to measure relative performance of engineers in one team.
Saying that, the article itself is off the point and very click-baity. It's a pity to see links like that on HN's first page.
Engineering management is oddly similar to some martial arts that are plagued by bullshit artists despite having a few legit uses and practitioners.
Also, if you don't have solid project management you shouldn't bother with engineering management. Hire a good PM instead. I've seen half a dozen companies make this mistake with serious consequences.
Also, if you don't have solid project management you shouldn't bother with engineering management. Hire a good PM instead. I've seen half a dozen companies make this mistake with serious consequences.
[deleted]
I'll go on a whim here and say that all roles in the software industry are bullshit in their own ways.
[deleted]
It's a simple test for me: does my manager protect me from bullshit so that I can get high caliber work done, or do I have to deal with bullshit myself because he can't?
The former are worth their salt. The latter can get back to coding or go pound sand for all I care.
The former are worth their salt. The latter can get back to coding or go pound sand for all I care.
Fair, but on the flip side, the easy thing to notice is the amount of BS that slips though. It is often much harder to quantify the amount of bullshit that the manager blocked, without more visibility of the dumb requests or whatever that the manager in receiving.
Even if a manager let nearly zero bullshit make it to you, from your perspective you can't always tell if that was your manager being good at that, or if your manager just received very little bullshit to deal with in the first place because their manager was good, (unless they happen to mention some of the non-sense they are blocking for you at some point or other).
Even if a manager let nearly zero bullshit make it to you, from your perspective you can't always tell if that was your manager being good at that, or if your manager just received very little bullshit to deal with in the first place because their manager was good, (unless they happen to mention some of the non-sense they are blocking for you at some point or other).
> Despite years of effort, and a market value for individual software companies of over trillions of dollars, we’ve yet to formalize a way of measuring how effective a developer is or isn’t.
I am not a developer, but I studied CS until my eyes bled, and I've been watching you guys. Seems to me you (royal, developers) have already long figured this out with 2 metrics. The first isn't how many lines of code, but the opposite; the best coders will meet programming specifications with the least lines of code, the smallest program that produces the required results. The second metric is how fast this code on a given platform produces the results, and the faster the better.
Isn't this how you all praise each other, with how clever and efficient the code is? Perhaps this doesn't scale, but it is measurable.
I am not a developer, but I studied CS until my eyes bled, and I've been watching you guys. Seems to me you (royal, developers) have already long figured this out with 2 metrics. The first isn't how many lines of code, but the opposite; the best coders will meet programming specifications with the least lines of code, the smallest program that produces the required results. The second metric is how fast this code on a given platform produces the results, and the faster the better.
Isn't this how you all praise each other, with how clever and efficient the code is? Perhaps this doesn't scale, but it is measurable.
Really the only two dimensions that matter for development as a function are time to market at a sufficient quality, and resources needed to maintain the codebase at sufficient quality once delivered. Any metrics about individual devs needs to support one of those two group goals.
The fewest lines of codes is an ok metric in that it often means more maintainable. But it can mean less maintainable if it's too cute. It's a leading indicator, but you can just directly measure bug volume and time to resolve issues.
Faster code is an irrelevant distraction 90% of the time.
Sister comment mentioned DORA metrics, which I wasn't familiar with and look exactly right:
* Deployment Frequency: Refers to the frequency of successful software releases to production.
* Lead Time for Changes: Captures the time between a code change commit and its deployable state.
* Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and full recovery.
* Change Failure Rate: Indicates how often a team’s changes or hotfixes lead to failures after the code has been deployed.
The fewest lines of codes is an ok metric in that it often means more maintainable. But it can mean less maintainable if it's too cute. It's a leading indicator, but you can just directly measure bug volume and time to resolve issues.
Faster code is an irrelevant distraction 90% of the time.
Sister comment mentioned DORA metrics, which I wasn't familiar with and look exactly right:
* Deployment Frequency: Refers to the frequency of successful software releases to production.
* Lead Time for Changes: Captures the time between a code change commit and its deployable state.
* Mean Time to Recovery: Measures the time between an interruption due to deployment or system failure and full recovery.
* Change Failure Rate: Indicates how often a team’s changes or hotfixes lead to failures after the code has been deployed.
> Faster code is an irrelevant distraction 90% of the time.
Time is money. Say a piece of code is executed zillions of times by hundreds of millions of customers. What would seem like a negligible increase in results, even a few milliseconds, adds up at scale. Sparing resources translates to saving money, both in energy expenditure and in squeezing in as many transactions in a minute as possible.
Time is money. Say a piece of code is executed zillions of times by hundreds of millions of customers. What would seem like a negligible increase in results, even a few milliseconds, adds up at scale. Sparing resources translates to saving money, both in energy expenditure and in squeezing in as many transactions in a minute as possible.
Most code is not executed a zillion times by hundreds of millions of customers.
Most products are not concerned with squeezing in as many transactions in a minute as possible.
All of those have their time and place. B2C codepaths used by all normal users in their most common daily usage? sure. HFT platform? sure. Pretty much anything else? You're probably spending more in dev salary than AWS savings and getting sniped by a competitor.
Most products are not concerned with squeezing in as many transactions in a minute as possible.
All of those have their time and place. B2C codepaths used by all normal users in their most common daily usage? sure. HFT platform? sure. Pretty much anything else? You're probably spending more in dev salary than AWS savings and getting sniped by a competitor.
> You're probably spending more in dev salary than AWS savings and getting sniped by a competitor.
I don't doubt you, but it is asinine if dev salaries are under such oppressive scrutiny when mind-boggling amounts of spending is wasted on management and especially executive salaries. Talk about bending over a dollar to pick up a dime.
I don't doubt you, but it is asinine if dev salaries are under such oppressive scrutiny when mind-boggling amounts of spending is wasted on management and especially executive salaries. Talk about bending over a dollar to pick up a dime.
those two have no demonstrated correlation with business performance, unlike DORA measures
Though it certainly seems counter-intuitive that the efficiency of a developer has absolutely no business value, my only point was that developers have their own metrics for praise of their peers, not that business should adopt them.
I've never heard of coders gushing over how fast someone got a piece of crap to market, no matter how profitable it was. Adobe development, for example, was one of the first to release their pro applications on Apple's PowerPC platform, but no one was impressed because their carbonized code was known not to be as performant as it would have been if ported natively in Cocoa. On the other hand, they also took a lot of grief for taking so long (wasn't it about 5 years?) to finally release Cocoa versions of those applications, just in time for Apple's platform switch to Intel, to be run in Apple's Classic emulator.
I've never heard of coders gushing over how fast someone got a piece of crap to market, no matter how profitable it was. Adobe development, for example, was one of the first to release their pro applications on Apple's PowerPC platform, but no one was impressed because their carbonized code was known not to be as performant as it would have been if ported natively in Cocoa. On the other hand, they also took a lot of grief for taking so long (wasn't it about 5 years?) to finally release Cocoa versions of those applications, just in time for Apple's platform switch to Intel, to be run in Apple's Classic emulator.
I wouldn't want to work with someone on a project who takes such a narrow role-based view of success. If the broader business goals seem gross or alienating or irrelevant to an engineer, perhaps they are, though not by necessity unless it's a typically exploitative class-based structure (even with some limited mobility to pmc)
[Context: After founding a startup and being a VPE or CTO four times, I now train and coach engineering leaders at vpecoach.com]
Engineering management is anything but a bullshit job, the impact of good leadership is very, very high. Knowing where you are going and why, having good processes, and solid communication is a step function improvement in basically every dimension of engineering team performance.
But I also understand this person’s take, because just because it’s an important and impactful job doesn’t mean YOUR engineering leader or manager is any good.
Like everything, management and leadership are skills, and most leaders have received next to no training during their entire career.
What level of leadership do you realistically expect from an untrained person? And if that isn’t what you need, what are you doing about it?
Engineering management is anything but a bullshit job, the impact of good leadership is very, very high. Knowing where you are going and why, having good processes, and solid communication is a step function improvement in basically every dimension of engineering team performance.
But I also understand this person’s take, because just because it’s an important and impactful job doesn’t mean YOUR engineering leader or manager is any good.
Like everything, management and leadership are skills, and most leaders have received next to no training during their entire career.
What level of leadership do you realistically expect from an untrained person? And if that isn’t what you need, what are you doing about it?
Good management can add tons of value for both employers and employees.
Bad management can subtract value.
Bad management often results from a misalignment of incentives.
Sorry, I'm too lazy to give details and it is a pretty complex topic.
Def not bullshit tho.
Bad management can subtract value.
Bad management often results from a misalignment of incentives.
Sorry, I'm too lazy to give details and it is a pretty complex topic.
Def not bullshit tho.
I mean doesn’t heaving salaries and a sellers market imply that engineering management jobs are not bullshit?
Are there any jobs which command big salaries and which companies hire for directly that are bullshit?
Are there any jobs which command big salaries and which companies hire for directly that are bullshit?
I'm a manager. This is a low-energy take on management, focused on the part of the job I call "keeping the spice flowing": knocking out tickets, landing key results, and coordinating with other teams. For a manager, this is all low-impact work.
High impact management work isn't mentioned here. These are things like developing your people and networking. It's a lot of work to get somebody promoted, even if that person is a well-known high performer. Networking with other managers, product managers, finance, IT... building influence with other parts of the company, this pays huge dividends for your team.
High-impact managers focus their efforts around the people on their teams.
High impact management work isn't mentioned here. These are things like developing your people and networking. It's a lot of work to get somebody promoted, even if that person is a well-known high performer. Networking with other managers, product managers, finance, IT... building influence with other parts of the company, this pays huge dividends for your team.
High-impact managers focus their efforts around the people on their teams.
Note how everything you categorize as 'high-impact' is basically politics.
"Rather than focus on delivering results (which again is difficult(!), might be wrong, and often not easily identified by leadership), these people spend time making alliances and crafting narratives about outcomes instead of delivering. Title acquisition becomes the goal, seeking to maximize the expected organizational rewards, at the expense of direct results, all while working to minimize accountability."
"Rather than focus on delivering results (which again is difficult(!), might be wrong, and often not easily identified by leadership), these people spend time making alliances and crafting narratives about outcomes instead of delivering. Title acquisition becomes the goal, seeking to maximize the expected organizational rewards, at the expense of direct results, all while working to minimize accountability."
Politics is something you do or something that is done to you is the saying no? Would you rather someone from engineering do your politics for you? Or someone from product or the business? I think the engineering person will look after you better.
Where it becomes fascinating is the 10+ year EM. They used to know what to do, but clearly don't anymore. They either accept that, and lean on their leads for technical decisions and just focus on politics, or dont accept it and thats what it can get bad fast.
Where it becomes fascinating is the 10+ year EM. They used to know what to do, but clearly don't anymore. They either accept that, and lean on their leads for technical decisions and just focus on politics, or dont accept it and thats what it can get bad fast.
[deleted]
I mean, a company is made up of a bunch of people, all with different ideas on how thinks should be done and in the end it’s often influence that decides the path forward.
Of course organizations have politics. It will always be that way unless you get rid of all the humans.
Of course organizations have politics. It will always be that way unless you get rid of all the humans.
I think the issue is that it's sort of circular, like, "managers provide value when they convince other managers not to be obstacles". I think there's important stuff managers can do, but creating complex hierarchies that they then have to navigate or circumvent is a neutral contribution at best, from a systemic standpoint rather than an individual one. For this high performer who's earned their promotion, having their manager go to bat for them is incredibly valuable. But if the reason they needed a manager to advocate for them was that other managers were either adversarial or ambivalent, that's just adding back value that was previously removed.
To be clear, I'm addressing this narrow aspect of management, I've had managers who helped me resolve disputes, get access to resources and opportunities I couldn't have gotten on my own, et cetera, and I see the value in that without qualification.
To be clear, I'm addressing this narrow aspect of management, I've had managers who helped me resolve disputes, get access to resources and opportunities I couldn't have gotten on my own, et cetera, and I see the value in that without qualification.
But if the reason they needed a manager to advocate for them was that other managers were either adversarial or ambivalent, that's just adding back value that was previously removed.
But "adversarial" management is just a reality in company that has $X to spend and 12 different ways to spend it.
Business decisions often have to made with limited data. A engineers "super cool feature that should obviously be implemented" is not so obvious at the CEO level where there are multiple competing projects.
As such there is a need to "sell" ideas internally -> that's politics.
But "adversarial" management is just a reality in company that has $X to spend and 12 different ways to spend it.
Business decisions often have to made with limited data. A engineers "super cool feature that should obviously be implemented" is not so obvious at the CEO level where there are multiple competing projects.
As such there is a need to "sell" ideas internally -> that's politics.
Just because it is the reality doesn't mean it can't be critiqued though, right? If the CEO doesn't have insight into this situation because their attention is divided - maybe the CEO should provide the people closer to the problem with the information they need to do their jobs, and trust that they've hired good people who will digest this information, prioritize appropriately, and get the job done? If they can't trust that's the case, then isn't that the problem we should be discussing? Maybe the CEO should focus on the strategic direction of the company and securing the investment required to implement it, and not manage projects at the feature level?
Generally I find that managers are awesome at facilitating stuff and making sure information gets where it needs to go but that when they dictate it leads to bad decision making because they don't have the proper insight. This becomes exacerbated as you add levels of indirection are between the manager dictating decisions and the people on the ground implementing them. That isn't per say their fault, it's just the dynamics of hierarchies. As information travels up the hierarchy it becomes more essentialized and nonspecific. It loses fidelity. Statistics can travel up the hierarchy, experience can't. So that engineer who's close to the problem has this rich first hand information about the system, and the CEO has a spreadsheet and third- or forth-hand accounts of the situation on the ground.
There's certainly a lot of global, systemic insights you can make from that position and useful work to be done. But it's probably not whether a individual feature of a broader project should or should not be implemented. Internal salesmanship is a bandaid, but structuring the organization differently is a solution.
Generally I find that managers are awesome at facilitating stuff and making sure information gets where it needs to go but that when they dictate it leads to bad decision making because they don't have the proper insight. This becomes exacerbated as you add levels of indirection are between the manager dictating decisions and the people on the ground implementing them. That isn't per say their fault, it's just the dynamics of hierarchies. As information travels up the hierarchy it becomes more essentialized and nonspecific. It loses fidelity. Statistics can travel up the hierarchy, experience can't. So that engineer who's close to the problem has this rich first hand information about the system, and the CEO has a spreadsheet and third- or forth-hand accounts of the situation on the ground.
There's certainly a lot of global, systemic insights you can make from that position and useful work to be done. But it's probably not whether a individual feature of a broader project should or should not be implemented. Internal salesmanship is a bandaid, but structuring the organization differently is a solution.
Sure, the CEO delegates decisions to his COO. Ok, now the COO has to decide which 5 projects to find out of the 12 the company wants to do.
Business decisions are rarely black and white which is why if you can’t articulate why you should get resources, you won’t - someone who can articulate their value better will get resources. And if they can convince someone else their idea is best, now you’ve got two people advocating (i.e. politics).
The larger orgs get the more politics because there is simply to much going on for any one person to have all the information needed to make a decision - they can only rely on others to argue for their own priorities.
Business decisions are rarely black and white which is why if you can’t articulate why you should get resources, you won’t - someone who can articulate their value better will get resources. And if they can convince someone else their idea is best, now you’ve got two people advocating (i.e. politics).
The larger orgs get the more politics because there is simply to much going on for any one person to have all the information needed to make a decision - they can only rely on others to argue for their own priorities.
Degrading "developing your people and networking" as "politics" just shows the lack of overall business and people acumen that engineers tend to suffer from. This is not necessarily a bad thing if you are aware of this, but these type of statements usually lead to engineers drifting away more and more from the purpose of the company.
It's not degrading or a value judgment (at this point).
But OPs post / self described high impact activities pretty much fit the definition of (company) politics perfectly.
The many pertinent questions I am asking are: Is it useful or necessary, to have people doing company politics full time, what are the incentives? What does this say about an organisation? Is such (internal) politics healthy for an org, how much is it predicated on, and much does it foster internal tribalism?
But OPs post / self described high impact activities pretty much fit the definition of (company) politics perfectly.
The many pertinent questions I am asking are: Is it useful or necessary, to have people doing company politics full time, what are the incentives? What does this say about an organisation? Is such (internal) politics healthy for an org, how much is it predicated on, and much does it foster internal tribalism?
> It's a lot of work to get somebody promoted, even if that person is a well-known high performer
Is it? Why? Sounds like a problem created by managers to me.
> Networking with other managers, product managers, finance, IT... building influence with other parts of the company, this pays huge dividends for your team.
I sincerely hope no engineering manager acts or thinks this way, or they will soon be just another MBA manager who doesn't know anything, other than how to navigate among other MBAs who also, don't know anything.
Do you not get the problem with people who don't know anything besides politics being in charge of delivering real world products and services?
Is it? Why? Sounds like a problem created by managers to me.
> Networking with other managers, product managers, finance, IT... building influence with other parts of the company, this pays huge dividends for your team.
I sincerely hope no engineering manager acts or thinks this way, or they will soon be just another MBA manager who doesn't know anything, other than how to navigate among other MBAs who also, don't know anything.
Do you not get the problem with people who don't know anything besides politics being in charge of delivering real world products and services?
[deleted]
I’m an engineer, and even I know that the technical solution is only like the 7th most important thing for a successful business endeavor.
We shouldn’t think too highly of ourselves.
We shouldn’t think too highly of ourselves.
Oh my sweet summer children. Feels like the author has perhaps never worked on a complex, big product or with any capable engineering management.
The worst and biggest messes in software engineering that I've seen have been situations where there was not enough engineering management. And those situations were fixed by... introducing proper engineering (and product!) management.
That being said, it is perhaps possible to survive with less engineering management in a situation where everyone is behaving and performing at senior or above level. However, realistically, that is very rarely the case.
The worst and biggest messes in software engineering that I've seen have been situations where there was not enough engineering management. And those situations were fixed by... introducing proper engineering (and product!) management.
That being said, it is perhaps possible to survive with less engineering management in a situation where everyone is behaving and performing at senior or above level. However, realistically, that is very rarely the case.
Similar to the other top comment, you're saying everyone who believes this must be naive and/or immature. Except that's the opposite of my experience: the most capable, longest-tenured technical people are the ones who are generally most jaded about management. Myself included.
I believe that there are probably a lot of problems out there that can be fixed by "proper engineering management". The problem is that 95% of what's out there is improper engineering management, which makes everything even worse. The whole point is not that engineering management is completely unnecessary, it's that in actual reality it's a trumped-up support role with false authority and completely swamped with utter bullshit. It's not done properly; that's the whole point.
I believe that there are probably a lot of problems out there that can be fixed by "proper engineering management". The problem is that 95% of what's out there is improper engineering management, which makes everything even worse. The whole point is not that engineering management is completely unnecessary, it's that in actual reality it's a trumped-up support role with false authority and completely swamped with utter bullshit. It's not done properly; that's the whole point.
I really liked my engineering management at Netflix. They really got the balance right. They sat in meetings with other management to sort out the big picture items and then passed relevant context on to us so we could figure out the engineering solutions to the problems that they had identified across the company (to go along with the engineering solutions to problems we had identified in our own org that we could solve).
They really helped the engineers save time in coordination while not getting in the way.
I think the key was that management didn't tell us what to do -- they told us what they company as a whole wanted to accomplish and how our team fit into that puzzle, and then we figured out the details.
They really helped the engineers save time in coordination while not getting in the way.
I think the key was that management didn't tell us what to do -- they told us what they company as a whole wanted to accomplish and how our team fit into that puzzle, and then we figured out the details.
Agile Software development done well is a good way to combat BS because it makes building a product into a team sport where everything is out in the open. Grooming, planning, sprints, standups, retrospectives, demos are all ceremonies which increase transparency and accountability. They also provide a way where development productivity can be measured against the collective assessment of the team.
No, but many engineering managers are. The key is not to be one, or work for one.
The author seems to be using "Sociopath" in the Gervais Principle sense, not as a general slur. Always worth a read:
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
This is a good point to call out. I'm going to add a link in the article.
Very long time Engineering Manager here.
Engineering Management is not bullshit, though there are many bad Engineering Managers out there, even at companies (like Google, where I've been an EM for over 6 years) that strive to build and support Engineering Managers. Google itself did research into the question of, "Do Engineering Managers matter?" The answer was Yes:
Google set out to determine what makes a manager great at Google. But first, a research team tried to prove the opposite: that managers actually don’t matter, that the quality of a manager didn’t impact a team’s performance. This hypothesis was based on an early belief held by some of Google’s leaders and engineers that managers are, at best, a necessary evil, and at worst, a layer of bureaucracy.
The team defined manager quality based on two quantitative measures: manager performance ratings and manager feedback from Google’s annual employee survey. This data quickly revealed that managers did matter: teams with great managers were happier and more productive.
https://rework.withgoogle.com/guides/managers-identify-what-...
Google currently asks Engineering Managers to focus on three areas: Leading work, developing people, and building community.
What are some ways I spend my time?
1. Making sure my people are supported in their lives and careers. This can mean giving someone a task they will take a long time to finish, because it's the right thing for them (and the team) to have that person learn about that area. You are trading off project/feature delivery for personal and team growth. It can also mean helping someone find ways to still have impact when they are struggling with some aspect of their job.
2. Clarifying strategies and priorities. There are only so many things the team can do successfully, and someone needs to be the person who says No. I am also the person best situated to look outward to other groups and teams to identify areas of collaboration.
3. Making sure we are organized appropriately and effectively, and that we are following good Engineering processes. I hate unnecessary process as much as anyone -- I've always said process should be something that helps you get your job done properly and effectively, not a hoop you need to jump through in order to do your job.
As an EM (and when I worked as a developer), I have had my own share of high-quality and poor-quality managers and Directors above me. If you feel EM is bullshit, I'm sorry you've never experienced what it's like to work on a team with a good, supportive manager.
Engineering Management is not bullshit, though there are many bad Engineering Managers out there, even at companies (like Google, where I've been an EM for over 6 years) that strive to build and support Engineering Managers. Google itself did research into the question of, "Do Engineering Managers matter?" The answer was Yes:
Google set out to determine what makes a manager great at Google. But first, a research team tried to prove the opposite: that managers actually don’t matter, that the quality of a manager didn’t impact a team’s performance. This hypothesis was based on an early belief held by some of Google’s leaders and engineers that managers are, at best, a necessary evil, and at worst, a layer of bureaucracy.
The team defined manager quality based on two quantitative measures: manager performance ratings and manager feedback from Google’s annual employee survey. This data quickly revealed that managers did matter: teams with great managers were happier and more productive.
https://rework.withgoogle.com/guides/managers-identify-what-...
Google currently asks Engineering Managers to focus on three areas: Leading work, developing people, and building community.
What are some ways I spend my time?
1. Making sure my people are supported in their lives and careers. This can mean giving someone a task they will take a long time to finish, because it's the right thing for them (and the team) to have that person learn about that area. You are trading off project/feature delivery for personal and team growth. It can also mean helping someone find ways to still have impact when they are struggling with some aspect of their job.
2. Clarifying strategies and priorities. There are only so many things the team can do successfully, and someone needs to be the person who says No. I am also the person best situated to look outward to other groups and teams to identify areas of collaboration.
3. Making sure we are organized appropriately and effectively, and that we are following good Engineering processes. I hate unnecessary process as much as anyone -- I've always said process should be something that helps you get your job done properly and effectively, not a hoop you need to jump through in order to do your job.
As an EM (and when I worked as a developer), I have had my own share of high-quality and poor-quality managers and Directors above me. If you feel EM is bullshit, I'm sorry you've never experienced what it's like to work on a team with a good, supportive manager.
How did Google change its promotion policies based on the data? From my time working with Google it felt like there were a lot of bullshit artists in management. To be clear, there were also a lot of bullshit artists among the engineers too. Very few people were engaged in using their time productively.
It's very fortunate for shareholders that Google has a cash-cow business, but to the article's point, once bullshit starts to expand within an organization the only true long term control on it is outside the organization ... competition and forced reform, or competition followed by death.
It's very fortunate for shareholders that Google has a cash-cow business, but to the article's point, once bullshit starts to expand within an organization the only true long term control on it is outside the organization ... competition and forced reform, or competition followed by death.
Changing perf/promo processes can be challenging. You can't always roll out minor changes (because the problems may be systematic), nor do them quickly; at Google's scale you need documentation and tooling to support your processes. You can try to fix some parts, but that can make other parts worse. But maybe that's OK. You can't optimize for everything, so you try to achieve the things you believe are most important and accept the remaining flaws.
Promotion policies continue to evolve at Google based on internally-sourced data. They changed most recently a few months ago. It's a constant that people don't like the current process, but they also don't like it when it changes :-). But I do appreciate that Google recognizes that the perf/promo processes could be better, and then they try to make them better.
Promotion policies continue to evolve at Google based on internally-sourced data. They changed most recently a few months ago. It's a constant that people don't like the current process, but they also don't like it when it changes :-). But I do appreciate that Google recognizes that the perf/promo processes could be better, and then they try to make them better.
Most companies are 10% difference makers, and 90% paid interns. To the
extent those interns need to feel like they're contributing, yes,
managers are important.
super simple answer: "management" is a misleading noun, whereas the useful activity is more like "facilitator".
i keep thinking of basketball and setting picks...facilitating others to score.
i keep thinking of basketball and setting picks...facilitating others to score.
> As someone who cares (you do, right?!), it’s your job to run towards accountability and responsibility. It’s also your duty to be aware of the methods and strategies of sociopaths, along with their strategies for influence and blame.
As an individual contributor with no desire to move to management and a deficit of skill in bullshitting and manipulating, I feel this advice ("run towards accountability") is really just self-preservation. I know I can't out-maneuver all the little Machiavellis around me, but if I can be legitimately useful to some of them (my boss, for example), then hopefully I can ride the coat-tails of the skilled Machiavellis for long enough to pay off my mortgage.
In other words, no I don't "care" about the goals of the company as a whole, but I still view it as rational to try and produce real value ("results" in the context of this article).
As an individual contributor with no desire to move to management and a deficit of skill in bullshitting and manipulating, I feel this advice ("run towards accountability") is really just self-preservation. I know I can't out-maneuver all the little Machiavellis around me, but if I can be legitimately useful to some of them (my boss, for example), then hopefully I can ride the coat-tails of the skilled Machiavellis for long enough to pay off my mortgage.
In other words, no I don't "care" about the goals of the company as a whole, but I still view it as rational to try and produce real value ("results" in the context of this article).
Engineering management is not bullshit, but there's a lot of companies with a focus on engineering that aren't necessarily good at hiring managers.
Yes and no. Depends on the manager.
Management is ruined by hierarchy.
engineering != management bullshit
[deleted]
Finally, an exception to Betteridge's law. But also, a 2,785-word word
salad that obscures an obvious one-word answer.
So workers increase their output by 3.5x to get +70% wages. I wonder why they complain about management bullshit...
Betteridge's law of headlines.
In my 20s I'd agree with the premise.
Now that I've seen high performers deviate from their job and make mistakes in the core role, I understand that even good workers benefit from managers.
I can even say the same thing about program management.
If communication is good, you don't need these as much, but big companies lack the ability to communicate effectively.
Now that I've seen high performers deviate from their job and make mistakes in the core role, I understand that even good workers benefit from managers.
I can even say the same thing about program management.
If communication is good, you don't need these as much, but big companies lack the ability to communicate effectively.
The answer is yes all management is bullshit
I guess the managers have found this comment. Once anyone notices when a manager takes vacation, then I'll consider it a vital part of any job
Why do you assume that anyone notices yours?
Even as an engineer, I hope FFS no one notices my vacations. It means everything is running smoothly and I actually get to have a little down time and not think about work
Every job I've worked at, when a co-worker goes on vacation, it's up to the other engineers and laborers to compensate. When the manager goes on vacation there's no extra work leftover
Engineers generally don't take over the manager's responsibilities unless they're technical or reporting responsibilites. Generally it's another manager. Most companies require management involvement in P0 incident response for an example. At most companies I've worked at an engineer generally wouldn't be an acceptable substitute. A peer or the manager's boss usually takes it in their absence. It's not unusual that a significant portion of management responsibilities aren't visible to their individual contributor direct reports.
Engineers having to compensate for your vacation sounds like a bad engineering org. Ideally, any gap in engineering should not be missed. If there are fires while you're out, there's something worse going on that needs to be addressed, whether it's bad management or bad engineers
Because my managers tell me about fires I have to put out when I get back
See other replies here.
Here, we see engineers reduce the contributions of such common roles as: Product Manger, Program/Project Manager, Scrum Master, Marketer, CEO, etc., as fungible or run by the biggest boogeyman of all, the dreaded MBA.
These arguments most typically result from not an inability, but an unwillingness to understand, the complexity and nuance that goes into running a business, and to recognize that actual smart people can make real contributions in non-engineering roles.
It's just personal and professional immaturity. Every time I ready these comments and articles, I really hope that the folks writing them are able to grow out of this mindset. They'd be a lot happier and more productive.