The Peterman Pod - Shopify Distinguished Eng (L10) on Principal+ Engineering, Career Story, Regrets

Episode Date: October 24, 2025

Ilya Grigorik grew to a Distinguished Engineer (VP-level role) at Shopify and I asked him what it took to get there. We covered his full career including the behind the scenes of his startup getting acquired by Google, his growth to Director at Google, and what it means to operate like a Distinguished engineer.𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀:• Transcript: https://www.developing.dev/p/distinguished-engineer-at-shopify• Spotify: https://open.spotify.com/show/0MX9PyeCzDhdlyRv6slwIX• Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀:00:00:00 - Intro00:00:45 - Thoughts on Waterloo00:04:36 - Starting his own company00:08:40 - Google acquisition story00:14:04 - Joining Google00:20:28 - Switching back to IC00:26:42 - Principal+ Engineering at Shopify00:40:09 - Career regrets00:44:53 - Top career-impacting book00:46:59 - Advice for younger self𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗜𝗹𝘆𝗮:• YouTube: https://www.youtube.com/@igrigorik• LinkedIn: https://www.linkedin.com/in/igrigorik/• X/Twitter: https://x.com/igrigorik• Personal Website: https://ilya.grigorik.com/𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman• TikTok: https://www.tiktok.com/@ryanlpeterman

People that have to ask that question by definition are not principal engineers. This is Ilya Grigoric. He grew to a distinguished engineer at Shopify, which is a VP-level role, and I asked him what it took to get there. To be a really effective principal plus engineer, you need to have a very good dynamic range, technically. He turned down a clear path to director at Google to go back to being an engineer. This is a path that is vastly underappreciated and is actually surprisingly common for a lot of principal and then higher-up roles. And his best advice, might change how you plan your career.

A better way, more resilient way to build your career is to optimize for being the only person as opposed to the best person. Here's the full conversation. You mentioned you went to Waterloo and I got to ask, the smartest interns that I ever worked with, they came from MIT, Caltech,

and Tsinghua University in China. But the best interns I ever worked with, all came from Waterloo. And so I'm curious, what is it that makes these Waterloo interns so strong? For me personally, the most important thing that Waterloo got right and better than most, and I know that more schools have adopted this pattern, but it's still not well understood, is their co-op program. So what Waterloo did really well is they realized that, yes,

there is the academic portion of learning Haru, engineer, and like what software design is all about. But then there's the hands-on and applied part. And instead of modeling it as, hey, you're going to study for three years and then you have an optional kind of intermission style co-op, which is what most university operate on, right? You could take a year off or something like that to go into work in industry. Waterloo said, you know what?

We're going to just do a rotation where every semester, you study, you work. You study, you work. You study, you work. You know what that means? You don't have a break in between. You're just constantly iterating through this loop. But what it gives you is at least six shots on goal for trying things. And this actually has very positive effects on many dimensions. So first of all, it removes the stigma of trying things.

Right? Because many of us, like we don't know what's going to stick with us. coming back to my earlier point about consulting versus something else or something else. I had so many of my peers going through university where we all started with some preconceived notion of what we wanted to do. It's like, oh, I really want to go to Wall Street and work there. And they try one of the co-op terms there. And they're like, no, actually, like that for whatever reason. I don't like the city or I don't like the industry. I didn't like the people. It just didn't click for whatever reason, right? Same thing for like medicine or other.

or consulting. And that's really important to discover early. And the really nice thing is it's a concentrated. It's like it's a three-month sprint. You get to try, right? And you have permission to try five more things at least without the stigma of looking at your resume saying, hey, like you went to a role for three months, you jumped. You went to a role for three months.

Like, are you really like committed? Are you like, do I want to hire you? It's like, no, that's my co-op, right? Like, that's the whole point. So you could, first of all, try a bunch of things. and get a kind of a good range of experiences under your belt. But also see the kind of the gamut of like, hey, here's how a large company operates. Here's a smaller company.

