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.
> 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.
Yeah. They think you're too weak-willed to just outright state your opinion and instead passively-aggressively point out what you really mean.
Passive-agressiveness exists but reading everything into that context just makes for poor workplace performance IMO.
Don't worry about me. Only three people I know have managed to seriously annoy me over the last >15 years and they all had to work for it (although it seemed to be quite effortless for at least two of them : )
I hate being slow rolled to idea or opinion..
If you have criticism about my work come out with it, I am not some delicate little snowflake, if there is better way I want to know.
Guidance (or "slow rolling") helps with strong/deep learning and enables opportunities for conversation.
If you trust your boss/coworker, considering letting them continue when they start such discussions.
If you don't trust them or feel frustrated/patronised while they're talking, then you have other issues...
Trust has nothing at all to do with it, nor does ownership as the article implies as I do not own any of the idea's or work I produce for my employer. That is the purpose of my employment, I trade my skills, knowledge and experience for currency.
My employer trusts my boss that is the only Trust that is required, I give my input based on how I see things, if they accept it great, if they want to go another route or use a different idea that is fine as well.
I do not have these types of emotional attachments to my work
This is where coaching skills as a manager can prove useful. If you feel there are some minor changes that could be an improvement, but don't want to impose your will/opinion, coaching ('ask') can be a better response than managing ('tell').
For example, you might ask "If you had to improve anything, what would you change?" It's an open-ended question that will encourage your team member to think. They can reply "Nothing" if they're confident in the final solution, or they may propose some tweaks they weren't fully happy with - "I'm not sure if that's the right shade of blue" or "I think that's the right call to action, but maybe we could get another opinion". If those are reasonable improvements, empower them to implement the additional change; if you disagree with the extras they raise, tell them you consider the version they proposed to be superior, which empowers their original decision.
Just don't be the manager who expects a detailed response and change every time ... then you're right back to where you started.
[1] See point 5 https://blog.codinghorror.com/new-programming-jargon/