heading · body

YouTube

Shopify Distinguished Eng (L10): Principal+ Engineering, Career Story, Regrets | Ilya Grigorik

Ryan Peterman published 2025-10-24 added 2026-04-26 score 8/10
career engineering leadership principal-engineer ic-vs-management shopify google generalist
watch on youtube → view transcript

ELI5/TLDR

Ilya Grigorik climbed to L10 distinguished engineer at Shopify after founding a startup, getting acquired by Google, and zigzagging between IC and manager roles for fifteen years. His big claim: at the principal+ level, the job description disappears — you get parachuted into a foreign country and have a week to figure out where to dig. His one piece of career advice, repeated three different ways: don’t try to be the best at one thing, try to be the only person who combines a weird basket of skills.

The Full Story

Waterloo’s open secret

Ilya credits the University of Waterloo’s co-op program — six alternating semesters of study and work — as the unfair advantage of its grads. Not the engineering curriculum. The rotation.

“Wateroo 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… what it gives you is at least six shots on goal for trying things.”

The compounding effect is psychological. You get to try Wall Street, medicine, big tech, a startup — and bail without it staining your resume, because the three-month stint is the structure, not a red flag. By graduation you’ve actually built things, not just learned big-O notation. Calling this an “open secret” he wishes more universities would copy.

Founding PostRank, getting acquired by Google

After Waterloo, Ilya did the standard hedge — applied to grad school at U Toronto. The summer before, he scratched an itch: PageRank used static links as a quality signal, but by 2010 the web had blown open with comments, likes, retweets. What if you ranked posts by social engagement instead? PostRank was that algorithm.

He shipped on July 8th and didn’t sleep for three days because the servers melted down — partly due to demand, partly because, in his words, “my code was terrible.” He went back to his grad school advisor, asked for a year off, and never returned.

The Google acquisition story he tells almost casually. They were demoing at a Bay Area conference. Phil Mui, the lead PM on Google Analytics, walked up after, said “this is cool, want to chat?” Ilya took the train to Mountain View that afternoon. The conversation ended with “maybe we should do something together.”

The unspoken context: Google was at war with Facebook over social, was building Google+, and PostRank’s infra and team became a catalyst inside Google Analytics. They didn’t really care about PostRank’s product — they wanted the experience.

Turning down director for a downlevel

This is the move that shapes the whole rest of his career. Ilya joined Google as an engineering manager (basically the same job he had at PostRank). After a year his VP told him he was on track for director. Ilya passed.

“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. I was like, okay, I think that’s a trade worth having because I get to control my time.”

He’d spent his first year reading internal Google design docs and realizing they were three generations ahead of the public papers he’d read while building PostRank. Then he discovered “Make the Web Fast,” a Sergey-blessed skunkworks group building radio towers, optimizing TCP/IP, dynamically rewriting bad HTML at the proxy layer. He took the lateral, downlevel step into it.

His framing for the trade: as a manager your time belongs to others. As an IC at a high level, you reclaim your own attention.

Tour of duty: the IC-to-manager seesaw

Ilya has flipped between IC and manager multiple times. He calls each switch a “tour of duty,” and his pattern is consistent:

  1. As an IC, he wanders into a problem with a machete — pathfinding, fog of war.
  2. The problem turns out to need a team — “I know how to get to the top of that hill with a machete. But now we need to build a highway.”
  3. He recruits a team, becomes a TL, slides into manager because that’s what the problem needs.
  4. The team is self-sufficient. He pulls back into IC mode and looks for the next problem.

The example: he started doing IC work on web performance metrics with W3C and IETF. Once the metrics shipped in browsers, the bottleneck became ecosystem adoption — getting analytics vendors and open-source projects to integrate them. That’s a “go-to-market problem” that doesn’t scale to one human, so he switched back to manager and ran developer relations to inject energy into the system.

“If the team is dependent on me — that means that I’m probably doing something wrong because my job is to uplevel the team and make sure that they can deliver this thing self-sufficiently.”

His success metric is the Homer Simpson disappearing-into-the-bushes meme. If you can fade out and the team keeps going, you did it right.

What the principal+ job actually is

The most quotable bit of the interview. New principal engineers ask him: what’s the job description? what boxes do I tick?

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

The job at that level is ambiguous by design. His mental model for someone joining at principal:

“You’re going to be dropped parachuted into foreign terrain. You’re on a 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.”

For distinguished engineer (L10, VP-equivalent at Shopify), the bar moves up to dynamic range — proof you can solve very different shapes of problem. Two axes:

  • Technical range: down to bare metal and up to “what is in the VP’s head and how does that translate into code.”
  • Execution mode: sometimes startup-mode “fire, see where it lands, fire again” because the problem is fog-of-war. Sometimes slow-thinking academic mode for an API design where the second- and third-order effects show up years later in your partner ecosystem.

He compares the role to a VP: “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 at layers below them, so they only get the hard problems with incomplete information.” Show them the volume and versatility of your toolkit.

Don’t be the best, be the only

The headline philosophy. Two paths to a successful career:

  1. Pick a domain and become the world expert. Live and die by that one skill.
  2. Build a portfolio of 80–90% competencies that almost nobody else has stacked together.

Ilya argues path 2 is more antifragile. What if you picked the wrong field? What if the company doesn’t need that exact skill? What if the world shifts under you?

