Developers can't fix bad management (2020) | Hacker News Reader

Developers can't fix bad management (2020)

iism.org

380 pointssidcool269 comments

I have a theory on why we're seeing so much "bad management" for software engineers: most leaders at workplaces have not been engineers themselves at a company with a great engineering culture (I wrote about what I think this means [1]: it's all the high-growth small and large tech companies we know)

The CEO, and the people under the CEO know and understand traditional, top-down management. Let the people with context and decision power make the big decisions, and pass this downwards. Works with finance, works with marketing, works with IT support, and should work with engineering as well... right?

But it actually doesn't work with software engineers as well as it could. Or with designers. UX researchers. PMs... all these people would produce a magnitude more output when given proper context and autonomy.

A few leaders read about this, and try giving autonomy. These results end up even worse than the status quo, as you can't just make it a free-for-all and expect it works overnight.

And to prove this point: look at companies where the founder had worked at a high-performing company before. Before founding Twilio, Jeff Lawson spent years at Amazon (he was one of the first AWS PMs), and in his book Ask Your Developer, he writes about just how much this experience shaped him, and all the practices he adopted from Amazon.

There's this really weird divide between "forward-looking tech companies"[2] who "get it", and everyone else. Which heavily benefits this first group.

[1] https://blog.pragmaticengineer.com/the-developer-culture-tes...

[2] https://news.ycombinator.com/item?id=25717390

It's not "traditional". It's common sense. You can't let an X company be run by someone without any affinity of X.

Would you let a painter do surgery on you?

> Would you let a painter do surgery on you?

False comparison. It should read "Would you let a painter _manage the surgeons_ who will operate on you?"

Having worked in the healthcare industry - the answer to that might surprise you.

To be fair, I am pretty sure most people here in HN wouldn't be at all surprised. We're very used to watching laymen having to manage potential millions of revenue.

I guess it's the right example, because healthcare is a mess as well

Crappy management begets crappy managers. Agreed.

I have a counter/supplementary theory that it is just as disruptive to assume a good developer will be a good leader or manager, too.

Rant time (aimed at no one in particular, especially not parent comment):

Managing is a very different skillset. There needs to be some significant knowledge of the industry at large, the specific domain that is relevant to your biz, and "generic" (for lack of a better phrase) management skills (i.e., communication and management of the squishy bits of your org that show signs of sentience and sometimes speak)

I've lost count the number of times I've heard colleagues say "They are such a bad (technical) manager, they'd never be able to do what I/we do." and have responded with "They don't need to. That's why they pay you."

I get very tired of this "debate" that it is management _versus_ IC/developer/engineer/worker. I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority.

You are a team, so work together.

I also hold the opinion that if your organisation has this mindset ("versus") within then you have a much bigger problem than what is presented at face value.

I agree managing is a skill all on its own. Yet IME it's easier to respect the choices or difficult circumstances when they come from someone who clearly knows the important parts at a conceptual and deep technical level.

> I also strongly believe a lot of what is perceived as "top-down" management is harbored by a "bottom-up" resentment - or just plain resisting authority.

As long as the people calling the shots still make more money than I do and I am the one cleaning up the mess that creates, I feel pretty justified in resenting them.

This is spot on in my experience.

The first thing that comes to my head when talking about bad management are manager positions with the power of taking decisions they they either don't fully grasp the consequences at-large of, or will not be hold accountable of bad results for.

Spot on.

I have no problems with managers dictating things as long as they take the responsibility of delays, failures, outages

How do you know they don't have a bigger-picture view than you? How do you know that they haven't had to acknowledge your problems but have to compromise because the alternative would be more problematic? (It's been my experience from both sides that even simply telling people this is the case isn't enough.. I've seen peers get upset when management explicitly acknowledge and explain why compromises are made but some on the team still feel resentment to that manager - but not the reasoning, despite it being objective) as well as members of the team I am managing hold resentment to me despite my own objective reasoning, and even support from other members of the team, not being enough to, I quote, "show them I am a good enough manager."

I'm not going to pretend managers are automatically all massive value-adds. A bad manager is a bad manager. But a bad developer is a bad developer. A bad person is a bad person.

My previous rant is mostly about those who perpetuate this nonsensical adversary between managers and workers everywhere they go, often wearing their repertoire of conflict with management like some kind of accolade.

To assume any given manager is bad because of previous experience, or based upon your own misunderstanding of what a manager does? That is ignorance and prejudice, which is your cross to bear.

"Managers" (the collective/stereotype) don't deserve any resentment. An individual manager that is disruptive and/or a drain on the team's productivity then sure, there is a valid grievance.

Consider that you may be making messes that you are unaware of, and that layers above you may be cleaning up all the time. The "bottom of the pyramid" is not all knowing and a reservoir of wisdom.

Look, I'm just saying it how I've seen it.

When I create messes I get fired.

When I fix messes my boss gets promoted.

This has been the case anywhere I've gone. It is the reality most places I think. Companies that operate differently are the exception.

While I agree that managing is a different skill set (have switched between the roles several times in my career) the problem with focusing on "it is a different skill set" is that it allows mediocre managers to get in who have neither a clue about the product nor about real life software processes but e.g. are great "agile master"s or have a sales background. A lot also depends on the nature of the project - some are more tangible and some other are very technical.

We need people who know where we want to end up, can recognize problems, understand dependencies, can remove hurdles, can provide resources, can communicate, make sound and stable decisions, motivate and plan. Some of these skills are mandatory in a developer but there are quite a number of managers who have a surprising lack of ability to recognize dependencies, mentally juggle dependencies, plan and making stable decisions. And when they are coming from a pure "agile master" factory they may even not be able to communicate and focus on a product goal.

> You are a team, so work together.

I agree but there are cases where managers are such a bad fit that exchanging them is the only option. Two days ago I put out feelers to see whether others thought our project manager was in over his head and we needed to escalate it. Working as a team together was not really an option as we as a team would have to do all the managers work, deal with the overhead he was creating and still had key questions undecided. Yesterday I learned the manager is quitting which is good for everyone, clearly he was not comfortable in his role and had looked for alternatives. And no, there was no animosity from the team and he had a lot of help when he started. A nice guy but not a fit.

This is a great comment, and it helps reveal to us why there are approximately zero good managers.

Imagine a job advertisement:

Position available for (Software Development, but any industry really) Project Manager.

Hard requirements:

• Take ownership • Delegate • Know where we want to end up • Recognise problems • Understand dependencies • Remove hurdles • Provide resources by identify bottlenecks and resource constraints and remove them • Be able to communicate to the team collectively and each member individually to a high level • Make sound and stable decisions • Motivate the team • Do all of these things well above average level • Not just this project and this team, but also the next project and when the team gets shuffled around from time to time

There are approximately zero people who can do all of this on a consistent basis. Maybe one in a million can do some of it well some of the time, perhaps. Maybe.

If you have a manager who is simply a reasonable sort of person, though they may be lacking everything else, I strongly urge you to do everything you can to keep that person where they are. If you don't mind tolerating them, you're on to good thing, because there's a fair chance ousting them will result in your team finding the next person is much much worse.

Yeah, but we do have an awful lot of middle managers, who know very little about software.

Consider e.g., https://en.wikipedia.org/wiki/List_of_current_Premier_League... except for one or two, all managers are former players. Why? We all know something about that industry at large.

My theory is that when you are competing on equal terms you cannot afford managers that are not part of the game.

Most managers climb the corporate ladder by leaving the rubble behind for others to deal with. They usually never learned to actually solve problems, and just scale the same tactics organisation-wide. This creates a culture of helplessness and shifts problems downwards. So they add processes to "manage" problems they themselves are unable to solve! The processes are just a cover for depending on local heroes and informal tribal gatekeeping, though. And so it goes on and on.

You usually hear in such orgs, that they are like family, and in most cases you don't get hired unless someone knows you.

Very underrated comment. The more nepotisitic/tribal an org is, the worse this gets. Everyone's just pushing the problems below.

The only way around this for devs is to say No to solving their problems and letting management deal with the fallout (loss of customers/revenue)

Yes, very good comment; pity to those of who have lived it. I am living it now! It's kind of fascinating really, to see the coping mechanisms in a dying company. The people on the lower rungs seeming to go along with the same charade over and over, going through the motions. Waiting for another storm to pass, to get home to their families at the end of the day.

My current manager, who is one of the best I have ever had, used to be dev and rewrote a lot of our systems so they were better organized.

I think your comment explains at least one aspect of what makes him a good manager.

Can you tell us more about what they do well? I’m a dev who has often been encouraged to consider management but I’ve scared of the Peter Principle. I’m keen to learn from good examples.

If you're being encouraged to take up management, then they've probably already identified that you're already doing some of the right things.

I hate it when I promote a team lead, and they change what they've been doing. I promoted because they were already doing the job.

That’s good advice, thank you.

But dont forget, Bezos is a business guy. Here his original idea: https://www.youtube.com/watch?v=rWRbTnE1PEM

That's a good interview, kind of like the early interviews with Gates when his enthusiasm for the tech was really shining through. Its great to hear Bezos talk about creating value for the customer, something that I feel is to a degree lacking in some of the bigger startups we see these days.

> But it actually doesn't work with software engineers as well as it could.

Part of the reason is that relatively small details have organization-wide impacts. A handful of services might be under-resourced and overdue to drop calls to legacy APIs... That causes ongoing effort to maintain those APIs, the outdated technology they depend on, ad infinitum. Entire migrations can grind to a halt. Engineer productivity could be cut in half. Gaping security holes can be unfixed.

Top-down solutions to those problems ("Here's budget. Fix it!") don't necessarily help as solving the systemic problems can require technical analysis to fully map from strategic needs to particular patches to particular projects.

The people that understand systemic technology impact and the people who understand systemic cost and value need healthy and active lines of communication. Passing status messages up, down, and across the chain of command only gets you so far.

It's the idea that money/technology can fix a people/process problem. I see it all the time. It takes many forms:

If we could just find the right magic tool then all our problems would be solved! Step 1 is build automation, step 2 is define the process! What we need to fix this broken process is more people. These two teams have different goals/OKRs so they have trouble getting along, let's fix it with technology

Technology and money are great accelerators but if you don't have a process that could be performed manually with enough people then technology is just going to make you do the wrong thing faster.

There's this weird notion among directors, VPs and svps that any problem can be fixed with staffing. It just needs more staffing, no biggie. They just can't grasp that it could be done by motivation of existing engineers, lesser micromanagement and more inspiration.

When you have a hammer, everything looks like a nail.

Too much autonomy is too much of a good thing. You end up with 5 "send a email" microservices, multiple design systems, etc. People won't bother to look outside of there team's scope to see if anyone else in the company has solved a similar problem. Or without a culture of external contributions, people will make their own versions of things that are 90% identical to an existing team's service.

This describes the org I’m in right now. The upper management (all former engineers, several ex-FAANG) are not only supportive but have explicitly reaffirmed that duplication of that sort doesn’t matter: every team must be as autonomous as possible even if it leads to a high degree of overlap.

And it’s already biting us. There are at least two issues I’m aware of that are a direct result of this policy which are very bad. When they come to light the company’s reputation (and share price) will very likely be harmed.

Too much autonomy can be too much of a good thing, but this is not universal, and when it turns out to be a bad thing, that says more about the group who has been given the autonomy than it does about autonomy itself.

A sibling comment talks about trust/skill, and these are factors that are more important than just focusing on autonomy as a stand-alone concept.

Open Source projects show both ends of this spectrum, with absolute autonomy yielding both amazing and mediocre results.

> Works with finance, works with marketing, works with IT support, and should work with engineering as well... right?

I think there is a variation of Gell-Mann's amnesia effect but for management. Everybody sees how their own manager/boss is mostly wrong and useless. However, when we deal with somebody else, for example as customers, we somehow conveniently forget that fact and we continue to believe that managers need to exist.

> I have a theory on why we're seeing so much "bad management" for software engineers: most leaders at workplaces have not been engineers themselves at a company with a great engineering culture (I wrote about what I think this means [1]: it's all the high-growth small and large tech companies we know)

I think that's part of it, but the bigger reason is that the management talent pool is too small to meet the industry need. The same is true of engineers as well.

