> What I dislike about the original post is that he seems to think his job is to lead and have them follow.
Can you help me understand what in the original post came across that way?
Sure, managers do have a responsibility to lead their team, and they're held responsible for the results their organization team produces. That's the job. It'll look different company by company, of course. But I definitely didn't have some kind of command-and-control management approach in mind.
> It isn't. His job is to support, to do the things, manage the interactions, that are preventing the team from working effectively.
I agree! Like I wrote toward the end of the post, "The real secret of managing an expert team when you can’t do their jobs is to give up the illusion that you have to be superpowered and all-knowing. Instead, you can be the manager, supporting and directing your team, making sure you deliver results through your team."
That sounds—to me, and I might be missing something—pretty similar to what you're advocating.
The overall tone is one of "father knows best" with plenty of adversarial over and undertones. My favourite example, and perhaps the clearest, is
"For example, if you just asked them to change the text on the “Login” button, and they’re talking about new libraries and rewriting the credential store, there’s a good chance your team didn’t understand what you told them."
There is an equal or better chance that you don't understand or are completely ignorant of dependencies with which they are intimately familiar, perhaps tangled copypasta created ad nauseam in response to overbearing leaders who could not be bothered to understand.
I've seen that more than once.
In that specific instance, it would be more helpful to dive into the why while expressing the surprise you actually feel. It might even be better to go straight to "is there something in there that shouldn't be?"
If your team has history you lack, one of your first jobs is learning the pain points and gaining enough of their trust that they will show you the scars and explain how they were earned.
I've certainly been misunderstood more than once. I've also misunderstood people who thought they were being perfectly clear.
That particular example is intended to be an example of a well-intentioned manager sending a message but it not being received. Maybe it's time pressure, or an interruption, or just bad wording. "Y'all, we need to change 'Login' ...oh, hang on, I need to take this call."
The next paragraph is an example of exactly what you're talking about—where the team shares information with the manager, the manager learns something about the system, and it leads to improved trust between team and manager.
I think you're taking "there's a good chance your team didn't understand what you told them" to mean "your team is so dumb they don't understand basic words and you need to correct them". It's meant as a value-neutral description of something that's really common in human interactions: someone tries to communicate X, but what's received is different than X. In this case, that's on the manager to fix.
So...how could I edit that paragraph so it comes across better, without trying to incorporate some of the things that came before (admit you're not the expert, ask questions, etc)?
I could make it even more ridiculous:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about how that means upgrading the load balancer and switching to a NoSQL database, there's a good chance your team didn't understand what you told them.
I could try to make the error attribution more obvious:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance you didn't communicate what you thought you did.
I could add some corrective actions later on:
> For example, if you just asked them to change the text on the "Login" button, and they're talking about new libraries and rewriting the credential store, there's a good chance your team didn't understand what you told them. Take the time to make sure they understood correctly. If they did, you've got something to learn.
I think you're railing against the exact sort of thing I'm working to fix here: people who think their title means they don't have to listen to their team, or that they're automatically an expert because of their title, or something. So your input on how to make it land with you (because it obviously didn't as originally written) would be helpful.
Can you help me understand what in the original post came across that way?
Sure, managers do have a responsibility to lead their team, and they're held responsible for the results their organization team produces. That's the job. It'll look different company by company, of course. But I definitely didn't have some kind of command-and-control management approach in mind.
> It isn't. His job is to support, to do the things, manage the interactions, that are preventing the team from working effectively.
I agree! Like I wrote toward the end of the post, "The real secret of managing an expert team when you can’t do their jobs is to give up the illusion that you have to be superpowered and all-knowing. Instead, you can be the manager, supporting and directing your team, making sure you deliver results through your team."
That sounds—to me, and I might be missing something—pretty similar to what you're advocating.