Handling conflicts and giving feedback are two of the most important things a manager needs to do. It has to be a given to lead a productive developer team. So we interviewed Tom Bartel, Engineering Team Leader at trivago to share some of the tips he picked up over the years he spent as a manager.In this interview we're covering:  Common conflicts in an engineering team  How to step in and handle conficts as a manager?  Steps to prevent conflicts  Rules for giving feedback  How to give feedback to help improvement?  Common mistakes at giving feedback  Bonus advice  How to get feedback as an engineering manager?Excerpt from the interview:"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.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.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..."Click here to read the full interview!

In software development when capacity is the problem, most managers think they need to hire more developers. But you can push engineering productivity higher by creating the right context for your existing developers.We interviewed Camille Fournier on the topic of productivity, to learn what she's been doing as a tech leader to keep it high in her developer teams.In this interview we're covering:Defining engineering productivityHow to measure engineering productivityChallenges for managers with engineering productivityOn-boarding for maximum engineering productivityEffects of mentoring on engineering productivityKeeping engineering productivity highHow to improve engineering productivityExcerpt from the interview:"Many engineering managers struggle with setting goals. They think about goal setting in a way that’s inspiring to their team without making it easy or pushing too hard.Some managers say the way to build a productive team is to hire smart people and get out of their way. I have never seen that work. It might work in theory if you have clear goals and if you motivate people to achieve those goals.Most managers aren’t good at setting clear goals. When you're always adjusting your goals, you can’t expect to just hire smart people, get out of their way, and watch them be productive.Most engineers don't learn how to be productive on a team without having experienced it. If you've never been an engineer on a hyper-productive team, you won’t know what it’s like or what you could do to make a productive team happen."Click here to read the full interview!

Scaling is a massive challenge for an engineering manager to overcome, let alone scaling in a distributed environment. Juan Pablo Buriticá had done it, and in this interview he shares how he managed to pull it off. You'll get his insights and actionable tips to overcome all the issues a tech leader will face when scaling distributed engineering teams.In this interview we're covering:Challenges of scaling distributed engineering teamsSteps of scaling distributed engineering teamsDifference between scaling from small to medium, and medium to large sizeHow did you scale distributed engineering teams at Splice?How to change a process while scaling distributed engineering teams?Your key takeaways from scaling distributed engineering teamsBonus advice for scaling distributed engineering teamsExcerpt from the interview:"Scaling an organization requires a lot of work with no tangible output. It’s about building a culture and processes; it requires a lot of attention, moderation, curation, and loads of conversations with humans. Humans can be exhausting with insecurities and all the stuff we bring with ourselves, because we're not machines.As a leader, that falls on you. I’ve done it twice, and if I had to do it again, I may use some shortcuts, but it's going to be different, and still a lot of work. That’s the first takeaway. Looking back, it was worth it, because it was exciting. It’s rewarding when you get it to work well, and I'm proud of our team.When scaling distributed engineering teams, be ready for a lot of work, repetition, communication, convincing and loads of complaints. Some people have followed me through teams. We agreed that when they complain, I ask, “Do you want me to solve this?” If they say yes, I do, but then they have to look for something else to complain about. We just laugh at that.I like complaints, because it's feedback as we're scaling. I've seen other leaders who can't deal with it."Follow Juan on his Twitter!Click here to read the full interview!

In software development it's more likely now than ever, that as a manager, you'll face the challenge of leading a fully or at least partially distributed developer team. It's a brand new thing for everyone, but Tim Olshansky, current VP of Engineering at Zenput has faced this already. In this interview he shares what he learned on managing distributed developer teams over the years, and gives you actionable tips on making it work as well as possible.In this episode, we're covering:Challenges of managing a distributed developer teamOn-boarding remote engineersBalancing synchronous and asynchronous workManaging distributed developer teamsMeasuring productivity at distributed developer teamsGiving feedback in distributed developer teamsRunning meetings in distributed developer teamsManagement tools at distributed developer teamsExcerpt from the interview:"I don't measure productivity specifically. It’s been a struggle, because the definition of productivity is a difficult one, particularly in the software engineering world. Is fixing a hundred bugs or implementing ten features better? What if none of those features affect the company positively?Firstly, I start by making sure we're working on the right things. If not, I try to fix that, because all the productivity in the world working on the wrong things is not going to get us where we need to be.The next question: are we working the right way? Are we doing things that are going to cost us in the long run? This is a classic technical debt conversation.Do we have the infrastructure to support the team to be productive? Does the team have to overcome difficulties to demonstrate what they've done? I try to assess those things and remove the impediments. Then the team can focus on doing what they like, which is problem-solving, and building new things.When all this is sorted, I look at the individual level. There, I see that if they say they're going to do something , do they get it done? If not, why not? Sometimes, folks need to be held accountable for what they commit to..."Click here to read the full interview!

Training engineering managers doesn't get the attention it deserves. It's extremely valuable to keep and grow your own talent, rather than get all your tech leaders from a competitive workforce market. We interviewed Matt Greenberg, who has gained years of experience training new engineering managers.In this episode, we're covering:How to make sure an engineering manager prospect is ready?Challenges of training engineering managersChallenges of transitioning to engineering managementCommon mistakes in training engineering managersHow to build a system for training engineering managersExcerpt from the interview:"People tend to think of engineering management as an opportunity to become a leader.In reality, accomplished engineers are also leaders; they’re involved in everything. You get opportunities to mentor and you have a say in project leadership decisions and technical decisions, whether you're an individual contributor or a people manager.Being a people manager entails all the administrative aspects of leadership. So, a lot of it comes down to hiring and firing people, performance management, dealing with HR or legal issues, finance, budgets and all these other things.I think a lot of people want to become software engineering managers for the wrong reason. Also, many people get out of it once they realize what they're doing. You should look at the end goal. Do you want to be a senior leader managing hundreds of people, or do you want to be an accomplished person on a small team?"Click here to read the full interview!