There's little apprenticeship, little mentorship, and little experience is gained seeing things done well. Capable people are being shoved aggressively and prematurely into decision-making roles (whether in management or engineering) before they've developed the skills and perspective necessary to do the job well. No question, talent scarcity makes for lucrative pay and easy mobility for the average tech professional. But quality suffers, nonetheless.

Fred Brooks had it right oh so many years ago. Communication is an exponential cost, so the more skills that you can give to a single person, the more they can do.

But it's even better than that, as every time communication occurs you are playing a game of telephone with translation errors. The essential complexity might be very easy, but when you need to translate that problem from users to project managers to architect to developer(and I'm sure many teams have many more layers than this) the complexity grows out of control.

I thought about this topic when the StackOverflow blog on Scrum ruining great engineers came out[0].

Imagine you have a chart where the x-axis is trust, and the y-axis is skill. x-axis at the far left is management focused. x-axis all the way to the right is developer focused. x-axis in the middle is mutual trust. bottom y-axis is no skill, top y-axis is extremely skilled.

Now let's look at some of the spaces this chart provides. If we start at the top right, we have Professors. They have a lot of skill and have tenure to be able to do what they want. On the bottom right, I imagine something like Adam Sandler's character from Billy Madison(1995), a son of a billionaire who wasted his life and had no productivity.

On the bottom left side we have government contractors or outsourced developers. They do the work they are told to do. In this spot Scrum can be a reasonable way to filter between the very least skilled workers and someone who is doing decent work. But by applying Scrum, you are naturally holding the management axis to the left.

The Top Left doesn't exist. The developer leaves for some place better.

So now we can talk about the middle. At the top of the middle we have Skunkworks projects. And as we can see, this balance between management and development can yield incredible results, if the developers have the skill to back it up.

So we can see there is a careful balance, most developers are probably somewhere in the middle "strike zone", and by applying Scrum to a developer who is highly skilled you are handi-capping them, and if you apply to much force they leave for better pastures.

When you have developers in this strike zone, give them advice, allow them to learn, but let them make their own decisions.[1]

[0]: https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-...

[1]: https://jessitron.com/2021/05/26/a-high-resilience-org-chart...

I think it's more than lack of experience with great engineering culture. I think bad management is actively incentivized by a spandrel of how our organizations fit together. There's a mismatch between the time it takes to yield measurable impacts and the time scale on which rewards accrue to individuals. Because large and complex projects take time, and are hard to measure, and it's hard to attribute the portion of success or failure to an individual, when three quarters in a manager is promoted to some new position which the CEO thinks desperately needs to be filled, it's off of the narratives the manager has been able to produce, not the actual impact. The tools for making a narrative of competence and success are understandable, punchy process and organizational improvements, cherry-picked measures that don't really mean anything, meetings, 1:1s.

So, when a sequence of directors each wants to "refresh" how the planning and prioritization process works, or reintroduce OKRs because they believe that what the org was doing up until that point was an incorrect, or champion some new set of Principles that obligates all existing projects to re-justify their existence in new terms, or move all project management into a new tool, they're creating a narrative of leadership. And they can tell a good story well before the non-impacts become visible, and without having to examine or deeply understand the technical aspects of what it is they're managing.

In some cases, this can be a modest productivity tax to the impacted teams. Some number of weeks from every quarter gets dedicated to servicing the most recent process changes etc. But sometimes it's actively harmful (creating separate silos for functions that really need to be in close coordination, etc).

I think there is another powerful force that explains why so many managers are perceived as bad: in most companies, career growth for managers means moving up, and moving up is at best uncorrelated with managing your team well and with respect. I would actually go as far as it is negatively correlated in some cases.

A lot of stuff I see about what an EM should do, on places like leaddev, in the well known eng. management books, those are all great. They cover most of what I enjoy doing as an engineering manager. But they also means shit for moving up in many (most ?) larger orgs.

Part of the issue is that as the company grows in size, it becomes essentially impossible to correlate company success with certain teams. The complexity becomes such as people above you cannot possibly understand properly what's happening there. At this point, it starts to become all about managing up and lateraly, which takes an awful lot of time. People above you even has less mental space than you on what's happening in your org. So one trick that many senior managers will us, in engineering and otherwise, is to be behind some big salient initiatives. It is kind of a marketing trick. Do something visible that be associated to you.

And then unfortunately the trick often becomes to leave before people can understand the mess that creates. But I think it is important to understand the incentive behind that: it is not because people are evil or stupid. It is just inherent to most large organizations. Very very few large orgs has been able to prevent this behavior.

The key is finding the right mix between autonomy and direction. You really need both cause there is a need for direction and organization esp as the group grows beyond team size.

But most problems aren’t a result of following the correct “science” of management, itself a dubious proposition, but can be traced back to what’s really important. You have to have the right people in the building to start with.

Having a manager who is also an engineer doesn't help that much. It's like seeing a movie about split personalities. They can be a good engineer and yet when they switch to management mode, they commit the exact same idiocy as any other crappy manager. There are good managers too, but an engineering background doesn't seem to automatically produce them. I don't know if it even helps.

I agree with your theory. I find the company I work at really interesting, I think it had the opportunity to have engineers as managers, but over time, more and more engineers decided not to become managers, and as that happened, more managers were hired from outside sources, which tended to be non-engineering managers (or managers who hadn't done actual software work for decades). I would not be surprised if this is a common issue.

Apple takes the approach of essentially forcing their best engineers to become managers.

[0] https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...

> In most companies, management is actually to blame for deliberately isolating engineers from discovering the customer's needs. News flash! Developers actually like the idea of figuring out and fulfilling needs with epic software solutions and are fairly neutral-to-downright-annoyed at spending their time creating something that no customer wants.

I agree with the first statement but disagree with the second. Yes, management is often at fault for not involving or engaging developers. That said, I've seen many really solid developers be motivated by solving complex technical challenges instead of work that actually creates business/product value. Of course, it's management's responsibility to harness that energy and align it with creating value... But just saying, a lot of really smart people are driven more by intellectual challenges than product impact.

I can say that this is true for me. I like helping people but I get my motivation from feeling that I have solved a problem well. Maybe it is the nature of the kind of software I tend to write, but I'm not all that interested in whether it is used by millions of people or purportedly helps a bunch of people. That's nice, it's just too far removed from the work for me to be motivated by it. The bonus is that I also don't have an issue if something I've worked on is scrapped for whatever reason, and I know that that is something that some people have a hard time coping with.

Technical challenges that are actuslly used beat out technical challenges that are just for fun though.

That depends on the engineer. There are absolutely people who aren't motivated by impact whatsoever.

And their coworkers will be able to find nice complex isolated problems for them to solve. That isn’t a problem in for the group in general, because that is like finding a really nice tool that you can use however you like. And most any domain can use brilliant solutions, if you think about it for a few days.

> That said, I've seen many really solid developers be motivated by solving complex technical challenges instead of work that actually creates business/product value.

Complex technical challenges create value for the developer, as it's fun solving problems like that. If management doesn't communicate the end-user's needs/wants and how the product helps them, even valuable work can feel like pushing up Sisyphus's boulder, so working on fun stuff at least creates value for you rather than work that appears to be purely for the leadership's vanity.

For people that are in software because they love it, rather than for fame and fortune, in fact love the fact that the maths side of your brain can make stuff happen for people. For technical challenges, nothing beats algebraic topology or QFT, but with software you can make stuff that is real, and amaze and deight your family. The problem is management’s persistent blindness to the reality of their technology and development technology. The non-technical folk will hear “we can’t add this new feature without touching dozens of risk places in the code” and not understand the fact that this is extremely risk and is an urgent problem. they seem to think, hire someone that can remember the dozens of places to change” and make for awesome failure analyses where 36 call points where changed but the 37th was missed and . . . Etc.

If you think the software you are making is useless, you should find a different position. Life is short, and it’s thrilling to be responsible for software that people use and enjoy.

Developers have opportunities to improve management by increasing management-visible headlines about user goals, and decreasing management-visible headlines about implementation details such as UI, WBS, wireframes, flowcharts, and tech.

Try this thought experiment: Imagine you have team task list with headlines such as "Add red button to top of home page". Imagine rewriting the headlines such as "Customer wants to contact us" and similar kinds of user stories.

When managers continually see headlines with user emphasis, and do not see headlines with implementation details, then management improves and developer autonomy improves, because both groups are looking toward users.

It turns out focus on user stories can help significantly, even more than some developers might intuit. Look at your task board headlines and the opening paragraphs of your management-visible writing-- can you improve your writing to emphasize user goals?

This is such a good point, Its a bit like how developers neglect to write documentation, developers often neglenct to communicate effectively or create 'communication artefacts' like diagrams, etc that make their work more comprehensible

Interesting that developers are expected to do all this other ancillary work that is the remit of other professions.

How often do we expect the technical writers, marketing, sales, management, etc to also do their share of writing the code?

I too would like to do lots less work and have other professions help out and be available for the scapegoat game when it goes wrong. Documentation not up to par, blame developers. Marketing failed to achieve goals, ...

I think the person doing much of the communication has to be the developer, noone knows what's happening in hid system better than he does.

But that must be a separate activity pruoritised and with time allocated. Lawyers have to do many anciliary activities, but they are given time to update their qualifications, etc by their employer

Or... managers could do this translation themselves, by first learning how to do the technical work. My personal gripe is how much we have to chew and digest things for the non-technical people. The managers that know how to solve the problem technically would not ask this as much, but maybe then they would also be writing code as that is always needed.

I feel like managers that can't understand the technical part are the one to ask for this "translation", and because of that the technical people get a significant overhead in work, and because of that more people are needed to do the work, and that in turn creates more need for more managers. It's like a vicious cycle that could be mitigated if everyone knew how to do the technical part, and for this to happen I think companies should start making programmers the managers as much as possible, but I guess that won't be happening anytime soon (but I'm sure it will in the future once programming becomes widespread enough).

After 12 years of software development, I've come to the conclusion that software managers are not needed. From what I can tell, they have meetings, try to get people to work more, and approve time off.

The best team I've been on didn't have a manager. The lead developer handled communication with the IT Director about project status; and that wasn't very often.

We had no meetings, or KPI goals, and other such nonsense. That is, until the company was bought. Everything changed after that and traditional management took over. Most people left within a year.

The best teams I’ve been in have been the ones where there was no filter between the developer and the client. The more filters, the harder everything becomes.

Co-located with your users for the win. If there's such a thing as a silver bullet in this space this is it.

Yeh Back in 94 I and another developer got flown up to Edinburg and delivered using RAD/DSDM in a month what a another traditional team said would take 2 years.

One of the other ideas at the times was a custom BT version of HTML - that got stamped on very had by the Labs thank god.

Perhaps, but that doesn't scale well.

My previous role, I served 100s of clients, each with 1000s of end-users. If those users had direct access to my development team (5 devs, 2 test engineers, 1 BA) they'd spend the entire day fielding requests and get nothing done.

So, to avoid that, you add a product management team. And an SDM, who acts an umbrella over the dev team to prevent shit raining down on them from tech support, product management, sales, etc.

I suppose that's the key - if an SDM doesn't see themselves as a shit umbrella, they aren't doing their job. That's not their only role, but from the developers' perspective, it's perhaps the most important.

