We’re covering:
-Usual challenges remote developer teams face
-Key elements to make a remote team work
-DOs and DONTs of managing a remote team
-Handling time zone differences
-On-boarding people new to remote work
-Remote rewards

Interview:
https://codingsans.com/blog/managing-remote-developer-teams

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.”

Managing Remote Teams: Katie Womersley (VP of Engineering at Buffer)

We’ll be covering:
-Mentoring in tech today
-His approach to mentoring
-Challenges in mentoring
-How to build a mentoring program

Interview:
﻿https://codingsans.com/blog/mentoring-developers

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."

Mentoring Developers - Gergely Orosz (Engineering Manager at Uber)

We’ll be covering:
-Biggest challenges when scaling a developer team
-How he overcame these challenges
-First steps to scaling teams
-How to get hiring right

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."

Scaling Developer Teams - Rich Archbold (Senior Director of Engineering at Intercom)

In the interview we're covering:
-Why is psychological safety important?
-The difference between psychological safety and the comfort zone
-Requirements for psychological safety
-How did Dan build psychological safety?
-How to promote psychological safety as a leader?

Snippet:
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."

Psychological Safety: Dan Rummel (Senior Director of Engineering at One Medical)

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 managers
-Challenges of transitioning to engineering management
-Common mistakes in training engineering managers
-How to build a system for training engineering managers

Excerpt 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?"

Training Engineering Managers: Matt Greenberg (VP of Engineering at Credit Karma)

In software development it's more likely now that 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 team

-On-boarding remote engineers

-Balancing synchronous and asynchronous work

-Managing distributed developer teams

-Measuring productivity at distributed developer teams

-Giving feedback in distributed developer teams

-Running meetings in distributed developer teams

-Management tools at distributed developer teams

Excerpt 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..."

Managing Distributed Developer Teams: Tim Olshansky (VP of Engineering at Zenput)

Level-up Engineering reveals actionable management secrets from some of the most successful tech leaders. This podcast brings you key insights from fellow engineering managers and tech leaders to level-up your management skills and to take your developer team to the next level.

Level-up Engineering Podcast