Giving feedback and receiving feedback is hard enough as it is. But creating a feedback culture or improving it for your team or even for your company seems like an undertaking far bigger than a single person.
You want to avoid sugarcoating in your feedback culture. You want to avoid the bystander effect. You want to build psychological safety.
All this has to start somewhere. Why not with you?
Let’s take a look at how companies like GitHub and Facebook do it.
Ryan Nystrom has plenty of experience with both. He’s currently Director of Engineering at GitHub, and an expert at handling feedback culture both on an organizational and personal level. He discusses the fine details in this interview on the Level-up Engineering podcast with our lovely host, Karolina Toth.
The feedback culture at a big company has two key feedback channels: a formal feedback process and an informal feedback process.
One half is the formal feedback process. In the case of GitHub or Microsoft, it’s a biannual performance review cycle, which is a common practice. It consists of writing a self-evaluation and receiving feedback from your managers and ideally your peers as well.
A standardized, formal, and consistent performance review process is a sign of a healthy feedback culture. It shows that you're always evaluating yourself, both sharing and receiving feedback to better the team.
The other side of a feedback culture is the informal feedback process. It’s about openness and sharing ideas or concerns without fear of retribution. It’s based on the psychological safety of being able to make mistakes and learn from them.
It only works in a safe environment where people look out for each other and feel safe to offer ideas and suggestions. A part of this is receiving their ideas, digesting them and acting on them.
My first experience with a robust feedback system was at Facebook. Their COO, Sheryl Sandberg, implemented a top-notch system. The performance review cycle drives promotions and compensation for everyone.
This works well in many aspects. It clearly tells you how much harder you have to work to get to the next level, or what projects you should take on to make your performance review look good.
The downside of this is that it often makes people very competitive. You end up obsessing over doing well on your performance review, and you drift away from the impact you're trying to make in the world.
GitHub has frequent biannual performance review cycles, but they aren't as intense. This way we can use these cycles to give each other feedback, think critically about our performance, and keep compensations fair. Once we've checked in, everyone gets back to what they’re supposed to do.
I also like how GitHub handles the informal side of the feedback culture. When I arrived, the openness of their engineering culture shocked me. I thought, “Oh my god, how can this place work?”
Everybody is sharing their ideas, but this makes it unique. People feel an immense amount of ownership and pride of their work and their teams. They care to make things better, and they care what leadership says and does.
There's continuous feedback and constant adjustment, so the company is improving itself in real-time.
As an engineering leader at GitHub, it’s my responsibility to make sure that everyone on my team writes a self-review every six months.
I focus the self-review on your results since the last cycle. We have a bulleted list of company values, and we look at your behaviors in relation to that and your results.
Then we look at what you’re delivering, and what impact you have on the business, the platform and overall. We aim to understand what it is about you that makes you successful, and we try to think holistically about your performance.
There are people who deliver incredible results but have toxic behavior. This is a good system to take everything into account, because you want well-rounded people. Maybe you don’t get 10X results, but we reward people who spend time supporting their peers.
Individual contributors write this self-review every six months. They also ask their peers for feedback.
It’s my job as a manager to take all this information and compile it into a result. I try to combine their self-review, peer reviews, and my own observations to create a report that sums up the last six months for an employee.
I don't like spending a lot of time on what they did. I just make sure it's listed and accounted for. I prefer to look forward and discover areas of opportunity. I focus on these questions:
I sit down with my direct reports, and we brainstorm things for the next six months for them to exercise skills, hit milestones, and progress their careers. Engineers, engineering managers, engineering directors, VPs and everyone else participates for themselves and their direct reports.
I send the report to people a couple of days ahead of time so they can read it and digest it. This gives them a chance to bring questions to the discussion or feedback about the report. This way, we don’t read everything together, but we can dig into the important stuff, like focusing on their questions and future opportunities.
It makes you feel that you have a voice; it's going to be heard, and it's going to be at least considered, if not acted on. If there is action based on your feedback, you get a sense of ownership. This type of employee engagement encourages you to take on responsibility for your team and for the company itself.
This makes people happier and feel safer to express ideas.
At the same time, you shouldn’t expect all your feedback to be actioned. That simply can’t work.
Think of your feedback as a data point, and if there is enough data, it may drive a decision. This is a useful approach to giving feedback, especially when you give it to a leader or a manager.
I used to work at DYNAMIT, and I made lasting connections there. Sometime after I moved to Facebook, they came to me for advice on building their own feedback culture. They needed more structure as they grew their engineering team. I helped them out, so I have some experience with this.
You need a regular feedback check-in, at least every six months. Having every employee write a self-review is a good starting point. No matter your team size, it’s valuable to sit down and think critically about yourself.
Facebook has a robust system with many different angles on evaluating yourself. You need to consider impact, velocity, influence, recruiting and other things.
I prefer GitHub’s way, where you focus on results and behaviors. A two-bucket system makes it easier for me to analyze the results.
You need feedback from your peers. There are debates whether you should get it directly or if it should go to your manager. I see both sides of the argument.
On the one hand, I’d love to be able to directly read what my peers write about me. They can give you their unfiltered opinion, but there are downsides to it.
The feedback about you going to your manager helps to avoid sugarcoating. I want to learn about the impact of what I do as much as I can, even if it’s small. When you’re giving feedback to a person directly, you often hesitate to be overly critical, and important feedback may be lost to this.
For smaller companies, I recommend having feedback go through a manager. They can put everything into an anonymized report about your impact over the last six months, including areas of opportunity.
It’s essential for an employee to learn what they should be doing. It tells you more about the team and the business’ priorities, and it helps you understand where to go next.
Managers should encourage people giving feedback. There needs to be a recognition that feedback makes the team stronger, makes people stronger, and builds relationships.
To encourage this, I always seek feedback about myself. I ask multiple times a week from different people on my team the following questions.
It may be borderline annoying, but I’m constantly looking for feedback. In my experience, as soon as you get comfortable or complacent, you slip up, and bad culture starts growing.
When somebody is telling me about the awesome work one of their reports did, I ask if they let them know. That’s positive feedback, it reinforces that they did something great, and the people around them are noticing it. I like to encourage that.
It starts at the top, with the person running the company. They have to lead by example and continuously seek feedback both at meetings and privately. If they show that have a growth mindset, they're open to feedback, and they take action based on it; it’s going to spread.
On the other hand, if the C-suite leadership doesn’t seem to care, then no one will.
A feedback culture doesn't happen naturally. You have to work at it, and you need to want to hear both the good and the bad.
Making your feedback specific is a good tactic for both good feedback and negative feedback.
When it comes to praising feedback, I tend to just want to say, “This was awesome; you’re a rock star.” But this isn’t the right way to do it when you want to reinforce somebody.
It's important to single out specifically what they did and how, instead of just giving them platitudes. Try to analyze what they did using the results behavior framework. Try to distill what you noticed that made what they did super successful.
For example, “I noticed that you used data to measure which people use X feature, and you decided that we shouldn’t build it. Thank you, this gives me confidence that you know your stuff.”
The other part of it is, what results do you notice? This could be something that they shipped, the impact they had on users, or just taking note of how they know their stuff.
You don’t need to filter your tone when giving positive feedback. Excitement is infectious, so it’s a good thing if you let others see yours. When people are hyped, they spread the positive energy around, they tell others about it, and they’ll be that much more open to give and receive feedback.
The same goes for constructive criticism; be as specific as you can be.
When things don’t go well, it's important to analyze what happened exactly, and what the results are. When there is conflict and emotions, look for ways to calm down, and focus on analyzing the situation.
It’s important to let people know the results of their actions. Sometimes when someone hurts your feelings, it may be appropriate to tell them, “I don't trust you as much anymore,” or, “I might think twice about asking you for a code review, because this interaction sucked.”
I've been on the receiving end of feedback like that, and it makes you consider ways to improve.
When I sense a lot of emotions, I hit pause on giving feedback and ask if something is off. I say, “I expected this to be received this way and it wasn’t. What's going on? Could I have said it better? Do you disagree? If so, why?”
It's important to dig into the situation, but there are limits to that. If somebody's mad at you, it’s useful to state your original intent. It may still be impossible to have that conversation at that moment, so you can take a minute and reconvene later.
Sometimes even if you talk for an hour or even two hours, you still need to continue later to get to the core of the issue. Look for answers to these questions:
The fact that somebody doesn’t react well to receiving feedback can be improved. Maybe there's something deeper that you don't understand, but it’s important to surface.
When faced with a conflict, and somebody tells you, “I don't want to talk about this,” my instinct as an introverted person is to run away and say, “They don't want to talk about it, and I don't want to talk about it either. Let’s pretend it never happened.”
This is dangerous. The problem at the moment may only be like a seedling, but it’s going to grow bigger. When that happens, the consequences may become severe, like somebody leaves the company, or it blows up into a huge issue months later.
You might be passive-aggressive with each other, and it spreads to the rest of the team. You might miss deadlines because you're not talking to each other.
An engineering manager needs to recognize the real-world consequences of leaving issues unaddressed. They grow, fester and poison everything in the workplace.
When it comes to senior engineers, I expect them to be able to handle their feedback.
It’s the engineering manager’s job to foster giving feedback and to build the team culture. But when tech leads complain about working with someone, I tell them, “You're a high-level engineer, this is part of your job. You're supposed to be a leader, so I need you to be able to solve these problems.”
When people are uncomfortable about giving feedback, I offer to coach them. They can give me the unfiltered version, and I help them phrase their thoughts and teach them the cause-and-effect framework for giving feedback. The point is that I encourage them to have these conversations themselves.
I can also do it for them, but I prefer to avoid that. It makes me a middleman where I have to translate and interpret their thoughts and emotions back and forth.
It's inefficient, and your feedback is going to land better if you give it personally. Even if it’s a video call, you see each other’s faces, body language, and reactions, and this helps you understand each other. Ideally, this will help you grow your professional relationship.
I push people to have these conversations together both for praise and constructive feedback.
Most of the time, it's about small things a person could do better. You just need to phrase it in a constructive way and have the conversation face to face. If you're early in your career, it's okay to work hands-on with your manager until you get familiar with the process.
Many people are uncomfortable giving feedback to me as Director of Engineering. I don’t make a big deal out of my title, but it's there. People see that, and they have their assumptions and expectations.
I always tell people to not think of me as a director, but to think of me as your tool. I’m your window to other directors and the C-suite leadership of the company. You can leverage me to make changes with your team.
I almost dehumanize myself somewhat, and I give my reports the menu on what I can do. I can take things to the CEO; I can give my manager, the VP of Engineering anonymous feedback for them. I can also poke around the teams if they bring a concern to me.
This tends to open people up, to bring me problems they see and ideas they have.
I try to do this for myself and for the other managers in the organization. I tell everyone to look at their managers as tools to make some change.
It doesn’t work with everyone. Some engineering leaders and managers like their title and the way people look at them because of it. It’s okay, you can’t change that, but I chose a different path.
Face-to-face feedback isn’t time efficient. When you’re receiving feedback from 20 people, a 30-minute feedback session with everyone takes a lot of time, and it’s exhausting both physically and emotionally. This is where you use written feedback with simple, pointed questions.
This is why we do a check-in feedback cycle twice a year, alternating with our biannual performance reviews. We send people two questions:
We ask people to spend five minutes on this and write the first thing that comes to mind. I do this with a couple of my peers, my direct reports, and their reports. I ask them all to do the same.
The idea is to make this a lightweight check-in but still use a formal process. It's all in writing, but it's not as structured or robust as the biannual performance reviews. It doesn't involve compensation or the HR department, we do it for ourselves, and involve everyone we can from engineering.
The human resources department is involved in the biannual performance reviews, to make sure everyone is compensated fairly. They look at everybody’s performance, both good and bad.
When someone is doing great, we need to put them on everyone's radar, and they may get a raise or promotion. If somebody is underperforming, you also give HR a heads up. Hopefully, nothing happens, or they find a way to help that person improve; but they need to keep an eye out.
We don’t involve HR in our own biannual feedback cycles, because I want to keep the process light. I try to avoid putting extra pressure on people with this. We keep that part of our feedback culture lightweight, and we aim to keep it constructive.
I have no idea how to fix a fundamentally lacking feedback culture at a big company. I've seen horror stories, where it was next to impossible to change this. I've never actually experienced this change at big companies; I’ve only ever read about this.
Company culture comes from the top, so the best way to change culture at a big organization is a sweeping change in leadership. It’s hard to make that change even from a C-suite position. You can advocate for it, but it requires everyone from the top to the bottom to be involved.
For a smaller company, it's never too early to start. Even if you don't have an HR department, you should put a recurring six-month calendar invite for your team to do a lightweight feedback cycle. You ask these questions:
As your company grows, and your engineering culture scales with it, this will be ingrained already. Everybody will be open to feedback, and ask for it constantly, so a strong feedback culture becomes natural.
When I’m encouraging people to share feedback, I tell them to consider their feedback a data point. I used to be nervous about giving critical feedback about others, because I didn’t want to cause trouble for them.
This is why I tell people to consider their feedback a single data point.
As a director, if I hear one thing from one person, but I don’t hear it from anyone else, I consider it a small issue. I’ll look into it and ask around if others are observing the same thing. If I see more corroborating evidence, only then will I consider acting on it.
No one is exclusively responsible for the consequences coming from their feedback.
This is why we ask for at least three to five peers to give feedback to everyone. If one person says they don’t like to work with you in code reviews, but no one else says the same, we focus on that specific relationship. If others say the same, we’ll consider a different course of action.
The bystander effect is a problem at companies. Everybody's uncomfortable giving feedback, and bad things are allowed to continue. This is why I tell people to tell me their opinion, so we can make good decisions for the team.
I always encourage people to give feedback, even if the CEO is saying something they don’t like. It’s the same principle: they won’t get mad at you or change the entire company based on your feedback alone. But if you tell them what you think, and they keep hearing it from different people, it may trigger a change.
Ryan got into programming as a high schooler, and he’s been building mobile websites and apps for 10 years professionally. He first became an engineering manager at Facebook, and later moved to GitHub, where he’s currently director of Engineering.
He doesn’t consider himself extraordinarily talented, but he never gives up, and he goes to any lengths to learn, to improve and to get things done. He’s grown wise enough to moderate this “never quit” attitude, which can lead to burnout. Over the years, he’s kept on his passion for video games and learned to fly planes.
At Apex Lab, we're experts in end-to-end digital product development. Our remote-first company operates with a flexible schedule, allowing us to help clients tackle difficult challenges worldwide.
Want us to build your next idea or upgrade your existing product? Our experts cannot wait to work with you. Get in touch with us and let's make this happen. 💡🚀