Edit - the team did interact with customers via various channels, but it was more controlled than "unfiltered". We had a forum where both sides could communicate (though the BA typically did the lion's share of that work from our end). We also had periodic beta review meetings with select customers. And of course, when tech support issues got to our level, we were often on the phone, VPNed into their systems, etc. But, between the BA and I, we triaged most inbound communication, and there was zero expectation a developer would respond unless specifically asked by me or BA (though they were free to do so if they wanted - most preferred not to do so).

I know agile and scrum and so on carry a lot of baggage these days but what you're describing is Less Agile. You flatten the org back out, create product teams that pull from a single common backlog and developers interface directly with their customers. That's not even the most controversial part! You also do away with pay tied to individual goals: everyone succeeds or fails together and are paid the same way.

https://less.works/less/framework/index

You get what you measure and if you track performance and features individually you get less collaboration and gaming of the points.

I liked this until everyone got paid the same. That's the fastest way to lose all of the people who can get more elsewhere. And it's not going to be the laggards who jump ship...

Right? I did mention it's controversial.

One factor I think is span of control. If the director you mentioned starts getting project statuses from 15+ teams then the director might not scale. The director will not be able to scale for things like appraisals, burning issues, hiring.

Sounds like your experience is with small organisations. Management is required in large enterprises.

Exactly. Once the number of stakeholders crosses a certain threshold, your lead developer will be so busy with them that they will essentially just become the manager because they wouldn't have any time to code.

What if the company hires someone dedicated for this role who... does not report to the lead developer but works with them?

Soooo...a manager?

Well, maybe you can call it manager. But it would be a "project manager" and no one would report to them - at least that is what I meant with the alternative that I suggested.

I absolutely hate useless management layers and unnecessary ceremonies but I've been on teams with no hierarchy and it was Lord of the fly until the most power hungry developers became the effective lead/manager.

I’ve been in the startup scenario where the most power-hungry developers successfully rebelled against the CTO and had him resign; “Lord of the Flies” is exactly how I described the maturity-vacuum period that followed.

I have something like PTSD from a similar situation.

My favorite cinematic metaphor for Bad Management is the night-bridge scene in Apocalypse Now…

I was on such team too. There was cycle of power hungry leader, revolution, everyone for himself which special kind of dysfunction, someone else takes power again, revolution, everyone for himself which special kind of dysfunction, ... .

Nature abhors a vacuum (c) We are social animals and there is no such thing as "all people are equal" or "flat organization". There is always a structure, only it can be explicit and regulated (and usually more efficient and easy to navigate due to explicit rules), or it can be implicit (aka Wild West).

We're going through this at the moment, company got bought, original CTO & IT Director left. Now the new bobble-heads try and introduce nonsense processes, much to the dismay of everyone already working productively.

I think the problem in large part is that most "managers" are brought in later on and then feel they have to go above and beyond to justify their existence/position/salary. In the end they do things just to be able to talk about all the amazing things they are doing and how their shiny new processes are helping everyone so much.

I have yet to see a successful founder introduce nonsense simply for the sake of it.

There are some jobs with a goldilocks element. Such that the job can be done just right, but it is easy to overdo or underdo it. Management is the most common job in this scenario, and we tend to really notice when it is overdone. Toes get stepped on, trust is not felt, everyone is unhappy. Unfortunately it many of the people that get into management try and push themselves to achieve as much as possible, which is what leads them to overdo it and make their teams unhappy.

After 17 years of development and 8 years of management I've come to the conclusion that developers are delusional about the relative importance of their role. I shall be the first to admit that - I used to be one myself.

Your run of the mile non-technical manager sure is not very good at understanding the intricate complexity of all the moving parts of creating software.

Developers on the other hand appears blind to the fact that they play only a minor role in the bigger picture. While technology is difficult it pales in comparison to orchestrating people across sales, strategy, business transformation, creative, development, QA, operations and infrastructure.

That's just the horizontal alignment. In a single entity. In a single timezone. With a single vendor. A scenario which never happens because in real life you have at least 3 levels of technical management, multiple divisions/departments involved, spread across continents and multiple vendors participating.

You need competent people to align, coordinate, communicate and pick up the stuff which falls through the cracks. Developers are not good at this work.

You need a manager. And of course they must be competent.

EDIT: I don't actually think developers are delusional. I worded the phrase to mirror the absolutism of the statement "I've come to the conclusion that software managers are not needed" which is just plain silly.

This is all true, but reads more like a PM-type role, which is absolutely critical.

I understood GP's point as more directed towards "pure Eng. manager" type positions, often when there's also already a PM present. And I've witnessed first hand how his criticism rings true in that case.

Yeah technical pm or a pm that understands the business deeply are critical.

This is true but I've also seen developers add ten percent more revenue to an organization on a rewrite of an existing billing system and it wasn't due to any insights from management. It was many conversations with key business users and developers. Management knew enough to step back and loosen the reigns. Everyone can make a huge difference on a project, and a team of non hero's that just care about learning the business and the craft can deliver greatness.

This! So much.

Sometimes you can plan for success/heroic actions (in the good way) but often it happens by accident.

The right person digging into a weird problem they encountered, two people sitting together to review a design or someone doing a firmware update that fixes a bug in the RAID controller giving you double the IOps...

I have tons of anecdotes from colleagues who did some unplanned work just because they talked with someone else and that work then turned out to have massive positive impact. The results are lauded but it wasn't even clear when the "little" project started that it would actually be a massive boon.

At a prior job (some website selling hotels online) I was responsible for the project that ended up giving the whole fleet a 25% capacity boost. Instead of 2000 machines we only bought 1500 next quarter. If we calculate that in perpetuity my project was a massive success. Millions of EUR saved since 2011.

The project initially started out as "tons of people tried building a decent perl RPM but couldn't get it to work, could you have a look?". The guy originally tasked with it was busy fixing a broken LDAP server. So I built some RPMs, wrote a bit of tooling around it and we ended up with a Perl environment separate from the system perl which was great because the business was nearly exclusively running on Perl 5.8.9. At that point I looked into using that to get us off CentOS4. With the help of two colleagues we got a CentOS5 environment running and could migrate to a x86_64 environment.

That migration than gave us a 25% capacity boost and happiness ensued all around. The OS upgrade wasn't part of the original project scope, we just went with it because it made sense and management understood that it's a good idea.

Then make sure developers are deeply aware of all the concerns you listed. A large part of why developers think they are the center of the world is because they are meticulously isolated from said world. This is exactly what the article addresses as one of the main concerns.

The comment you replied to gestures at but doesn't outright say this, but I think you have a good point.

I genuinely think that many engineering managers see their most important skill as "getting engineers to do things for reasons they don't understand".

That isolation is often as much self-imposed as not. While the GP may have been a bit aggressive in his/her characterization of it, I agree with the general thrust that developers tend to be both narrowly focused on their own technical work and prone to inflation of its worth.

> prone to inflation of its worth

This issue is not limited to developers.

Of course it isn't: most individuals tend to inflate their contributions' importance. There are matters of degree, though. My experience is that developers tend to overestimate more often and by larger amounts.

As a developer, I’ve noticed a pattern: devs complain about too many meetings -> devs are left alone (aka isolated) -> devs complain about being left out of decision making process/chain of comm.

I agree. And then if the same devs have reduced meetings, are included in more cross dept initiatives, and included in decision making, they end up upset that their freedom is suddenly gone. Its not even just devs this is a common thing from call center reps to the top of the broken pyramid. Everyone is the linchpin in their perceived contribution to the world.

Meetings are to align people. Complaining about too many of them can be a sign of many different things, but one of the biggest is needing to align with so many people to get anything done.

If you hold the same number of meetings but stop inviting some stakeholders, those stakeholders are going to be upset. If instead you remove some meetings from the process entirely, by e.g. not requiring multiple design reviews for internal products, or by not letting platform teams force everyone else to use their software, or by letting teams spin up their own low capacity services without meeting with ops, or anything else that lowers the complexity of getting work done, then your team will be happy and the previous gatekeepers will be complaining.

It's a good observation. IME you can't be in all the meetings you need to be in to obtain alignment on complex problems in a changing environment AND be effective in writing code, very generally speaking. My most frustrating career points have been when I was a tech lead, doing a bit of both. Being more purely IC or purely managerial, it is much easier to get important work done.

Its also a grass is geener issue. Work is generally more enjoyable as an IC, you get to focus and write code. Until you end up having to build something really stupid, and you want more control over product direction. Then you end up as manager, and long for the simplicity of being able to focus and write code. At least that's how I've felt at times.

Both of those problems can be solved to a degree with more efficient communication. Async communication channels like email and other messaging are great at not wasting peoples time while keeping everyone in the loop who needs to be, properly used. Sometimes I think phpbb style forums would work better than the usual tools. But overall I find people don't experiment enough or put enough effort into optimizing communication and it leads to this false dichotomy of either isolation or time wasting. There's a middle ground of optional participation where you communicate widely but don't force peoples attention, and that's how you can reduce meetings without reducing valuable communication. You can always put a time limit on feedback if needed, mark some things important... Just find what works!

My answer was intentionally phrased to mirror the absolutism of the GP. A large part of my time is spent explaining why certain process is in place or why we cannot get a license for this or that tool or why one needs to be considerate of the other crafts.

> developers are delusional

> Developers .. appears blind to the fact that they play only a minor role in the bigger picture.

> Developers are not good at this work.

Developers aren't some special creatures with one dimensional fixed mindset. They can do whatever that needs to be done.

This is kind of silly stereotyping precisely why makes developers hate managers. I hate managers who think of their team as mere code monkeys that are "not good at" some mythical management work.

I am a manager myself but I never diminish role of my team members as "minor players", "not good at work" ect. They are my peers and partners who are equally as "major players" as anyone else.

but in the end, you decide who gets promoted or not, you decide who has to put the "extra effort" to satisfy whoever you work for. So of course everyone is a major player, it's your best interest.

but you're also the one who gets the time to see the big picture and hopefully realize that, yes, the development side of a project, while the most fundamental, is also just one of the part. The other being : handling customer expectations, making sure the budget use can be explained, making sure people stay happy even when confronted to "absurd" customer's request, making sure to understand the project ecosystem to make sure you get the right customer contact person in front of your team, making sure the one dev with a broken back gets a proper chair, making sure good project are rewarded, you make sure HR's department craziness don't alienate your devs, you-f*g-name-it (been there, done that, got the tshirt : I've been in dev, business consulting and management :-))

>the development side of a project, while the most fundamental

There's an entire world of industries in which software is a 'nice-to-have' enabler of various levels of business logic, not the product itself.

The assumption that development is the fundamental key to all projects is, I'd imagine, the 'delusion' referenced earlier.

Yeah, I work in an industry where software enables things, so it is central. But even in my industry (business apps), we could just go on with pen and paper like before. So programs are not "absolutely fundamental" but in the 21th century, well, they are :-)

But I can admit it's not like that everywhere, sure. But I've yet to see industries where people pay programmers to work on IT project which are not fundamental in a way or another or in the process of becoming fundamental. The point is when programs get deployed, they usually transform (and hopefully improve) a situation. Once the transformation is accomplished, the program becomes fundamental...

My reply was worded to mirror "...I've come to the conclusion that software managers are not needed." which is obviously nonsense.

"Developers aren't some special creatures with one dimensional fixed mindset. They can do whatever that needs to be done."

Yes, but it is ok to generalize in a broad discussion like this one. Otherwise we can have no meaningful conversation. In general managers do not understand developers. And in general developers do not understand management. Those that are good have been exposed to both sides.

I never diminish anyone but it is naive to think that everyone contributes equally.

> which is obviously nonsense.

I think I've observed enough of this sentiment over the years, from some very smart and successful people, to come to the conclusion that, if it is nonsense, it is non-obvious.

> I never diminish anyone

Perhaps you never _intend_ to diminish anyone, but to some, your statements may reasonably appear to be diminishing some cohort.

I definitely agree that (in general) devs and mgmt do not understand one another.

I think this is bc one practices abstraction while the other practices persuasion.

I see these two forces as equal and opposite. A yin and yang kind of thing.

It appears that the best orgs have these two things in balance.

How are abstraction and persuasion "equal and opposite"? They seem to be completely orthogonal activities.

My idea is that the skills required to build things are at odds with the traits/skills required to persuade.

My cherry picked list:

Building: honesty, introversion, reason Selling: charisma, extroversion, empathy

> They are my peers and partners who are equally as "major players" as anyone else.

I love this. The best teams I've been a part of are those that had a mutual respect for everyone else's work. I was an engineer on those teams, and thank god for the product manager, tech lead, design work, ux researchers, etc. Things work so much better when there's a real culture of "we're all in this together, and we all have important roles to play".

You understand, that company goal is not to "build a good product", even less to "write a good code", it's to increase a company value (in the sense that "good code" is orthogonal to the goal)? It might be unfortunate for developers, but quite often (almost always from what I've seen) developers' role _is_ minor here. Not in derogatory sense, just money don't come from writing code, they come from sales. Also no, not everybody can be a good manager, and not everybody can be a good developer, as those two roles require different mindsets and different training, so very few people can effectively do either (and not at the same time). So a good developer normally can't do "whatever needs to be done". You don't want a developer to do your surgery, do you?

