LongCut logo

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

Loading video analysis...