On Giving and Receiving Feedback
I wrote this to share with my students for an iOS app development class I am teaching at the University of Colorado's ATLAS Institute. I want to provide a framework for how I give feedback, and to encourage my students to take a thoughtful approach to working with others.
These are some thoughts that I've developed in my experience working with teams that make software. While much of this relates to what I've learned in the context of software development, I believe these things to be generally applicable to life and relationships.
The Purpose of Feedback
The immediate purpose of feedback is to improve the quality of whatever is being worked on. But the process — if done thoughtfully — can lead to something deeper and more significant: the growth and improvement of the people involved.
Receiving Feedback
People are sensitive about their work. I am. Hearing feedback about your work can be uncomfortable. And the more care and thought you put into it, the easier it is to feel defensive or hurt when criticized.
Most people simply can't receive "negative" feedback in a constructive manner1.
But if you truly care about your work and you want to get better, you must learn to invite feedback and receive it constructively.
Without perspectives from other people, our work will never become as good as it could be — and neither will we. Learning how to receive criticism earnestly is difficult, but important. To spurn criticism is a wasted opportunity. Whether the criticism is valid or not, there is usually something to be learned.
When your work is criticized, that's an opportunity to question why you did it that way and to explore your work more deeply.
If you question yourself and find the criticism to be misguided, now that's an opportunity to defend your work and explain why you did it that way. This gives you the valuable experience of explaining and articulating your reasons, and it provides an opportunity for the other person to grow or learn something too.
Remember that no matter how invested you are in what you do, you are not your work. And seek balance in your life, so that you are not invested in your work to the point at which it defines you.
Providing Feedback
Some goals I have when providing feedback are:
- to improve the product
- to treat people well and to encourage their growth
- to get what I want
Ideally, these are all the same thing. If "what I want" is not aligned with the previous goals, something is out of balance.
It's not just that I think what I want is always the best decision for the product — but I believe that great products require the people who develop them to fight for what they think is right.
With that in mind, some of what I'm discussing here is about effective persuasion. Being persuasive2 is a bit of an art; it requires delicacy, nuance, and intuition. I hesitated to include thoughts about persuasion in this essay, but in terms of being effective in my work environments, I consider it to be an incredibly important skill that has benefited both me and my clients.
Tone
People have different ideas about what makes for an appropriate tone to use when providing feedback. You have to find what works for you and those you're working with. Effective communication considers the target audience, so your tone should appropriately differ based on who you are communicating with.
Personally, I prefer a straightforward, concise approach to feedback. Focus on the work, not the person.
My ideal team would be made up of people who respect one another and provide straightforward and thoughtful feedback that challenges the others to do their best work.
Too Hard
I've seen people give valid feedback in ways that are simply too harsh for the feedback to be received well. And unnecessarily so. If you want your feedback to actually matter, it must be positioned with care.
One pitfall is to treat the product as the ultimate goal of utmost importance. That's what we're all here to work on, right? But the way we treat other people is important, too. The way you treat others reflects strongly on your character, and it affects your ability to be effective in your work environment.
There are people who are smart enough or indispensable enough to get away with some pretty bad behavior for a long time, but that usually turns out poorly for everyone involved. How about being stellar at what you do and treating people well? Now that's something to strive for.
Too Soft
I've also seen people trying to be sensitive to the point where it becomes counterproductive.
For instance, if there's a typo, saying "maybe this word should be spelled correctly? What do you think?" isn't a helpful tone. It introduces uncertainty to something that should not be uncertain. The example may be a bit drastic, but I've seen people communicate that way. When there is ambiguity, it leads to unsure expectations, and trying to soften feedback too much can often lead to more frustration and hurt feelings in the end.
Sensitivity is important, but to be overly deferential isn't a true sign of respect. I think we should show respect by providing honest, thoughtful criticism.
Use phrases like "I think ...", "maybe ...", "do you think ...?" honestly — not just to soften your feedback. Say what you really mean. Do not equivocate.
Just Right
Ultimately, it's all about balance. The key is to cultivate environments in which feedback is expected and appreciated.
I'm all for tearing apart designs and learning from each other. I quite enjoy that. But a relationship needs some bones before it can stand up to that kind of criticism, so tread into that carefully.
Read the environment, and do what you can to improve it.
Encouragement
Learn to encourage others.
I don't think that "negative" feedback should be book-ended with positive statements. I find that practice to be condescending and ineffectual.
I do think it's important — and often more effective — to give positive feedback as well as negative. It's easy to take the good for granted and mainly notice what you don't like. It takes an active effort to keep an eye out for the good, and to recognize and encourage it.
Point out good design, things that are well done, things that you like. Express appreciation for attention to detail, the amount of hard work that went into something, and the ways in which teammates are growing and improving. Be genuine.
One of my favorite ways to do this is to point out things that I learn from others. When reviewing code, I like to look for interesting ways of implementing things that I wouldn't have thought of, and am always looking out to learn new APIs or language features that I'm not familiar with.
Adopting this practice helps you learn more than you would if you're only looking for the negative.
Ask Questions
It's often better to say "is there a reason you did it this way?" rather than stating how you would have done it yourself. If you don't understand how something works, ask about it. Demonstrating that you are willing and eager to ask questions and learn from others fosters an environment in which feedback is welcomed. This is important regardless of your experience or seniority.
Asking questions is often more effective than making statements, and it opens a line of conversation in which everyone can learn.
Offering suggestions for improvements is better than simply pointing out problems. It's okay to say "I don't think this is great, but I don't have a solution in mind yet." But you should at least explore solutions yourself before saying something.
Things to consider:
Is the feedback expected or requested?
In most software engineering teams, developers are expected to review one another's code, so in the context of code reviews, my feedback is expected and desired.
As a software engineer I am primarily hired for my skills in writing code and I am often tasked with implementing existing "finished designs" that were designed by professional, full-time user interface designers. As much as I would like my clients to see me as a more than "just an engineer" I recognize that it is not often the case, especially at the beginning of an engagement.
With care, I have been able to earn some respect in those areas by carefully providing unrequested feedback in a manner that can be well received.
Stereotypes being what they are, it's often hard for software engineers' design opinions to be taken seriously. But many caring software engineers know the platforms and interface patterns better than a lot of designers do. I've seen this lead to a lot of frustration, but thoughtful communication and feedback can help.
Everyone has different goals, priorities, and knowledge.
Don't assume that others are going after the same things you are. Find ways to get what you want that also fulfill the needs and desires of others.
Is it the right time to present your feedback?
It's best to address overarching design concerns at the beginning of the process — before a lot of effort goes into implementation. Try to spot problems and express concern as early as possible in the design process.
Sometimes problems don't show themselves right away so that's not always possible, but try to be proactive in identifying possible issues.
Are you feeling angry or upset about something that just happened? It might be good to wait a bit before responding.
You don't need to say everything.
I have often found that it is more beneficial to provide feedback on just the most important issues, rather than pointing out everything that is wrong.
There's a certain pleasure to tearing apart a design when you can find 1000 things wrong with it. But to communicate effectively and get what you actually want, you must learn to show restraint.
In fact, if a design has serious flaws, you can often get the whole thing reconsidered by pointing out just one large problem. This can help preserve your influence and reputation. If you try to assert superiority by exhaustively criticizing something to the best of your ability, you can develop a reputation for being difficult, and people will be less likely to want to involve you in the future. It's no wonder. People just don't like their work being torn apart.
Being concise is also valuable in terms of people receiving what you want to communicate. Your feedback should be as long as it needs to be, and no longer. It's hard to leave things out, but you have to choose your priorities wisely.
When a Decision is Made
Move forward, and put your heart into it. Don't be bitter if things didn't go your way. And there's no need for a snarky "I told you so" if things go wrong and you saw it coming.
As iron sharpens iron, so one person sharpens another. Steve Jobs compares a team working really hard at something they're passionate about as being like a rock tumbler, in which they polish each other and the ideas they're working on.
Strive for relationships that invite and hold up to mutual criticism. Nurture your relationships so that criticism can be both given and received, and avoid those that cannot learn to receive caring criticism, yet give their own in an uncaring manner.
So please, criticize me my work. But do it thoughtfully. Do it with an open mind. And do it with good intentions.
- This study explores how people respond to "disconfirming feedback" and finds that most people avoid it and often terminate relationships in which it exists. This interview with one of the authors provides more insight.↩︎
- There's a subtle distinction between persuasion and manipulation, and I think that comes down to motives. I don't condone manipulation.↩︎