Actually, I should measure things external to "my subordinates". I don't know what example to present to you, let me try. I am part of team building CAD system

Actually, I should measure things external to "my subordinates". I don't know what example to present to you, let me try. I am part of team building CAD system. What should I, as a manager, measure is an efficiency of a user of our system. E.g., time to complete a task of (un)trained user, delay distribution of a response time, something like that. These are external to the development effort, generally. I emphasize that by diving into design (or, worse, development) questions I will not get a quality product. I have to measure things that no sane software developer will measure - that measurement is just not interesting as a process. I have to measure them and present to my colleagues as an external constraint to the system, for them to use that constraint to make system better. As a leutenant, you cannot win a battle by asking questions about "why have you targeted that khata on a kholm?". You assess a situation (measure variables external to each member of the platoon) and... well, that depends then. Even if I order platoon to do something it is up to platoon members to develop their ways and coordinate them. This is the case of mission-oriented tactics, which is implicitly utilized by every good SW dev team. If you still think I am bossing, have tunnel vision and enforce top-down tyranny, well, so be it.