3 ms·

You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request. Please, answer to me why are you

by thesz 10y ago

You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request. Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough? The only reason I, as a manager, would like to ask questions about "blue and huge" is to provide a way to me to experiment or allow some other people to experiment and fine tune (think A/B experiments). But that would be in SOW in first place.

vanderZwan 10y ago
> You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request. 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. > Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough? I'm describing a generalised approach based on the examples in the article. If you think this is a literal example of what to focus on, then I might as well throw back at you that what you are describing with SOWs sounds a lot like the fixed, rigid waterfall approach where everything is set in stone at the start, which in the words of Winston Royce himself "is doomed to fail".[0] Which brings me to my second point: for the sake of the example I'm assuming here that this is not a bike-shedding situation where a manager just wants to change something for the sake of feeling like they added something to the conversation (in which case your only hope is to add something so trivial that it functions as a lightning rod - see the Duck story of Battle Chess[1]). Let's assume that the boss in this scenario has a reason to want to change something better than bike-shedding. Whether it's a good or bad one is to be determined. Instead of assuming either, the best option then is to engage in a (brief) dialogue to figure out said reason. The designer, being the expert, should be the best person to guide the boss and help decide the validity of said input. So the goal of this conversation is not to propose a change to "blue and huge". The goal is to approach the design from the point of view of the designer; focussing on the points that still somehow feel uneasy is just efficient since that is most relevant. By asking the designer to work us through the design process we get to ignore the first gut-feeling "solutions", letting the designer keep ownership and acknowledging that they know what they are doing. If you approach the conversation like this, most of the time it will quickly become obvious that that one of the parties forgot to take something into account: maybe the shade of blue would align more with company colours, despite not popping out as nicely; or maybe it's the opposite: the darker shade would look better, but the designer decided being consistent with the overall look of the company was more important. Furthermore, discussions like this are immensely helpful for making it clear to the designer what metters most to the client. In the end the designer can walk away with a better understanding of their client's wishes: "ok, I'll have to figure out a new balance between aligning with the the company colours while still having some pop in the overall look - and I have a bit more leeway than I originally thought." [0] https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s [1] https://en.wikipedia.org/wiki/Battle_Chess#Development https://en.wikipedia.org/wiki/Battle_Chess#Development
- thesz 10y ago
  >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.
  - vanderZwan 10y ago
    > 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).
    - thesz 10y ago
      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.

by thesz 10y ago

vanderZwan 10y ago

> You are not presenting a quantitative basis for a change. That "work me out of a design" is as diminishing as direct request. 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. > Please, answer to me why are you concerned with such minutiae next to project completion? Is the Statement of Work you have prepared with designer not detailed enough? I'm describing a generalised approach based on the examples in the article. If you think this is a literal example of what to focus on, then I might as well throw back at you that what you are describing with SOWs sounds a lot like the fixed, rigid waterfall approach where everything is set in stone at the start, which in the words of Winston Royce himself "is doomed to fail".[0] Which brings me to my second point: for the sake of the example I'm assuming here that this is not a bike-shedding situation where a manager just wants to change something for the sake of feeling like they added something to the conversation (in which case your only hope is to add something so trivial that it functions as a lightning rod - see the Duck story of Battle Chess[1]). Let's assume that the boss in this scenario has a reason to want to change something better than bike-shedding. Whether it's a good or bad one is to be determined. Instead of assuming either, the best option then is to engage in a (brief) dialogue to figure out said reason. The designer, being the expert, should be the best person to guide the boss and help decide the validity of said input. So the goal of this conversation is not to propose a change to "blue and huge". The goal is to approach the design from the point of view of the designer; focussing on the points that still somehow feel uneasy is just efficient since that is most relevant. By asking the designer to work us through the design process we get to ignore the first gut-feeling "solutions", letting the designer keep ownership and acknowledging that they know what they are doing. If you approach the conversation like this, most of the time it will quickly become obvious that that one of the parties forgot to take something into account: maybe the shade of blue would align more with company colours, despite not popping out as nicely; or maybe it's the opposite: the darker shade would look better, but the designer decided being consistent with the overall look of the company was more important. Furthermore, discussions like this are immensely helpful for making it clear to the designer what metters most to the client. In the end the designer can walk away with a better understanding of their client's wishes: "ok, I'll have to figure out a new balance between aligning with the the company colours while still having some pop in the overall look - and I have a bit more leeway than I originally thought." [0] https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s https://www.youtube.com/watch?v=NCns726nBhQ&t=8m45s [1] https://en.wikipedia.org/wiki/Battle_Chess#Development https://en.wikipedia.org/wiki/Battle_Chess#Development

thesz 10y ago
>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.
- vanderZwan 10y ago
  > 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).
  - thesz 10y ago
    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.