He's a medium, but like which one resonates with me more, right? So it's industry. It's the type of work that you do. It's the type of an environment that you're in. And I think that is really helpful. On top of that, you actually get exposure to like engineer things, not learn the hypothetical an academic of like, I know how a big O notation expresses this particular algorithm. It's like, I actually had to build the thing, right?

And it turns out this didn't work or that particular solution worked. Or we had to solve it under these constraints. And the whole big old thing was an unissue because I was like sorting 10 items in an array. Who cares? Right? It's like pragmatic engineering. So I think that is key. That is still the superpower of Waterloo.

And I wish more universities, like, it's an open sequence. And I wish more people would copy it because it's such a lever for success for people that go through that program. After you went through all of those iterations and all the co-op loops, I understand that you started your own company, which became post-rank that was then acquired by Google. And I'm curious the story behind you choosing to found a company right after graduating from Waterloo. I graduated from Waterloo and as most students, I didn't know what to do. I wasn't ready to commit. So my escape, which was a well-trodden track for many, is I'll go to grad school.

So I applied and then got into University of Toronto, actually. And during that summer, in between, I had a couple of project ideas that I wanted to get off the ground. So I had a particular itch that I wanted to scratch. And the itch was, if you think back to, how Google was founded. The key insight, if you simplify it and boil it down, that like Larry and Segie had back in 1997, is, hey, we could treat the link crap of the internet

effectively as a feedback loop on what is good content. So if you and I create pages and we link to each other, that's a mutual signal at both directions that there's something there, right? So disconnected pages are not worth much, but in effect, it's kind of a social currency. Links are a social currency. right now fast forward to 2010 2011 when I'm sitting there the web two revolution has already

happened or like well underway you now all of a sudden have dynamic content on the web not static links not static web pages but we have comments on blogs right blogs became a thing comments became a common thing so my observation was hey if a conversation is happening on reddit about an interview that Ryan has recorded like that means there's something there I don't I can't qualitatively say whether it's good or bad. I just know that people are talking about it and that a signal. So what if you built a system that went out and aggregated all of these interactions and then built a better version of page rank effectively, right?

Links becomes one input, but thumbs up and number of conversations, a number of likes, and all of these things become additional inputs. And that was post-rank, right? It's kind of embedded in the name. It was an algorithm for ranking posts based on social engagement, kind of a child of the Web 2-0 era. Still remember the day, it was like July 8th when I released it, and then I didn't sleep for three days because the servers were melting down.

Not strictly because it was such huge demand, although there was. It was also because my code was terrible. So it was just kind of like brute force, just throw more servers at the problem, and then eventually optimize it out over the next couple of weeks to get it back to a manageable set. So that becomes kind of this nucleus of, hey, there's a feature there. right and it got it got good publicity which then turned into conversation hey is there a product here so i remember the structure points that somewhere late in may we're kind of in the middle of

all these conversations with investors kind of unanticipated fork in the path right and i'm thinking what what do i do like i'm uncertain are we going to be able to close around can i do this because in a couple of weeks i'm supposed to start my grad work and i'm looking at that syllabus i'm like what are the courses I'm most interested in? And I go through the list and it was like the ones that immediately stood out to me about like entrepreneurship and like how to do a company. I'm like, wait a second. So I could go and learn about the stuff academically and read books.

Or I can like I'm literally having the conversations right now with investors. Like I could just like go into like I can read those books on my own time and I can go and try it. Which led me to reaching out to my advisor and basically asking, hey, can I take? take a year timeout. I was planning to do this this year, but how about I start next year? And he hammed in hot and said, okay, I understand and come back to me in six months. To close that story, we did end up closing the round, and that became post-rank the company, and I never did get to finish my so-called graduate degree. So in the process of building this company, I know eventually it was acquired by Google,

but I'm really curious because I feel like a lot of acquisition conversations are behind the scenes, hush, hush. What does that kind of conversation look like when they reach out for an acquisition and maybe you can tell that story? It's a lot less stressful than you make it sound to be. I remember we were actually, we were building the product that I was describing

