Shopify Distinguished Eng (L10) on What Principal+ Engineering Looks Like
By Ryan Peterman
Summary
## Key takeaways - **Principal Engineer: Figure it out yourself**: The role of a principal engineer is defined by ambiguity; you're expected to identify problems and figure out solutions without a prescribed job description, much like being dropped into foreign terrain on a reconnaissance mission. [00:10], [00:46] - **Distinguished Engineer: Dynamic Range of Problems**: A distinguished engineer demonstrates the ability to solve problems across the entire stack, from the bare metal to business requirements, and can adapt to different execution models, whether it's rapid iteration in a 'fog of war' or deliberate, slow thinking for foundational APIs. [01:34], [02:23] - **Career Strategy: Be the 'Only' Person, Not the 'Best'**: Building a resilient career involves optimizing for being the 'only' person with a unique combination of skills, rather than being the 'best' in a single domain, as the latter can become obsolete if the world changes. [04:43], [05:32] - **Generalist Advantage: Wide Toolbox, High Competence**: Acquiring 80-90% competence in multiple domains quickly, especially with modern tools like LLMs, allows you to build a versatile toolkit. This enables you to combine skills to solve problems that specialists cannot, making you resilient and effective in ambiguous situations. [06:43], [10:31] - **The Translator Role**: A key contribution is acting as a translator between different parts of the company, synthesizing information and bridging gaps, even if you're not the most knowledgeable person in every room. [07:42], [08:19] - **IC-Management Fluidity**: Transitioning between individual contributor and management roles should not be stigmatized as a demotion; it offers valuable skills and perspective, making it easier to partner across different functions. [11:31], [12:55]
Topics Covered
- Master ambiguity: The real job of senior engineers.
- Distinguished engineers solve problems with dynamic range.
- Be the only, not the best: Build a resilient career.
- Generalists are translators in ambiguous situations.
- Career paths aren't linear; embrace transitions.
Full Transcript
You went from a principal engineer to a
distinguished engineer. I'm curious what
is the tour of duty there that got you
promoted.
One of the I think underappreciated or
misunderstood aspects of being a
principal engineer is when people ask
what do you do like you know g give me
give me a job description because I want
to become a principal engineer like what
are the boxes I need to tick the answer
is actually embedded in the question
because people that have to ask that
question by definition are not principal
engineers right because the problems
become ambiguous enough at that level
where you kind of have to figure it out
yourself like my expectation for I I
mentor a a lot of uh principal engineers
that come into Shopify. Uh my
expectation for someone coming in at
that level is look uh you're basically
to use an analogy here, you're going to
be dropped parachuted into foreign
terrain. You're on a reconnaissance
reconnaissance mission and within the
first seven days you should figure out
the lay of the land and figure out where
the problems are. Build alliances with
your directors, VPs, whoever needs to
be. figure out what their problems are
and then kind of understand the
situation and figure out where you can
apply your particular skill set to help
them. Right? I don't have a prescription
for you. Like it it is your agency. It
is your problem to figure this out and
that requires a particular kind of skill
set and a toolkit that you have to
develop to figure that out, right?
Because there's a lot of ambiguity in
that. Going to a level above that kind
of as a distinguished engineer, it's
even more amorphous in many ways. there
isn't any shared definition right but I
the way I think about it is uh proof of
the dynamic range of the problems that
you can solve so and then dynamic range
kind of goes in a couple of different
directions one is technically uh so are
you able to have you shown a repeatable
record of being able to operate kind of
at all layers of the stack if you're
engaged with the team are you able to
kind of go all the way down to the bare
metal and understand what are the
constraints what are the problems going
to from ground truth reconstruct the
problem at the same time are you able to
operate with the business requirements
you know with your VP and product
counterparts to actually understand
what's in their head how it manifests in
code and translate that into actionable
change and like deliver the right
product that's the technical aspect of
it um but then there's also the uh the
execution model uh kind of in the middle
where you have to be able to flex uh
there are different types of projects
that you get parachuted into some
projects are uh working at the frontier
of knowledge or product space where
there's like just fog of war. You don't
know what you don't know and you have to
be working kind of the startup mode of
look, we're going to fire. We're going
to see where it lands. Then we're going
to aim and we're going to fire again and
we're going to do that really rapidly,
really fast, as quickly as we can so we
can figure out where the hell we are and
then we'll figure out what we're going
to build. Right? That requires a
particular skill set. On the other hand,
you can be parachuted into kind of a
slower moving pace pace layer of the
company where it's like okay guys we
have this uh platform API problem you
know we have a just using like a random
example right um and it's really
important that we think through how we
design this API because it'll have
second and third order repercussions
like years down the road for our partner
ecosystem and all the rest so we need to
engage our slow thinking brain to really
understand how this change at this layer
will manifest its way through all the
others, right? And that's a very
different mode of engagement. That's
like that's much more in a way academic,
but you also need to be able to take all
of that divergent thinking and converge
the problem to like here here's the
actual recommendation, right? So it
really becomes the demonstration of your
toolkit of being able to execute across
all of those domains because when you
talk to like the expectation for a
distinguished engineer is kind of
similar to a VP like it is a VP
equivalent role right like write me a
description for a VP well the job of a
VP is to solve every problem that lands
on their plate right it's like and by
definition all the easy problems have
been solved before like at layers below
them so they only get the problems with
incomplete information or imperfect
decisions. So, uh, show me the volume
and show me the versatility of your
toolkit.
That gives me confidence that I could
parachute you into like I can give you
this weird shaped problem next. And with
reasonable success, you'll be able to
navigate yourself out of it. One thing
that I I share often with uh folks that
I coach and work with is I I I have this
belief that a better way, a more
resilient way to build your career is to
optimize for being the only person as
opposed to the best person. So
what does that actually mean there?
There are two different paths that you
could take. You could say, look, I'm
going to pick a particular domain and
I'm going to be the best person that
will know the most about a particular
thing. So, I'm going to like take
security as an example, right? I'm going
to learn everything there is to know and
that's going to be my life life calling.
And that's great. There's absolutely
nothing wrong with that. Um you you can
optimize for that. My personal
philosophy is um that is one way to
success, but it is not the most
resilient way to success. Uh because
what if you pick the wrong field? What
if the world changes under you? What if
um your particular company does not need
that particular skill set? Be the only
to me is is about building a talent
stack or a portfolio skills that you can
juggle and be effective. And I think
this is actually um reflects back in the
dynamic range conversation that we were
just having, right? Were you able to
say, look, uh and maybe this is actually
me justifying my own career track
because when I look back on my career, I
could say like look, I was a mediocre
designer. I was a mediocre um
salesperson.
I was okay at support, but like come on.
Like that that's not my life calling
either. But you know what I did really
well? I combined all of those things
into a unique toolkit that other people
could not do. Like I could look at a
problem and I could say, "Yeah, I could
sling together website. I know Photoshop
well enough and I know how to host it
and I know how to secure it and I can
stand all of that up for you in, you
know, in the next two days." You don't
have to hire a team for that. and I have
I have the dynamic range to do that.
Now, if it turns out that um we now
hired a graphic designer, that's
excellent. But great, I'm just going to
take that particular skill set out of my
quiver, hand it over to them, and I'm
going to focus on the other things,
right? And I think generally uh you can
acquire very high competence like 80 90%
uh competence very quickly in a domain.
you can get to 80% in a matter of days
to weeks and especially now with the
tools that we have access to with LLMs
and all the rest like the ability to
acquire context is uh just amazing.
You can spend the next year to get
yourself to 90%.
And now if you optimize for that, you
have resilience because um I'm able to
converse
with our marketing team because you know
what? I took the time like I I literally
remember going on Amazon and I bought
15 books on marketing and I spent a week
nothing but reading marketing books so I
could understand the lexicon the jargon
and and speak the right words when I
talk to marketing teams.
I'm also adept enough at uh working with
our PR teams because like I've written a
lot right and I've practiced that
muscle. I'm also an engineer so I and
now I'm able to bridge. So oftentimes
when I find myself in conversations at
Shopify or elsewhere, I'm the translator
between all of these different parts of
the company and organs of the body where
I'm able to kind of synthesize that
information and bring it together. And
that gives me a lot of versatility,
right? It doesn't mean that I'm the
smartest person in in the room. Uh often
times that's far from the uh from the
truth. I'm often the most senior person,
but rarely am I the most knowledgeable.
And that's actually very important
because part of my skill set is to
figure out who are the most
knowledgeable people and figure out how
to leverage them in the most effective
way. Right? My contribution is I
understand kind of fundamentals of the
platform and what you can do with um our
APIs or our platform. I understand the
business requirements. There's a very
messy middle in the middle of how you
actually implement the solution with a
number of variants.
That's not my responsibility. My
responsibility is to help the people
that know the most about that messy
middle navigate through that decision
space and I have a toolkit to help them
facilitate that. But it's not it doesn't
mean that you know the most senior
person in the room knows all the answers
which I think is a mistake that a lot of
engineers make when they think about
principal engineers like oh if you're a
principal you know everything there is
to know about the web platform. It's
like well not really right like what
I've learned is a lot of pattern
matching. I've learned how to find
answers. I know where to find answers
and I know how to navigate out of tricky
situations, but it doesn't mean that I
know every API and every quirk. Now,
some people do because that's what they
make their life calling. And that's I
think that that's perfectly fine, but as
a general strategy, I think it's not as
resilient. An anti-fragile career is
where you have a set of these
capabilities where you can just swap out
at any given moment and say, "Okay,
well, I guess I'm solving a go to market
problem right now. So, let me pull out
my
other quiver of capabilities."
I see. So when you say don't be the
best, be the only, you're saying that
generalists have an advantage because
they can put together a bunch of skill
sets, get most of the way there, and be
the only because the intersection of all
those skill sets is more special and
more resilient because you have such a
wide toolbox. Is that right?
>> Yeah. This is this is literally
probability math, right? It's like how
many people if you multiply out the
probabilities of how many people know
this particular have this particular
skill set like you know enough about
databases you know enough about graphics
you know about you do you know enough
about all these other components who is
the person that is the only person that
has sufficient domain expertise and
connective tissue to solve this problem
right so the being the only is about
having a wide range of tools that you
can reach into and say hey I can combine
them in any particular way which is what
makes you versatile style and makes you
effective in these kind of ambiguous
situations where you can based on the
situation adapt how you work, right?
Because I can shift gears and say,
"Look, I've I've been a manager before.
I understand what it means to do
performance management. I understand how
to coach people." Um, so I can even if
I'm working as an IC, I can take an
engineer aside and say, "Look, like
here's some feedback or here's some
recommendations here. I know how to
conduct myself. I know what things to
say, what not to say, and and help them
along the way, right? It doesn't mean
that I'm exercising that skill all the
time, but I'm able to be parachuted into
situation where I can act as that
temporarily. And that's turned out to be
incredibly helpful. I had one mentor who
did seesaw as well. And he said that
management always appreciates an IC that
understands management because it's much
easier to partner with them.
>> Yes, absolutely. So I would absolutely
encourage um if you're an IC track and
you've never tried management like def
like being a TL is a great learning
wheels um you should definitely try if
it if it suits you to do management as
well but don't assume that it's a
one-way path right you can go back and
forth and there isn't a stigma I think
historically there has been in some
organizations because also we've kind of
painted this picture of hey the path to
success is you grow to be a manager
right but That's not like when I talk to
a lot of managers in like high roles,
directors and all the rest, you know,
after you sit at a bar and and have a
couple of drinks, they're like you
reflect back on what was when were you
happiest in your career? They say, "Huh,
you know, it was a couple years back
before I became an ex because I had like
I was really competent at that thing and
I was loving it, but I was told that in
order for me to like grow quote unquote,
I needed to take on this other thing."
It's like well huh well that's that's an
interesting reflection right and at the
same time they will reflect and say but
I've also learned a lot in this new role
I appreciate what it means to run a team
the complexity the interpersonal
dynamics the performance management and
all the rest and that's an amazing tool
to have in your toolkit great now um
let's set up our organizations in a way
where that is okay for people to transit
between those roles you're not penalized
and let's not as an industry position
that is some sort of like demotion,
right? Because oftentimes it's like,
"Oh, you're a manager. You became an IC.
What happened?" What do you mean what
happened? Like nothing happened. I just
I I wanted to take on a new challenge.
Like that's not a demotion.
Hey, thanks for watching that clip. If
you thought it was interesting, it's
from a longer conversation that's
available right here, right now. And if
you have any feedback for me, feel free
to drop a comment on YouTube. I read
every single comment that I get.
Loading video analysis...