I agree, you need a manager, but through my limited experience I feel as though the issue is developers are mostly detached from the buisness end of things. When things go wrong or some issue occurs I've always had managers step in to aid from the buisness side. You almost need a manager who has developer experience like yourself to make for a good manager. I suppose even a manager who is able to understand the general overview of what the developers are doing would be good.

Basically it seems the average manager in buisness would be a bad fit to manage developers. overall a manager is still needed for sure. I guess its the same everywhere though a bad manager vs a good manager makes a world of difference.

It sounds like you've gone from one extreme to another. None of the things you mention pale in comparison to software engineering at all. They are all solvable problems that many people can do. Sometime they are difficult, often they are not. Managers are certainly not useless and do work for certain types of organizations. They are not always needed though. Believe it or not there are people capable of managing and programming at the same time. You seem to be one of them so your view point is very strange.

No, I've actually mostly worked in well balanced places. It is my experience that technology is the lesser issue and the one with the smallest impact. That's not to diminish the highly skilled developers - the work just have less impact that we seem to believe.

I do not believe in self organizing teams. I have not seem them work. Without direction the team will fumble until someone assumes control. I have also not seen many happy in such an environment.

The opposite is strict top-down control, such as what is often described and lamented on HN, is equally bad. No one wants to work under a dictator.

There's a balance to be struck between authority and autonomy.

Inexperienced developers can be delusional especially if they see their role as 100% banging out JIRA tickets

The issue with this argument is that a significant part of the "bigger picture" is artificial bloat which emerges from the fact of having layers of management. Managers spend much time actually managing themselves. It's of course not all black or white.

I don't think it's an issue with my argument but I do think the difficulty of grasping the bigger picture is a major issue.

It can be reluctance to understand why you're doing what you're doing. It can also be because no one cares to explain it to you. Most of the time it's probably between those two extremes.

And yes some times it's bloat. But rarely all of it. I don't have a solution to this.

This reads almost like a tautology.

I'm reading: "You need a manager to coordinate a deeply hierarchical and separated structure with production at the bottom and the clients at the outside."

I mean no disrespect, but from my perspective I see a deeper problem here that is being patched over by exceptional people like yourself. Shouldn't the creators and clients have a major, high impact role and the coordinators a supporting role in terms of decision making?

To make an exaggerated joke it looks a bit like a dictator complaining about all their responsibilities and the hard decisions they have to make. Well maybe they shouldn't even be in that position to begin with.

And yes I've seen the diagrams and the theory behind this. But I've become more and more suspicious of bureaucracy and process that tries to fight the symptoms of lack of trust and human connection.

Ha - yes, you're right it sounds like a tautology. I worded my answer to reflect the absolute statement of no manager is ever needed.

"Shouldn't the creators and clients have a major, high impact role and the coordinators a supporting role in terms of decision making?"

No. The creators usually answer "how to do it". The more important question is "what to do". Both groups are important but doing the right thing is more important than how you do it.

>And yes I've seen the diagrams and the theory behind this. But I've become more and more suspicious of bureaucracy and process that tries to fight the symptoms of lack of trust and human connection.

This resonates but what I have seen is when you engage a company that has this model you have to emulate their model to fit within their needs, then you get infected with it.

As a CEO and long time developer before then... its complicated. High performance teams are killed by managers unless they stay out of the way and then whats the point right? Managers are great for managing clients, but not devs.

Low performance, bare minimum devs, sure need reminding and pro-ding to get anything done... yes, you need managers to babysit.

Companies with heavy management usually have mediocre at best devs and little to no innovation. They have great sales and support - this keeps them alive.

Captain obvious here - there is no one size fits all. Do what makes sense at your org and take home a paycheck or leave and start your own business - there has never been a better time!

oh, and any given dev can switch from high performance to bare minimum depending on the project, week of the month, what they ate for dinner last night, etc.

Same could be said for a manager.. or a manager that gets bad devs or devs that get a bad manager. This is the value of a hands-on ceo that does not have their head in the sand.

'High Performance Devs' I've found tend to build the things they want to build.

I've yet to meet the kind of superstar dev who is also superstar market and customer oriented.

That can be challenging as a lot of important innovation doesn't come from customer feedback and you need talented people to do those things as well.

This is very true. Most shops have an R&D team for long term innovation and other devs like myself who love customer feedback and want to deliver solutions now.

I have not heard this about "most shops", in fact I have never worked in an org with a functioning software R&D team (unless you count enterprise architects choosing vendors).

No but I've seen similar dynamics play out at most companies. Broadly, "product teams" focus on customer feedback and delivering value to customers, at the expense of technical debt and lots of fickle requests. "Infrastructure" teams are heavily insulated from customers and deal with a more long-term roadmap and fewer changing requirements.

Product and Engineering need to be peers in this regard.

I think Spolsky said it best about the dynamic between managers, product and developers

https://youtu.be/A3-ijSmDQ3c?t=983

just an observation: if you moved from developer to CEO without significant time as a Dev or Eng manager you have very different skills and focus. CEOs of all but the smallest companies are playing checkers; Dev Managers play chess. This isn't some sort of insult; we need to focus on individuals with distinct skill sets and characteristics. CEOs can't and shouldn't be concerned with this level of detail.

It's also uncharitable to split teams into either high-performance special ops teams vs. mediocre, low skill / low potential teams. Two trends make this distinction meaningless: GROWTH and SCALE. If these don't apply then you can totally let the team self-manage. FANG companies typically have all those rockstars you're looking for and multiple levels of technical management.

Google even tried to go without managers. They backpedaled pretty quickly. https://www.inc.com/scott-mautz/google-tried-to-prove-manage...

Even if CEOs "can't and shouldn't be concerned with [individuals with distinct skill sets and characters]" (not a point I'm conceding, what makes you think a CEO's job is "checkers" compared to the chess of a Dev Manager who is realistically 2-4 levels below them in the organization?

'High performance teams are killed by managers unless they stay out of the way and then whats the point right'

The point is two-fold. First, creation and maintenance of a high performance team as the company grows is worth someone focusing on, not just hoping it happens organically (sometimes people, especially new hires, need to know "yes. You are really free to make this decision yourself. I'll back you on it." Likewise, sometimes people doing good work need someone who can spend the time to highlight the value of it to the rest of the business, to effect a promotion). Second, ensuring other needs of the business inform that high performance team, WITHOUT interrupting it, are also worth focusing on.

These are both true regardless of the environment, but become bigger needs the larger the company is.

"creation and maintenance of a high performance team"

Managers do this? right, right. I would say managers at best dont mess it up. Creation and maintenance of high performance team comes from within. The surrounding support certainly helps, but to say a manager creates and maintains this is a bit of a stretch.

"ensuring other needs of the business inform that high performance team"

I have found if it needs to be known or communicated it will happen. High performance teams are not just coders (another fail from managers) they are intelligent people who can read and write emails and know how to speak to other humans. This may be the stereotype of some hot pocket eating teenager in a closet from the movies but that is certainly not the case in most professional environments.

So for the first, I am explicitly describing managers in an agile, team lead style. But, yes. Managers, first and foremost, hire the team. Ideally from feedback, but ultimately the manager is responsible for the team's formation. But then the manager also has to help smooth out bumps along the way. Having someone objective who can help smooth out disagreements can be HUGE. Likewise someone who can give feedback to individuals; a large personality can be a huge asset to the team, but can also leave others feeling alienated; someone who can help carve out space for those others to speak up, and to help coach the person filling the room how to recognize that and also to carve out space for others, is immensely helpful. And maintenance includes progression, both for individuals and the team; devs are often focused on what they're working on, they're not evaluating how to get their work recognized, and more junior ones often aren't evaluating how to grow themselves. It also includes HR issues; having someone who can do the legwork for your Visa sponsorship, for instance, frees you to do real work. A good manager is basically the team's admin assistant as well.

For the second, of course they are. You have to take the two statements I made together. There is a spectrum; at one end are devs working on what they feel is important, but not knowing they're not working on what the business feels is important. At the other is the business deciding everything the devs do, oftentimes changing priorities every week. Having one person as a middleman there can be immensely helpful. That may look like a manager saying "Hey Bob. Jane has this need; work with her to understand and implement it", and handling everything off to a dev, but the point is that the manager, A. Gave Jane (and everyone else) one person to reach out to initially when it came to their needs of the team, B. Helped determine that Jane's need was a priority against all the other needs, and C. Gave Bob permission to ignore all other incoming requests and direct them back to the manager, to focus on Jane's need. That is not to say Bob is not reading and writing; it IS to say that Bob can benefit from someone keeping him from being interrupted by every person in the business with a need who thinks he might help.

This feels right. I also believe that what people need are LEADERS and not MANAGERS. I'm sure there are plenty of examples of the two on the web.

The challenge I see a lot of managers have is that they look to much at an engineer as a widget and not literal human that is just as capable as the manager (most the time). There are often times no lines between roles and responsibilities and every shop does that slightly different, and not based on some framework they masterly put together, but just something based on how the pieces fell in place with some help from previous experiences.

I just wanted to say also - _most_ engineering managers are not good managers. They were good engineers that are in the unfortunate process of the Peter Principle.

The role of the manager is to ensure the team can get on with their jobs, to celebrate their success and have their back when things don't go according to plan. Unfortunately most manager can't help to start interfering with the team and go for a top down driven management style.

High performance teams are usually created by good management. If you change the management then bad management can easily undo that. My best managers have been deeply technical people with good people skills, an interest in management, and willingness to get out of the way and no longer make the decisions they made when they were a developer. Management is a lot more than babysitting it generally involves a lot of coordination up and down the organization to ensure the team is doing the right work in terms of organizational and customer priorities. Good management can give you what to work on while leaving you to decide the how.

I'd like to make a wild inference and suggest that you and the parent poster are talking straight past each other, because you're drawing your experience from two different business paradigms.

kbmunchkin wrote:

> The lead developer handled communication with the IT Director about project status

The fact that the ultimate person being reported to was the head of IT strongly implies to me that it was an in-house development team working on in-house projects.

Your list,

> orchestrating people across sales, strategy, business transformation, creative, development, QA, operations and infrastructure.

Strongly implies that your experience comes from building consumer products.

Personally, I've spent time working on both successful and unsuccessful projects on both sides of the fence. What I've seen is that the most straightforward way to create a dysfunctional team is to try to take what works from one context, and apply it uncritically to the other. I personally hate working with a dedicated product manager on an in-house project every bit as much as I hate working without a dedicated product manager on consumer-facing stuff.

Nah, we're not talking past each other but we likely come from wildly different backgrounds.

To make a general statement saying managers are not needed is as silly as saying all developers are delusional

Consider that those two statements may be about in the same wheelhouse, but "developers aren't needed" is way, way more rediculous than "managers aren't needed".

> but "developers aren't needed"

No one ever said this though, I'm not sure what the point of bringing it up is.

Strongly agree with this. I've been in situations where my team had no manager, a bad manager, and a great manager. The situation where I had no manager was the worst, by far.

I've found that if you throw a bunch of Alpha Geeks together without constraints you may as well be herding cats. They'll want to work on their individual wishlists of strategic research problems (throw in this new tool! new methodologies I saw at this conference!) with less concern for the unromantic tactics, socialization, and alignment that makes a project succeed.

> developers are delusional about the relative importance of their role

I think it's that developers fail to grasp that they are in the enterprise world. Web development and SaaS has blurred the lines, but at its core it's the same: the product you work on is a tool for another business. It's a bit more sexy because it's not mainframes, cubicles and suites anymore, but in the end the job is the same. And in that setting, the role of a developer is indeed minor in the bigger picture. There are exceptions in R&D, cutting edge projects, or in an early stage startup, but for the vast majority of developers the above is true.

I guess the problem are not managers per se, but non-technical managers. Somehow it is OK to have a pure salesperson / MBA manage engineers, but you would never put a developer in charge of the sales department.

I think many developers (not just coders, but in general technical people who make the actual product, designers, engineers, ...) feel there is an unfair primacy of managers / business people over developers / technical people. This is even reflected in the job descriptions: I hate the term "individual contributor" for example, it implies replacability and that non-ICs (managers) contribute more than one person.

Not every company has "bullshit" managers and for sure some developers are delusional. But these bullshit managers exist, and I believe this happens when you put people who are far away from making the product in charge. If the managers and executives are not intimately familiar with the product and the customers, then the product becomes some interchangable thing that you hustle. This can be disastrous for the work climate but also for the success of the company.

I always wondered if it was possible to build an inverted company organization, where developers/engineers were formally at the head of things, and much of the administrative tasks that management works on were subbed to specialists reporting to the developers.

If you look at a lot of pretty incredible projects that often were finished ahead of schedule or with groundbreaking capability, they often happen to be led by a deeply technical person. e.g. Hoover Dam, the SR-71, etc.

If you look at CEOs of tech companies, I believe a majority of them have an engineering undergrad degree of some form.

I work at a company that operates much like this. I've passed up on more lucrative opportunities in the past because it's such a great place to work as a developer as a result.

Do you think the company holds it’s own in terms of competitiveness vs other companies as well as making a reasonable profit to survive?

Actually, it implies that managers are multiplicative. You -hope- that it's a value > 1.0. I quite like the term individual contributor - it implies you're actually doing work (and that it falls on the rest of the business to make sure you know what work will be valuable).

But, yes. Bullshit managers invariably choose to take empowerment onto themselves, despite a lack of knowledge, and oftentimes without any real responsibility, either (i.e., they don't bear the consequences of their decisions).

So much this.

I even worked at one incredibly toxic organization for a year, before I left, where sales people would literally roam the office, grab a dev, and task them with a customer request.

This company was in a very specialized niche market, and was basically the only player. The only thing I couldn't figure out is why someone else hadn't come along and eaten their lunch, because they were suffering from chronic under-funding. Getting them to commit to migrating to AWS was a major eye opener for them; since they suddenly had to actually pay bills or they'd lose the whole operation.

> Your run of the mile non-technical manager sure is not very good at understanding the intricate complexity of all the moving parts of creating software.

> Developers on the other hand appears blind to the fact that they play only a minor role in the bigger picture.

Y Combinator was largely founded as a rejection of this premise. Paul Graham believed it was much easier to teach great Software Hackers how to business, than it was to teach business folks how to software. I think it turned out pretty well.

> A scenario which never happens because in real life you have at least 3 levels of technical management, multiple divisions/departments involved, spread across continents and multiple vendors participating.

And your organization with 3 levels of technical management and all those divisions and departments will often get their lunch eaten by a very small group of people working in a startup, moving faster and accomplishing more in less time.

"Paul Graham believed it was much easier to teach great Software Hackers how to business..."

I agree

"And your organization with 3 levels of technical management and all those divisions and departments will often get their lunch eaten by a very small group of people working in a startup, moving faster and accomplishing more in less time."

You misunderstand. It is not my org - it is the client orgs. And none of those are software companies. The speed with which you can move is irrelevant because you are constrained by the pace of the org you're working for.

A delusion is a sincerely-held false belief. Please consider: If all of the developers left your organization, could it still produce products? How about if all of the managers left? Your implicit devaluation of labor is not congruent with the actual reality of whose hands work the keyboard.

(And before you write a knee-jerk response, double-check your reasoning. Without managers, developers produced the Free Software ecosystem. Without developers, what did managers produce?)

Ask yourself who paid for the Free Software first. We are all humans and need to eat.

I generally support this assessment.

As a 'developer' I thought 'we were doing all the stuff' while everyone else catered to us.

During my roles out of that seat, I view 90% of development as a form of intellectual labour, it's just work, one piece of many things.

The hardest job by far is selling.

The next hardest job overall, as the commenter mentions, is making a 'whole product' and targeting it at customers.

Engineering is hard, but not harder than the above.

I would almost like every Engineer to work for 3 months in PM or Sales just to get their perspective flipped.

Engineering feels more 'worky' because it's more direct.

Regarding selling - I've know amazing people who could sell all kinds of products that don't even exist. So selling by itself doesn't seem to be the hardest thing - selling something that relates to the reality of the product is far more difficult.

This is a similar mentality of people who get very upset over incentives sales gets and/or "company provided trips".

We all forget, at least in a for profit company, that we are all employed by selling things. Like it or not without the good salespeople, some of us don't have jobs.

Your claim is provably false.

Large scale software development without management is proven to be possible by the existence of functioning FLOSS projects like the Linux kernel, various GNU tools, KDE and plenty of other examples.

I have not heard of a single software development company with 0 software developers. Not even Oracle manages that.

Managers are necessary for the parts of the company other than development. You can have a FLOSS project developed organically, and separately a company in the business of support, services, etc. Managers are also necessary in order for the company to exercise control over the development and extract value. And this may be needed for a company to survive. But they are not needed for software development itself.

Even FLOSS enthusiasts need to eat. Money don't come from writing code by itself, they come from sales. Or from donations. In both cases there is a lot of non-coding work. Do you want to do it? I don't. How do we call those guys who organize donations or sales? Collect requirements? Yes, there are requirements in FLOSS too, otherwise you wouldn't get donations, or support contracts, and those requirements are coming from the people who pay. Let's call everybody developers, only some won't write code and would organize coders, gather requirements, distribute payments. Wait, those people are currently called managers.

Clearly some management is required somewhere in the chain, and if they're any good then they're important. But certain tiers of management seem to largely be pointless intermediaries; especially if they're not as technical as the developers.

I've stopped being skeptical of the general concept of management. I'm no fan of LinkedIn, but Reed Hoffman said something in a talk that instantly changed my entire opinion about the idea of a developer moving up in the hierarchy and no longer writing code. Paraphrased from memory: "You're still programming; just at a higher level of abstraction."

Anecdotally I’ve seen the same in managers.

I tend to believe these arguments just curve right into confirmation bias.

I’ve been on teams that worked fine with managers and those that did not. It depends on the commitment of the actors in question.

Anything else is reading what we want to in the tea leaves.

Edit: Been working on distributed systems since the late 90s, from public uni to big corp, to day 1 startups. It’s just computer configuration. Not magic.

lol. try an A/B test.

A) Get rid of developers B) Get rid of dev managers