How do you build psychological safety in your team? Why is it important?We sat down for an interview with Dan Rummel. He is currently the Senior Director of Engineering at One Medical, and he’s held engineering and leadership positions at various Bay Area startups. He shares this invaluable insight with you on creating a workplace with psychological safety, so you get to understand his way of thinking and pick up actionable tips you can apply at your company.In the interview we're covering:Why is psychological safety important?The difference between psychological safety and the comfort zoneRequirements for psychological safetyHow did Dan build psychological safety?How to promote psychological safety as a leader?Excerpt from the interview:Leading by example"Leading by example is often neglected. It’s a real challenge for leaders and managers because their typical personality types can take up a lot of space in the room. I think leading by example means making space for others.We need to actively make space for others to chime in during meetings. It also helps a lot to show vulnerability, talk about some of your challenges, or throw out the occasional wild or even silly idea. Even if you know it will likely be shot down, this lets your team know you’re fair game for debate as well.Perhaps the most important thing to do is to admit when you're wrong, and not make it a big deal. Just saying, “I was wrong; you've got it,” helps the healthy debate and makes it comfortable to rumble through ideas and to find the best outcomes.The reason healthy teams produce better outcomes is that there's a diversity of experiences and perspectives that come to the table. When people can build mental models with everyone else's experiences, your outcomes get exponentially better, and you get beautiful results from those debates."Click here to read the full interview!

Working with a remote team has many upsides, but managing a remote developer team is one tough job to have. There are loads of challenges you wouldn’t have to worry about in an office, like possible time zone differences or making sure people feel part of the company. It requires a lot of attention to keep everything on track.We sat down with Katie Womersley, the VP of Engineering at Buffer. She’s managing many remote engineering teams, and she shared a lot of invaluable experience she picked up over the years in dealing with all the obstacles of working with distributed teams.In this episode, we're covering:Usual challenges remote developer teams faceKey elements to make a remote team workDOs and DONTs of managing a remote teamHandling time zone differencesOn-boarding people new to remote workRemote rewardsExcerpt from the interview:The dark side of managing a remote developer team:“Remote developer teams often have mental health issues that people don't talk about. It could make your teammates less productive, less healthy, and more likely to quit and go work somewhere in an office where they feel better. Anxiety and depression correlate with feeling lonely or being isolated. Naturally, when working remotely, people often work from home most of the time.Many but not all developers find themselves a bit more introverted, a bit more on the quiet side, so they’re not going out every day with a ton of friends. One thing we see is that the rate of anxiety and depression is higher with remote workers, so the most practical advice is to be very open in talking about mental health with people, because it really affects their work and their ability to be a successful teammate on the job.Remember, a manager is not a therapist; it's not your job to solve the issue, but it’s your job to be aware of it and to make sure your teammate gets proper help. Make sure they go see a doctor, go to a co-working space, get out and do some exercise, or get an actual therapist before it ends up becoming a real health problem.”Click here to read the full interview!

Software companies often grow quickly, which means developer teams often suffer to manage scaling at the pace of growth and necessary workload. We sat down with Rich Archbold to pick his brain on how they scaled developer teams at Amazon, Facebook and Intercom.In this episode we’ll be covering:Biggest challenges when scaling a developer teamHow he overcame these challengesFirst steps to scaling teamsHow to get hiring rightExcerpt from the interview:Common mistakes when scaling engineering teams..."I would say the biggest one is not putting enough emphasis on hiring for behavior and attitude. It’s the most expensive one too. Understand the team you're hiring for, and what's the balance you need to have in there.The mistake we made in the past is hiring too many juniors. Unless you've got two seniors to match every eight juniors, you don't have a viable team. I call it guns and bullets. There's no point having a lot of bullets, if you don't have any guns to fire them, or the other way around.Hiring 10 junior engineers can reduce the capacity in your organization, because your best people who were executing at a high rate, now have to mentor juniors. It takes a lot of their time for about six to nine months, and the overall capacity takes a hit. Make sure you understand the balance of strengths in your organization, and you're not just thinking about adding people, but strengthening the team."Click here to read the full interview!

Mentoring is underutilized in the software development industry today. So, we did an interview with Gergely Orosz, currently an engineering manager at Uber, who has gained a lot of experience with mentoring over his years as a developer/manager.In this episode, we're covering:Mentoring in tech todayHis approach to mentoringChallenges in mentoringHow to build a mentoring programExcerpt from the interview:How do you think a company could implement a mentoring program?"I've not seen many companies with good mentorship programs and this includes Uber. It's a work in progress, but at least there's something. On the other hand, despite the fact that there's not much structure or best practices, I hear people talk about mentorship all the time, so somehow it’s working. It means that people really want mentoring and it has real value, but I think companies have a long way to go.At companies, there are two ways a process can go: from the bottom up, or from the top down. Mentoring has to be voluntary, so neither of them will fully work. It cannot just be fully organic, because you might have some teams where people mentor each other, but it will not spread to other parts of the company. You surely can’t make it mandatory.The number one thing that helps a lot is tying mentoring into performance. Good mentoring happens in a lot of places, but often it’s left unrecognized. The most obvious place to recognize it is when you have your performance review or promotion conversation. That makes it tangible. If mentoring doesn’t come up there, it turns into a side project some people will do and others won’t."Click here to read the full interview!