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

[prmph]

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

Why do you assume this is the case here?

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

Again, "doubt" is not evidence to contrary. If you believe I'm making things up, then there is no longer any basis for a discussion.

I think you're arguing in bad faith. I therefore will not respond to your threads any longer. Have a good day.

[ido]

I don’t think they’re arguing in bad faith, only that their experience is different than yours. As with many things the answer is “it depends” and “a good manager is a good manager” and it’s hard to reduce to simple rules like “they’re good/bad if they worked as a developer before”. I had great managers who were very experienced developers (20+ years direct experience developing and still actively programming) and others that relied on a very experienced tech lead or senior developer that they could trust with technical decisions.

[P5fRxh5kUvp2th]

> I had great managers who were very experienced developers (20+ years direct experience developing and still actively programming) and others that relied on a very experienced tech lead or senior developer that they could trust with technical decisions.

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.