Let me know :)

Drain a company of managers, and the devs will self organize and save the company. Drain the company of devs, and the managers will desperately try to hire anyone to replace them. Devs are vastly, vastly, more important than management. Any given manager could leave a company and literally no metric would move.

Now imagine that setup with a bad tech lead who didn't know what they were doing. No oversight, no control, no feedback, no communicated goals to keep people accountable, etc.

Every single approach works when you have driven, intelligent people who all mean to do the right thing. The validity of an approach is only tested when those things stop being true and you need to notice and recover.

> who all mean to do the right thing

And to some degree agree on what the right thing is.

Well, no approach works when you have incompetent people doing the bare minimum and trying to subvert anything for their gain, so I don't known where you want to test anything.

The truth is that not all approaches work on your perfect scenario. Many are known exactly for turning competent cooperative people into incompetent individualists.

But in reality most teams are somewhere in between?

Then the lead developer is the manager

If you had no KPIs and no meetings how did you know what to work on and what the company needed? Osmosis?

KPIs are generally set on a timeframe where they usually become meaningless by the end of that timeframe. For software, goals set for a year out are almost never going to be meaningful by the end of the year.

Pick your flavor of Agile or whatever process your team can agree to, but I doubt the term "KPI" will ever come up when doing real life planning and work.

1) It's pretty clear then that you don't have much experience with planning at level beyond a few people if you've never heard the term KPI come up in software

2) Agile still comes with meetings

Oh, I've heard the term KPI come up many times.

Never once have those "KPIs" been actually relevant to real world planning.

I’ve only ever heard of managers “working on developer KPIs” and never seen them actually defined and distributed.

Although I am not completely sure I agree with the thesis, I think it's worth pointing out that one of the largest software projects in existence, Linux kernel, doesn't have software managers either.

In any case, when I first read the headline, I thought, well, in a worker cooperative, the developers can fix the bad management. :-)

But the Linux kernel had Linus Torvalds who acted as a dictator. We can argue he did some kind of technical management there.

Yeah - I think that's good insight. You need someone that has all power and resolves conflict if necessary. But even for something as big as the linux kernel, Linus did the dictator part _and_ continued coding, doing PR reviews etc.

So how much management is really necessary?

How much time did he spend on coding as Linux got bigger?

And you could argue PR reviews was how Linus performed his management function. Which could be an interesting way to organize technical management in proprietary software projects, too...

> How much time did he spend on coding as Linux got bigger?

Yeah, I don't know. But even just keeping up with PRs seems quite time intense.

> And you could argue PR reviews was how Linus performed his management function

You certainly can, but just because the word "management" appears in there, it is wholly different from the "management" that the original post is talking about. But yeah, you can call both management. You can also call a software developer a manager of the codebase I suppose.

I think the original article is predicated on the notion of "management" as a role (specific person so designated), and not a skill, that can be taken up by any developer. If it was the latter then the whole argument would fall apart.

Personally, I think managers are primarily intermediaries between capitalists and laborers. So they are needed under capitalist mode of production, where surplus value is extracted (according to Marx, at least), but they are probably superfluous under different modes of production, like that of open-source software.

> I think it's worth pointing out that one of the largest software projects in existence, Linux kernel, doesn't have software managers either.

Most linux contributors, as I understand it, are paid to do it by their employers, and get managed that way.

A significant amount of work on the Linux kernel is done by contributors who on the clock for Intel, Red Hat, etc., and I'm sure have software managers.

That could sorta make sense if these managers would actually talk to each other, but.. I think they are not.

That lead developer was effectively the manager then.

But you can't just leave all choices to developers, there has to be a commercial point to it all - that isn't something a lot of devs even consider. Technical changes may be great, but the time spent on that has to paid for somehow, not just in 'job satisfaction' for the techies working on it...

I think below a certain threshold of competence, a manager will negatively impact the productivity of a team mostly by eroding any ability to focus on a single task at a time. A good manager should shield the team until it is appropriate from the very things a poor manager would be dumping on the team as they arise.

I've been programming professionally since 1993, and I can tell you that some of the software managers I've have had been invaluable. When they are good they can be very propulsive. I don't necessarily have time to collect up all the different and sometimes contradictory specs from the product owners and make sense of them. When the manager is technical and can do this for you it's golden.

I'm coming up on 15 years of professional career in software (development experience being 25 years or so).

In small projects, a lack of managers can be pretty effective when there is good team cohesion and lack of conflicts over priorities and expectations.

In larger projects and teams, where your team has to interact with other teams and navigate competing pressures within a larger organization, while still delivering on internal goals and keeping turnover reasonable.. managers are crucial.

The best managers make you feel like there is no manager. They run interference for you. They talk to you, understand your individual priorities as a developer (project priorities as well as career priorities), and coalesce that information across their entire team to quietly craft a path forward that preserves cohesion and effectiveness and productivity and happiness. They also communicate progress to higher ups, and interpret (to the executives) the day-to-day operations with relation to broader organizational goals.

Managers are the interface between larger organizational priorities and a team's individuals. For a company, managers serve the role of both implementing policy top-down, as well as understanding operational dynamics from the bottom up and communicating it to the higher-level positions in the org.

They are fundamentally a structural necessity once you step beyond a certain scale of project or product or company.

My personal thoughts on managers used to be closer to yours, but it has evolved over time. These days, I'm more inclined to think that _everyone should get an opportunity to be a manager_. Maybe even a structure where management roles are cycled between different people on the team with a willingness to take on the role. I think more developers need to understand how difficult good management is, and to get a personal exposure to that problem space. I think it would make developers into better developers.. who, rather than reacting blindly to their local perception of the symptoms of management (poor or good), get a firsthand view of the other side, and learn to better interact with it in the future.

> The best managers make you feel like there is no manager. They run interference for you.

This is the most important thing, and its hard to recognize as its invisible to the developers. "Do I need a person running interference so I can focus and get stuff done?" is also a useful metric to decide if/when you need a manager.

> everyone should get an opportunity to be a manager

