June 22, 2023 • 28 mins
On this first episode, Brian Ogilvie and Alex Gaiser discuss where we are in our careers as senior software engineers, what we're looking to learn as we look to grow into Staff+ engineers, and more about the format of the show.
Links:The Pragmatic Programmer, by David Thomas and Andrew Hunt
Refactoring, by Martin Fowler
Staff Engineer, by Will Larson
Get in touch!Facebook: /themainthread
Twitter: @themainthread
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:11):
Hi,
everybody and welcome to the main thread. on this podcast,
We're going to explore the journey from mid/senior to staff plus level software engineer.
I'm Brian Ogilvie, and my friend and co host Alex Gaiser and I will be digging into the nitty gritty of what it takes to make that leap from senior engineer within your team to a true technical leader with organization- or company-wide impact.
(00:31):
Each episode,
We'll interview staff engineers from some of the world's largest tech companies like Meta, Google, and Amazon,
as well as some of the executives who lean on these engineers for setting and implementing their technical direction.
We'll also interview technical leaders from some smaller companies so that we can provide the broadest possible perspective and hopefully one that's useful to you on your career journey.
(00:51):
In this first episode,
Alex and I get together to discuss who we are, our mission for this podcast, and where we are on this journey from senior to staff.
We're excited to share this journey with you.
Let's get into it.
Why don't we start by kind of introducing ourselves and saying a little bit about uh why we're here.
Why we're doing this.
Do you wanna start?
(01:13):
So,
I'm Alex,
I'm a software engineer,
a senior software engineer with uh Bazaarvoice (BV), A content management,
social media management and analytics company.
Um I spend a lot of my time building things to scrape and uh publish post all of your favorite social media networks.
(01:34):
Um It's not much but it's honest work.
So looking good.
And we've started this podcast to kind of see what we can do to take our careers to the next level.
How about you,
Brian?
So,
yeah,
I'm Brian Ogilvie and uh I am a software engineer at Meta.
Um I've been there uh for just under three years now.
(01:55):
Um I work on the enterprise side of things working in infrastructure and security.
Um And uh and Alex and I were talking recently.
Um We,
we both went through the same boot camp when we were entering the tech industry a few years back.
Uh We came out of General Assembly together.
Uh Both found our first jobs in the industry at the same time and have been working um and just kind of staying close since then and,
(02:19):
and have,
you know,
worked through a number of different jobs,
worked up,
gotten promotions.
Um But we both have a number of different resources that we use on a regular basis and have always used to find content on technical um concepts and uh breaking into the industry,
et cetera.
But we were talking recently that it doesn't seem there's much content available for people who are now actually pretty firmly established in the industry,
(02:44):
have been around,
have,
have had some success and are looking to move from that mid slash senior level up to that um much more senior level that staff slash/principal level.
Um And we thought it would be helpful both to us and to anyone else who's out there,
kind of at the same similar part in their journey to talk about this.
Um So what we wanna do with this podcast is we want to talk about some of the concepts that are um important uh for growing beyond that mid/senior level.
(03:12):
Um And we wanna do it,
not just with the two of us,
but we wanna bring on people,
we know um people who are already staff plus engineers at various uh companies of different sizes.
Um We want to bring in managers,
executives from these type of companies to hear their thoughts on what they look for uh in terms of their staff,
engineers,
their principal engineers (03:31):
who they trust and why.
Um And we just thought we'd share our journey as uh we're on this path looking to take our careers to the next level.
So I thought uh we start out with just a couple of things like,
you know,
what do we know?
What do we know here?
Um What have we learned so far?
In terms of,
uh,
our careers,
um,
(03:52):
what's taken us from the very intro level,
junior jobs to,
uh,
these promotions and,
um,
getting to the level we're at now.
And,
uh,
what do we think is probably gonna be different about the path from here to the next level?
Yeah,
I'd say that the first thing that we've probably learned,
the biggest lesson that we've learned is that it's about process and people over projects and um code.
(04:17):
It's often about how you're able to organize people rather than how much,
how fast you're able to grind out the specific solution to a problem.
Um You know,
you wanna be uh I guess it's a bit of a cliche,
but you wanna be a force multiplier.
You want to be somebody who can organize people to get things done,
who can help lubricate to lubricate the process so that,
(04:39):
you know,
things that are,
are able to run smoothly.
And I suppose one of the things that I've learned is just the value of consistency.
It becomes extremely unwieldy to work on a large project over a long period of time when it's like digging through layers of archaeology,
when you're looking back through how a code that was written a month ago,
a year ago.
(04:59):
And it's like you can just see by the standards and practices that were used to implement,
that particular piece of code would be like almost to the,
to the year of the month when it was written because there's no consistency and that becomes very difficult because you basically have to, like an archaeologist, learn about all the different strata as you go back in time.
Whereas if it's all one uniform thing throughout the entire code base for,
(05:21):
for years and years and years,
it's very difficult to do, it's much, it's almost becomes a shortcut to learn.
Um You know,
when you go from one piece of code to,
to the next,
you know,
if you see one pattern in one place and you walk and you spend a lot of time worrying about it,
its strengths,
its weaknesses,
you go all the way back to,
I don't know,
a year maybe might be a bit of a stretch.
(05:43):
But like,
you know,
you go all the way back a year in the same repo and you see the same pattern implemented.
Um,
suddenly you don't have to learn that entire piece of code all over again,
that entire project all over again.
You know,
generally speaking,
what to expect.
Um,
you can kind of get a sixth sense even for like where things are going to be,
(06:03):
how it's likely to have been implemented if and that is just,
it speeds things up,
it reduces cognitive load.
We can probably talk about books,
we like later,
but there's a book that I really like that talks a ton about things like cognitive load.
And one of the things that we've learned as we've gone,
getting gotten older and I guess,
uh,
less,
(06:23):
less exciting is that things like process and consistency are things that,
um,
when you see it,
it makes you happier than any elegantly piece,
written piece of code.
And I'll often take like a consistently written code base that's maybe not the most like concise or elegant over one that's like beautiful and concise and,
you know,
does something in some like a novel,
(06:44):
interesting way.
Sometimes novelty is the enemy,
in fact.
So can you talk to me a little bit about,
uh when you say consistency?
What does that mean exactly in this context?
Um Being consistent about,
about what types of things,
standards and practices,
everything from like,
like I said,
what patterns you use,
what technologies you use?
Um,
not always bringing in a third party uh uh solution like a third party package to solve a problem.
(07:11):
Not,
I mean,
I've seen this,
we,
I worked in code base where we had four different in the same repository,
four different logging,
um,
uh packages that we used.
Um,
they all did slightly different things and they all did one or two things better than each other in addition,
of course,
to our custom one that we built ourselves.
(07:33):
Um And the,
the problem was,
of course is that once you got into things like security or trying to figure out how one of them worked or how,
um,
you know,
what one of them did better than anything else.
The problem is,
is suddenly you,
you don't know which if you're working with one of them and they're very similar,
you find out that like,
(07:53):
oh,
security,
um,
doesn't work for one of them.
So now you need to remove it or you have to,
um,
decide if you want to keep it.
That means that you have to do a whole lot more work to maintain it than if you had just chosen one,
maybe slightly suboptimal but single um solution.
And in,
in the case of third party packages,
(08:14):
when you don't have control over what their dependency is,
if they're ever gonna just be deprecated or that sort of thing,
if you,
the more of those you maintain,
the more unwieldy your code base becomes and so being consistent in terms of like vetting and choosing a single,
if you're gonna choose it to go the third party route,
choosing a single one and being consistent with it throughout your entire project life cycle.
(08:34):
Um or if you're gonna spin up your own,
being consistent about that as well.
Um So when I say consistency,
I mean,
basically doing the same thing over and over again,
like being,
you know,
measuring twice and cutting once and then sticking with it and not always trying to over optimize when I'm talking about third party packages,
like react is always susceptible to this,
(08:56):
the whole JavaScript ecosystem because it's because NPM is so easy to contribute to um the whole of React and um uh javascript ecosystem in general is very susceptible to the idea of,
you know,
you can just,
if you can younger people or maybe less experienced people will just download a React library for every component.
Yeah,
there's a package for that React library package for that,
(09:18):
right,
for everything.
And the problem is,
is that's great.
It saves you a little bit of time in the short run.
But if you go overboard and you're using slightly different third party packages for every problem or not checking back what people had done before or um,
having to maintain all of them,
you know,
(09:38):
that becomes a problem.
So I guess when I'm talking about consistency,
that's a slightly different problem.
Well,
there's kind of two problems here which is like maybe like,
you know,
bloat but then there's also,
but it's,
but bloat can arise from a failure to,
um,
to be consistent in,
um,
(09:59):
in your pro processes and your,
and in your practices,
right?
So like if you are,
if you choose a third party package,
you know,
and then you are inconsistently applying it, that causes bloat and that causes the problem that you are.
Yeah.
And that is causes the other those problems compound.
I think that's something that I've learned anyway to like to not just rely on like out of the like out of the box solutions.
(10:24):
From third parties.
Um,
or if I do, spending a lot of time making sure that I'm using ones that we've already checking what ones we already have in the project first before I go and find a new one.
So I think,
uh,
a lot of times I feel like,
um,
sometimes like learning those personal practices of saying,
ok,
before I just pull something else in,
(10:45):
maybe I need to do a little bit more research about the research about what's already here.
What are the downsides of bringing this in?
Um And,
and,
and I think there's,
there's a ton of that involved in,
in,
in,
in your personal growth as an engineer and in developing your own productivity and your own care over the code base that you're in charge of.
Um And then I think there's a big step from,
(11:06):
from that uh to learning that personal practice to growing to the point where you are helping your entire organization
Uh instill that those that set of values.
There's a concept I've,
I've read in um I think it's "The Pragmatic Programmer" which we'll link in the show notes.
Um But he talks about don't live with broken windows,
(11:27):
right?
Um The,
the idea of um you know,
if you're living in a neighborhood where a window gets broken,
if nobody fixes it,
if that window just stays broken,
uh It gives everybody there the sense that no one really cares that much about the place and sure enough,
like,
more things start breaking.
Right.
Somebody's paint gets chipped and it stays and,
um,
you know,
(11:47):
it,
it just,
these things have a way of festering.
Right.
And it's the same thing in your code base,
you know.
Right.
You want to instill that,
that sense throughout your organization of pride in what it is that you're doing pride in the quality of your product.
And part of that is,
um yeah,
you don't,
you don't want to have a bunch of unused packages around creating security risks and creating uh slow bundles,
you know,
huge bundles for your consumers,
(12:09):
that kind of thing.
Um And yeah,
it,
it a lot of times I find that now as I'm trying to move in into this more senior level,
so much of it becomes around demonstrating uh with data,
usually what I think is the right way to do things and,
and drumming up support and getting people to rally behind that because again,
(12:32):
it's one thing for me to just say,
hey guys,
we got to be doing this,
we gotta be doing this,
we gotta fix what we're doing.
We gotta clean up this um get these test suites to pass et cetera or get our increase our test coverage,
et cetera.
But like if I'm not backing it up with data and if I'm not getting enthusiasm,
buy-in from not only uh my peers but also leadership uh upper leadership,
(12:53):
then I'm not really doing the job that a company expects from a senior,
uh,
a staff engineer.
Right.
That's one of the things that I've,
I've heard consistently from,
uh,
my manager and from,
um,
more,
you know,
senior I CS who are,
who have been around longer than I have that,
that one of the,
one of the main things that staff engineers do is they are consistently in communication with leadership,
like upper level management (13:17):
directors,
et cetera,
they lean on their staff engineers to help drive the direction of the org.
So it's not,
you know,
I think that the biggest difference between like a senior engineer and a staff engineer is that a senior engineer can operate in a ton of ambiguity,
get a project done,
deliver it on time,
come up with great technical solutions.
(13:38):
But uh but the staff engineer is the one who is saying,
wow,
in an ocean of a million projects that need to get done,
which are the top priorities for this organization, and and how can I come up with a technical solution that we can get buy-in across teams?
Right?
I think that that is one of the things that I feel like I need to to work on almost more than anything is that that sense of like "I need to be solving problems for my organization,
(14:03):
not waiting for my organization to tell me what to do."
Like that is kind of the biggest shift
I think in the paradigm between a senior engineer who is very accomplished to get things done with a team of people and the one that the leadership is really gonna lean on.
So that's another thing I want to talk about actually is the concept of leadership in general.
Because I think when I was a junior,
(14:23):
I tended to think that,
like,
there's,
there's engineers and there's managers,
right?
Like there's,
there's the people who build the stuff,
there's the people who write the code and then there's the people who,
like,
manage it all and the,
those are the leaders and these are the,
these are the ICs,
right?
And I think that there's um you know,
a staff,
staff engineer is a leader,
(14:44):
right?
Whether it's a tech lead specifically that type of senior engineer.
But,
but you're,
you're more than just someone who executes on your own.
You are someone who leads the technical direction,
even though you're not a manager,
you're not in that management track.
That's something that I feel like I wanna focus on in a lot of our interviews here and our talks with each other is what is,
what does that look like?
What is leadership and how does it differ from,
(15:05):
from leadership in an executive track?
Right.
What does it look like to be a technical leader?
Exactly.
And how people have had that impact?
I mean,
like people who are already at that level,
that's something that I always am looking for examples of um in my job and with the people that I talk to,
it's like,
how do you make those impacts?
Because I,
like,
(15:26):
I,
like,
we've probably,
you know,
made pretty clear,
the hardest thing is not often the technical solution.
It's getting people to do things that they maybe don't want to do.
And like you said,
with the data that helps and it certainly can make your case.
But until you can get somebody excited about it or somebody to like,
you know,
want to work on it,
it doesn't mean anything.
(15:47):
A lot of the time often you can twist people's arm,
twist people's arms,
you know,
but it's not,
you know,
it's not,
you're gonna get a lot less work done than if you can get everybody excited about the idea.
There's um oh,
it's a famous quote,
but it's basically like "If you can give people,
you know,
a feeling of importance and a feeling of buy in,
(16:08):
you know,
that you can get them to do anything,"
right.
So,
so figuring out how to get people excited about something is one of the most valuable skills in any job.
And as we get higher and higher and farther away from the actual nitty gritty,
you know,
hands dirty code details.
I think it just becomes more and more important.
(16:30):
Every project I've had that involves other people lives and dies on how well I can,
I can get people interested in it and how well I can get people to,
um,
you know,
buy in to why it's valuable.
We've done a number of process changes.
I won't go into the details because they're frankly rather mundane,
but I think they're very important and data certainly helps.
(16:53):
But until it wasn't,
it was,
it's never been until sometimes the data will be enough um for certain types of things,
but for process things often it's like,
not until you can really demonstrate value to somebody's life or get them excited about why it's a valuable thing before they'll actually even start doing it because you can't be their babysitter.
You can't just monitor them all the time.
(17:13):
It takes so much energy to get people to like to just sit there and watch and like,
you know,
I don't know,
sometimes it feels like you're a little,
you know,
gargoyle sitting on their shoulder,
like telling them what to do and,
and,
and you can't do that.
It's a total drain on your energy if you can't get them,
get them people to want to do it on their own.
So I wanna,
(17:34):
I wanna go,
I,
I,
I wanna,
I wanna extend from that.
So follow me for a second while I kind of go a long way around here.
Um I think that juniors like,
like,
you know,
young,
newly hired engineers who are talented but are,
are,
you know,
given very clear scope,
they measure their progress,
um,
their impact in terms of like sprints,
(17:56):
right?
Like we,
we've asked,
uh an IC3 to,
um,
you know,
implement this one form,
right?
And they get it done in a,
in a,
in a sprint,
let's say,
and that's,
that's their impact.
It's really easy to see.
Like,
hey,
I did this,
I,
I,
I shipped it.
I was,
I was asked and I did,
I did a good job.
That's my impact,
right?
And as you get a little more senior,
(18:16):
maybe you start measuring your impact in terms of like a whole project or a large feature with a lot of different moving pieces,
right?
Where you get that in place and maybe it takes a couple of months,
right?
But you're able to measure that impact to say that.
Yep,
we had this project and we executed on it over the course of the last,
I don't know,
6 to 8 weeks we delivered,
(18:36):
uh we can measure its usage,
that's our impact,
right?
But as you get beyond that,
as you start getting in that,
that real Staff,
you're measuring your progress and not in terms of weeks or months,
but in terms of haves maybe even years um to solve a really large technical problem with a whole lot of moving pieces and a whole lot of blockers and a whole lot of ambiguity.
Um And I think one of the hardest things about that,
(18:59):
um one of the things I've heard some of our most senior engineers talk about is when you've got a project that is going to span multiple halves or even years.
Um You need to figure out how to start adding value as you go,
right?
You can't say,
"Hey,
two years from now,
all of this that I'm working on,
I promise it's gonna be super valuable,"
right?
The steps you take,
you need to be very careful about what you prioritize and how you order things.
(19:23):
So that as you're taking that journey,
that's gonna last a couple of years,
you need to be able to show value along the way,
right?
There needs to be something that you're adding that's actually valuable.
And so the reason I think about this is because sometimes it's like you want to change a process or refine something because maybe it's a better engineering need,
maybe it's uh trying to lock down security risks or get a hold of where your user data is,
(19:45):
all of that kind of stuff that,
that,
that larger companies have to deal with,
right?
You,
you can't just say,
"Hey,
we're gonna do this thing that's gonna be really hard and it's gonna take years and we're all gonna slog through it,"
right?
You need to be able to say, "By the end of the next month,
we will have accomplished this tiny chunk of this two year process."
And I this is how,
what the value will be because as you start building those little bitty chunks of positive impact,
(20:08):
you start gaining momentum in that project,
right?
And so over the course of the first year of a two year project,
you might be able to say we're only halfway to where we want to be.
But in that year,
we've accomplished these things that have already brought down this amount of latency by this percent or this.
Uh we've,
we've um identified and locked down this many millions of,
(20:29):
of um of instances of improperly exposed user data,
that kind of thing,
right?
Um Th those are the kind of things that I think as a staff engineer,
you have to be able to think long term,
think about things in,
in years and then be able to break those down into actually meaningful chunks of impact.
And that's the biggest,
I think the reason that why leadership do lean on these types of engineers is because that's leadership's timeframe,
(20:54):
right?
Like they're thinking about how to improve the company in the next 5,
10 years,
right?
And they need engineers that are thinking on that level too.
That's right.
And I think that numbers are persuasive.
I think that's one thing that I've learned quite a bit is that being able to quantify it instead of just saying,
I feel like this is gonna be better and being able to demonstrate that value when people don't have uh an easy way to measure it whenever you can give them real numbers to work with is very valuable.
(21:22):
And that's,
I've started doing a lot more recently is like,
um,
yeah,
just trying to figure out how to quantify everything in a way that's like easy to,
easy to digest,
but also concrete because I don't know,
I feel like people get a lot of like,
you know,
"This is just gonna be better,
but trust me," and it gets,
and so when you're able to demonstrate that this is,
(21:43):
it's gonna be this much better and here's how I'm measuring it.
People are a lot happier.
Um I've gotten a lot better at using tools that are completely,
I mean,
this is maybe something else we can talk about,
but I've gotten a lot better at tools that are not at all related to software engineering.
For that reason,
I've been building a lot more.
I don't know if you know,
are familiar with Mode.
You guys probably have some sort of special custom like uh meta version of this.
(22:08):
But um maybe,
but what is Mode?
It's basically like it allows you to run sequel queries and materialize data on your all your databases basically.
So you write a little like SQL query and then it'll put it and then it'll grab all the data,
put it in a table for you.
You know,
it's easy to write joins with.
And is it,
is it like a data pipeline de-normalization type of thing.
(22:32):
It's actually basically like Sisense where I used to work before this um where,
but it's a little bit more focused just on the um the the data side of things.
The the point is like,
I'm write--.
I know I had barely ever have had to write sequel in my career,
but I'm writing a lot more sequel lately because I'm basically just pulling numbers from the database able to say like this many posts were created over this many months,
(22:55):
this many users,
you know,
created posts with um or created data points with this type of content.
And this is how we were able to demonstrate that this is an increase or a decrease whatever we want over the past several months based off of ship work that we,
that we've done because we,
yeah,
it's funny,
I think like we have uh a,
(23:17):
a very sophisticated and mature ORM that we use um for,
you know,
so we have like the application query layer that we use for all our production code.
So I never ever write sequel for,
for my production code.
However,
for my working on my project and deciding what we're gonna do or figuring out how users are using my project,
(23:39):
I write sequel all all the time,
you know,
for all of these,
these uh you know,
our our logging tables and that kind of stuff then it,
yeah,
it does become,
I feel like that sequel.
Um Not so much for production but for,
um,
making business decisions has become so important.
Yeah.
Never for production.
Like,
I,
I don't think I've ever written a production line of sequel and I don't,
(24:00):
and if I,
anybody ever asked me to,
I probably would want their head examined.
They don't,
can't think of many reasons why it would be,
you know,
particularly good idea.
I mean,
I'm sure you must not be working in a code base that began as php in the early 2000s.
Right?
I'm just saying like there should that.
That's normally it's,
(24:21):
it's just funny because I've come full circle all around because I learned SQL a while ago just to learn how all that works.
Maybe I'm in a different world because I've also done a lot of noSQL over the past several years.
But recently we've been doing a lot of,
a lot of the work databases that I'm working with evidence in SQL.
Don't touch any SQL.
Uh Most of the database access stuff was also abstracted away years ago,
(24:45):
but I write quite a bit of SQL by hand in order to uh yeah,
in order to write little reports that I'm always giving out to people to say like this is what we need to do and this is why it's useful and,
and all that sort of stuff.
Exactly like you were,
what you were talking about.
So we,
we've got about,
we've got about five minutes left here.
And,
um,
I think it'd be great if we could each recommend something that we think is a great resource for people who are on this journey in their,
(25:09):
in their careers.
Um,
do you have a book or an article or something?
You wanna,
you wanna throw out?
Well,
actually I've got it here because I don't ever leave it too far away.
So,
when I'm trying to work my way through again now,
"Refactoring" by Martin Fowler,
it's always a classic because it's amazing and everybody knows it's amazing.
(25:30):
Fantastic book.
And that's what I,
I go back to all the time,
I think,
um,
you know,
as I write code and also,
you know,
I,
we just talked before the episode started recording that.
Uh,
we,
we've both been on call this week and a lot of times,
uh when I am dealing with a bug ticket in one of the projects,
it's not my main project.
One that I don't work on all the time.
It takes me a while to sort of get oriented in the,
(25:52):
in the corner of the code base where the,
the bug is coming from.
And,
um,
a lot of times I think,
ok,
since I'm,
I have fresh eyes on this,
right?
I,
I didn't write it myself.
Um Why am I confused?
Right.
What's,
what's here like that's making it hard for me to understand the bug.
And that usually presents a very good opportunity for refactoring,
right?
Like a way to just even that uh one of my favorite parts of the book is um swapping lines in,
(26:18):
in,
in the "Refactoring" book.
I remember it like just kind of moving lines that are related close to each other within the body of some other,
you know,
larger function.
And when you get them all kind of close enough together where the function still works properly,
but you can reason about the logic,
then you can take those groups and make them their own functions,
right?
And that,
that's like one of the most simple techniques from that book,
(26:38):
but I love it and I use it all the time.
Um Yeah,
so "Refactoring" is awesome,
awesome book.
So the one I wanna pick here um is called "Staff Engineer".
Uh This was written by Will Larson who was an engineering manager at uh Stripe at the time that he wrote it.
Um And he wrote down his thoughts around um what it takes to become a staff engineer a "staff+" as he calls it.
(26:59):
Um And also uh you know how to thrive once you get that position.
It's a great book.
I've read it once.
I'm still working my way through it again for a second time.
He's got terrific interviews in it from uh other senior leadership,
uh senior engineers,
excuse me,
staff+ engineers uh at places like Stripe, Google,
uh a number of other uh large tech companies the,
the book is just full of tons of knowledge.
(27:21):
Um And I think uh it'd be great for us to kind of spend some time in some of our interviews with staff engineers uh talking about sections of the book to see how they um how their experience either jives or differs from that.
Um But I can't recommend it enough for anyone who is uh currently looking to become beyond senior and really start influencing their entire organizations and companies as a technical leader.
(27:45):
Well,
I'm sold,
I just ordered it on Amazon.
There you go.
So I've already already made a sale. Well, with our final minute,
I wanna just say thanks for tuning in.
Um This is gonna be a journey again like this is,
this is uh Alex and I just want to share our learning as we're on this journey.
And um you know,
(28:05):
hopefully we will uh learn from some really smart people and,
and learn from each other and,
and,
and hopefully hear back from our listeners as well about um what they want to hear about and look forward to learning together.
Well,
till next one.
Hi,
everybody and welcome to the main thread. on this podcast,
We're going to explore the journey from mid/senior to staff plus level software engineer.
I'm Brian Ogilvie, and my friend and co host Alex Gaiser and I will be digging into the nitty gritty of what it takes to make that leap from senior engineer within your team to a true technical leader with organization- or company-wide impact.
(00:31):
Each episode,
We'll interview staff engineers from some of the world's largest tech companies like Meta, Google, and Amazon,
as well as some of the executives who lean on these engineers for setting and implementing their technical direction.
We'll also interview technical leaders from some smaller companies so that we can provide the broadest possible perspective and hopefully one that's useful to you on your career journey.
(00:51):
In this first episode,
Alex and I get together to discuss who we are, our mission for this podcast, and where we are on this journey from senior to staff.
We're excited to share this journey with you.
Let's get into it.
Why don't we start by kind of introducing ourselves and saying a little bit about uh why we're here.
Why we're doing this.
Do you wanna start?
(01:13):
So,
I'm Alex,
I'm a software engineer,
a senior software engineer with uh Bazaarvoice (BV), A content management,
social media management and analytics company.
Um I spend a lot of my time building things to scrape and uh publish post all of your favorite social media networks.
(01:34):
Um It's not much but it's honest work.
So looking good.
And we've started this podcast to kind of see what we can do to take our careers to the next level.
How about you,
Brian?
So,
yeah,
I'm Brian Ogilvie and uh I am a software engineer at Meta.
Um I've been there uh for just under three years now.
(01:55):
Um I work on the enterprise side of things working in infrastructure and security.
Um And uh and Alex and I were talking recently.
Um We,
we both went through the same boot camp when we were entering the tech industry a few years back.
Uh We came out of General Assembly together.
Uh Both found our first jobs in the industry at the same time and have been working um and just kind of staying close since then and,
(02:19):
and have,
you know,
worked through a number of different jobs,
worked up,
gotten promotions.
Um But we both have a number of different resources that we use on a regular basis and have always used to find content on technical um concepts and uh breaking into the industry,
et cetera.
But we were talking recently that it doesn't seem there's much content available for people who are now actually pretty firmly established in the industry,
(02:44):
have been around,
have,
have had some success and are looking to move from that mid slash senior level up to that um much more senior level that staff slash/principal level.
Um And we thought it would be helpful both to us and to anyone else who's out there,
kind of at the same similar part in their journey to talk about this.
Um So what we wanna do with this podcast is we want to talk about some of the concepts that are um important uh for growing beyond that mid/senior level.
(03:12):
Um And we wanna do it,
not just with the two of us,
but we wanna bring on people,
we know um people who are already staff plus engineers at various uh companies of different sizes.
Um We want to bring in managers,
executives from these type of companies to hear their thoughts on what they look for uh in terms of their staff,
engineers,
their principal engineers (03:31):
who they trust and why.
Um And we just thought we'd share our journey as uh we're on this path looking to take our careers to the next level.
So I thought uh we start out with just a couple of things like,
you know,
what do we know?
What do we know here?
Um What have we learned so far?
In terms of,
uh,
our careers,
um,
(03:52):
what's taken us from the very intro level,
junior jobs to,
uh,
these promotions and,
um,
getting to the level we're at now.
And,
uh,
what do we think is probably gonna be different about the path from here to the next level?
Yeah,
I'd say that the first thing that we've probably learned,
the biggest lesson that we've learned is that it's about process and people over projects and um code.
(04:17):
It's often about how you're able to organize people rather than how much,
how fast you're able to grind out the specific solution to a problem.
Um You know,
you wanna be uh I guess it's a bit of a cliche,
but you wanna be a force multiplier.
You want to be somebody who can organize people to get things done,
who can help lubricate to lubricate the process so that,
(04:39):
you know,
things that are,
are able to run smoothly.
And I suppose one of the things that I've learned is just the value of consistency.
It becomes extremely unwieldy to work on a large project over a long period of time when it's like digging through layers of archaeology,
when you're looking back through how a code that was written a month ago,
a year ago.
(04:59):
And it's like you can just see by the standards and practices that were used to implement,
that particular piece of code would be like almost to the,
to the year of the month when it was written because there's no consistency and that becomes very difficult because you basically have to, like an archaeologist, learn about all the different strata as you go back in time.
Whereas if it's all one uniform thing throughout the entire code base for,
(05:21):
for years and years and years,
it's very difficult to do, it's much, it's almost becomes a shortcut to learn.
Um You know,
when you go from one piece of code to,
to the next,
you know,
if you see one pattern in one place and you walk and you spend a lot of time worrying about it,
its strengths,
its weaknesses,
you go all the way back to,
I don't know,
a year maybe might be a bit of a stretch.
(05:43):
But like,
you know,
you go all the way back a year in the same repo and you see the same pattern implemented.
Um,
suddenly you don't have to learn that entire piece of code all over again,
that entire project all over again.
You know,
generally speaking,
what to expect.
Um,
you can kind of get a sixth sense even for like where things are going to be,
(06:03):
how it's likely to have been implemented if and that is just,
it speeds things up,
it reduces cognitive load.
We can probably talk about books,
we like later,
but there's a book that I really like that talks a ton about things like cognitive load.
And one of the things that we've learned as we've gone,
getting gotten older and I guess,
uh,
less,
(06:23):
less exciting is that things like process and consistency are things that,
um,
when you see it,
it makes you happier than any elegantly piece,
written piece of code.
And I'll often take like a consistently written code base that's maybe not the most like concise or elegant over one that's like beautiful and concise and,
you know,
does something in some like a novel,
(06:44):
interesting way.
Sometimes novelty is the enemy,
in fact.
So can you talk to me a little bit about,
uh when you say consistency?
What does that mean exactly in this context?
Um Being consistent about,
about what types of things,
standards and practices,
everything from like,
like I said,
what patterns you use,
what technologies you use?
Um,
not always bringing in a third party uh uh solution like a third party package to solve a problem.
(07:11):
Not,
I mean,
I've seen this,
we,
I worked in code base where we had four different in the same repository,
four different logging,
um,
uh packages that we used.
Um,
they all did slightly different things and they all did one or two things better than each other in addition,
of course,
to our custom one that we built ourselves.
(07:33):
Um And the,
the problem was,
of course is that once you got into things like security or trying to figure out how one of them worked or how,
um,
you know,
what one of them did better than anything else.
The problem is,
is suddenly you,
you don't know which if you're working with one of them and they're very similar,
you find out that like,
(07:53):
oh,
security,
um,
doesn't work for one of them.
So now you need to remove it or you have to,
um,
decide if you want to keep it.
That means that you have to do a whole lot more work to maintain it than if you had just chosen one,
maybe slightly suboptimal but single um solution.
And in,
in the case of third party packages,
(08:14):
when you don't have control over what their dependency is,
if they're ever gonna just be deprecated or that sort of thing,
if you,
the more of those you maintain,
the more unwieldy your code base becomes and so being consistent in terms of like vetting and choosing a single,
if you're gonna choose it to go the third party route,
choosing a single one and being consistent with it throughout your entire project life cycle.
(08:34):
Um or if you're gonna spin up your own,
being consistent about that as well.
Um So when I say consistency,
I mean,
basically doing the same thing over and over again,
like being,
you know,
measuring twice and cutting once and then sticking with it and not always trying to over optimize when I'm talking about third party packages,
like react is always susceptible to this,
(08:56):
the whole JavaScript ecosystem because it's because NPM is so easy to contribute to um the whole of React and um uh javascript ecosystem in general is very susceptible to the idea of,
you know,
you can just,
if you can younger people or maybe less experienced people will just download a React library for every component.
Yeah,
there's a package for that React library package for that,
(09:18):
right,
for everything.
And the problem is,
is that's great.
It saves you a little bit of time in the short run.
But if you go overboard and you're using slightly different third party packages for every problem or not checking back what people had done before or um,
having to maintain all of them,
you know,
(09:38):
that becomes a problem.
So I guess when I'm talking about consistency,
that's a slightly different problem.
Well,
there's kind of two problems here which is like maybe like,
you know,
bloat but then there's also,
but it's,
but bloat can arise from a failure to,
um,
to be consistent in,
um,
(09:59):
in your pro processes and your,
and in your practices,
right?
So like if you are,
if you choose a third party package,
you know,
and then you are inconsistently applying it, that causes bloat and that causes the problem that you are.
Yeah.
And that is causes the other those problems compound.
I think that's something that I've learned anyway to like to not just rely on like out of the like out of the box solutions.
(10:24):
From third parties.
Um,
or if I do, spending a lot of time making sure that I'm using ones that we've already checking what ones we already have in the project first before I go and find a new one.
So I think,
uh,
a lot of times I feel like,
um,
sometimes like learning those personal practices of saying,
ok,
before I just pull something else in,
(10:45):
maybe I need to do a little bit more research about the research about what's already here.
What are the downsides of bringing this in?
Um And,
and,
and I think there's,
there's a ton of that involved in,
in,
in,
in your personal growth as an engineer and in developing your own productivity and your own care over the code base that you're in charge of.
Um And then I think there's a big step from,
(11:06):
from that uh to learning that personal practice to growing to the point where you are helping your entire organization
Uh instill that those that set of values.
There's a concept I've,
I've read in um I think it's "The Pragmatic Programmer" which we'll link in the show notes.
Um But he talks about don't live with broken windows,
(11:27):
right?
Um The,
the idea of um you know,
if you're living in a neighborhood where a window gets broken,
if nobody fixes it,
if that window just stays broken,
uh It gives everybody there the sense that no one really cares that much about the place and sure enough,
like,
more things start breaking.
Right.
Somebody's paint gets chipped and it stays and,
um,
you know,
(11:47):
it,
it just,
these things have a way of festering.
Right.
And it's the same thing in your code base,
you know.
Right.
You want to instill that,
that sense throughout your organization of pride in what it is that you're doing pride in the quality of your product.
And part of that is,
um yeah,
you don't,
you don't want to have a bunch of unused packages around creating security risks and creating uh slow bundles,
you know,
huge bundles for your consumers,
(12:09):
that kind of thing.
Um And yeah,
it,
it a lot of times I find that now as I'm trying to move in into this more senior level,
so much of it becomes around demonstrating uh with data,
usually what I think is the right way to do things and,
and drumming up support and getting people to rally behind that because again,
(12:32):
it's one thing for me to just say,
hey guys,
we got to be doing this,
we gotta be doing this,
we gotta fix what we're doing.
We gotta clean up this um get these test suites to pass et cetera or get our increase our test coverage,
et cetera.
But like if I'm not backing it up with data and if I'm not getting enthusiasm,
buy-in from not only uh my peers but also leadership uh upper leadership,
(12:53):
then I'm not really doing the job that a company expects from a senior,
uh,
a staff engineer.
Right.
That's one of the things that I've,
I've heard consistently from,
uh,
my manager and from,
um,
more,
you know,
senior I CS who are,
who have been around longer than I have that,
that one of the,
one of the main things that staff engineers do is they are consistently in communication with leadership,
like upper level management (13:17):
directors,
et cetera,
they lean on their staff engineers to help drive the direction of the org.
So it's not,
you know,
I think that the biggest difference between like a senior engineer and a staff engineer is that a senior engineer can operate in a ton of ambiguity,
get a project done,
deliver it on time,
come up with great technical solutions.
(13:38):
But uh but the staff engineer is the one who is saying,
wow,
in an ocean of a million projects that need to get done,
which are the top priorities for this organization, and and how can I come up with a technical solution that we can get buy-in across teams?
Right?
I think that that is one of the things that I feel like I need to to work on almost more than anything is that that sense of like "I need to be solving problems for my organization,
(14:03):
not waiting for my organization to tell me what to do."
Like that is kind of the biggest shift
I think in the paradigm between a senior engineer who is very accomplished to get things done with a team of people and the one that the leadership is really gonna lean on.
So that's another thing I want to talk about actually is the concept of leadership in general.
Because I think when I was a junior,
(14:23):
I tended to think that,
like,
there's,
there's engineers and there's managers,
right?
Like there's,
there's the people who build the stuff,
there's the people who write the code and then there's the people who,
like,
manage it all and the,
those are the leaders and these are the,
these are the ICs,
right?
And I think that there's um you know,
a staff,
staff engineer is a leader,
(14:44):
right?
Whether it's a tech lead specifically that type of senior engineer.
But,
but you're,
you're more than just someone who executes on your own.
You are someone who leads the technical direction,
even though you're not a manager,
you're not in that management track.
That's something that I feel like I wanna focus on in a lot of our interviews here and our talks with each other is what is,
what does that look like?
What is leadership and how does it differ from,
(15:05):
from leadership in an executive track?
Right.
What does it look like to be a technical leader?
Exactly.
And how people have had that impact?
I mean,
like people who are already at that level,
that's something that I always am looking for examples of um in my job and with the people that I talk to,
it's like,
how do you make those impacts?
Because I,
like,
(15:26):
I,
like,
we've probably,
you know,
made pretty clear,
the hardest thing is not often the technical solution.
It's getting people to do things that they maybe don't want to do.
And like you said,
with the data that helps and it certainly can make your case.
But until you can get somebody excited about it or somebody to like,
you know,
want to work on it,
it doesn't mean anything.
(15:47):
A lot of the time often you can twist people's arm,
twist people's arms,
you know,
but it's not,
you know,
it's not,
you're gonna get a lot less work done than if you can get everybody excited about the idea.
There's um oh,
it's a famous quote,
but it's basically like "If you can give people,
you know,
a feeling of importance and a feeling of buy in,
(16:08):
you know,
that you can get them to do anything,"
right.
So,
so figuring out how to get people excited about something is one of the most valuable skills in any job.
And as we get higher and higher and farther away from the actual nitty gritty,
you know,
hands dirty code details.
I think it just becomes more and more important.
(16:30):
Every project I've had that involves other people lives and dies on how well I can,
I can get people interested in it and how well I can get people to,
um,
you know,
buy in to why it's valuable.
We've done a number of process changes.
I won't go into the details because they're frankly rather mundane,
but I think they're very important and data certainly helps.
(16:53):
But until it wasn't,
it was,
it's never been until sometimes the data will be enough um for certain types of things,
but for process things often it's like,
not until you can really demonstrate value to somebody's life or get them excited about why it's a valuable thing before they'll actually even start doing it because you can't be their babysitter.
You can't just monitor them all the time.
(17:13):
It takes so much energy to get people to like to just sit there and watch and like,
you know,
I don't know,
sometimes it feels like you're a little,
you know,
gargoyle sitting on their shoulder,
like telling them what to do and,
and,
and you can't do that.
It's a total drain on your energy if you can't get them,
get them people to want to do it on their own.
So I wanna,
(17:34):
I wanna go,
I,
I,
I wanna,
I wanna extend from that.
So follow me for a second while I kind of go a long way around here.
Um I think that juniors like,
like,
you know,
young,
newly hired engineers who are talented but are,
are,
you know,
given very clear scope,
they measure their progress,
um,
their impact in terms of like sprints,
(17:56):
right?
Like we,
we've asked,
uh an IC3 to,
um,
you know,
implement this one form,
right?
And they get it done in a,
in a,
in a sprint,
let's say,
and that's,
that's their impact.
It's really easy to see.
Like,
hey,
I did this,
I,
I,
I shipped it.
I was,
I was asked and I did,
I did a good job.
That's my impact,
right?
And as you get a little more senior,
(18:16):
maybe you start measuring your impact in terms of like a whole project or a large feature with a lot of different moving pieces,
right?
Where you get that in place and maybe it takes a couple of months,
right?
But you're able to measure that impact to say that.
Yep,
we had this project and we executed on it over the course of the last,
I don't know,
6 to 8 weeks we delivered,
(18:36):
uh we can measure its usage,
that's our impact,
right?
But as you get beyond that,
as you start getting in that,
that real Staff,
you're measuring your progress and not in terms of weeks or months,
but in terms of haves maybe even years um to solve a really large technical problem with a whole lot of moving pieces and a whole lot of blockers and a whole lot of ambiguity.
Um And I think one of the hardest things about that,
(18:59):
um one of the things I've heard some of our most senior engineers talk about is when you've got a project that is going to span multiple halves or even years.
Um You need to figure out how to start adding value as you go,
right?
You can't say,
"Hey,
two years from now,
all of this that I'm working on,
I promise it's gonna be super valuable,"
right?
The steps you take,
you need to be very careful about what you prioritize and how you order things.
(19:23):
So that as you're taking that journey,
that's gonna last a couple of years,
you need to be able to show value along the way,
right?
There needs to be something that you're adding that's actually valuable.
And so the reason I think about this is because sometimes it's like you want to change a process or refine something because maybe it's a better engineering need,
maybe it's uh trying to lock down security risks or get a hold of where your user data is,
(19:45):
all of that kind of stuff that,
that,
that larger companies have to deal with,
right?
You,
you can't just say,
"Hey,
we're gonna do this thing that's gonna be really hard and it's gonna take years and we're all gonna slog through it,"
right?
You need to be able to say, "By the end of the next month,
we will have accomplished this tiny chunk of this two year process."
And I this is how,
what the value will be because as you start building those little bitty chunks of positive impact,
(20:08):
you start gaining momentum in that project,
right?
And so over the course of the first year of a two year project,
you might be able to say we're only halfway to where we want to be.
But in that year,
we've accomplished these things that have already brought down this amount of latency by this percent or this.
Uh we've,
we've um identified and locked down this many millions of,
(20:29):
of um of instances of improperly exposed user data,
that kind of thing,
right?
Um Th those are the kind of things that I think as a staff engineer,
you have to be able to think long term,
think about things in,
in years and then be able to break those down into actually meaningful chunks of impact.
And that's the biggest,
I think the reason that why leadership do lean on these types of engineers is because that's leadership's timeframe,
(20:54):
right?
Like they're thinking about how to improve the company in the next 5,
10 years,
right?
And they need engineers that are thinking on that level too.
That's right.
And I think that numbers are persuasive.
I think that's one thing that I've learned quite a bit is that being able to quantify it instead of just saying,
I feel like this is gonna be better and being able to demonstrate that value when people don't have uh an easy way to measure it whenever you can give them real numbers to work with is very valuable.
(21:22):
And that's,
I've started doing a lot more recently is like,
um,
yeah,
just trying to figure out how to quantify everything in a way that's like easy to,
easy to digest,
but also concrete because I don't know,
I feel like people get a lot of like,
you know,
"This is just gonna be better,
but trust me," and it gets,
and so when you're able to demonstrate that this is,
(21:43):
it's gonna be this much better and here's how I'm measuring it.
People are a lot happier.
Um I've gotten a lot better at using tools that are completely,
I mean,
this is maybe something else we can talk about,
but I've gotten a lot better at tools that are not at all related to software engineering.
For that reason,
I've been building a lot more.
I don't know if you know,
are familiar with Mode.
You guys probably have some sort of special custom like uh meta version of this.
(22:08):
But um maybe,
but what is Mode?
It's basically like it allows you to run sequel queries and materialize data on your all your databases basically.
So you write a little like SQL query and then it'll put it and then it'll grab all the data,
put it in a table for you.
You know,
it's easy to write joins with.
And is it,
is it like a data pipeline de-normalization type of thing.
(22:32):
It's actually basically like Sisense where I used to work before this um where,
but it's a little bit more focused just on the um the the data side of things.
The the point is like,
I'm write--.
I know I had barely ever have had to write sequel in my career,
but I'm writing a lot more sequel lately because I'm basically just pulling numbers from the database able to say like this many posts were created over this many months,
(22:55):
this many users,
you know,
created posts with um or created data points with this type of content.
And this is how we were able to demonstrate that this is an increase or a decrease whatever we want over the past several months based off of ship work that we,
that we've done because we,
yeah,
it's funny,
I think like we have uh a,
(23:17):
a very sophisticated and mature ORM that we use um for,
you know,
so we have like the application query layer that we use for all our production code.
So I never ever write sequel for,
for my production code.
However,
for my working on my project and deciding what we're gonna do or figuring out how users are using my project,
(23:39):
I write sequel all all the time,
you know,
for all of these,
these uh you know,
our our logging tables and that kind of stuff then it,
yeah,
it does become,
I feel like that sequel.
Um Not so much for production but for,
um,
making business decisions has become so important.
Yeah.
Never for production.
Like,
I,
I don't think I've ever written a production line of sequel and I don't,
(24:00):
and if I,
anybody ever asked me to,
I probably would want their head examined.
They don't,
can't think of many reasons why it would be,
you know,
particularly good idea.
I mean,
I'm sure you must not be working in a code base that began as php in the early 2000s.
Right?
I'm just saying like there should that.
That's normally it's,
(24:21):
it's just funny because I've come full circle all around because I learned SQL a while ago just to learn how all that works.
Maybe I'm in a different world because I've also done a lot of noSQL over the past several years.
But recently we've been doing a lot of,
a lot of the work databases that I'm working with evidence in SQL.
Don't touch any SQL.
Uh Most of the database access stuff was also abstracted away years ago,
(24:45):
but I write quite a bit of SQL by hand in order to uh yeah,
in order to write little reports that I'm always giving out to people to say like this is what we need to do and this is why it's useful and,
and all that sort of stuff.
Exactly like you were,
what you were talking about.
So we,
we've got about,
we've got about five minutes left here.
And,
um,
I think it'd be great if we could each recommend something that we think is a great resource for people who are on this journey in their,
(25:09):
in their careers.
Um,
do you have a book or an article or something?
You wanna,
you wanna throw out?
Well,
actually I've got it here because I don't ever leave it too far away.
So,
when I'm trying to work my way through again now,
"Refactoring" by Martin Fowler,
it's always a classic because it's amazing and everybody knows it's amazing.
(25:30):
Fantastic book.
And that's what I,
I go back to all the time,
I think,
um,
you know,
as I write code and also,
you know,
I,
we just talked before the episode started recording that.
Uh,
we,
we've both been on call this week and a lot of times,
uh when I am dealing with a bug ticket in one of the projects,
it's not my main project.
One that I don't work on all the time.
It takes me a while to sort of get oriented in the,
(25:52):
in the corner of the code base where the,
the bug is coming from.
And,
um,
a lot of times I think,
ok,
since I'm,
I have fresh eyes on this,
right?
I,
I didn't write it myself.
Um Why am I confused?
Right.
What's,
what's here like that's making it hard for me to understand the bug.
And that usually presents a very good opportunity for refactoring,
right?
Like a way to just even that uh one of my favorite parts of the book is um swapping lines in,
(26:18):
in,
in the "Refactoring" book.
I remember it like just kind of moving lines that are related close to each other within the body of some other,
you know,
larger function.
And when you get them all kind of close enough together where the function still works properly,
but you can reason about the logic,
then you can take those groups and make them their own functions,
right?
And that,
that's like one of the most simple techniques from that book,
(26:38):
but I love it and I use it all the time.
Um Yeah,
so "Refactoring" is awesome,
awesome book.
So the one I wanna pick here um is called "Staff Engineer".
Uh This was written by Will Larson who was an engineering manager at uh Stripe at the time that he wrote it.
Um And he wrote down his thoughts around um what it takes to become a staff engineer a "staff+" as he calls it.
(26:59):
Um And also uh you know how to thrive once you get that position.
It's a great book.
I've read it once.
I'm still working my way through it again for a second time.
He's got terrific interviews in it from uh other senior leadership,
uh senior engineers,
excuse me,
staff+ engineers uh at places like Stripe, Google,
uh a number of other uh large tech companies the,
the book is just full of tons of knowledge.
(27:21):
Um And I think uh it'd be great for us to kind of spend some time in some of our interviews with staff engineers uh talking about sections of the book to see how they um how their experience either jives or differs from that.
Um But I can't recommend it enough for anyone who is uh currently looking to become beyond senior and really start influencing their entire organizations and companies as a technical leader.
(27:45):
Well,
I'm sold,
I just ordered it on Amazon.
There you go.
So I've already already made a sale. Well, with our final minute,
I wanna just say thanks for tuning in.
Um This is gonna be a journey again like this is,
this is uh Alex and I just want to share our learning as we're on this journey.
And um you know,
(28:05):
hopefully we will uh learn from some really smart people and,
and learn from each other and,
and,
and hopefully hear back from our listeners as well about um what they want to hear about and look forward to learning together.
Well,
till next one.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy And Charlamagne Tha God!
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.