and we were presenting at one of the conferences in the Bay Area. And we got off stage and Phil Moody, who was the lead PM on the, Google Analytics kind of walked up to us and like, hey, this is cool. Do you want to have a chat? And I remember taking a train from San Francisco to Mountain Mew later that day, sitting in the conference room and him basically interrogating us about what is it that you build. And then ending the conversation with, hey, maybe we should do something together.

It's like, okay, well, tell me more, right? That's a blank check for the full of conversation. So it was very friendly. there's nothing kind of more to it than that. And then what we learned after is this is right in the time span when Google and Facebook were like at war in terms of drawing the battle lines for social. This is when Google woke up to the fact that Facebook is on a runaway trajectory and all hands on deck. This is when Google starts working on Google. This is when Google starts working on Google plus, which of course has since been sunset.

But it became this catalyzer within Google for, hey, we need an answer. And they were looking for all the health that they could get and all the experience that they could acquire to speed run this whole thing. And we became that catalyst for Google Analytics because what they saw in us is, like, frankly, they did not care for the PR product that we were building. What they cared about was the experience and some of the infrastructure that we've accumulated that we could bring in to fast run and fast track this whole thing to say, hey, if I'm using Google Analytics, I can get really good insights on how my social engagement is going.

And I can figure out how Google Plus is helping me and all the rest. So that became the kind of the mutual point of win-win situation that led us joining forces with Google Analytics. in being brought in as an acquisition, how'd they determine leveling or compensation or any of that stuff? Google, as many other 10 companies run the same process. It's usually kind of accelerated batch model, where you bring in the whole team and you kind of do a wholesale evaluation. But otherwise, everyone on our team went through the panel, through the full panel, myself included. So that that was the bar.

And really the exercise for them was to vet the quality of the team and then to figure out where on a leveling do all the engineers stuck up. I see. Okay. So it is just a normal interview process. What about in the case, though, because you're bringing in company and assets and stuff, is that just like a giant signing bonus or something? Or how's that? It depends on the company that, you know, and the deal, of course. So there's both polarities to it, exactly as you say.

right there's the like there's the IP there's the customers there's the people and you can treat those as distinct conversations right so as far as negotiations concerned are you acquiring the product what are you going to do with the customers right is there IP there are you going to use the technology many like there's the aqua hire acquisition where you effectively acquiring the team you're saying cool thing you build but that's not the thing i need you to be building let's just put that on the shelf and let's just focus on like rebuild the thing in our infrastructure. PostRink was closer to that.

It was not a full kind of aqua-hire because they brought in and they used the IP. But for all intents and purposes, the thing that we built ourselves, we had to rebuild from scratch with Google Analytics because you're just operating at a completely different order of magnitude. And it was an amazing trial by fire, if anything, for our engineering team because we went from managing tens of thousands of analytics accounts. and granted, yes, we were crawling the web at a fairly large scale to operating in the service that was literally executing

on more than half the internet. Right? So like to make a modification to a data pipeline, I remember the conversations fondly, like sitting with our SRE team and they're like, okay, well, you're going to add this bit field right here. That's going to be this number of xabytes of data. I'm like, oh my gosh.

Okay. let me think about this more carefully, right? Because before, that was not even a conversation point for me and my team. So a lot of it was about the talent and ensuring that they're bringing in the right folks with the right experience and that they're capable of kind of hitting the ground running and working with the rest of the Google Analytics. So I want to get into your career at Google. and it sounds like you were placed initially in Google Analytics.

I'm curious what the leveling was and the role. Were you a manager? Because you mentioned you brought your team with you. So I was founder and CTO of Pellstrike, and I joined as an engineering manager because effectively that's what my role was at Google. And I was very invested in making sure that we build the right thing, the right way,

