[P5fRxh5kUvp2th]

The single best manager I've ever had was completely non-technical. Some of the worst I've had were very technical.

The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.

[watwut]

Absolutely worst managers I had have zero technical background. They both treated people badly and also were incompetent and did not understood our work. Which led to absurd processes, being simultaneously under pressure and having nothing to do, social issues in teams and so on.

The worst thing about outside managers is that they generally don't understand teamwork and peer cooperation. They are too used to relationships based on hierarchy, negotiation and competition. And they don't have experience of actually cooperating with same level peers.

[andirk]

I worked at a company that almost only hired [nationality omitted] engineers. Seemed their goal was to become one of the managers so they could rule the others with an iron fist, much like they had been ruled for years. The very bad code proved that the engineering part of the job was mostly nominal. As a defensive measure, they knew to never hire good engineers. I was hired by one of the directors.

So in that case, the managers _were_ kind of technical but it would have been better if they weren't.

[prmph]

Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well. On a deeper level, however, a manager who lacks any clue about the work being done will either frustrate the team or leave them to their own devices altogether. The former is bad under any circumstances; the latter is bad unless the management provided is supposed to be at a very general level.

[skeeter2020]

One of my scrum teams is all very senior developers working in a new area with lots of unknowns and technical challenges. I purposely "leave them alone" not because I'm a clueless manager, but because this type of work is always messy and will have false starts. The phrase "reasonable trust" screams "FAKE!" to me. You trust until it's broken, or you don't trust. I think what you might mean is trust but verify?

[prmph]

You're conflating "guidance" with lack of trust; the two things are entirely separate, and I'm not sure why they are being confused.

I'm leading a small (4 person) team working on a large multi-year greenfield project, and I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into. My insights, as someone who bridges the technical and domain sides are also key to the success of these meetings.

Would you say I don't "trust" the team by not allowing them to work in a silo?

[P5fRxh5kUvp2th]

> Would you say I don't "trust" the team by not allowing them to work in a silo?

Yes, this means you don't trust them.

As I've already said, I've been doing this for roughly 25 years now. I can tell the difference between a technical decision and a business decision.

Even the wording ... "by not allowing them" implies both that you don't trust them and you don't have enough respect for the authority you wield to avoid using it cavalierly. I mean "by not allowing them to kick kittens". Sure, if they're about to start kicking kittens, #savethekittens. Otherwise, let them work.

Because here's the thing. Shitty managers don't know they're shitty, if they did, they would stop being shitty because recognition is the first step to becoming a non-shitty manager.

Because it's one thing to tell me all of the developers are inexperienced and don't have these skills so you don't trust them. It's another to claim you DO trust them and treat them as if they're inexperienced developers.

[prmph]

I'm not sure if you are capable of understanding the point I'm making, but I'm going to try again (hopefully for the last time):

Please read this sentence again in my comment above: > I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into.

Without getting into specifics, the team simply does not have all the domain knowledge they need to successfully complete the project. I believe you understand what domain knowledge means. It does not mean I think the team is incompetent. No, but the client has some specific domain knowledge (not exactly related to software engineering) that should be incorporated into the project.

Now, according to the team structure, I bridge the gap between the client's domain knowledge and the team's core skills. And this is what shows that I trust the team: I schedule meetings where we all meet with the client, not just me, so that we can figure out some of the decisions together.

If my use of the word "allowing" is what is throwing you off, then let me phrase it this way: how do you expect the team to deliver a successful project by working without interacting with me and the client to acquire the domain knowledge that is needed? If you want the client and I to leave the team alone, how do you expect the team to even know what the client actually wants? The project is a large project; we are refining the specs as we go along. These are not rhetorical questions. I await your answers.

[P5fRxh5kUvp2th]

> Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?

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.

[spdionis]

Most managers I've known would love to have someone to "believe and trust" to delegate stuff to.

I feel like the micromanaging managers simply don't have enough work to do? I personally celebrate everytime I find a developer who can manage themselves, their work, and if they can also manage the team (at least partly) that's amazing!

[musingsole]

Desiring a coworker you can trust and trusting the coworker you have are too very different things.

I'd love to be a good person, but these pies aren't going to steal themselves.

[prmph]

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