One way to test drive being a manager: read the Ask A Manager column (https://www.askamanager.org/) for a few days or browse the archives. Read the question submitted by the reader, consider how you would deal that problem, then compare your response with Alison's (and the commentors below.)

Yes, most the problems are not technology or software problems. Some are downright silly. But that's largely true of software development, too.

The best managers make you feel like there is no manager.

Excellent summation. They're there to help you to do your job better.

> The best managers make you feel like there is no manager.

Totally agree. This has been written before, many years ago. I'm sure it's possible to find references from other cultures and traditions as well:

"When the Master governs, the people are hardly aware that he exists."

http://thetaoteching.com/taoteching17.html

When I was younger I wondered what all these other people in the business did with their time. Surely it was all about the code and all these other corporate drones just needed to respect that. Then I guess I started moving over to the dark side and got a bit more empathy for the real jobs that other people have to do - so devs don't have to spend ALL their time talking to customers, paying the bills, handling the marketing etc. Strangely many of these people, even customers, were curious about likely dates for shipping the work. Turned out their jobs depended on it too. I recently interviewed an engineer working at a startup run by engineers. There is no management, which he thought he'd like. Instead they use commitment. After 18 months of very long hours and weekends guess why he wanted to move on? Organizing the work and the people is an art, lots of people get it wrong even when they try hard to get it right - but these articles? I hope my competition is reading them.

This can only be true for teams built of mid level to senior engineers, right?

I've come to the conclusion that software managers are not needed

I think some layer of management is needed for strategy, business operations, market positioning, etc., but they should get out of the way as much as possible, similar to how Joel has done it at Fog Creek.

Many years ago I was visiting a startup being incubated at Stevens Institute in Hoboken, and there was a group of graduate engineer students on-site looking at a demonstration; the CEO asked what the most important factor in building the product was, and the very smart engineers talked about output, efficiency, portability/miniaturization, etc. The CEO stopped the brainstorming and said "whether or not someone will buy the product".

> After 12 years of software development, I've come to the conclusion that software managers are not needed.

If devs are doing:

- Scoping

- Product design

- Coding

- Debugging

- Scaling

- Releasing

- On call duties

- A/B tests

- Can't cause outages

- Postmortems

- Enhancements

- Fight bullshit corporate politics

- Fight to remove blockers

- Fight to remove deadlocks

- Ultimately produce something that earns money for the company

- Write bullshit promotion docs for themselves

- Wait to be Pipped or something.

What exactly is the value provided by a manager?

So the developers take on the responsibility of a manager so they don't need a manager? The value of a good manager is that they can do some of the stuff on that list so the developers don't have to (ideally including all the 'fighting').

> So the developers take on the responsibility of a manager so they don't need a manager? The value of a good manager is that they can do some of the stuff on that list so the developers don't have to (ideally including all the 'fighting').

Incompetent managers fail to unblock their teams and instead push pressure on their reports to "fight". Often blocking career growth, promos, compensation changes with these reasons.

I'm sorry. If the dev ultimately does this work, the manager should be fired or made an IC where they can demonstrate their value.

  What exactly is the value provided by a manager?

the illusion of a management structure.... ive seen it a few times in very dysfunctional corporate cultures where they value the illusion more than the reality...

in those cases the managerial "class" is more like an old-boys club, and its the grunts who do the real work (and the boot when things go south)

It depends on your company.

My manager seems to defend the team from a lot of bureaucracy. I see his schedule and task lists and other paperwork and I am extremely happy to have him.

Yes I've seen this style described as 'servant leader'

My current manager was also my previous manager at my previous company! He is so good I literally followed him lol.

> The lead developer .. was your manager.

> From what I can tell, they have meetings, try to get people to work more, and approve time off.

Do not under appreciate the importance of managers attending meetings, because a good manager attends those meetings so the devs don't have to. A good manager of developers seeks to shield her developers from the busywork and politics imposed by the larger organization so they can be as productive as possible.

Seems like it depends on how you define ‘manager’. Your lead developer is what I would call a manager. In my experience, most managers have been team leads who set priorities for the group, help arbitrate technical decisions, advocates for more resources for their team, negotiates with other teams over who will do what work and take responsibility for which parts of the system, advocate for promotions for their team members, and deal with underperforming team members.

I don’t know how a large company could function without that role. If you have 200 developers working on 100 different projects.... who is deciding what to work on? Who is deciding how many people should work on what? Those people are managers.

I like how Engineering Manager is defined in "The Managers Path" -- which is what you are describing. They shoud be someone who does an occassional bug fix to maintain a boots on the ground approach, but is spending 95% of their time on the items you listed. I think one issue w/ Managers is that we get manager's who should be at this technical level, but are instead so hands off (or fully non-technical) they can't even reason (or delegate) priorities when architecture or tech debt is involved. To be fair, I have worked with fully non technical managers who had a good understanding of how much time to allot towards architecture, refactoring, etc. But those are rare.

Well, in my experience I'd say it depends. It depends on the developer. But it takes a good manager to understand if a developer needs management or not... :)

While I see your point and get where you're coming from, I think it would be made explicit that "management isn't needed" is a gross oversimplification that is only possibly valid below a certain threshold of company size. I currently work for a very large international company and none of the things we do would be even possible without management.

We're also lucky enough to have pretty good management, at least locally in my department, I haven't really been exposed to the higher levels of decision-making (which is a sign of good management IMO, that stuff is mostly irrelevant to me)

I have admittedly less experience than you, (~10yrs) but from what I've seen, my conclusion is that really bad management is worse than no management at all, fairly bad management is about as bad as no management at all(and from here can the opinion that management isn't needed really form in developers head) and good management is way better than no management at all.

I also think that software/tech management is a different beast from basically all other types of management. Experienced managers from other sectors tend to fall in one of the first two categories above in my experience.

Good managers are perceived from the developers point of view as someone who just helps organise tasks, and help you find the right person to talk to if you need something from outside your team.

In reality of course they do lots of other stuff too, but those things mostly shouldn't bother the developers IMO.

Never should a manager ever act as a go-between. Doing that puts you firmly in the "worse than no management" category of managers

Of those 12 years, did you spend any time in any other role?

Like manager, or director, product, product marketing?

The world looks very different from there.

My first questions would be (1) how big is/was the team? (2) how experienced? (3) how fast were you growing/changing? (4) without any sort of process or documentation how did you handle performance reviews (good and bad), promotions, growth? I'd also bet that your lead was (a) really good and (b) doing 2 jobs.

IME smaller organizations with experienced & stable teams can do fine without formal management, especially if the system is small enough to fit entirely in you head. Beyond that you need some form of management.

Aside: you come off at best somewhat ignorant or less charitable as kind of a jerk; there's a lot more to running a software company than writing code by yourself. We get it; you think all managers are useless MBA suits, but some of us actually still self-identify as devs that just want to improve the systems that build software. You can only get so far focusing solely on individual improvement.

Aren't there a lot of things that need to get done that are annoying to developers? I personally enjoy having someone else in charge of all the manager responsibilities such as planning who works on what wand when, handling expenses, etc

> The lead developer handled communication with the IT Director about project status; and that wasn't very often.

I think depending on the organizational context, and how much external communication a project needs to succeed, this can mean that the lead developer becomes a manager in responsibility but not in resources. This can harm the project and its participants both because the lead developer's attention may be siphoned off towards management-related activities, and because their advocate to upper-management is less equipped.

E.g. Can the lead developer recognize that the project needs a person with a skillset not already present, write a JD and oversee the search for a suitable candidate? Or will the organization say "tech leads don't hire; managers hire"? Does the lead developer have the same access to the decision-making process of the larger org that a manager would, or will they be denied access to certain meetings, documents and resources? ("Sorry, we keep that personnel info in the same place we keep compensation info, which only managers should see").

I think the article makes the point that the problems preventing an org from making good products or decisions extends all the way up to the CEO, and I agree. And in the many organizations, software managers are a necessary evil to try to compensate for those broader dysfunctions.

> this can mean that the lead developer becomes a manager in responsibility but not in resources.

I think you've nailed it here - what's been described is a manager under another title, and one who will be hampered in that role in the exact ways you describe.

ive seen this happen alot... a lead dev is a manager without a title, and is not recognized or have any true authority, and they arent compensated for it either... its the worst of both worlds...

If that was true developers would make their living just by sitting in front of their personal laptops and coding. Instead they tend to apply for jobs at companies that have a lot of managers

Bad managers are actively harmful to a team. Great managers will make a team shine with productivity and satisfaction. You'll never accept a bad manager again once you work with a great one. Sadly, they are few and far between. And to truly be great, their managers all the way up to the CEO also need to be great. So a role under such a leadership team is rare. But they do exist. It is worth your time to seek them out.

Why dont you see the lead developer as a manager in this instance?

Depends on the team experience, morale, complexity of product, organization, and customers.

I also agree that a high-performing team tasked with a clear mission don't need more than a glorified secretary.

But if any of those start to fail then it starts degrading everything. Without decent managers, development/progress can collapse.

Decent managers can paper over the other deficiencies to a surprising degree.

Good software devs can also paper over deficiencies in the chain as well to a surprising degree.

Bad managers can be part of the problem too. Bad devs will obviously kill the whole thing.

And of course everyone in that chain has their own agendas, from selflessly devoted to the macro-organic corporation to machiavellis edging for any economic and power advantage.

Capitalism is supposedly about the free market, but organizations strangely don't align themselves to the basics of microeconomics. They are centrally planned top-down pyramids. Incentives will never properly align to maximize organizational productivity because of the totalitarian nature will reward those with power, not productivity.

I bet you would hate to spend 4+ hours per day in negotiation meetings, stacking up plans and writing reports, some days not even having time to start working on development tasks. You'd probably give all this to someone who wants and has experience to do it, someone like...a manager?

If your lead dev didn't have to spend that much then I'm afraid that experience does not extrapolate on what larger companies do; if they did then I think you're missing the elephant in the room that the lead dev was de-facto the manager at the expense of their direct duties.

My experience is about 1/3 of developers are completely lost without a manager checking up on them periodically, between 1-5 times per week. (Varying depending on seniority, while the frequency changes it seems like the percentage does not; junior developers are more likely to get lost but not always in the ways a manager check-in helps.) By this I don't mean a one hour meeting, but something more like a standup, or just an email "hey, last week you were working on X and I didn't any updates about it, how's that going?"

If you get a team of purely the of developers that don't need this, it's great! But that means somewhere else there's probably a team that's 2/3 or worse that, and that's hell. If there's a manager, it's luckily just hell for the manager.

> The best team I've been on didn't have a manager

I feel exactly oppositely. The best teams I've been on have been ones where the manager has a strong focus on being a crap-umbrella for the team, sheltering us from anything coming from above, being an advocate for our needs, and a fierce seeker of true requirements for the projects that our team needs to work on.