division of why we started this damn company to begin with because I strongly believed in like, I want to help publishers understand. That was still like me scratching my own itch of like, I'm going to make Google Analytics solve my problem. Damn it. And I think we succeeded at that. It took us about a year to effectively rebuild our stack. And the team was on a good trajectory. And that's where I took us to back and looked around. for hey what's the next adventure I was in a really good direction within Google analytics there I remember a conversation with one of our VPs at the time where you know we were having one of these career sit downs and you're like

look you have all the things you need you're on track for director you know here the things that I could see I could see you take on and all the rest and like huh that sounds all exciting and like and I'm a very honored that like you think I'm capable of doing this work. But at the same time, I can not let my curiosity get the better of me. Like, Google is such an amazing technical playground that even though that first year was a pressure cooker of like, I need to get this thing shipped, right? I'm going to work my butt off to get it working. I also was spending every free moment of time just like diving deep into various design documents in wikis. Google is an open culture, which is the

the thing that I loved about Google. And I could approach anyone and everyone about any piece of infrastructure, any product. And I leveraged that. And I learned a lot because, you know, I remember building Post-Rank and reading papers that were published about Big Table This and Hadoop that. And I'm like trying to figure out how to replicate some of the magic that Google had. And then I'm reading the internal design documents. And I'm like, oh, my God, this is three generations ahead of this paper that I was reading.

This is amazing. I wish the world knew about this, right? And then I would have the time, I would talk to the engineers. I'm like, how come we never published a follow-up on this thing? They're like, we're too busy. It's not that it's a trade secret. We're literally too damn busy. Like, if you find us the time and I was like, huh, well, that's interesting.

Like, wouldn't it benefit the entire world, the entire like intranet if we did more of this? Which led me down some interesting conversations. And I discovered this group within Google, which was called Make the Web Fast, which was basically Sconcours project started by Sergey around, well, how can we make the internet fast? And it's a very kind of self-referential, self-motivating thing. There's very direct evidence that the faster the internet is, the faster users browse the web, the more they use Google. So it's a mutually beneficial relationship, right?

So within that group, we had all kinds of fun projects, we literally built radio towers, trying to figure out how to build more effective cellular networks. You know, dog trenches, built towers. We worked on TCPIP and trying to figure out how to reduce congestion. We worked at optimizing proxies for, hey, turns out that most humans write terrible websites. Could we just, like, optimize it out on kind of dynamically as a web server plugin? To hold on a second, when we say make the internet fast,

what does it even mean? Like, we know it when we see it and when we feel it, but if you had to put a number on it, how do you express that? So if you walk the full dynamic range of those questions, it's just absolutely amazing laboratory of like experiments to run. And I was really fascinated about that. And I remember at that point in time, I realized that I had an opportunity to cash in some chips. And I could say, look, I see a path towards kind of,

career growth as a director in this and that would be a great achievement on the other hand i could take a step back i could take this lateral step and go and work as an i see in this field i'm actually not quite even sure how i'm going to contribute i just know that this is a really cool area that i'm passionate about and i'll hopefully probably find something useful that i can do there um but that would definitely take me off the career track right i remember that conversation it was like well you know if a IC bar at Google is actually really high. So if anything, you're going to be down-leveled, likely, and you're going to reset your track.

I was like, okay, I think that's a trade worth having because I get to control my time. I get to work with people I look up to, and I get to work in a domain that I think is just absolutely fascinating. So I made that pivot. And in retrospect, it was an amazing right decision for me because it allowed me to kind of find a domain. flex my curiosity and technical muscle in a completely different direction.

You turned down this more clear-cut director path, which would be the clear-cut growth path for career to optimize for other things, which sounds like intrinsic motivation in the work, curiosity, and also sounds like maybe you got some time back. Is that the math you were doing in your head and making that choice? Exactly that. It was, and it was a lot of uncertainty in that process, but this is kind of a repeating arc through my career where as a manager your time is managed by others right like you are you are in the service of others and i wanted to shift gears and go into a mode where i have more self-direction and go pursue some like interesting research or projects that like where i can apply my own skill set in a unique way so later i saw that you switched back to management and your director of developer relations at Google. So what was the rationale then switching back, given what you just said? Yeah, so I've seesawed a number of times through IC to manager.

And I think this is a path that is vastly underappreciated. And it's actually surprisingly common for a lot of high-performing ICs. And like you'll find in principle and then higher up roles. And the observation is, I think it was a tour of duty when I'm doing management. To be a really effective, like, principal plus engineer, you need to have very good dynamic range technically, right? You can work well at the low level of the stack. You can also zoom out and look at the business requirements currently deeply understand what's actually necessary. Where can you relax constraints?

Where you need to hold the line and all the rest. And once you get attached to certain projects, like some projects you can execute and you call it done, you're like a great assault that problem, right? But many problems that are handed to you, they become, they come as nebulous statements that then evolve into, huh, this is actually like a team's worth of effort. Like now that we've understood the shape of this problem. And what often happens is you kind of see this pattern of some individual doing the trail blazing work, path finding, where we need to climb. And then they find themselves, okay, now I need to recruit a team of people

to help me actually build a thing. Like, I know how to get the top of that hill with a machete, but now we need to build a highway. Right? And to build a highway, I need a team. Okay, well, let me go find a team. Before you know it, you're kind of, you're a TL. Right?

And you're exercising your soft power to help direct people and all the rest. It's not a far stretch to switch to a manager, right? Because, like, well, now you're doing performance management as well, plus a few other tricks. But oftentimes you'll find kind of yourself managing or being responsible for the direction of a broader team. And before you know it, like I think it's a natural transition to say, well, okay, fine,

I'm going to like manage this domain. I'm going to manage this as a product team. I'm going to manage this like the growth of the individuals and the rest. And that's completely fine. That's what happened to me with developer relations. When you think back to the kind of the set of problems that I shared with you, I ended up gravitating towards the question of how do you? you measure performance.

And I found myself doing a lot of web standards work. I got engaged with W3C and ITF and trying to figure out, hey, what kind of metrics can be defined in browsers such that we all have a common ground truth for how to measure performance? And that was great. I did a lot of that. And that was my kind of IC contributor role. Then you get those metrics into browser. And then the problem becomes great.

How do I get community or ecosystem adoption in this thing? Well, I need to go tell people. and I need to convince them to adopt it, right, and integrated. Well, now I need to go talk to all of the analytics vendors. Let me go talk to all the open source projects, right? That problem does not scale with one human. Like, you really need help of other humans. This is where the go-to-market and the kind of developer relations part came in.

And I quickly realized that, like, it would be really helpful to have a team of people that can focus on this thing. And this is the thing we deeply care about. We want to accelerate the adoption of these things. it's kind of my model based on prior experience was, look, if we just leave this ecosystem B as it is, in three to five years' time, we will probably see the adoption that we want. But I'm not happy with three to five years. My question is, how can I compress it into one to two years, ideally one year or less, right? And for that to happen, we need to inject energy into the system.

The energy is a team of people. Great, fine. let me switch to my manager role. I'm going to go recruit people and I'm going to put my organizer hat on and we're going to go and execute this problem. So when you say tour of duty, it's this starting as an IC, doing pathfinding and then becoming a manager potentially is all in service of a mission or a problem. Like you see some problem. Maybe EM is the best way to solve that problem. Maybe IC is, but it's really all about the problem. Exactly. Exactly. And it's kind of like your relationship and your commitment to the problem, right? Because not every problem has to become your mission. I'm often engaged in projects where I'm participating. I'm actively contributing. And then I say, look, guys, you're, you're well on the way. Like, you have the right vector. Go execute. You have everything you need. Like, you don't need me here. And in fact, that's my kind of measure of success as a principal engineer oftentimes, right? I don't, if the team is dependent on me, that means that I'm probably doing something wrong because my job is to up-level

the team and make sure that they can deliver this thing self-sufficient. So if you know the Homer Simpson meme where he like disappears into the bushes. Yeah. Right. It's like kind of like that. Like if I can pull that off successfully on a project and the team continues executing in the right direction with a good velocity, like that's success for me oftentimes. Now occasionally I stumble into a problem where I'm like either I'm like just it's in my bones and I feel like I need to be like I want to own that problem and see it to a logical conclusion. Or I have some unique position or leverage in it where, like, yes, I'm the right person to take on the broader responsibility and kind of execution of the team to see it through

completion. And it's a judgment call for which, you know, when you pull that off and when you say, okay, this is going to be my tour of duty. Like my job is over the next, I know that I'm committing for the next two years or something to like really run this thing, own this ship, and that's my responsibility. And you know what, at the end of it, I'm going to do the same thing I did before. I'm going to like my success. I need a succession plan.

And my succession plan is either we solve the problem when it's done or I've set on a trajectory where I can successfully pull back and focus on the next thing. And to focus on next thing, I'm going to become an IC again and go find the next thing to solve. I know later the story continues with you went to Shopify, you became an IC, and you went from a principal engineer to a distinguished engineer. I'm curious, what is the tour of? 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 does, what do you do? Like, give me,

give me a job description because I want to become a principal engineer, like, what are the boxes I need to tick? And 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 other, I mentor a lot of principal engineers that come into Shopify. My expectation for someone coming in that level is, look, you basically, to use an analogy here, you're going to be dropped, parachuted into foreign terrain. You're in a reconnaissance mission.

And within the first seven days, you should figure out to lay the land and figure out where the problems are, build alliances with your directors, is, BPs, 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 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 the way I think about it is 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. So are you able to, have you shown a repeatable record of being able to? to operate at all layers of the stack. If you're engaged with the team, are you able to go all the way down to the bare metal

and understand what are the constraints, what are the problems 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. But then there's also the, the execution model kind of in the middle where you have to be able to flex. There are different types of projects that you get parachuted into. Some projects are 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, a pace layer of the company where it's like, okay, guys, we have this platform API problem. You know, we have a, just using like a random example, right? And it's really important that we think through how we design this API because it will 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. 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'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 our plate. Right. It's like and by definition, all the easy problems have been solved before like layers below them. So they only get the heart problems with incomplete information or imperfect decisions. So show me the volume. and show me the versatility of your toolkit that gives me confidence that I could parachute you and see 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 share often with folks that I coach and work with is 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 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 take security as an example, right? I'm going to learn everything there is to know, and that's going to be my life calling. And that's great. But there's absolutely nothing wrong with that. You can optimize for that. My personal philosophy is that is one way to success, but it is not the most resilient way to success. Because what if you pick the wrong field? What if the world changes under you?

What if your particular company does not need that particular skill set? Be the only to me is about building a talent stack or portfolio skills that you can juggle and be effective. And I think this is actually reflects back in the dynamic range conversation that we were just having, right? Were you able to say, look, 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 salesperson. I was okay at support, but like, come on, like, that's not my life calling either. But you know what I did really well? I combine 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

thing 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 the dynamic range to do that. Now, if it turns out that we now hire the 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 you can acquire very high competence, like 80, 90% competence very quickly in a domain. You can get to 80% in a matter of days to weeks,

especially now with the tools that we have access to with LLMs and all the rest. Like the ability to acquire context is just amazing. You can spend the next year to get yourself to 90%. And now, if you optimize for that, you have resilience because I'm able to converse with our marketing team because you know what? I took the time like 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 can understand the lexicon, the jargon and speak the right words when I talk to marketing

teams. I'm also adept enough at 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 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, or I'm able to synthesize that information and bring it together.

And that gives me a lot of versatility. It doesn't mean that I'm the smartest person in the room. Oftentimes it's far 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. My contribution is I understand fundamentals of the platform and what you can do with 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 variance. 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 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's 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 myself 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'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 and 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 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, you know enough about databases, you know enough about graphics, you know about you dot, 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 being the own, 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 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 been a manager before. I understand what it means to do performance management. I understand how to coach people. 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 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 a 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 if you're an IC track and you've never tried management. Like being a TL is a great learning wheels. You should definitely try if it suits you to do management as well.

