Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: