Shopify Distinguished Eng (L10) on Principal+ Engineering, Career Story, Regrets

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 - Intro 00:00:45 - Thoughts on Waterloo 00:04:36 - Starting his own company 00:08:40 - Google acquisition story 00:14:04 - Joining Google 00:20:28 - Switching back to IC 00:26:42 - Principal+ Engineering at Shopify 00:40:09 - Career regrets 00:44:53 - Top career-impacting book 00: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

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  People that have to ask that question by definition are not principal engineers.

• 0:03Ryan Peterman?

  This is Ilya Grigorik. He grew to a distinguished engineer at Shopify, which is a VP level role. And I asked him what it took to get there.

• 0:11Speaker 00

  To be a really effective principal plus engineer, you need to have very good dynamic range technically.

• 0:17Ryan Peterman?

  He turned down a clear path to director at Google to go back to being an engineer.

• 0:21Speaker 00

  This is a path that is vastly underappreciated and is actually surprisingly common for a lot of principal and then higher up roles.

• 0:28Ryan Peterman?

  And his best advice might change how you plan your career.

• 0:32Speaker 00

  A better way, more resilient way to build your career is to optimize for being the only person as opposed to the best person.

• 0:41Ryan Peterman?

  Here's the full conversation.

• 0:46Ryan Peterman?

  You mentioned you went to Waterloo and I gotta 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?

• 1:10Speaker 00

  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 how to engineer and then 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 universities operate on, right? You could take a year off or something like that to go and work in industry. Waterloo said, you know what?

• 1:55Speaker 00

  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. Right? And this actually has very positive effects on many dimensions. So first of all, it removes the stigma of trying things.

• 2:24Speaker 00

  Right, because many of us, like, we don't know what's gonna 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 wanna go to Wall Street and work there. And they try one of the co-op terms there, and they're like, no. I actually like that, for whatever reason, you know, 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 others, or consulting. And that's really important to discover early. And the really nice thing is, it's a concentrated, like, it's a three-month sprint.

• 3:08Speaker 00

  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, you're like, are you really, like, committed? Are you, like, do I wanna 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 good range of experiences under your belt. But also see the gamut of like, hey, here's how a large company operates. Here's a smaller company, here'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 environment that you're in. And I think that is really helpful.

• 3:51Speaker 00

  On top of that, you actually get exposure to, like, engineer things. Not learn the hypothetical and 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? Like, and 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.

• 4:22Speaker 00

  I think that is key. That is still a superpower of Waterloo. And I wish more universities, like it's an open secret. And I wish more people would copy it because it's such a lever for success for people that go through that program.

• 4:36Ryan Peterman?

  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.

• 4:55Speaker 00

  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 Voltron track for many is I'll go to grad school. So I, 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 Claire and Sergi 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.

• 5:39Speaker 00

  So if you and I create pages and we link to each other, that's a mutual signal in 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.

• 6:24Speaker 00

  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 PageRank effectively, right? Links becomes one input, but you know, thumbs up and number of conversations and number of likes. And all of these things become additional inputs. And that was PostRank, right? It's it's kind of embedded in the name. It's it's a was an algorithm for ranking posts based on social engagement. Kind of a child of the web 2.0 era. Still remember the day of 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 like such huge demand, although there was. It was also because my code was terrible.

• 7:06Speaker 00

  So it's kind of like brute force and just throw more servers at the problem. And then eventually, you know, optimize it out over the next couple of weeks to to get it back to a manageable set. So that becomes kind of this nucleus of, hey, there's a 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 do I do? Like, I'm uncertain. Are we going to be able to close a round? Can I do this? Because in a couple of weeks, I'm supposed to start my my grad work. And I'm looking at that syllabus.

• 7:51Speaker 00

  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 this stuff academically and read books. Or I can like, I'm literally having the conversations right now with investors like I or I could just like go into like, I can read those books on my own time. And I could, I can go and try it. Which led me to reaching out to my advisor and basically asking, hey, can I take a year time out? You know, I was planning to do this this year, but how about I start next year? And he handed it hard and said, okay, I understand. And you know, come back to me in six months.

• 8:33Speaker 00

  To close our story, we did end up closing the round and that became the post rank of the company. And I never did get to finish my so-called graduate degree.

• 8:41Ryan Peterman?

  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, like when they reach out for an acquisition? And maybe you can tell that story.