But don't assume that it's a one-way path. 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 have a couple of drinks they're like you in your flight back and when was when were you happiest in your career they say huh you know it was a couple of years back before I became at X because I had like I was really confident 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 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 a new toolkit. Great. Now, 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 or some sort of demotion, right? Because oftentimes it's like, oh, you're a manager, you became an IC. What happened? What do you mean what

happened? Nothing happened. I just, I wanted to call on a new challenge. Like, that's not a demotion. When you look over the course of your career, were there any points where you have regrets that others could learn from? Don't let the pressure of your success stop you from trying. Let me unpack that a little bit. I reflected on this as a writer, as a blogger. I remember when I look back, and I wonder if you can relate to this, when I look back in my early writing, I read it now, I'm like, oh my God, that is terrible.

What was it? Like, how could I have published that? That is just flat out embarrassing. I hope nobody finds this, right? Or, frankly, if I go in GitHub and look at my own projects, like, it is embarrassing code. but you know what it was the limit of my ability at the time when I did it and I'm so glad that I did it right because it was those milestones like putting that work out there that gave me the right feedback

gave me the right encouragement that then led me to improve but the challenge that you run into is as you level up and as you get like an audience and an expectation it's like well you know Ryan's interviews are really good so in the next one like I expected to be like an out of the park better than ever. You keep setting a higher and higher bar where you start to filter. Like, here's the thing I would have published before, but I'm not sure if it's up to my standard now. Like, is it really interesting?

Do I have a unique take on it? Whereas before, it was like, I don't care. Like, I just thought. Here you go. Keep publishing. Like, I struggle with this all the time. Like, keep putting stuff out there because don't let that expectation become a gate and filter for the work that you put out.

because that feedback that you get and exposure is like that that is actually the quintessential ingredient that you need for growth definitely definitely and yes i can relate i think there was uh there's a year two where i was writing a newsletter and every week i'd publish something and at some point the email list is growing and it's growing and i could tell at the beginning when i'm ideating what am i going to write this week a lot more nose coming in my mind i go oh no no Oh, this one. This topic's not good. Right. I've seen this somewhere. Yeah. It's that courage to be wrong, to be disliked, to make a mistake, right?

It's like, Ryan, I thought you're like, or I thought you're smarter than that. Like, why did you say that thing? Like, well, that's what came to my mind. And like, it's fine. I don't claim to be an Oracle, right? I have other expertise and other things. And this is what I thought at the time. Definitely. And I also wonder if that kind of similar thinking, as you grow in your career, I mean, it would take some courage for you to step into a new area that's completely new to you.

If everyone knows you as distinguished engineer and very knowledgeable in your given domain to step into some new area where you're going to make a lot of mistakes, that feeling of that downgrade is tough for a lot of people. Yeah, that's where setting the right expectations with yourself and others is also very important. The way you show up to these conversations makes all the difference, right? Because I don't show up as, hey, I know all the answers. Rather, I show up as, hey, guys, I'm here to help. I'm just, I'm like really curious. And I started asking why. Like, what are the fundamentals?

Help me understand this. The way you ask questions becomes very important because it's very easy to come across as trying to question all the things as opposed to being curious, right? There's a subtle difference between them. Am I trying to attack your work or am I just trying to construct a model? And just setting clear expectations of that.

Oftentimes when I begin these conversations, I'm just very open about, guys, I don't know what you know. Right? And I need to very rapidly build my mental model of this space. So I'm going to ask a lot of dumb questions. Like, excuse me up front. I also have my expertise

and I also know some other things that you don't. So help me navigate through this. And it becomes a collaborative exercise, right? Because I can clear roadblocks and do things that they can't, but they can bring all of the knowledge. And this becomes the symbiotic relationship that goes back to, how do I leverage the expertise of people in the room as opposed to trying to question their work?

