Scaling Software Teams Casted

Denise is a Senior Engineer at GitHub, a prolific speaker, as well as an author and illustrator.
In this episode, we dive deep into the role that gender plays in inclusion. What solutions can narrow the gap between men and women on engineering teams? Listen in as Wes and Denise break it down.
Wes’ Takeaways:
Gendered language matters
We have a responsibility as allies to speak out
Documentation and the Double Rooney Rule can help us narrow gendered gaps
Don’t correct people publicly on inclusion things

Kevin Stewart is an engineering leader who has worked across multiple company stages such as Fastly, Heptio, Nodesource, and Adobe. Today, he is the VP of Engineering at Harvest.
In this episode, we talk about the invisible burden that code-switching puts on underrepresented groups. How can we build D&I initiatives that actually lead to more diverse hiring and greater inclusion on our teams? Listen is as Kevin and Wes discuss.
Wes’ Takeaways:
Our metrics may undermine our D&I efforts.
Code-switching places an invisible burden on under-represented folks.
If we’re in a position of privilege, we need to champion underrepresented groups instead of tokenizing them.
Make sure people like public praise… Also, praise their work instead of their identity.

Zach Holman was employee number 9 at Github. He was one of their earliest engineers, and he saw the team expand to over 250 employees. Years later, he was fired from his role and has since gone on to start his own companies and advise other startups.
In this episode, we talk about a really hard subject… firing and getting fired. We also cover why your onboarding process may be to blame if you have high turnover and the next steps you should take after someone is let go.
Wes’ Takeaways:
Fire humanely: Give warning, offer PIP, and understand/think deeply about human impact
Don’t let this be the end of your relationship. “Once you’re out, you’re out” is lame.
Onboarding is highly correlated with firing… If you’re seeing high turnover, it’s likely an onboarding problem.
Your goal should be: How do we make a company that most of the people who work here are happy and successful?
If things end well, ex-employees can be referral sources and advocates

How do you lead the leaders on your team? Today’s guest has been developing leaders for years, and she’s sharing her insights on this episode of Scaling Software Teams. Jill Wetzler is the Head of Engineering at Pilot. Before her current role, she scaled Lyft’s Infrastructure Engineering organization from a handful of people to over 100 infra engineers. She was also Lyft’s Director of Engineering Leadership Development. In this episode, we talk about the principles and tactics she’s used to develop leaders; from skip-level one-on-ones to developer advocacy. We also dive into the management issues that can hold under-represented individual contributors back and what we can do to fix them.
Wes’ Takeaways:
Skip-level one-on-ones can be incredibly useful for finding coaching areas for managers
Hire managers who think about management the same way you do–Stay in front of management hiring.
Use a charter to align teams on tasks, priorities, and customer needs.
Developer advocacy is critical for a developing team. (What engineers wish HR would be)
If under-represented groups are stuck, it’s likely a management issue.

How do you know if your one-on-ones are effective? In this episode, we’re diving deep into one-on-ones with our guest, Jason Evanish. Jason Evanish is the founder and CEO of GetLighthouse, a company that’s focused on helping develop great leaders by enabling better one-on-ones. Jason is passionate about helping teams build strong relationships, and it starts with building trust through one-on-ones. What are the three elements of a successful one-on-one? Listen in as Jason breaks it down.

Wes’ Takeaways:
1. The top 10% of managers have regular, well-executed, one-on-ones.
2. One-on-ones are for building trust, not giving status updates.
3. Remote 1:1s are different, and that’s okay.
4. Make sure you’re using this time for clear expectation setting.

These are challenging times, especially for engineering leaders. How do you “engineer” the trust in a distributed team that would occur normally in a localized workforce? Today’s guest is here to show you how. Jeremy Wight is the VP of Product and Engineering at Base. Base raised $2.6M in 2019 to build the first software platform that’s exclusively for Executive Assistants. Jeremy has been building a remote team for the past two years, and he’s collected some amazing insights about building a fully distributed engineering team. In this episode, we talk about the best-practices he’s used to keep his remote team rowing in the same direction and shipping product that matters.
Listen in to hear the full conversation.

Wes’ Takeaways:
1. High-functioning remote teams focus on moving KPIs instead of shipping features.
2. Little “p” product ownership breeds more autonomous remote workers.
3. Serendipity breeds trust, but serendipity is hard on remote teams.
4. How you win is putting the fire out in 30 seconds or less.
5. If we aren't building the right things, it doesn't matter how much we work.