Handling Conflicts and Giving Feedback to Improve Your Engineering Team (Interview with Tom Bartel, Engineering Manager at Trivago)
Managing engineering teams day-to-day often involves handling conflicts, and regularly involves giving feedback.
Handling conflicts well is a must to keep your developer team together. People spending a lot of time on the same project can often be at each other’s throat, and a manager needs to know when to step in and how to resolve a conflict.
Giving feedback is absolutely essential. You need to continually improve your people, and giving them positive feedback to empower them, or critical feedback to course-correct regularly is key to a productive engineering team.
This is why Fanni Karolina Tóth from Coding Sans interviewed Tom Bartel, Lead Developer at Trivago on the topic of handling conflicts and giving feedback. Tom has many years of experience both at managing developer teams, and being an individual contributor.
In this interview we’re covering:
- Common conflicts in an engineering team
- How to step in to handle conficts as a manager?
- Steps to prevent conflicts as an engineering manager
- Rules for giving feedback as an engineering manager
- How to give feedback to help improvement?
- Common mistakes at giving feedback
- Bonus advice
- How to get feedback as an engineering manager?
About Tom Bartel
Tom studied computer science the classical way. He was always interested in programming, especially in web development.. Eventually he got an opportunity to move into a management role. Later he switched back into an individual contributor role, and became a developer again.
There are work related conflicts. Engineers often have different opinions about the right way to solve problems, what technology or approach to use. These are easier to handle.
Then there are interpersonal conflicts, these are harder to deal with. Engineers claim to be rational, but they are still humans with emotions, and that causes conflicts. Sometimes people or their work gets criticized and they don't take it well, so hard feelings develop over time. Other times people just don't get along well, and that leads to conflict too.
Choose carefully when to intervene
It's necessary to step in as a manager, but it’s all about the timing. You shouldn't step in every time something small happens. You're not their parent and they’re not children. You should expect a certain professionalism in their behavior.
When the team atmosphere, the output and the productivity is threatened, then it's time to step in and take them aside. Talk to your developers, but not individually.
Get everyone in the room
If you talk to them individually, you will get different versions of the same story. You can’t really figure out what is the truth, it’s likely somewhere in between. It's hard to resolve conflicts this way.
Everybody needs to be heard, so your best option is to get everybody in the same room and talk things over.
Preventing conflicts isn't always possible.
Build a safe environment
The closest you can come is building an open team atmosphere and psychological safety. Foster a culture of open communication in your team. You should set an example in your team meetings.
It's helpful to talk to everybody one on one regularly, so they get a chance to speak up. Some people bottle stuff up for a long time thinking it's not a big deal, and they don't want to blow it up. But at some point it gets big if they let it fester, and never vent it out. There may even be a point where it’s too late to intervene.
Having a culture of open communication in the team is a good first step.
Keep your eyes open
You will still not be able to prevent all conflicts. The second best thing you can do is to diagnose it early. The earlier you can catch something, the easier it will be to resolve, and the less damage it does.
Real life example
At one point I had a new developer join a team of senior developers. The new guy was a junior both in skill level and age. The senior team members were used to each other and worked very well together, but the new guy didn't fit in well.
It was partly the new developer’s fault. Sometimes he joked around in ways that would annoy the others, and didn't take the learning opportunities seriously enough. When his first round of feedback came, it was mostly bad. He didn't see it coming and he was devastated.
Obviously there was a rift in the team with the existing engineers on one side, and the new guy on the other side. It wasn’t a healthy situation.
I did what I talked about earlier, and got them all in the same room. We had a painful and awkward but ultimately healthy conversation. Everybody got to name what they didn't like about the situation, let it be behaviors or anything else. It resolved some misunderstandings too, because often problems are just that.
It massively improved the situation.
I also had a one on one conversation with the new engineer. My expectations were clear: he had to stop with certain behaviors, and he had to take some things more seriously. To my surprise, he did everything I asked, and turned himself around. He applied himself, and improved the situation dramatically.
The original team opened up, and they made an effort to integrate him more, like going to lunch together. In the end, the team became a team again, rather than falling apart completely.
It doesn't always go well
This is an example with a happy ending, but people can’t always turn the situation around like that. He was still young at that point, which helped. It won’t always work out well.
Feedback is extremely important, we all need it. The world is complex, and you can’t perceive everything going on around you. You have some blind spots about yourself and you can’t know the effect of your behavior and actions on others.
You have to have feedback, otherwise you're flying blind, and you won’t have any development.
The ground rule is that feedback should be timely. It should be about something recent, ideally give it on the same day or the next one, but at least on the same week. After that, it loses a lot of value. The other person may not remember the situation, so it's hard to explain your point.
Don't generalize, feedback should be about concrete things that happened. A general feedback may be: “I think you should be more polite.” It's hard to put into practice, because the person doesn't know what you mean. Make it actionable by being as concrete as possible.
Limit critical feedback to one on one
If it's critical feedback, it's best given in a one-on-one setting behind closed doors. If you criticize somebody in front of others, they may not want to lose face, and start defending themselves. Then they close down, rather than being open to your feedback, and it may not have any effect.
Ask for the reason
It's also important to ask for the person's perspective, ask why a certain behavior is there. Why they say certain things or get angry at certain moments. If you just tell them, “This has to stop, do it differently,” then maybe they’ll do it, but they may not buy into it.
Have them contribute to the solution
It's better if the solution at least partly comes from them. Ask questions like, “What could you do differently? What do you suggest resolving the situation or avoiding the situation in the future?” If they come up with the idea, they will have more buy-in, and they’ll be more committed to changing their behavior going forward.
Give your team members concrete pointers on what they should change.
In general people should use their strengths at work. So, if you see them using their strengths, praise them for it. If you see them do a good job, acknowledge it, so they keep doing this and make even more effort using their strengths. That's where the most potential lies.
If you only ever criticize, and try to fix weaknesses, people lose confidence, because they constantly feel like they’re doing something wrong, and have to be careful. You don't want this type of atmosphere. If all they ever do is avoid mistakes, they will never do great things.
Positive feedback is easy
Positive feedback can be given in any situation, but it also depends on the recipient.
Some people feel embarrassed when they get praise in public, as they don't like to be the center of attention. In that case you should adapt your style to the recipient. If they prefer a quiet setting for receiving even positive feedback, respect that.
Give negative feedback in a safe space
You should always give critical feedback in a private setting. Make it a safe environment, where nobody's watching or listening. They will be more open to accepting the critical feedback.
Often when people are giving critical feedback, they go, “Nice job on this feature! But your code review comments have a bit of a hostile tone, I would like this to change. But really, great job on that feature.” They sugarcoat the criticism. They start with something positive, then they deliver the actual message, then end with something positive again.
People call it the shit sandwich, I call it sugarcoating. It waters down the message, and often people won’t get it. This is better to avoid.
Give one critical feedback at a time
If you have a lot of critical feedback to give, pick the most important with the most potential benefit, and stick to that one, so you don't overwhelm the recipient.
If you give too much critical feedback all at once, the person will likely be overwhelmed and at one point just shut down. They will think, “I'm not doing anything right. Everything's wrong. I'm a failure.” You don’t want this, because they get discouraged, they won’t take action, and won’t improve.
I see a lot of people ask: “How can we improve the situation?”
If you're the manager and you see a person interrupting others, it doesn’t have anything to do with you. So don't ask, “How can we change that?” It suggests to your direct report that you're part of the problem, and you share the responsibility to fix it. You don't. It's their mistake, be clear about it. And make the expectation clear that it's their job to fix it.
So, don't say “we”, but say: “What do you suggest to improve the situation?”
You need feedback too
You should also know how to receive feedback. In a leading position others often don’t dare to give you honest and open feedback, so you have to make extra effort to get it. If you don't get it, you’ll develop blind spots or start to put distance between you and your team.
Receive feedback well
Feedback is a gift. Whenever somebody gives you critical feedback, thank them for it. You also have to accept it, so you have a responsibility on the receiving end to consider it carefully.
Whatever you may think, say something along the lines of: “Thank you for feedback, I may not have an answer right now, but I will think about it.” Then they know you take them seriously, and it's important for you, and they’ll give you feedback again.
Use all the feedback
Even if you don’t agree with the feedback, use it as a data point. Everybody's perception is different. There are lots of subjective feelings in human behavior and human interactions. Maybe someone else says the same thing to you later, and if you start seeing a pattern. It may make you more observant about yourself and realize there’s something you could fix.
As an engineering manager you have great responsibility when you give feedback, and it’s the same when you receive feedback. You can’t ever have the full picture, even about your own behavior. Feedback from others makes the picture more complete, that's why we all need it.
You should create a safe atmosphere in your team. There are exercises where everybody shows a bit of vulnerability. For example talk about the most important thing they had to cope with while growing up.
You can openly admit mistakes yourself to encourage others to do the same. This is the basis for giving feedback to each other. It shows everybody that it's okay to not always be perfect and strong, but you can show some vulnerability once in a while.
That's a great basis for giving and receiving critical feedback in a developer team.
What You Should Do Now
🚀 If you need developer help for your project then click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.