• 9:01Speaker 00

  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, you know, we got off stage and Phil Mooney, who was one, who was the kind of lead PM on Google Analytics, kind of walked up to us and like, hey, this, this is cool. Do you want to have a chat? And I remember taking a train from San Francisco to Mountain View later that day, sitting in a 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?

• 9:45Speaker 00

  That's a, that's a blank check for the full conversation. So it was, it was very friendly. There's, 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. Google needed, this is when Google starts working on Google Plus, which of course has since been sunset. But it became this catalyze, catalyzer within Google for, hey, we, we need an answer.

• 10:30Speaker 00

  And they were looking for all the help 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, they frankly, they did not care for the.

• 10:47Speaker 00

  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 mutual point of win-win situation that led us joining forces with Google Analytics.

• 11:18Ryan Peterman?

  In being brought in as an acquisition, how'd they determine leveling or compensation or any of that stuff?

• 11:25Speaker 00

  Google, as many other tech companies, run the same process. It's usually accelerated batch model where you bring in the whole team and you do a wholesale evaluation. But otherwise, everyone on our team went through the panel, through the full panel, myself included. So 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 stack up.

• 11:54Ryan Peterman?

  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?

• 12:08Speaker 00

  It depends on the company and then the deal, of course. So there's multiple layers to it, exactly as you said, right? 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? There's the aqua hire acquisition where you're effectively acquiring the team. You're saying, cool thing you built, but that's not the thing I need you to be building. Let's just put that on a shelf and let's just focus on rebuilding the thing in our infrastructure. PostRank was closer to that. It was not a full aqua hire because they brought in and they used the IP.

• 12:52Speaker 00

  But for all intents and purposes, the thing that we built ourselves, we had to rebuild from scratch with the Google Analytics because you're just operating at a completely different order of magnitude, right? 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 a service that was literally executing on half, more than half the internet. Right? So like to, 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 exabytes of data.

• 13:36Speaker 00

  I'm like, oh my gosh.

• 13:40Speaker 00

  Okay. Let me think about this more carefully, right? Cause 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, with the rest of the Google Analytics team.

• 14:05Ryan Peterman?

  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? Cause you mentioned your, you brought your team with you.

• 14:20Speaker 00

  So I was founder and CTO of PostRank and I joined as an engineering manager. Cause effectively that's what my, my role was at Google. And I was very invested in making sure that we build the right thing, the right way and kind of manifest the vision 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.

• 14:55Speaker 00

  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, and that's where I kind of took us to back and looked around for, hey, what's the next adventure? I was in a really good direction within Google Analytics. And 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 were like, look, you have all the things you need, you're on track for a director, you know, here are the things that I could see, I could see you take on and all the rest. And I'm like, huh, that sounds all exciting and like, and I'm very honored that like. You think I'm capable of doing this work.

• 15:39Speaker 00

  But at the same time, I couldn't 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 gonna 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 and wikis. Google is an open culture, which is 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 PostRank and reading papers that were published about big table this and hadoop that.

• 16:23Speaker 00

  And 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, half the time I would talk to the engineers and 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 internet 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.

• 17:06Speaker 00

  Which was basically a concourse project started by Sergey around, well, how can we make the internet fast? And it's a very kind of self-representational, self-motivating thing. There's very direct evidence that the faster the internet is, the faster users browse the web, 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. Dog trenches, build towers. We worked on TCP IP and trying to figure out how to reduce congestion. We worked on optimizing proxies for, hey, turns out that most humans write terrible websites.

• 17:50Speaker 00

  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 that 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? Right? So if you walk the full dynamic range of those questions, you like, it's just absolutely amazing laboratory of like experiments to run. And I was really fascinated about that. And I remember that at that point in time, I realized that I had, I had an opportunity to cash in some chips.

• 18:29Speaker 00

  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 IC 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. But that would definitely take me off the career track. Right? I remember that conversation. It was like, well, you know, if IC bar at Google is actually really high, so if anything, you're going to be downleveled likely and you're going to reset your track.

• 19:13Speaker 00

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

• 19:31Speaker 00

  it allowed me to kind of flex my curiosity and technical muscle in a completely different direction.

• 19:35Ryan Peterman?

  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 was, it sounds like intrinsic motivation in the work, curiosity, and also it sounds like maybe you got some time back. Is that the math you were doing in your head and making that choice?

