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

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

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.