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.
The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.
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.
So in that case, the managers _were_ kind of technical but it would have been better if they weren't.
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.
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?
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.
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.
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.
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!
I'd love to be a good person, but these pies aren't going to steal themselves.
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.
pegged you correctly.
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.
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.
Even something as simple as believing when a developer says 3 weeks for something.
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.
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.
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.
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.
When something technical goes badly wrong, and there are two competing stories on who to blame, how do they decide?
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?
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?
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.
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.
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.