• 19:58Speaker 00

  Exactly that. It was, and there was a lot of uncertainty in that process, but.

• 20:04Speaker 00

  This is kind of a repeating arc through my career where as a manager, your time is managed by others.

• 20:12Speaker 00

  Right? Like 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 skillset in a unique way.

• 20:29Ryan Peterman?

  So later I saw that you switched back to management and you're director of developer relations at Google. So what was the rationale then switching back, given what you just said?

• 20:42Speaker 00

  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 is actually surprisingly common for a lot of like high-performing ICs and like you'll find in principal 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, you can work well at a low level of the stack. You can also zoom out and look at the business requirements currently deeply understand what's actually necessary.

• 21:25Speaker 00

  Where can you relax constraints? Where can you, where you need to hold, hold the line and all the rest?

• 21:32Speaker 00

  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, you kind of, you see this pattern of some individual doing the trailblazing work, pathfinding, where, 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 to the top of that hill with a machete, but now I need to build a highway. And to build a highway, I need a team. Okay, well, let me go find a team.

• 22:17Speaker 00

  Before you know it, you're kind of, you're 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 gonna like manage this domain. I'm gonna manage this as a product team. I'm gonna 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 measure performance?

• 23:02Speaker 00

  And I found myself doing a lot of web standards work. I got engaged with W3C and IETF and trying to figure out, hey, what kind of metrics can we define in browsers such that we all have a common ground truth for how to measure performance? And that was great. 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 of this thing? Well, I need to go tell people, and I need to convince them to adopt it, right?

• 23:33Speaker 00

  And integrate it. 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 be 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. Like, my question is, how can I compress it into one to two years? Ideally, one year or less, right?

• 24:18Speaker 00

  And for that to happen, we need to inject, 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 gonna go recruit people and I'm gonna like, put my organizer hat on and we're gonna go and execute this problem.

• 24:33Ryan Peterman?

  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.

• 24:54Speaker 00

  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 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-sufficiently. So if you know the Homer Simpson meme where he like disappears into the bushes?

• 25:33Ryan Peterman?

  Yeah.

• 25:33Speaker 00

  Right, like, 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 its 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 gonna 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

• 26:18Speaker 00

  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 gonna do the same thing I did before. I'm gonna like my success. I have, I need a succession plan. And my succession plan is either we solve the problem and it's done, or I've set it on a trajectory where I can successfully pull back and focus on the next thing. And to focus on the next thing, I'm gonna become an IC again and go find the next thing to solve.

• 26:42Ryan Peterman?

  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 duty there that got you promoted?

• 26:55Speaker 00

  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, you know, 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. Because the problems become ambiguous enough at that level where you kind of have to figure it out yourself. Like, my expectation for, I mentor a lot of principal engineers that come into Shopify. My expectation for someone coming in that level is, look, you're basically, to use an analogy here, you're gonna be dropped, parachuted into foreign terrain.

• 27:40Speaker 00

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

• 28:25Speaker 00

  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 operate at all layers of the stack? If you're engaged with a 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, kind of 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,

• 29:06Speaker 00

  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.

• 29:51Speaker 00

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

• 30:33Speaker 00

  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 the expectation for a distinguished engineer, it's 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 layers below them. So they only get the hard problems with incomplete information or imperfect decisions. So show me the volume and show me the versatility of your toolkit

• 31:18Speaker 00

  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 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 like, take security as an example, right?

• 32:02Speaker 00

  I'm going to learn everything there is to know and that's going to be my life, 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 picked 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 a portfolio of 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

• 32:47Speaker 00

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

• 33:13Speaker 00

  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 we now hired a graphic designer that's excellent, but great, I'm just gonna take that particular skillset out of my quiver, hand it over to them and I'm gonna focus on the other things, right? And I think generally you can acquire very high competence, like eighty, ninety percent competence very quickly in a domain. You can get to eighty percent in a matter of days to weeks, especially now with the tools that we have access to with L L M's and all the rest, like the ability to acquire context is just amazing. You can spend

• 33:58Speaker 00

  the next year to get yourself to ninety percent. 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 and like I literally remember going on Amazon and I bought fifteen 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 working with our P R 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 am the translator

• 34:41Speaker 00

  between all of these different parts of the company and organs of the body, where I'm able to can 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 the room. Oftentimes that's far from 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 skillset 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 the fundamentals of the platform and what you can do with our A P I's or our platform. I understand the business requirements. There's

