Any team member that continuously talk high-level who’s not willing to or not able to go down to numbers (measured values) – whether it’s timeline, money, percentage of success or failure, people in the team, number of meetings needed – eventually makes me sick at least because I don’t see and have never seen an on-going high-level discussion that produced any fulfilling outcome, or any particular artifact – any ultimate value (“ultimate” as opposite to some “intermediary”).
It may feel that talking high-level is something that can cut off the sharp corners and maybe keep the participants of a conversation to feel less stressed, less pressure, having more room for discussion. It may… sometimes. But if pretty much all that you’ve achieved/built in the significant percentage of cases/conversations is a “room for discussion”, then, pretty much everything of what you can get next is just the next discussion. And then some people may wonder “why does that app still haven’t been built”, “why it’s taking that long”, “what have the engineers been doing all that time”. For better or worse, in many cases the thing that engineers were doing was exploring that “room for a discussion” to see how much was there in that room, if anything at all, other than bare walls.
If you think that a lack of precise expectations and clear instructions is something that allows your team to be more “free and creative”, you may be wrong. Because the other result of the lack of precise expectations and clear instructions is a team with too few (if any) people being productive – too few people that make a reasonable amount of meaningful contributions. And arguably the worst thing those people may hear next from a management team, in essence, is “I don’t know and don’t want to know the details, I can’t tell you the exact decision about the next priorities, but we really need to move faster and be more productive”.
I’m arguing that the only measure for the engineer’s productivity is the amount of properly formatted artifacts that they produce. If the number of all combined properly formatted artifacts that the engineer or designer produced over a period of time isn’t less than expected and you still don’t have a working solution, it’s not the engineer’s problem. It’s your management problem.
“Properly formatted assets” can mean
* a code that compiles and pass sanity tests,
* a documentation that looks reasonable for at least one more colleague who’s familiar with the terminology and context,
* visual-design assets (mock-ups) that follow the conventions team agreed upon