4 ms·

The open question does not always work. I'd say it never works, even. If I take "coaching" attitude, I will take attitude of sports coach - observe, measure an

by thesz 10y ago

The open question does not always work. I'd say it never works, even. If I take "coaching" attitude, I will take attitude of sports coach - observe, measure and explain why corrective action is needed. The action itself is a choice, mostly, but manager and coach should present a basis for it. Continuing my my rant, I emphasize that manager and coach are external to the team, they view performance from outside (and often prohibited to look under the hood). This is the reason why open questions do not work - difference in view points creates difference in the context.

vanderZwan 10y ago
I thinks specific questions would work well. To use the bad boss example: > I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great! Let's change this to: > I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'. (This honestly still needs a bit of work, but is getting there) In this phrasing we show interest in the designer's work, respect their choices and don't assume our ideas are better than theirs. Instead we assume they know what they are doing and give them the space to convince us and also tell us what parts of the design do and do not matter to them, before engaging in giving proper feedback. The big issue with the cited bad example is that the boss doesn't say why the design needs a darker shade of blue, or why the word ‘giant’ has to change to ‘huge’. It doesn't give any other feedback than "this is wrong, this is the fix". It's not open for debate.
- jnbiche 10y ago
  >> I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great! >Let's change this to: >> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'. Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way. Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...". Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys". That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
  - deleted 10y ago
    [deleted]
  - vanderZwan 10y ago
    > That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying. Right, there's no reason the designer/software engineer shouldn't take the initiative
- 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
sumo89 10y ago
Saying "this is how to improve" is fine and all, but it's much more effective when the methods to improve are thought of by the person they're for. That's what coaching is, helping people realise the steps they need to take to get to the end goal.
- thesz 10y ago
  I cannot agree more. This is why I propose measurement and observations with the report of the results to the people who should change. Probably, with a set of options of "how to change", just to spark a thinking or discussion.
tedmiston 10y ago
> The open question does not always work. I'd say it never works, even. IMO whether it works varies a lot by the employee's experience level. For a long time I tried to help junior engineers in the same way I would want to be helped (minimally, open ended, high focus on code quality), then got frustrated when the results weren't what I expected. Catering your message to the audience is one of the best pieces of management advice I've received. I'm not actually a manager, but as a senior dev, similar situations arise in code reviews.

by thesz 10y ago

vanderZwan 10y ago

I thinks specific questions would work well. To use the bad boss example: > I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great! Let's change this to: > I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'. (This honestly still needs a bit of work, but is getting there) In this phrasing we show interest in the designer's work, respect their choices and don't assume our ideas are better than theirs. Instead we assume they know what they are doing and give them the space to convince us and also tell us what parts of the design do and do not matter to them, before engaging in giving proper feedback. The big issue with the cited bad example is that the boss doesn't say why the design needs a darker shade of blue, or why the word ‘giant’ has to change to ‘huge’. It doesn't give any other feedback than "this is wrong, this is the fix". It's not open for debate.

jnbiche 10y ago
>> I like it! Really good. Maybe just a darker shade of blue there, and change the word ‘giant’ to ‘huge’. Other than that, it’s great! >Let's change this to: >> I like it! Really good. Can you briefly work me through the design process behind it? I'm particularly interested in how you settled on the colours over there, and your ideas behind the word 'giant'. Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way. Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...". Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys". That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.
- deleted 10y ago
  [deleted]
- vanderZwan 10y ago
  > That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying. Right, there's no reason the designer/software engineer shouldn't take the initiative
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

sumo89 10y ago

Saying "this is how to improve" is fine and all, but it's much more effective when the methods to improve are thought of by the person they're for. That's what coaching is, helping people realise the steps they need to take to get to the end goal.

thesz 10y ago
I cannot agree more. This is why I propose measurement and observations with the report of the results to the people who should change. Probably, with a set of options of "how to change", just to spark a thinking or discussion.

tedmiston 10y ago

> The open question does not always work. I'd say it never works, even. IMO whether it works varies a lot by the employee's experience level. For a long time I tried to help junior engineers in the same way I would want to be helped (minimally, open ended, high focus on code quality), then got frustrated when the results weren't what I expected. Catering your message to the audience is one of the best pieces of management advice I've received. I'm not actually a manager, but as a senior dev, similar situations arise in code reviews.