StaffEng

After 3 years, we’re coming out of retirement, because something fundamental broke open in the last few months—something that changes everything about how we work.
We Don’t Know How to Learn This Yet
AI coding tools promise a 10X—maybe 100X—productivity boost. But here’s what we’re seeing: most engineers don’t know how to learn these tools. The old playbook—read the docs, practice, master—doesn’t work when the tools are fundamentally stochastic and changing weekly. Even worse, there’s nowhere to go for real instruction. Documentation tells you what features exist, not how to think differently about your work.
I’ve never felt this much behind as a programmer. The profession is being dramatically refactored as the bits contributed by the programmer are increasingly sparse and between. I have a sense that I could be 10X more powerful if I just properly string together what has become available over the last ~year… - @karpathy

Deep Conversations with Practitioners
We’re rebooting the Staff Engineer podcast with a specific focus: practitioners using AI to deliver valuable outcomes with specific examples.
The Future Isn’t Evenly Distributed
Right now, there are deep pockets of breakthrough AI usage everywhere. From engineers, to philosophers. Small teams moving at speeds large organizations can’t match..
These practices exist, but they’re isolated.
What We’re Looking For
Practitioners over theorists. We’re not interested in abstract conversations about what AI might do. If you’re using AI to deliver outcomes and have specific examples of what worked and what didn’t, we want to talk.
Details over declarations. “AI made me 10X more productive” is a headline. “I rewrote my entire workflow around X pattern, which failed until I realized Y, and now I’m shipping features in days that used to take weeks” is the conversation we want.
Diverse domains, unified question. We’re starting with staff engineers because that’s our foundation—engineers expected to show great judgment at scale. But we’ll talk to anyone whose work sheds light on our core question: What does good engineering judgment look like when the tools are stochastic, the landscape changes monthly, and the bottleneck shifts from implementation to direction?
Our Thesis
A fundamental shift is happening in how we work. The engineers authoring this future—not just experiencing it—will have massive advantages. We choose authorship.
But we don’t know what that looks like yet. We don’t have the playbook. That’s what we’re building.
How to Participate
We’re setting this up in two ways:
1. Join Our Listening Sessions
Before we start recording episodes, we want to hear from you. We’re organizing Zoom sessions to discuss:
What you’re running into with AI in your work
The problems you’re facing
The surprising wins
The bureaucratic barriers
The things you wish someone would talk about
Sign up to join a session
2. Suggest Guests (Including Yourself)
Know someone doing interesting work with AI? Are you doing interesting work with AI?
We’re looking for:
Practitioners (not people selling AI tools)
People delivering outcomes, not just observing
Specific examples of what worked and what didn’t
Willingness to go deep on the details
Fill out form with your suggestions

This episode is a celebration of the journey we have been on as this podcast comes to a close. We have had such a great time bringing you these interviews and we are excited about a new chapter, taking the lessons we have learned forward into different spaces. It's been a lot of work putting this show together, but it has also been such a pleasure doing it. And, as we all know, nothing good lasts forever! So to close the circle in a sense, we decided to host a conversation between the two of us where we interview each other as we have with our guests in the past, talking about mentorship, resources, coding as a leader, and much more! We also get into some of our thoughts on continuous delivery, prioritizing work, our backgrounds in engineering, and how to handle disagreements.  As we enter new phases in our lives, we want to thank everyone for tuning in and supporting us and we hope to reconnect with you all in the future!

Links
David Noël-Romas on Twitter
Alex Kessinger on Twitter
Stitch Fix
Stripe
JavaScript: The Good Parts
Douglas Crockford
Monkeybrains
Kill It With Fire
Trillion Dollar Coach
Martha Acosta
Etsy Debriefing Facilitation Guide
High Output Management 
How to Win Friends & Influence People
Influence

The structures of an organization can often be self-reinforcing, and in a changing environment, this becomes a recipe for future vulnerabilities. That is why senior ICs need to play a slightly discordant role at times by alerting teams to issues conventionally outside of their bubble of concern. Peter Stout is a Technical Director at Netflix where he has a cross-functional role at the juncture of business and technology. He joins us on the show today to share some of the finer details around what inhabiting this position in the above manner looks like. We start by hearing Peter describe himself as a generalist, and share how this played out in the broad focus of his college degree as well as in his career pivot from Chemistry into Software Engineering. We discuss the rapid growth of the engineering team at Netflix, how this has led to less tightly-defined roles for junior and senior engineers, and how this factors into the way Peter approaches his place in the organization. Peter talks about the shift he made from technician to technical director and how much of the skills he learned from the former position he brings into the latter. He talks about his tendency to seek out the blank spots in the organization and how he tries to focus on a long-term vision, using that to guide him as he connects the dots between teams and influences decision making. Here Peter considers his role as a disruptor and how he gauges how much pressure to apply while still staying largely in sync. We also have a great conversation about Peter’s approach to mentorship and his philosophy around how he grew into the leadership position he occupies. Tune in today!

Links
Peter Stout on LinkedIn
Netflix
Range
The Leadership Pipeline

Often the biggest impacts a Staff Engineer can make in their organization are not technical but rather people-related. When teams are value-aligned due to good leadership, they go on to make larger impacts than they would otherwise have. As Senior Principal Engineer at Dropbox for almost a decade, James Cowling learned a lot about how people think and work together, and he joins us today to share some of his insights. Joining this conversation, listeners will hear about James’ experience at the helm of numerous high stakes projects at Dropbox, such as migrating the company off Amazon S3 by building their own distributed storage system. For James, the main job of a tech lead is getting their team to have a firm grasp of the why behind a project, and to become completely values-aligned as a result. James takes us through his approach to diagnosing struggles within teams and how he helps groups to step back and course correct by drilling down on their purpose within the larger organization. We talk about the strong culture that gets built as a result of this approach and the power it has to keep teams robust. In today’s conversation, James also gets into how Staff Engineers themselves can stay in tune with the larger company, the single most important quality to nurture in Software Engineers who hope to grow into leadership positions, and a whole lot more.

Links
James Cowling on LinkedIn
James Cowling on Twitter
Convex
Dropbox
'Stepping Stones not Milestones'

Staff engineers may not get much time to code anymore, but this does not mean problem-solving and system design is not an integral part of their day-to-day. Today’s guest is Bryan Berg, Staff Engineer at Stripe, and he joins us to talk about the nuances of his position and his unique approach to the many challenges it entails. As a Staff Engineer, Bryan acts as Tech Lead of the Traffic team, and we begin our conversation by hearing about how he landed in this role. Bryan describes the ambiguous challenges he faced during earlier days at Stripe, and the knack he had for finding and working on processes and systems that were previously underinvested in. We then jump forward to the present and dig into what Bryan’s current role entails, hearing him describe a wide range of tasks from reviewing documentation, communicating between teams, writing vision documents, and ensuring the work he directs falls into the company and stakeholder requirements. We also explore the interesting concept of when to draw on past experience versus keeping an open mind when facing new challenges. On top of all this, our conversation covers how Bryan judges the success of his work, sustains faith in his ideas, pitches to colleagues, debugs difficult pieces of code, and finds inspiration to be a great technical leader.