>First, you are still thinking in terms of a top-down decision where the boss has to choose between deciding what is best, or delegating that with no further input, whereas I'm talking about creating a collaborative dialogue which may or may not result in change at all.
I think I can say exactly the same about your opinion.
I think that it is not me (as a manager) who should approach a design from a designer point of view. Not that I cannot, I should not. Shall not, if you may. And I explained what I may to do - up front specify a way for someone to change various parts of a design to experiment or alter.
Because if I have doubts about design I shall not order designer to change it. Neither shall I ask about the design rationale. Both variants are equally bad to me if I put myself in the boots of the managed one.
I have to measure through experimentation and then present my findings for designer to decide whether he is right in his decision. Because it is my job to measure and report for everyone to take actions (can be suggested by me, but that's all). "Everyone" here includes my management and employees I manage.
> I think that it is not me (as a manager) who should approach a design from a designer point of view
> Because it is my job to measure and report for everyone to take actions (can be suggested by me, but that's all).
Before you measure you first have to know what to measure, and if you really believe that engaging with your subordinates will not help you with deciding that, I hope to goodness that I will never work under someone like you. Because if you think you can determine that all on your own, that means you still are the one bossing over your subordinates. It implies tunnel-vision you have and systematic top-down tyranny (even if unintentional).
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.
I think I can say exactly the same about your opinion.
I think that it is not me (as a manager) who should approach a design from a designer point of view. Not that I cannot, I should not. Shall not, if you may. And I explained what I may to do - up front specify a way for someone to change various parts of a design to experiment or alter.
Because if I have doubts about design I shall not order designer to change it. Neither shall I ask about the design rationale. Both variants are equally bad to me if I put myself in the boots of the managed one.
I have to measure through experimentation and then present my findings for designer to decide whether he is right in his decision. Because it is my job to measure and report for everyone to take actions (can be suggested by me, but that's all). "Everyone" here includes my management and employees I manage.