I think I would be very anxious being on a team that didn't have some manager who took seriously the role of sheltering and nurturing the rest of us. It's obviously not an easy job to do well (else we wouldn't have had bad management experiences).

After 20 years I realize managers are important to keep other managers away. If you have ever worked without a manager in a department you become the manager as other departments will need someone to meet with someone. More importantly secret deals, backstabbing and positioning are going on above you. Your department might be chopped up next, you need someone to fight those battles.

Project managers are a different story.

Managers are not needed but management is. There are many ways to fulfill the task of management, one way is to have a manager, one way is to have the developers handle it themselves.

If you're lucky you can get a team of devs who are capable of self-managing and communicating with the outside world and handling everything else they need to do to be successful besides just writing code (writing JDs, talking to customers, dealing with budget, etc.)

But hiring a team like that is hard. Developers like that cost a lot of money. The law of comparative advantage is a real thing. If you can't hire a team that can manage everything themselves you can at least piece together people who can fulfill the different functions.

And that's how you end up with developers and managers.

Sure, at very small sizes where everyone personally knows everyone, there are a lot of things you can get away with.

I like the story of google, however. They theorized they didn't need managers, tried to prove it, and ended up proving the opposite. It's almost the kind of thing only google could do, that is a large enough company with the resources to run large scale studies internally, yet is curious and cares enough that they're willing to run such a study to definitively determine the direct value of managers and manager traits.

https://www.inc.com/scott-mautz/google-tried-to-prove-manage...

As a developer, I got some valuable insights from the book Extreme Ownership by Jocko Willinck. I think particularly the principles of "leading up the chain" is crucial when you're a developer with managers who don't have the necessary context of understanding to make optimal decisions on their own. Perhaps not as easily applied in all company cultures. But in my case, it gave me the confidence to voice my opinion on a few critical issues of strategic importance over the past few years. This year I was promoted to "system responsible" (basically lead dev with technical responsibility for the system) and I think that was in part an acknowledgment of my ability to take ownership of a situation and helping to make sure sound a sound strategy is in place.

I can also recommend this book (it’s on Audible too and a great listen).

Check.

It's not for lack of trying. A large part of developer culture is spent on working against or around bad management. Agile, XP, scrum, etc. Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management.

Bad management is everywhere. We humans are not very good at managing knowledge work. Worse at software in my experience. And all too often I see software developers taking the blame or blaming themselves.

A good deal of software errors are enabled by poor management practices.

When you let off the management reigns and trust developers to understand the importance and impact of their decisions you get a lot better results.

The insidious part is that every effort to work around bad management of this type is captured by management, and twisted, corrupted, and festered until it becomes yet another torture inflicted by management.

Agile would be just fine, if it was the bottom-up, developer-focused scheme that the manifesto writers and True Scotsmen claim it to be.

Unfortunately, it's been co-opted, and we end up with interminable daily standups that are driven by line managers, or by yet another useless person who bought a Scrum Master certification, and exist solely for developers to justify themselves and kowtow in self-abasement. Likewise with the whole cavalcade of infantilizing sprint planning meetings and planning poker and retrospectives and meeting after meeting after meeting imposed as part of a holy Process, that the company spent tens of thousands of dollars having consultants implement.

Agile is exactly the corporate management hell it claims it was out to solve.

> Piles of books on it. Youtube channels and blogs dedicated to advice on how to navigate bad management.

Can you recommend some? I’m at a point in my career and at an organization where this is a matter of survival way more than actual competence.

https://jaymeedwards.com/ provides some good content on his Youtube channel

https://www.amazon.ca/Elegant-Puzzle-Systems-Engineering-Man... helps to understand managing from an engineering perspective

To understand some of the history and context: https://www.youtube.com/watch?v=a-BOSpxYJ9M

A bit dated but still useful book: https://www.tablegroup.com/topics-and-resources/teamwork-5-d...

Best of all, for surviving at a difficult organization, invest in yourself and get a good therapist. I can't recommend this enough. Burnout is the worst but you can manage if you have solid, professional support to aid you.

I’ve been watching Jayme Edwards videos for the last couple of weeks and they’ve been very helpful. Just wanted to say thanks for recommending!

The main problem is that you get promoted for creating social solutions to technical problems. If you solve a problem by writing a great solution in code people will pat you on the back at best, if you do it by creating a plan, hiring people and delegating tasks you become a manager.

"Managers are a force multiplier", well so are developers. A good developer can write programs that runs on thousands or even millions of machines delivering great value, thus there is no limit to how much value a developer can deliver. However since managers gets promoted by implementing social solutions they will always try to go that route. Of course you can do it wrong the other way and be too technical, but I doubt it happens often since managers holds so much more power than developers. Google and Facebook have about the right amount of technical focus, most companies are way less technical than that and suffers from it.

Every organizational problem is a management problem. I doesn't mean developers can't and shouldn't try to fix it. Concluding such article with "Developers are fine" is too cynic.

For reference, at my org, management already does what it says it should do and already don't what is says what it shouldn't do. Still there are developers who need to step up their business understanding. Despite all the training, the stimulus, the right incentives, it is not natural for new tech/team leads to communicate well how technical challenges must translate into business decisions.

This shit is hard and complex, stop trying to assign blame.

I treat all such articles with the condition of "I am not saying this happens everywhere but it happens fairly often" -- which is also my experience.

I've met several excellent managers and I have huge respect for them but seriously, they are rare. I am almost 20 years in the industry and I am not sure I've even met 5 of them.

My point is not that good management is possible. The article drew conclusions to which my experience is a counterexample.

Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function.

It is also a story the pretty much every group in an organization tells themselves at some point: from HR's perspective things would be great if the company just let them if the company let them pursue their vision of proper talent acquisition. The sales team believes they're most important because without them there's no revenue and they understand customers the best because that's one if their closest contacts. And so on.

The truth is that no one group would accomplish much if they were the only ones in charge. In reality, there should be a seat at the table for all of the groups.

Absolutely developers should be in the mix for understanding customer needs and helping guide things appropriately. But developers are no more inherently capable of understanding those needs than anyone else, and in fact a non technical view is just as important when the target audience is not just technical folks.

An organization will fail when pretty much any one of its groups is sufficiently bad at their job, and will rarely succeed just because one group is good at theirs. But the "if only developers ran things" trope is old and worn and wrong.

> Just another story that essentially says everything would be great if only the developers ran everything. It's an over simplified view of how large organizations function.

Just another manager who wears their ego on their sleeves.

A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything.

> A lot of developers handle EVERYTHING (including politics) in modern companies except promotions and performance reviews. There is no real need for a manager if devs are doing everything.

Which modern company does this? The closest that jumps to mind is Valve.

Wrong: I'm not a manager. Check my profile, you'll see the area I work in. I have no interest in being a manager because I understand the different skill sets and what I enjoy doing.

But if we're bringing the issue of ego into it, there's yours right on display thinking developers know everything. Well, consider this: If you were right, there'd be a lot fewer startups with great ideas that flop even with developers in charge, but they fail because they can't execute on their idea by also running an organization properly.

Developing code and running an organization are different skill sets, and not many people have both.

I think you're conflating diversity in skillsets with corporate hierarchies. I think the article was less about devs vs marketing vs any other dept, but rather about managers as a distinct class above all the rest, with all the decision-making power.

Different depts having a seat at a table is great if your org is flat enough that the table is actually the group making the decision. If their decisions just get overridden by middle management, it's back to the same problem again: not that there are too many depts with their own limited perspectives, but that managers with little to no technical background are making decisions that affect their more skilled minions, typically without their minions' buy-in.

The problem isn't any particular skillset, but the professional managerial class whose management skills are too often dubious to begin with, unmeasured, untested, and yet prioritized over technical skills, be they marketing or HR or dev. Some orgs help mitigate that by having a feedback loop for their managers and the ability to underlings to skip a step or provide meaningful feedback that can result in the discipline or "impeachment" of someone above them, but that's the exception rather than the norm. In most orgs I've seen managers are recruited from other management backgrounds horizontally instead of rising up the ranks from a technical background. Maybe the intent is to recruit better people-people instead of super-smart devs who don't understand humans, but in my limited experience that rarely works past a certain tiny scale...

Most don't have "tables" to begin with, just thrones and various forts.

I understand what you're saying, and had the article put it in similar terms I wouldn't take much issue with it. Instead the article took the tone of developer superiority vs. managerial incompetence & intransigence. Where, by implication if not direct statement, all failures are failures of management.

I don't like that management gets bashed so consistently, because it is a view blinded from the truth: good management isn't actually all that rare as this POV would make it seem: Good management is nearly invisible. It smooths over things, putting fewer roadblocks in workers ways, and thereby only gets noticed when there's a problem. And even the best managers will encounter problems, meaning people really only take note of management when there's something negative going on.

Maybe it's because I've had all three types that articles like this put me on the defensive. I've seen bad management, I've seen invisible management that generally makes my life easier in ways I only notice because I've had bad managers, and I've had at least one manager that was so good that they not only made my life easier, they made me much more effective at my job.

Rising through the ranks is also no guarantee of success: management is a skill, and it does not always overlap with being good at the jobs you manage. All that does is make sure the manager understands the work, not actually understand how to manage a group/department/division etc., Which is a different skillet. I'm not a manager, despite opportunities, precisely because I understand that fact, my own preferences, and my own limitations.

It's also important to remember that "bad management" is frequently not monolithic. There may be very good managers throughout an organization, but one bad mid-high level manager makes them all look bad when even after they fight back against something,they lose the fight and their job is still to implement it. No different than an excellent developer forced to write something useless/bad/inefficient. Is the developer a bad developer? There are some fights like that-- won or lost-- that I've only found out about long afterwards, because again: good management is often invisible.

Those are very fair points. Yes, good management can make projects (and people) function more smoothly, and yes also that it can be a thankless job that only gets noticed when something goes wrong, not for all the times it goes right.

For all those reasons, it would be nice of the skillset of management could be decoupled from the hierarchy, pay, and prestige of management. Too often the "managers" in an org, and by the extension the CxOs, are there not due to their skill in managing people/projects, but more or less "awarded" the position as a consequence of their connections, founder status, length of employment, whatever.

If only "management" could be thought of more as "facilitation" (or mediation, or HR, or similar) in that it's a unique skillset, yes, but no more or less valuable to a group than any other skillset -- not an inherent part of some hierarchical and unaccountable structure. Managers should not be above the people they manage, but be able to offer workflow & worklife improvements, help resolve and mediate conflicts, etc. And there's no inherent reason they should get paid more or less than workers of any other skillset.

Top-down control != group facilitation skills, but present-day corporate hierarchies try to pretend they're one and the same, to the detriment of many orgs, and especially anyone under (visibly) bad management.

A "seat at the table for all" implies a level of idealistic flatness that's just not there in most hierarchical organizations. I think it's easier to teach a flat organization better people and project management skills than to try and flatten a purposefully-hierarchical organization that uses middle-management not to improve the productivity of self-directed workers, but to corral a disposable workstaff who have miserable lives because they're thought of mere doers-of-tasks, not partners in planning -- a vicious cycle reinforced by the existence of a professional managerial "class" (as opposed to skillset).

Startups would never beat large organizations if good management was common. The only reason startups can compete is that management is totally awful at larger organizations preventing any real value from being delivered. Of course many managers are less bad, but most are still bad.

> Software development is much closer to creating a new factory than running an existing factory

This has been known, and ignored, for at least 30 years now.

Known among software people, non-software people often need to be informed of this.

Maybe "ignored" wasn't the right word... rejected might be a better term.

A lot of the ideas communicated resonate with me. The estimation process doesn't work well, and creates friction when things change that can interfere with the delivery of what's actually needed.

BUT...how do you also maintain some degree of accountability? If timelines can perpetually slip due to changing requirements and there's no objective mechanism for identifying this, then things might not get delivered at all. Surely some delays in the delivery process are due to inefficiencies or poor prioritization -- deadlines help identify this.

Now, to some extent the answer lies in hiring. The right blend of autonomy and individual motivation negate the productivity slip that might occur in an environment where it's easy to procrastinate. The right people in the right environment will self-police and police each other (in a healthy way).

I appreciate deadlines as a mechanism for forcing a discussion about tradeoffs. If there's some cost to delaying things then I'm more likely to think carefully about taking on the associated work. This usually leads to better decisions. I (usually) avoid spurious refactoring and overzealous testing, and scrap features that are less important.

So, rather than do away with deadlines entirely I think it's important to build up a culture that:

* Avoids punitive patterns -- rarely should folks be held unaccountable for adjustments in the timeline. Unless it's a clear pattern, it's not the fault of the person.

* Embraces (sometimes a lot of) discussion about deadline adjustments and the associated trade offs. There should be some friction to missing a delivery date, but not so much that it prevents us from doing the right thing.

This is of course hand wavy and really hard to get right.

> rarely should folks be held unaccountable for adjustments in the timeline

unaccountable? Was that a typo?

Oops. Yes. Folks should rarely be held accountable for timeline slips.

Thanks!

Unfortunately it is more like two way street.

Bad managers putting blame on developers for "not doing their job" when they did not provide correct environment for developers to do their job well.

Developers don't recognizing they are in fact making a lot of management decisions every day because of nature of they work and that they make poor job of it.

Can I point out the fact that this article compares software developers to auto workers trying to explain the problem and then highlights failed management strategies as a fact that software development is nothing like manufacturing, saying " and if I ever run a factory, I'm gonna use it! But it has no place in software projects."

I dont disagree with this article in general but please dont contradict yourself.

I don't think he really contradicted himself - what he's saying is that auto workers fell behind because management was trying to manage them like farm workers when they weren't, and that software is falling behind because managers are trying to manage them like factory workers when they aren't.

Their conclusion is a bit off. The WBS and GANTT charts are used for resource planning. I don't work for a unicorn so resource constraints mean that I actually need to plan, prioritize, and schedule work. If I do a bad job of that then my developers get laid off, we don't get paid for slack.

One thing they miss is that managers manage expectations both up and down. People only get angry when you step outside of their expectations. I work in a PMP setting and I am up front in my project plan about how we're using PERT estimation (so they always look high), that we're dedicating time to testing, automation, and documentation, and explain why. Its straight up in scope. The client signed it. The CIO signed it. Problem solved.

The one thing I find is that developers chronically underestimate. And that's something that I found going from a programmer to a project manager. I always thought about my code and never the back-and-forth communication with stakeholders, and the change requests, and all the little BS that inflates estimates. That's why I teach my programmers PERT estimation, because it forces them to think about what the doomsday scenario is. We've gotten pretty darn good at estimation these days, which is good because we are a consulting shop, so if we underestimate we don't get paid, or have to get a change request.

There are managers like you, who understand estimation.

Then there are managers like my former manager, who took a 2.5 year estimate from me and sold it to leadership as something we can do in 6 months.

When he tells me the project got a green light, I pointed out that I also listed several risk factors that would be major blockers in the first 6 months. This manager was also the scrum master on the project, and proceeded to contribute nothing for the next 3 months. He was waiting around for a promotion to some sort of leadership/project management position. Luckily his replacement was a massive improvement.

A year later and we were right on track for my original estimate but I lost all credibility in the org despite busting my butt to keep the project on the rails.

It's not just engineers who are bad nor is it just managers. Both sides have to do their part and respect each other or it can go sour.

Wow. So much of this article resonates with me. Strong parallels with the recent re-debate of "bullshit" jobs.

I have the privilege of working in a pretty low management shop, but sometimes it rears its ugly head and I chafe at it.

Of recent I've observed that not everyone is like me in this regard. Even though humans don't like being managed, they also don't like taking risks. And for some people, the ability to offload risk, accountability, and liability to a scapegoat figure that is inconvenient to deal with at times (e.g. a bullshit manager) is actually a purchase they're willing to make.

It's ironic to me, that years ago, the world had lots of clerks (people who kept the wheels of process logistics rolling) and less managers. Today, there are fewer (almost no) clerks, but lots of managers. Look at what most of your manager does, and see if (s)he isn't mostly just a clerk that collectively figured "manager" pays better.

When a project is delivered on time, within budget, and produces the expected value for a company, it is not necessarily the result of "good management".

This is why "bad managers" survive in our industry, far too often a manager's performance is measured on the success of the projects they are "accountable" for.

I believe the responsibility of a "manager" is to provide support to the people they "manage", which can take on many forms. e.g.

- Hiring additional staff to handle the current workload at the desired cadence.

- Influencing the stake holders so the business priorities benefit their employees (and indirectly the company).

- Providing emotional or moral support to their staff.

- Being a source of motivation through exuding passion, or setting an example that their staff aspire to.

Reminds me of a small-ish company I worked for.

All promotions were based on the fact that the original person holding the role left.

You could end up as head of r&d with being just out of college for two years.

People self select to be in these situations and they can self select themselves out of it too (by changing employer). There are lots of not so great engineers working in not so great companies. Good engineers tend to have options to improve their work situation and most of them do. Sometimes they are happy to take the money for an easy job as well.

However, I see a lot of issues that have also to do with a few factors that are hard to control:

1) programmers are mostly young. There are older programmers and they don't actually disappear (I'm one of them). However, the number of programmers keeps on doubling every five years meaning that at the ripe age of 46, I've experienced about five doublings meaning there are about 16-32 x more juniors aged 20-25 active than people my age. I work with a lot of people half my age currently.

