Don’t fix their decisions. Help improve their decision-making instead.
If you have any kind of lead role on your team, then you're responsible for giving feedback on other people's work and decisions. Naturally, you may find sometimes yourself disagreeing with conclusions that other team members have made. This could happen with one of your junior teammates, a higher-up, or perhaps a peer in another department.
While it may be tempting to simply prescribe a different solution or even explain to someone why their conclusion misses the mark, it is significantly more important to focus on how someone reached that conclusion than what their conclusion is.
For each decision that you’re trying to catch and correct, there are a dozen decisions that you’re not even aware of. If you want to empower people to make good decisions on their own, focus on their decision-making instead of their decisions.
The key is to stop giving answers and start asking questions.
A few scenarios
What makes this method so effective is that you can use it to manage down, up, and across people in your company. To illustrate the similarities and differences, I’ll cover these three scenarios separately:
A junior team member suggests an approach that you think is wrong.
Someone with higher authority than you makes a decision you don’t agree with.
A peer shares a conclusion that you don’t find convincing.
A junior team member suggests an approach that you think is wrong.
When I was a tech lead, I was close to the code and usually drove the major projects on my team, so I knew largely what was going on. Even if I wasn’t directly working on something, the other engineers on my team would typically ask for my input. I felt good about the technical direction and that we were making good decisions. After all, I was the one making most of them.
This changed when I became an engineering manager. I was no longer the primary contributor to major projects. At first, I tried to stay on top of every pull request and look at every line of code that was being added to the codebase, but even that quickly became unsustainable. Even if I could continue doing that, I would be undermining the new tech lead and the team would feel bottlenecked by how quickly I could review things. I knew I couldn’t be the person driving the decisions anymore, but how could I still ensure the team was making good decisions on their own?
As a senior team member, you'll often be mentoring or coaching more junior teammates on their decisions. In this scenario, the reason to focus on decision-making over the decision itself is to ultimately train the other person to make better decisions on their own. If you simply give the person a different answer, you're robbing them of the opportunity to learn and think for themselves. If they're in a similar situation in the future, are you confident they will reach a better outcome without you?
Let’s take for example a junior engineer proposing a solution that fails to meet the goals of the project.
Say "This approach isn't going to work. You should do XYZ instead".
- While direct, this often deprives the person of a learning opportunity. In the case of someone making a typo or silly mistake, it might be fine to just call it out and move on. If it's an important mistake though, you should give them a chance to reach that conclusion themselves and suggest their own solution. If it still misses the mark, nudge them in the right direction but don’t immediately jump to a direct suggestion.
Ask "What were you thinking?", "Did you even read the spec?", or a similarly vague, un-targeted question.
- While this is technically a question, it rarely leads to an honest answer. The tone comes off as an attack on the person's abilities rather than the objective decisions themselves. Most of the time this will just cause your team member to get defensive or resentful and is counter-productive to the discussion.
Ask "I'd like to better understand your rationale for this approach. What tradeoffs did you consider when deciding to do XYZ?"
- Start with genuine curiosity and encourage your team members to explain their thinking. It's reasonable to expect that anyone should be able to justify their decisions. If it becomes clear they didn’t think it through, well at least now they are.
Ask "How would this work if X scenario happens?"
- Sometimes people might not have the same context or line of thinking as you. By giving the person a chance to explain their thinking for a specific scenario, you can help them or potentially reach the same conclusion as you without having to directly say it. You may even learn something new from the exchange.
When you focus on understanding the factors that went into the person's decision instead of just the correctness of the final decision, you're coaching your team members to be able to make better decisions on their own and develop good communication skills that will benefit them in their future careers.
Someone with higher authority than you makes a decision you do not agree with.
When I first started at Yahoo as a fresh college grad, if our CEO told me these were the company goals or my manager put me on a project, I didn’t think too much about why we chose those things, I just focused on how well I could contribute to it. If did disagree, I’d only bring it up in passing with colleagues or try to put myself onto projects that I was more excited about.
As I developed more experience and saw how some of those decisions played out over the years, I started to form my own opinions about which decisions seemed good and which ones did not. By the time I became a manager, I became responsible for not just executing on these projects, but advocating for which projects to take on and often having to push back in tactful ways. If I went along with a “bad” decision that someone higher up made, my entire team would be affected it. How could I influence or better understand these decisions that weren’t up to me but still had a significant impact on my work?
In contrast to giving feedback to a junior team member, sharing feedback or disagreeing with someone with higher authority can be quite daunting. In this scenario, focusing on decision-making over decisions allows you to better understand how leadership is thinking and what their priorities are. Only then can you effectively identify points of leverage and offer suggestions that might differ from the decisions other leaders make.
An example is a product leader deciding to prioritize certain roadmap items over others that you think are more important.
If you repeatedly disagree with someone but don't voice it, you have fallen into the pattern of learned helplessness or ruinous empathy. Once this becomes a pattern, it can be hard for you and those around you to break out of it.
As the saying goes, “The only thing necessary for the triumph of evil is for good people to do nothing". Your coworkers are probably far from evil, but choosing to say nothing could result in a failure that could have been easily prevented. I really can't emphasize enough how important it is to speak up, even when you're not completely sure who’s right. In order for disagree-and-commit to work, you have to express your disagreement first.
Say "I don't agree with this" or "That's not a good idea."
I know I just told you to disagree, so why is this bad? While there are some important times to take a hard stance, most of the time directly challenging the decision right away is going to backfire by causing the other party to become defensive or try to ignore you. Since you have less authority in this scenario, you need to be tactful to get your message across.
If you have a good relationship with this person, being direct can still work. Still, I think you can be more effective by reserving immediate judgment and starting by asking questions.
Ask "What factors lead to this prioritization?" Or "Where can I find the <research | feedback | metrics> to learn more about this?"
By seeking to understand the other person's decision-making first, you can learn what they are valuing and how you can help achieve their desired goals in potentially other ways.
Furthermore, asking where you can self-serve the inputs to the decision is more useful than just asking for justification because you can go to the source yourself. That will give you the option to look at the data and possibly suggest alternative conclusions or observations that could change the decision.
Ask “What feedback would you like on this decision”?
- A great way to make it easier to deliver difficult feedback is if the person explicitly asks for it first. Sometimes you may find that the answer is the decision has been made and there’s no room for discussion. Often times though, you may find that good leaders aren’t 100% sure of every decision they make and even if the general direction of the decision is final, the means of getting there could be up for discussion.
Ask "How will we evaluate if this is the right or wrong decision"?
- Sometimes it's hard for you or anyone to know what the right decision is. In that case, it may be more helpful to know how to assess the decision going forward so you can revisit the decision in the future.
A peer shares a conclusion that you don’t find convincing.
Back when I worked as an engineer at Intercom, I attended a design critique where our team’s designer was walking the leadership team through a big new feature we were developing. During that meeting, I saw a few things throughout the presentation that didn’t make sense to me and called them out to talk about them. After the meeting, the designer pulled me aside and asked if we could talk.
In a private room, she told me that the way I brought up those issues during the meeting hurt her credibility with the leadership team and made it feel like we weren’t on the same team. To make progress, she had to sell our stakeholders on the overall design and while the things I brought up were valid, it wasn’t the right time or place to surface them, especially if they weren’t core to the overall design.
I learned then that just because someone is a peer, it’s still important to deliver feedback at the right time in the right venue. I appreciated her bringing up her feelings after that meeting because we were able to agree on reviewing the designs 1-1 next time so I can still share my feedback, but I would also be more cognizant to back her up in those high-stress meetings and feel like we’re on the same team.
If you're working with a peer, you're both reviewing and collaborating on their work. In some cases, you might feel unsure about a decision that a peer is making. When working with peers, focusing on decision-making over decisions fosters a more collaborative working relationship. If you can understand the factors that led to a proposed decision, you can collaborate on the problem together instead of butting heads.
An example is a designer proposing a design that doesn't "feel" right and you’re not sure if that’s going to be a real problem or if it’s your own biases kicking in.
Say "This doesn't feel right to me."
- This type of feedback is extremely common for design and unfortunately nearly impossible to act upon. Is it the layout? The colors? Do you think it doesn't solve the problem? Be as specific as possible. Don't make the other person play 20 questions to understand your feedback.
- This is the same as the previous scenario. If your gut is saying that something is wrong but you don't express it or act on it at all, you're doing everyone a disservice as well.
Rattle off a list of issues and problems off the top of your head.
It’s not just your teammate’s responsibility to process your feedback. You have an obligation to think about the best way to deliver your feedback too. If something is really important, make it clear that it’s important. Conversely, if it’s just a suggestion or not that big of a deal, please make that very clear.
In a real-time meeting, it’s often better to just focus on the top 1-3 issues. If you have a bunch of small critiques or notes, leave them in writing in a place where both of you can easily see and discuss them on a micro level.
Start with "What kind of feedback are you looking for?"
- This is a powerful tool when communicating with peers because you an inviting the other person to open themselves up to your feedback. If the topic that you have an issue with is something that they're still working on or not looking for feedback on, then you've also saved a lot of time.
Start with "What goals are you optimizing for?"
- Similar to understanding what feedback the other person is looking for, it's helpful to know what they are trying to accomplish. Since you're working with a peer, it's important to strike a good balance between trusting their judgment and being a collaborative partner. Once you're both on the same page in terms of the type of feedback and the goals, then whatever feedback you want to share becomes much more effective because you can give feedback on the decision-making and not necessarily the decision itself.
Start with "Who is the decision-maker?"
- If you're not a designer and you're giving feedback on design, it can be helpful to reiterate who is ultimately responsible for the decision. Sometimes we have feedback to share but don't expect it to be immediately acted upon. Simply establishing that upfront can empower your peer to consider your feedback without feeling pressured to act upon it. It's ultimately better for everyone to have ownership over their domain and feel empowered to own their specializations. That's why they were hired after all.
The next time you find yourself in any of these situations, consider taking a step back and seeking to understand how the person you're talking to came to their conclusion.
Most decisions aren’t life-or-death. They can be reversed and we can live with their consequences. In fact, making decisions and seeing how they pan out (for better or for worse) is the best way for people to learn. Don’t rob people of that opportunity.
Your job as a leader is to help people make better decisions, so help them think through their decision. Challenge directly but with empathy, and help people see the impact of their choices.