Laissez-Faire Leadership.

I've been on several massive teams where the project managers had no idea about the tech stack, but worked so well with the dev teams that they relied on the devs to give them input on tasks and proper expectations and allowed them the ability to have a stake in the game, not just sitting there taking directions from people who know nothing about their tech stack.

I think its disingenuous to say you can't lead developers without having an intimate knowledge of the tech stack they're using. I've worked on small teams and massive teams and in only a few cases ran into non-technical managers who thought they could strong arm developers into hasty releases and poorly coded prototypes. Most of the managers I've worked with who were not technical, went out of their way to build a more affable relationship with developers since they knew we were the key to the project's success.

Yessss. So many companies dont understand that. Every time I was a part of project that struggled it was due to terrible middle managers that did not understand anything and could not decide.

They often try to dispatch ALL their work to someone beside status meetings and forwarding emails.

Useless leeches. If you are this kind of Project Manager do everyone a favor and leave.

Team will most likely not even notice you are not there.

That is not my observation.

Having some ability to program can definitely be a plus, but it is also frequently a hindrance, if the manager is not aware of the dangers.

Best managers I had were just good at managing. They did not try to make technical decisions but instead tried to figure out a process to work with a collection of various experts that would let these experts to make best use of their expertise in context of the project.

Ability to program (as in developer who has just been promoted to management role) is frequently a hindrance. It is a crutch that the new manager uses which prevents him from learning his new trade well.

It lets him understand stuff without needing to communicate with the team, it lets him see through bullshit without having to build rapport and honest relationship and it lets him make passable decisions without consent from the rest of the team.

Which works for a while but in the end tends to result in mediocre manager and team.

Also a programmer manager frequently only ever learns to work with other programmers. This might be fine for strictly development team but leaves the manager out of the water when interacting with non-development teams, clients, etc.

Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?

The entirety of your second paragraph speaks to a belief that developers can't manage themselves. That without a manager, no work would get done and no software written.

But having been in this game for roughly 25 years now, I promise you I know how to get software written successfully. What I need is the manager to __believe and trust__ me when I tell them something. There's a vast difference between a negotiation to figure out what can be done in the next 2 weeks and arguing with a fuckwit who thinks they know better than you despite moving into management after 2-3 years of software development.

In my experience, they were a developer for a couple of years 15-20 years ago and while they might think they're still a developer, they're generally more clueless than a manager who has no development background.

The absolute best manager's I've ever had were one's who still did at least some active development on the product. I know that's hard for a manager to fit in to a busy schedule but I really feel like there should be concessions made in the organization for this to happen.

You're talking as if Devs are brainless outside of programming, let's babysit them.

The best development managers/directors I've worked with were hands on, and they knew significantly more than me, they knew their stuff really well.

And in fact, the latter half of that sentence is what I meant.

I'm currently a software architect and each of the teams I work with has a very senior developer (all of them over 20 years experience). I generally communicate things that are up and coming and leave them alone. 1 of them is kind of terrible at communication so I'll sometimes have to bridge that gap, but otherwise they do just fine on their own.

The other poster claims he won't "allow them to work in a silo". A senior developer doesn't _WANT_ to work in a silo.

A good manager trusts their team and enables them by removing problems. A good manager plays the politics on behalf of their team so they can get work done. Their position has little to do with the software itself because software developers are the boots on the ground, the doers.

I highly disagree with this.

For some reason, many devs seem to think they are somehow better than everyone else, that they are the most important part of any team, that no on besides them can have any insight on timelines, or budget, on which features are or aren't important.

News flash - all of the above is none-sense. Developers are a profession that provides a specific skill, a highly valued one, but one that is a part of building things in most cases. There's nothing demeaning or wrong about devs having managers, whether or not they happen to also have been developers themselves. Some great software managers were never developers, and some great developers are horrible managers, just like in every other profession.

> It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.

Every skilled profession has people who are managed. Doctors, lawyers, they all have managers, and most of them interact with the public, who can override their expert opinions.

Wow, just a reminder that everyone's experience is unique and can't always be generalized. My first thought was "I can't imagine a development manager not doing that."

Seriously, I feel for you. Essentially all of the engineering managers I've had at one point or another have been coders. Some were well, well out of practice by the time they were my manager, and as I moved up in my career my managers were less interested in the details of my code, but I could always talk with them about highly technical concepts. I really feel bad for folks who think their engineering managers can't judge good code. And as someone who's also been an eng manager, I can't imagine managing devs without having an understanding of good code.

Out of curiousity would you say the same about product managers?

The best way to do that is to train your senior devs to act as part time PMs.

In an environmental consulting environment (not software) all projects except for really big, multiyear government contracts were managed by engineers that were the project leads. That is literally what "lead" meant - the person who led (managed) the project. We only had one actual project manager, and he was as much sales/contract development as anything else.

I was a junior engineer, and I still managed small projects. That included costing, tracking hours/labor, and making sure that deliverables were complete.

Then when I started in software development/operations, I had to deal with non-technical PMs and wasted tons of time explaining why what they wanted was either not possible as specified, or otherwise a waste of time.

IMO, if your PM is not a technical person with expertise in the area of your project, you mare wasting money by paying their salary. Get your lead devs to manage your projects as part of their professional progression. Non-technical PMs are pretty useless.

You've nailed it. This is why I would go so far as to say that someone with no programming experience can't effectively manage developers.

I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about.

If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not.

I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.

I have a hunch that this is quite rare in most companies. Most managers are unskilled enough to override their own intuitions in favor of the mediocre leetcode dev that just vetoed a strong engineer.

In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going.

I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing to help with the cost-benefit analysis for each suggested feature.

Problem is, for that, you need a developer who cares about and deeply understands the use case/the product. Many of the devs I've had to work with were more interested in building pristine codebases with clever abstractions and ability to scale to unnecessary numbers of users or bytes.

+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?

These are clearly the wrong people to be pushing into management. Good management (it does exist) includes people who have coded, but are willing to give that up to enable others to do that. They get satisfaction from being enablers and making space for their underlings to be creative and make decisions.

Further, there are many excellent managers who don't have a typical developer background, but can recognize what success means for their team within an organization and how to achieve it. I've been managed by many excellent managers with backgrounds in chemical engineering and the classics.

The developers you describe should decline these positions and find a better fit where they can make better use of their time. Choosing to accept positions like this hurts them, as well as others.

I’ve managed teams where the devs just wanted to be left alone to build things and they were skilled enough to manage their own career growth, which made my job as a manager very easy.

I’ve also managed teams where, before I took over, the devs had consistently been lied to by the organization leadership, hadn’t been given the work that would grow their skills and confidence, and needed constant coaching and a platform to vent. This team didn’t want to “be left alone to do their job”. This was a very hard management job.

Your comment suggests that you’ve only experienced the first case of being a manager, which may be why you strongly disagree with the other comment.

So the leads are de facto managers in that they're assisting the manager in managing the other developers. I think this can work, but I don't think it contradicts what I said. It just means the leads wind up doing some managing even though that's not what their titles say.