This is where it all goes wrong.
Your job is to make sure your team is clear about the task to be done. Yes, including the “what if…” questions. You don’t need to have the answer now, but you do need to respond helpfully to the questions.9 Once the team is clear about the task to be done, you can assign them to invent the approach, shape the details, and implement it.
Or in manager speak. "Look, just get the 'throw' done as quickly as possible, and you can suggest different ways of working in the retro. Or make a ticket for it. Do you want to make the 'take' ticket or should I?"
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.
(Also, the credential store needs to be changed because the passwords - including the manager's - are all in plaintext. But sure - it's the devs who don't understand you when the task is obviously just a text change.)
Dev: "Cool, got it."
(Having been that dev, wrong! Don't got it. Which is why, as manager...)
Mgr: "I need you to plan travel to LA. For the six of us. Planning to leave tomorrow before lunch. What questions do you have?"
Dev: "Do we have a budget or cost restriction? Is there a time we need to be in LA?"
Mgr: "Let me double-check the budget and get back to you in a few minutes. We're supposed to be in LA by 6PM tomorrow."
(Other good what-if scenarios could include that meeting the travelers are supposed to be in all afternoon tomorrow, whether everyone needs to travel together, where the group is leaving from, if the Dev should book travel or just send a plan, ...)
All of those things help shape the approach, the details, the implementation.
Because, without clarity, some manager who's not an expert and hasn't asked the right questions will say "yeah, sure, we can use the plaintext credential store Bobby threw together, it's fine, get it done fast".
When the manager is invested in creating clarity for the team (which is not the same as barking out orders or trying to "get the 'throw' done as quickly as possible), they'll take the up-front time. And when Bobby says "hey, look, plaintext credential store!", the manager can point back to the approach the team put together (e.g., salted, hashed, ever stored/logged in plaintext, etc).
Reading between the lines, it sounds like you've seen some pretty bad management, probably with a lot of short-term thinking and disrespect for "inferiors". That sucks. I've had some terrible managers too, along exactly those same lines. But I've also had some pretty good managers too. I've found that a lot of managers are terrible because they don't know better. They don't know how to support a team, or how to be clear, or how to listen. And a lot will make improvements when given some help.
In most cases, the answers were dedicated time and interruptions.
He trusted the team to know their jobs and worked to insulate them from the chaos around them. They came to trust him when they experienced what they craved, dedicated time, no interruptions.
What I dislike about the original post is that he seems to think his job is to lead and have them follow.
It isn't. His job is to support, to do the things, manage the interactions, that are preventing the team from working effectively.
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.
"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.
neilv•4mo ago
Be careful with this. Something I've seen at least a few times, and it's always gone badly...
1. A manager (or exec) has real experts on their staff telling them one thing.
2. The manager not only doesn't know enough about the domain, but they don't know how good their own people are.
3. The manager goes and consults someone outside who they think is more expert (e.g., someone they know who worked for a company that pays better, or who is, say, a professor of what the manager thinks is the domain).
4. The outside 'expert' makes some small offhand remark without realizing how big a question it was, or shoots off their mouth without having hardly any accurate information about the actual situation. (ProTip: Professional analysis is different thing than casual recreational chattering on HN.)
5. Manager comes back and overrides the team, based on what the outside 'expert' said.
6. Bad decision is implemented, morale is destroyed, the good people leave, and (AFAIK) that manager doesn't get referrals from the people who left.
jamesmiller5•4mo ago
Trust. Easily lost, hard to win and all that. If you don't actually trust those you manage you're not really operating at your best, let alone bringing out the best of your team.
It's a humbling experience tbh, requires putting your faith of success in other people, which in my experience is harder to teach (and is often learned through tough failures) than any kind of computer skills.
neilv•4mo ago
* Sometimes you implicitly trust that someone will do the right thing. Easy: you just know.
* Other times, you decide you're going to invest in trusting someone to do the right thing.
In the second kind, people can pick up on that investment, and respect it or be inspired, in which case it is self-fulfilling.
Though some people won't pick up on it, or won't care, or will think your investment is naive and to be taken advantage of.
So you have to think about how you convey it, and decide who you're going to invest in.
Investing in everyone on your team is a good default to start with.
cybadger•4mo ago
Asking questions is a way to gather information that you can then share back with the team. If I were new to a team and had a situation like what you describe, I might go back to my team: "Hey all, I was talking with Professor SmartyPants about $PROBLEM and they suggested $APPROACH. It sounded plausible to me, but y'all are the experts here. Is $APPROACH something we've thought about, and can you help me understand the pros and cons?"
The discussion that follows would help me figure out how good folks on my own team are: who considers the idea, who can explain why it's good or bad, who gets huffy when new ideas are brought.
So yes, 100%, be careful with thinking "I asked questions of a lot of people" means "now I'm an expert that should override what my team is telling me"!