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