And that takes a lot of that stigma out of that new environment in work. but I think there's an even higher filter for when you're like broadcasting because there's an expectation and an aura of like what what you're expected to be saying right and I think it's some people do a better job of that than others in terms of staying true to their thoughts and less filtering

is there a top book that impacted your career the first thing that comes to mind and this is this not a book but an author as Sir Ken Robbins He has a series of books on finding your element, creative schools, and the rest. If nothing else, go on YouTube and search for Ken Robinson and watch his TED Talks. It is, I think, 20 minutes of your time that is going to be the highest ROI, if not today, this week, maybe this year. He's been an inspiration to me, and I think his messages need to be continued. personally he passed away. But a key of it is we need to rethink how we think about education.

And it actually kind of circles back to the conversation we're having about Waterloo. His message is, stop, we need to rethink our education system from a factory line model where we like put people by age into a certain bin and teach them specific skills. Like we all spike in different ways at different points in our life, right? Like let's have an environment where people can choose their own adventure. Now, how do you execute that? It turns out to be really hard, and he dedicated his life to trying to figure that out, like how do you reform the educational system? But I think his philosophy is very much kind of in line and probably informed a lot of my thinking for, hey, it is about creativity. You should mix things up. You should combine skills. Let's build a system that

actually allows us to help kids learn these behaviors better, as opposed to pigeonholing themselves into like, well, no, you're in grade five. In grade five, you're only supposed to learn this thing. Thank you very much. And like, please don't touch advanced math until you, like, until you get in grade six. It's like, well, that's nonsense, right? Like, for some kids, they can go all the way to grade eight math when they're in grade five, just to use one example.

And then the last question is if you could go back to yourself at the beginning of your career and give yourself some advice, knowing everything you know now, what would you say? I would come back to the don't be the best, be the only. I think early in my career had a lot of fear of, hey, I'm mediocre at a lot of things. Like I see my friends, I would look up to my friends who are really good at design and I'd be like, oh, I wish I could do that. Right. Or I look to my other friends who were just better engineers. Like, I wish I could do that.

But the thing that I had was ability to negotiate across. all those themes. And that's uncomfortable because I wasn't sure if that would pan out. And it turns out that it did. And then the other thing is exactly as we were just discussed, don't like, don't filter, be braver about the stuff. It's kind of ironic that later in my career, I part of like my nine to five effectively became public speaking. Going through high school, I was deathly afraid of public speaking. I would run away from class to avoid it. Like I said, I vividly remember those stories. And then it dawned me later when I was doing post-trank that, hey, why is it that I was even through university, like I had cold sweats standing out in front of a class trying to explain

the thing. But I was totally adept and fine when I was pitching my product to an audience. And the difference is, in one hand, I was trying to describe a thing that I didn't have any particular investment in. It was a test of my knowledge versus here's the thing I'm passionate about and I want to enact change in the ecosystem to move it to some new direction. So that turned out to make all the difference for me. And maybe that's the key thing. Like, if you told me early in my college career that my future holds public speaking, I would, I don't know what I would do. I would say that you're crazy. I see.

So to be more brave, chase your passions. Yeah, and it's also very different when you're chasing your passion. A lot of things flip in how you engage, as opposed to being told to stand up and rehearse a skit. 100%. Awesome. Well, thank you so much for your time, Ilya. I'm really excited to share this one with everyone. Is there anything you want to say to the audience before we end the recording?

I think we've covered a lot of ground. I hope some of it is useful. And you can find me on the internets. And please feel free to reach out and have a chat. Awesome. I'll put that in the show notes. All right. Thank you.

Thanks, Ryan. Appreciate it. Thanks for listening to the podcast. I don't sell anything. or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior I sees. There's no well-studied list out there on Google that I can just search this up. So if there's

someone in your org or at your company who you really look up to and you want to hear their career story, Let me know and I'll reach out to them.