2) Most people aged 30 would count as "senior" because they are relatively scarce and more experienced than most programmers. I got that label slapped on me around that time. That's nearly 17 years ago. I did not have a lot of experience at the time and I've certainly learned a lot since then. This is a common pattern in our industry. We have a lot of very junior senior engineers rediscovering a lot of things about software engineering every generation because there are very few proper seniors around to learn from. I'm usually the oldest person in a project and that's been the case for almost ten years for me. Yet, I know lots of engineers my age as well and most of them are in a similar situation.

3) Scrum adds roles to teams that I would classify as junior management. Product owner or scrum master would be good examples of job descriptions that end up like that. I've experienced more than a few PMs that were effectively on their first job and scrum masters that had little more than a two day training + a hand shake as management background (been there, done that). Junior management and junior "senior" engineers adds up to very predictable issues. Sometimes it works. Mostly it doesn't. The problem is not the process but a lack of experience on both sides. Hiring more people makes it worse.

4) Proper seniors are expensive but being old doesn't necessarily mean you are very good. I know I have to work hard to keep up with younger people. There's something to say for removing mildly burned out cynical forty somethings from your team. I've had to make calls like that to resolve a few toxic situations. Putting an old person in charge does not necessarily solve your problem either.

5) Software engineers generally lack soft skills needed for management and there's a lot of pressure on people to get promoted to their level of incompetence. Once that happens they are easy to manipulate by senior management. Large organizations with a lot of middle management that isn't so great fall victim to this. It' a classic A's hire A's and B's hire C's. Replace hire with promote and you have basically a template for how great companies almost inevitably turn mediocre. The A's tend to leave when that happens.

6) If you think forty something male programmers are scarce, try finding a forty something female one. They are a small minority in any age group but the golden combination of being forty plus, female, and still doing actual engineering is super scarce. As in: I struggle to name a single person that qualifies as that. Most women I know that age have long stopped being engineers and have turned manager or changed career entirely. Women generally are better at soft skills and make great managers so it's not the worst thing. But there's also sexism that drives them away from engineering prematurely before they've had a chance to become really good at that. I know more than a few women that have hit a glass ceiling where people just naturally assume a lack of technical skills because of gender bias. If you have the option, balance your teams as much as you can and things will get better. Resist the urge to put the girls in charge because they are girls. That's a form of sexism that helps no-one. Instead promote them to being tech lead, senior engineer, principal engineer, etc. They'll make better managers when they are ready for that career move. Better still, they might attract some junior female talent. Women generally know where the good jobs are. I've been in a few places that had good policies on that front and it makes a difference.

> can self select themselves out of it too (by changing employer)

... who's exactly like the old employer because everybody is following the same playbook.

Wonderful comment. Mirrors a lot of what I've experienced directly or indirectly in the industry.

I'd add that mid-sized and up companies are usually not homogeneous. There are usually good and bad leaders, managers, and developers to be found within them. You can have a great experience in one part of a company and a horrible one in another part.

Another thing that I've found is that there is no "one true way" for a team to operate. I have found that what works best is to lean into a methodology that meets your business partners wants/needs and hire people that work well in that environment in that mode. Be it highly formalized and layer ITIL, super agile kanban+devops, or somewhere in between.

Im not so sure that there is anything wrong with being 40 and cynical. I would question the sanity of anyone who isn't.

To understand the angle of this article, I looked for what this site is selling: https://iism.org/training

> We have a management problem! > How traditional management sabotages the bottom line > Developers are fine, management needs to change

Folks who agree with these headlines & don't click away immediately seem more predisposed towards the offered product, which seems to be a mixed bag of developer-entrepreneur-leadership training that would make sense for a small, flat organization.

The best manager I ever had really just left the team to do its job.

I think we might only really need management on a higher lever for large projects.

We certainly don't need Project jockeys for managing very small teams.

As with many things in software, we don't have the maturity to clearly identify where the complexity and overhead are needed. A project manager for a 3 person team is like a bloated multilayer web app that gets 50 users a day. It's just superfluous.

I still believe companies should approach software development like they are producing a TV show. Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process. I get the feeling a couple of show runners would have a better time of it than most classically trained managers.

>Software development, as much as we try, is not an engineering process like widget production or bridge building. It is still by and large a creative process.

I actually think it's the opposite. Majority of the software projects (IMHO) out there are exactly like bridge building. For the most part you adhere to the same engineering principles, and depend on the budget/requirement, have some room for creativity. Some bridges are masterpieces and will last more than a hundred years while some others could collapse at any time.

Bridge building dates back to antiquity and has developed a rigorous knowledge base of tools, materials, and techniques.

Software development cannot even pick a language or paradigm with less than a century of experience. We do bridge builders a disservice for thinking that we are in their league with big project engineering.

The problem is that it takes 10 years to learn how to write software well. And after 10 years you no longer write software, you become a manager of people who are just beginning that process.

Comes down to definition of autonomy. If you loosely define the problem to be solved, it is no wonder some take a different than expected approach. If you define the problem that needs to be solved correctly, then autonomy should work as team is likely to come up with better solution. Tech is R&D and creative and the conceptual models will be different amongst the stakeholders and team - the key is make sure everyone has the same model.

Few cents from someone who moved into Engineering Management from Software dev in a high growth organisation.

30% Hiring for my team but also helping out for other teams. This also includes optimising our process etc.

15% Maturing and coordinating the tech org getting things like oncall routines in place or what forums do we need (or what should've just been an email)

20% Growing individuals through coaching and mentoring as well as finding opportunities for them to shine.

20% hands on teamwork usually being the one who asks stupid questions to ensure all uncertainties are brought up.

15% putting out fires

I'm pretty happy with this division. I'm also very happy to also have a product manager and a tech lead in my team to avoid one person wearing all those hats.

My "favorite" kind of manager:

The project is running behind. A time extension is accepted by the big-wigs. The manager quite brain-fully increases the number of tasks that need to be completed in the newly allocated timeframe.

Managers shouldn't be there to manage the people directly. They are there to manage the processes and environment. If a process isn't working, step in and prod it. Remove if necessary. Add where necessary. Sometimes repeatedly. That is, add then remove them add the same process.

To that end. Developers are there to manage the code. Apply the same rules. Don't be afraid to try last year's failed strategy. Or to take out last year's success.

I found business analysts and project managers to be wonderful.

Managers are just useless layers of bureaucracy and their job could easily be automated.

MBA programs are the easiest of all of the graduate degrees.

But because of good old boy networks, MBA program networking, and mangers hiring other managers the parasite continues to spread.

Agreed. PMs/BAs are going out of style in favor of "product managers" and it's a huge mistake. Most of my friends who are in technical lead roles would kill to have a dedicated PM to do the parts of their job they don't like and aren't great at. Given the pay differential, it would be a good trade for most employers to do this as well...

I've only had the luxury of working for one company that had BAs.

But it was absolutely wonderful.

They would communicate with the stakeholders and users and other groups to flesh out the specification.

And they would bring the specification to the developers almost fully formed with what we had to do.

So from there we just were able to just engineer! Which is really what our specialty is.

It was heavenly to me, because I find the most painful part of this career is trying to squeeze, schmooze, and cajole a coherent specifications out of stakeholders and users.

I firmly believe a good project manager can be the difference between a projects success and failure.

All problems can be fixed. How you fix them is relative to what are you trying to optimize for. If the management is bad to development culture, the developers can go elsewhere. If the leaders (including developers and management) is bad with decision making, the market will fix it.

This points out several problems which management must not create. But because engineers cannot fix these, the other side of the same coins is having a checklist of mismanagement red flags which tell an engineer to find a new company.

I think he just invented Developer Anarchy

https://www.youtube.com/watch?v=tIxHmsWCd7g

Honestly I just call this Software Literacy.

I can't help it: https://www.youtube.com/watch?v=fcIMIyQnOso

Problem is computing is overstaffed with non-technical managers that believe programming is a thing for little employees.

Enterprise Agile has made this situation worse.

It's not as straightforward as the author of this article suggests.

Not all engineers do care about whether their work serves the company's interests, and some (many?) will go out of their way to square a round hole, so to say, to justify some itch they wanted to scratch.

I know the HN take on things is that the best engineering management comes from people who are/were engineers in the past. But, respectfully, I just have to disagree that they're any better, especially if they come from "big tech" (e.g. FAANG). There's a real (terrible) tolerance for vanity projects, gamesmanship, and ego stroking that comes from that lot, IME.

No but they can bear the blame until they burn out and afterwards be replaced by a fresh bundle of youngsters. That's how it usually goes at the companies I consult to clean the mess

Reply on news.ycombinator.com