• 35:26Speaker 00

  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 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 myself out of tricky situations.

• 36:08Speaker 00

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

• 36:37Ryan Peterman?

  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 skillsets, get most of the way there and be the only because the intersection of all those skillsets is more special and more resilient because you have such a wide toolbox. Is that right?

• 37:02Speaker 00

  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 skillset. You know enough about databases. You know enough about graphics. You know enough about, 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 only, 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.

• 37:45Speaker 00

  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.

• 38:14Ryan Peterman?

  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.

• 38:26Speaker 00

  Yes, absolutely. So I would absolutely encourage if you're an IC track and you've never tried management, like, being at 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. 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 have a couple of drinks, they're like, you reflect back on what was, when

• 39:07Speaker 00

  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, 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, let's set up our organizations in a way where that

• 39:49Speaker 00

  is okay for people to transit between those roles. You're not penalized and let's not, as an industry, position as 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 wanted to take on a new challenge. Like, that's not a demotion.

• 40:09Ryan Peterman?

  When you look over the course of your career, were there any points where you have regrets that others could learn from?

• 40:17Speaker 00

  Don't let the pressure of your success stop you from trying. Let me unpack that a little bit. I reflected on this like as a writer, as a blogger. I remember when I look back and I wonder if you can, if you can relate to this. When I look back on 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 on 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?

• 41:00Speaker 00

  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, you know, 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, it's just a thought. Here you go. Keep publishing. Like I struggle with this all the time.

• 41:43Speaker 00

  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 is actually the quintessential ingredient that you need for growth.

• 42:01Ryan Peterman?

  Definitely, definitely. And yes, I can relate. I think there was a, there was a year or 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 no's coming in my mind. I go, oh no, this one, this topic's not good, right? I've seen this somewhere.

• 42:25Speaker 00

  Yeah, it's, 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 Ilya, like I, I thought you were smarter than that. Like, why did you say that thing? It's like, well, that's what came to my mind and like, it's fine. I don't claim to be an oracle, right? I, I have, I have other.

• 42:46Speaker 00

  Expertise and other things. And this is what I thought at the time.

• 42:49Ryan Peterman?

  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 that feeling of that downgrade is is tough for a lot of people.

• 43:19Speaker 00

  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 start 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 like, 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.

• 44:01Speaker 00

  Oftentimes, when I begin these conversations, I'm just very open about, guys, I don't know what you what you know, right? And I need to very rapidly build my mental model of the space. So I'm going to ask a lot of dumb questions, like, excuse me upfront. 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 of 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.

• 44:45Speaker 00

  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.

• 45:06Ryan Peterman?

  Is there a top book that impacted your career?

• 45:09Speaker 00

  The first thing that comes to mind, and this is, this is not a book, but an author, Sir Ken Robinson. He has a series of books on like 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 message needs to be continued. Unfortunately, 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.

• 45:54Speaker 00

  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 that, how do you execute that? 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.

• 46:34Speaker 00

  Let's build a system that actually allows us to like 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 to 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.

• 47:00Ryan Peterman?

  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?

• 47:10Speaker 00

  I would come back to the, don't be the best, be the only. I think early in my career, I 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'd look to my other friends who are just better engineers. Like, "I wish I could do that." But the thing that I had was the 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.

• 47:48Speaker 00

  And then the other thing is, exactly as we were just discussed, 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.

• 48:10Speaker 00

  I would run away from class to avoid it, right? Like I say, I vividly remember those stories. And then it dawned on 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 a thing. But I was totally adept and fine when I was pitching my product to an audience. And the difference is, on one hand, I was trying to describe a thing that, you know, I didn't have any particular investment in. It was a test of my knowledge. Versus, "Here's a 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.

• 48:54Speaker 00

  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.

• 49:08Ryan Peterman?

  I see. So, to be more brave, chase your passions.

• 49:12Speaker 00

  Yeah, and it's also very different when you're chasing your passion. Kind of a lot of things flip in how you engage, as opposed to being told to stand up and rehearse a skit.

• 49:24Ryan Peterman?

  Hundred percent. 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?

• 49:37Speaker 00

  I think we 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.

• 49:47Ryan Peterman?

  Awesome. I'll put that in the show notes. All right. Thank you.

• 49:50Speaker 00

  Thanks, Ryan. Appreciate it.

• 49:52Ryan Peterman?

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