Because you're not reading my comment carefully, and ignoring the caveats I've put in my comment (it's a problem I've noticed with communication in general; people respond as if I don't mean them).

This is what I said: > On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well.

So I do agree that trust is important. Feedback and guidance is not about lack of trust, and I'm not sure why you're confusing the two.

For what it's worth, I prefer a manager who is engaged with what I'm doing, not micro-managing me, but helping me to align my efforts with the overall picture.

[P5fRxh5kUvp2th]

> and I'm not sure why you're confusing the two.

pegged you correctly.

[kevin_nisbet]

My experience has been similar, I think it depends way more on the individual than whether they are technical or non-technical. I do suspect those with non-technical backgrounds are at a disadvantage though.

When I started my career I had a manager who couldn't even type, but just approached his role as I want to keep an eye on what's going on, and when I see friction or blockers I'll jump in and start working on removing those blockers.

I've seen a technical manager get promoted, from IC to VP of engineering within just a couple of years, and treat the VP role as his job is to tell everyone in his employ what to do, no feedback allowed (didn't treat those in his employ with trust as you put it). I don't know that I've ever seen a worse leader and had a litany of problems with them, and ended up deciding to leave within weeks of this person taking over. I don't even know if it's this persons fault, as the org didn't like hiring leaders externally, so basically the entire engineering org was just ICs with basically no leadership experience.

[P5fRxh5kUvp2th]

> I think it depends way more on the individual than whether they are technical or non-technical.

yep, exactly.

I think your anecdote about the engineer turned VP is fairly typical. imo it's generally more difficult for engineers to become _good_ leaders because it means moving from an environment where you have complete control to one where you don't and a lot of engineers can't bridge that divide successfully and become terrors like you described.

non-technical managers never had that control. They have their own challenges, but generally speaking, it's easier for them in terms of control.

in my opinion, of course.

[ido]

I often repeat how one of the best managers I had (he was the CEO of the company but it was a 5 person - including me - startup, so he was practically the closest thing to a manager) was a former restaurateur who never worked in software before!

[magicalhippo]

My manager has no technical background either, and for our team he's great. However, I think they key is he understands enough technical stuff and listens to reason. If we present good technical arguments, he will listen and take that into account. He won't try to force something through just because.

[ido]

Yep, he deferred to the programmers for technical decisions.

[P5fRxh5kUvp2th]

and that's a large part of what I meant by trust.

Even something as simple as believing when a developer says 3 weeks for something.

[prmph]

A technical manager might in most cases defer to the judgement of the developer. However, provided he knows his stuff, he can also mentor the developer to grow.

If you are arguing that managers with technical knowledge of the work being done are wholly unnecessary, then you are necessarily arguing that all teams are doing optimal work all the time, and have nothing to gain from external feedback.

I call bull on that. There are several times where, after discussing some estimates with my developers, it turns out that the overall approach was inefficient. By pointing them in the direction of a more efficient approach to the problem, and leaving them to work out the details, and making them feel free to discuss other alternatives, we have been able to get stuff done in reasonable time.

Your whole point of view seems to suggest some kind of conflict between technical managers and developer teams, where I see none necessarily. Managers are a resource for the team, not people who lord it over their teams.

I have been contracting and consulting for years. Without exception, the worst managers I've had in terms of demanding the impossible, and failing to appreciate the work I have put, were those without any clue what it takes to do what I did. The technical managers would work with me to write specs that made my work a breeze.

[P5fRxh5kUvp2th]

^ and this is why technical managers are so problematic.

a manager who worked as a developer for 3 years some 10-15 years ago is not in a better position to estimate the work than an actual developer with the same 10-15 years of experience. But they think they are.

And it's not just managers that have this unfortunate attitude, I see it in a lot of PM's and PO's as well.

> There are several times where, after discussing some estimates with my developers, it turns out that the overall approach was inefficient. By pointing them in the direction of a more efficient approach to the problem, and leaving them to work out the details, and making them feel free to discuss other alternatives, we have been able to get stuff done in reasonable time.

I doubt it. What I've seen is corner cutting get called efficiency only for the system to devolve over time.

What's worse is this is exactly what I meant about trust (or lack thereof). If your team is recommending an approach, take it. Believe it or not, they're aware of time.

There are always going to be times when corner cutting is needed, but if you ignore the technical needs your system will eventually be mired in shit. And your developers don't want it to be mired in shit. That you think you know better than them is telling.

[skeeter2020]

Managers can optimize for people or process but rarely do both really well; I'm not surprised a restaurateur is the exception. Their entire life is essentially keeping a highly dynamic, human-centric, likely broken system running while minimizing work in progress and focused on delivery.

[cma]

> The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.

When something technical goes badly wrong, and there are two competing stories on who to blame, how do they decide?

[ptero]

If something technical goes badly wrong there should be a post-mortem concluding with enough clariry so that it is clear to everyone what the cause was.

[marshmallowmad]

How does a non technical manager know who is doing bad or good work? I wouldn’t want to work on a team where the person in charge of my compensation can’t understand if I’m doing decent vs. great work. Leads to the best folks getting frustrated and leaving over time. Mediocrity is all that will remain if manager’s can’t understand the work their team is doing and the obstacles they face.

[P5fRxh5kUvp2th]

Is it your supposition that managers should be doing things like code reviews to ensure quality?

If they're not working at that level, 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?

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