This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.

It’s obviously way more nuanced than 2/3/5 lines of text on both sides but;

It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead.

At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do.

My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly.

YMMV with team sizes, team maturity, and where you are with your product dev.

In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.