> 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.
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.
Right, there's no reason the designer/software engineer shouldn't take the initiative
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.
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."
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.
> 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).
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.
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.
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.