[prmph]

> why isn't the output enough? Developer X's solutions are solid, developer Y's solutions tend to need bug fixes for the next 2 months, who is performing better? Why can't a non-technical manager do that too?

How would a non-technical manager know that? By examining the git commit history? Or having the team tell on each other?

And if developer Y's work tends to need bug fixes, it might be that he usually works on a more difficult class of issues. How is the non-technical manager going to understand that?

[P5fRxh5kUvp2th]

After seeing this post my opinion has finally clicked over to "you're a shitty manager".

You're imagining a managers job is to ensure quality. That's a tech leads job. And QA, if you have them.

You're imagining yourself as Gandolf with the staff of perfection screaming "You shall not pass".

That is not your role, nor has it ever BEEN your role.

What's worse is that you're implying that you cannot manage teams working with tech you yourself have not worked with. This means you cannot manage projects that are in rust, lisp, perl, ruby, python, GCP, or any other technology that you yourself are not both familiar with and an expert in. When your company decides to move to the cloud and they choose GCP but AWS is the only thing you've seen, do you recuse yourself?

And when you hire a developer with 5+ years experience in GCP, HOW DO YOU MAINTAIN QUALITY?

The answer is you do it the same way the non-technical manager does it.

What you're not understanding is that your developers are BETTER THAN YOU at their job.

Just yesterday we had an interview with a senior manager who is being hired to take over the three teams I mentioned in another post that I regularly work with, 3 teams that have 20+ year developers on them. I gave him a thumbs down based solely on the fact that when he has someone who isn't performing up to expectations, he starts reviewing code. I do not want that for these teams, or the senior developers on them. Furthermore, I know if we hire someone like that, they will leave. I know they will because _I_ would leave. Furthermore, this department is in a bit of a political fight with another technical department. Them leaving means this department automatically loses that fight.

The problem with shitty managers is that it can often be very difficult to fully quantify their effects on the organization because any single instance of it can be very subtle.

The question is, how do you quantify a managers output?

And the answer is you do it the same way a non-technical manager does.

You don't need to be able to read code to know your Toyota should not force accelerate on its own.

[prmph]

I think you’re having a pretty narrow understanding of the word “manager”. All your argument ms boils down to an inability to perceive that I’m using the word manager in a general sense, as someone who manages technical developments. I’m not referring to a political manager.

Indeed if the only value added by a manger is to play politics, then I’m not sure whether the word manager should even apply to such a person.

How a good day, and best wishes with your “management” style.

[P5fRxh5kUvp2th]

right, you can't imagine that working, can you?

The reason we're looking for a manager is that there isn't one, but the show must go on. One of those 3 teams was managed solely by me after it was created to build a new integration with a 3rd party vendor.

Once that integration went live someone on the business side sent out an email to everyone in the company and said they had never seen a project go so smoothly in the multiple years they had been there.

Yet here you are, unable to even _FATHOM_ such a thing working successfully.

What makes it worse is that Joel Spoelsky was talking about this in the late 90's, early 2000's, it's what made me originally start thinking about it. This aint new.