Yup, pretty much this. Thank you!

Yeah but you can't be consistently fully mathematically correct with people around you, its often the parts you don't even realize have some room for mis-interpretation that tend to bite back hardest IMHO

The problem with leaving little to assumption is that is tends to be verbose and people tend not to like to listen to long speeches and will simply not read long text. So, as everything in engineering, it's a tradeoff.

My spouse gets frustrated with me for being too verbose in my requests, and also frustrated with me for following instructions in "the wrong way" when those requests were under-specified in the first place. Knowing "the right level" to communicate requests can be challenging in any relationship, even one with 20 years of shared experience to fall back on.

I micromanager will work around that by splitting the requirements up in tiny jira tasks that cannot be ignore easily, and then follow up daily on every single task.

This completely kills initiative, tough, and may reduce the value added by each team member by 50% or more.

The only time to use such tactics is with someone who is acting in very bad faith and at risk of being fired. It can be done for a while to establish an example, while rewarding better behavior with more autonomy gradually.

If they still ignore the instructions, then that's proper grounds for firing them (even in Europe), and if they chose to leave because of it, well, that's ok too.

Yeah but then you write out a spec that costs you a ton of time, that won't be read, or won't be followed to the letter, and you'll be known as someone who obsesses over specifying things. If you spend that much effort communicating what's needed, you might as well just do it yourself.

(I have no idea what your generalized statement is in relation to btw, so I could be talking out of my ass as well, lol)

The other pitfall of trying to clarify all assumptions is that your message then becomes too long. Then the reader actually will skim over the main points, which makes it worse.

So yeah, it takes a lot of works to communicate efficiency, no matter the length of the end results

I have the opposite takeaway. If I experience that people follow my input too literally, I try to figure out which of the following three applies:

1) I've been micromanaging them too much, and they stopped thinking for themselves. Possibly partly because they were lazy, or annoyed or because they thought it was ok.

2) They don't have the ability to see that my instructions did not make sense in the situation they're in. Maybe they didn't have the training, self confidence or initiative to realize that the instructions were assuming a situation that was different from the actual one.

3) There is real bad faith involved.

Most cases fall roughly under 1). In that case, the proper response is to reduce the level of micromanagement, and let the people figure more things out on their own. That means that even when I spot that they're making minor mistakes, I need to keep my mouth shut. People need to make mistakes sometime so they can learn from them. If they want to discuss those topics with me, I will try to treat them as peers not subordinates. While doing this I also try to make it clear that I expect independent thought.

Then there are the cases that fall under 2). In those cases, I try to give tasks or instructions that are either intrinsically easier, or if that is not possible, I may break the tasks down to more manageable units, while trying to actively provide training and mentoring.

The rarest case is 3) If this is the case, I will provide some push back. Luckily, as a tech lead, I don't have direct reports, so I can refer such cases to the line manager if it gets too bad.