“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 you know what I did really well? I combined all of those things into a unique toolkit that other people could not do.”

The math is just probability: multiply out the rarity of each skill in your stack and the intersection becomes the empty set with you in it. He once bought 15 books on marketing and read them in a week so he could speak the lexicon when sitting with marketing teams. Now at Shopify he’s often the translator between engineering, product, marketing, PR.

He’s blunt about what this means: he’s rarely the smartest or most knowledgeable person in the room. His job is to find the people who are, and help them navigate.

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

What he has is pattern matching and “knowing where to find answers.”

The regret: don’t let success raise your filter

Asked for regrets, Ilya gives one line: don’t let the pressure of your success stop you from trying.

He looks at his old blog posts and old GitHub code and cringes. But putting that sub-standard work out is what got him the feedback that made him better. The trap is what comes next:

“As you level up and as you get an audience and an expectation… you keep setting a higher and higher bar where you start to filter, like ‘here’s a thing I would have published before, but I’m not sure if it’s up to my standard now.’”

Once people expect quality from you, you self-censor. The drafts that would have been fine at thirty become “not interesting enough” at forty. The growth ingredient — exposure, reactions, mistakes in public — gets cut off precisely when you have the most to say. His advice is to keep the courage to be wrong, to be disliked, to ship the half-formed thought.

He links this to a personal arc: he was deathly afraid of public speaking through high school and university. Cold sweats. Then he started pitching PostRank and was fine. The difference wasn’t the skill. It was that he was now talking about something he was invested in changing, not regurgitating someone else’s curriculum.

Key Takeaways

  • Co-op rotations beat one-shot internships. Six three-month bets, no stigma for bailing, by graduation you’ve shipped real things.
  • The IC↔manager move is a switch, not a one-way ladder. Both directions are valid; pretending otherwise is an industry pathology. Try management at least once as a TL — it makes you a better IC partner forever.
  • Tour of duty model: commit to a problem, not a title. The right shape (IC pathfinder → TL → manager → back to IC) emerges from the problem, not from career planning.
  • Principal-engineer test: if you’re asking what the job description is, you’re not one yet. The ambiguity is the role. Parachute in, build alliances in seven days, find leverage.
  • Distinguished-engineer test: dynamic range. Bare metal and boardroom. Startup fire-aim-fire and slow-thinking API design that won’t bite you in three years.
  • Be the only, not the best. Stack 80–90% competencies that nobody else combines. Probability math: the intersection of weird skills shrinks to a population of one.
  • Get to 80% in days, 90% in a year. LLMs have made context acquisition shockingly cheap. Use it to expand range.
  • Self-censorship is the post-success killer. The audience you earned by shipping bad work will stop you from shipping more bad work. Resist it.
  • Show up to expert rooms with curiosity, not interrogation. “I’m here to help, I’m going to ask dumb questions, here’s what I bring.” That framing kills the ego friction of being the senior person who doesn’t know.
  • Optimize for being able to control your own time. This is the recurring reason he steps off the manager track. Manager = your calendar belongs to others; senior IC = you direct your own attention.
  • Sir Ken Robinson’s TED talks are the recommendation. Not a book. 20 minutes on YouTube.

Claude’s Take

Ilya delivers the goods without trying to sound profound, which is most of the reason this works. The “don’t be the best, be the only” line is going to get clipped and circulated, and it should — it’s a real reframe, not a platitude. The math actually checks out: rarity compounds multiplicatively when you stack skills, and most career advice has people trying to be additive (“I’ll go deeper in my one thing”).

Two places where he’s slightly self-flattering that are worth noticing. First, the “be the only” doctrine works much better if you’re already in a top 5% IC chair at a great company — the latitude to build a weird skill stack is itself a privilege of that position. For someone earlier in their career, “be the best at one thing for now” is probably still the right play, with “be the only” as the L7+ pivot. Second, the seesaw between IC and manager is real, but it’s noticeably easier to do at Google and Shopify than at most companies, where flipping back to IC genuinely is treated as a demotion. He acknowledges this gently but doesn’t dwell on it.

The interview is also missing one thing I’d have wanted: concrete failure stories. He gives one regret (the self-censorship arc) and it’s a thoughtful one, but the rest reads as a fairly clean retelling. No “this acquisition almost blew up because…” or “I made the wrong call on this technical bet…” That’s partly the format — short interview, friendly host — but it does mean the advice is calibrated for survivorship.

Score: 8/10. High signal-to-noise for anyone in or aiming at IC leadership; the “parachute, seven days, build alliances” image is the clearest articulation of the principal+ role I’ve heard. Drops a notch because some of it (“be the only”) gets repeated three times across the interview without much new content each pass, and because the regret section is thinner than the question deserved.

Further Reading

  • Sir Ken Robinson — TED talks on creativity and education (“Do schools kill creativity?” is the canonical one). Ilya’s strongest recommendation in the whole interview.
  • Ilya Grigorik’s blog at igvita.com — long-running, web performance heavy, the body of writing he’s referring to when he talks about the courage to publish work you’ll later cringe at.
  • High Performance Browser Networking (O’Reilly, free online) — Ilya’s book on TCP/IP, HTTP/2, mobile networks. Output of the “Make the Web Fast” years at Google.