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.

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

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

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

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

My cherry picked list:

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

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 :-))

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.

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

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!

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

This issue is not limited to developers.

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

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.

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.

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

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

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

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.

(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?)

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.

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

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.

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.

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.

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.

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

Let me know :)

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.

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

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.

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.

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

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.

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

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.

Project managers are a different story.

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.

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

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.

+1

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?

  What exactly is the value provided by a manager?

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)

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.

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

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

So how much management is really necessary?

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

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.

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.

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

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.

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

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.

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

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

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.

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

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.

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

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.

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.

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

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.

2) Agile still comes with meetings

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

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.

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

Like manager, or director, product, product marketing?

The world looks very different from there.