They Know More Than I Do

▲ They Know More Than I Do(cybadger.com)

26 points by r4um 6 days ago | 10 comments

▲ neilv 2 days ago | parent | next [-]

> When asking questions of your team, it can help to (separately) ask the same question of multiple individuals. The difference in answers can be illuminating. [...] Ask questions of your boss, your peers, stakeholders, and anyone else that might have useful information.

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 2 days ago | parent | next [-]

> ...but they don't know how good their own people are.

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 2 days ago \| parent [-]
		To maybe make trust easier, let's say there's two kinds trust: * 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 2 days ago | parent | prev | next [-]

Author here. Yes, if you don't know the domain, you should have a really good reason for overriding the team.

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"!

▲

2 days ago | parent | prev [-]

[deleted]

▲ PeterWhittaker 2 days ago | parent | prev | next [-]

One of the best project managers I know was faced with a similar scenario, and succeeded wildly by doing mostly #2, but with very specific questions: what do you need to work effectively, what is preventing you from getting this.

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.

▲

cybadger 2 days ago | parent [-]

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

	▲	PeterWhittaker 13 hours ago \| parent [-]
		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.

▲ mrkeen 2 days ago | parent | prev [-]

> 4. Be Clear About What Needs To Be Done

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.

At this point the manager is basically the dog-with-ball meme saying "no take, only throw"

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.

Button text change? From a manager? I guess this article will calibrate your expectations such that you think you aren't micromanaging when you are.

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

	▲	cybadger 2 days ago \| parent [-]
		Mgr: "I need you to plan travel to LA." 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.