Nobody is coming to plan your career for you. The industry will happily let you drift: take the next role that opens up, learn whatever tool lands in front of you, stay in the city you happened to grow up in, and find out at the annual review whether any of it moved you forward. Drift can look like progress for years, because the job keeps getting renamed around you, analyst, then data scientist, then machine learning engineer, now AI engineer, and a new title feels like movement. It is not. Looking at the people who have genuinely accelerated, in data, ML, AI, or traditional software, the acceleration never came from the titles. It came from a handful of deliberate choices that most people never consciously make, and that is what this post is about.
There are five of them, and this post takes them one at a time. Spend real time working out what you actually want, and only then grind toward it. Get very good at learning things quickly, which in practice means getting very good at fundamentals. Keep taking on problems just outside your wheelhouse, and check every month that you are still learning. Treat what you work on, where you are, and who is around you as the highest-leverage decisions you own. And build the non-technical skills, because past a certain point they are what move you. None of these are original to me, and I will point to the people I took them from. But each one is something I genuinely believe, and each one is cheap to act on early and expensive to discover late.
Know what you want before you grind
Philip Su is one of the rare engineers to have reached Distinguished Engineer, the IC9 level, at Meta; he got there by founding Meta’s London office and scaling it from around a dozen engineers to more than five hundred, and he later worked at OpenAI at the same level.1 Then, having reached the summit that thousands of engineers orient their careers around, he asked to step back down to IC7, because the organisational weight of the role had crowded out the technical work he actually loved.2 When he reflects on his career now, the advice he keeps returning to is not about output or promotion tactics. It is about values and self-awareness: knowing what you want before you spend years wanting it on autopilot.
The lesson I take from his story is about how people allocate their thinking. Most of us spend nearly all of our effort on moving and almost none on choosing the destination. We go with the flow, and the flow feels safe because everyone around us is in it. But the flow optimises for an average of other people’s goals, not yours, and its failure mode is brutal: you can execute flawlessly for a decade, arrive exactly where the ladder was pointing, and only then discover that the destination was never really examined, only pursued. At that point, changing course costs seniority, salary, and a chunk of your identity. The same reflection, done at the start, costs an honest few weekends.
So invert the allocation. Spend a serious fraction of your time, especially early on, working out what you would actually want to be true at the end of your career, not what would sound impressive at a reunion. The goal does not need to be precise; it needs to be honestly yours. Once you have it roughly right, work backwards from it to a few checkpoints, the next role, the next capability, the next kind of problem you want to have solved, and point your effort at the nearest one. Direction first, then the grind.
Learn fast, and let fundamentals make you fast
The second pillar follows from the churn I opened with. If the tools of this field turn over every few years, and they now do, with AI models writing a growing share of the code and reshaping the daily work around judgement and review (I wrote about that shift in a post on working with coding agents), then you cannot stockpile tool knowledge in advance. The durable skill is the meta-skill: being able to pick up whatever becomes relevant, quickly, at the moment you need it. The people whose careers look robust are not the ones who guessed the right framework; they are the ones who process new material fast, extract a working mental model, and start building with it while others are still on page one of the docs.
What makes someone fast at that is not a trick. It is fundamentals: the ability to break a problem down, and the comfort with abstract concepts that lets a new tool slot into things you already understand rather than arriving as a pile of unfamiliar facts. Terence Tao, asked for advice, describes what he calls cheating strategically: if ten things make a problem difficult, find a version that switches off nine of the difficulties and keeps one, solve that, and repeat before recombining.3 He also points out that the interesting problems sit at a boundary, where existing techniques get you 90% of the way and you must invent the last 10%. Both habits are exactly what fast learning looks like from the inside. Strong fundamentals mean the new library is a small delta on ideas you already hold, and the ambiguous project is a set of separable difficulties rather than a wall. Weak fundamentals mean starting from scratch every time the field jumps.
So when you choose what to study, weight the things that transfer: decomposition, the core concepts under your specialism, the ability to reason about a system you have never seen. Learn the current tools well enough to be dangerous, expect them to be replaced, and do not mourn them when they are.
Take on problems just outside your wheelhouse
Fast learning needs raw material, and that is a choice you make over and over: which problems you put yourself in front of. If you want to accelerate rather than just progress, the pattern I believe in is deliberately moving toward problems that sit outside your current wheelhouse and would genuinely matter to the business if cracked, but that are not so far beyond you that you get overwhelmed and fall short. This is Tao’s boundary from the previous section, applied to your career instead of a proof: enough overlap with what you can already do that you will deliver, enough stretch that delivering forces you to grow. Get the calibration right and each project pays you three times, in new skills, in visible business value, and in the confidence to aim slightly higher next time.
Picking these problems well is not a purely individual judgement, because the right stretch depends on the context you would be stretching in. The same problem can be a career-maker at one company and a dead end at another, depending on where the company is in its life cycle, what resources and tools already exist, and who would be around you while you wrangle with it. A hard problem with strong colleagues and half-built infrastructure is a very different bet from the same problem alone on a greenfield. So when you weigh a project or a role, weigh the surroundings as part of the problem, not as scenery.
I will not pretend the stretch feels good. Working outside your wheelhouse means feeling uncomfortable, and often it means imposter syndrome: the sense that you are not up to the task and that everyone else can see it. That feeling is not a signal to retreat; it is what the right level of challenge feels like from the inside, and learning to keep working through it is part of the skill. Some people shrug it off by temperament. If you are not one of them, treat the discomfort itself as something to train in a deliberate way, by taking stretches small enough to survive at first and letting each completed one recalibrate what “too hard for me” means, because rapid growth only happens out there and you cannot afford to let the feeling veto the attempt.
Then repeat it as often as you reasonably can, and harvest the feedback from every attempt, including the ones that fall short. The compounding is the point: each stretch project extends the wheelhouse, which makes the next, harder problem reachable, and momentum builds. A few years of that separates people dramatically from those who stay inside their comfort zone until the work becomes repetition of the same year. The test I use for whether it is working comes from Kun Chen, an engineer who reached E7 at Meta and Partner at Microsoft, in his interview with Steve Huynh: ask yourself each month what you learned that you did not know the month before.4 There are other ways to measure growth, but this one is hard to fool. If the honest answer is nothing, the problems you are choosing are not challenging enough, and your growth has quietly stalled regardless of how busy the month felt.
Choose what you work on, where you are, and who is around you
Naval Ravikant compresses this pillar into one line: “The three big decisions - what you do, where you live, and who you’re with.”5 His accompanying point is the one I want to underline: if you are going to live in a city for ten years, hold a job for five, or be in a relationship for a decade, it is worth spending a year or two deciding, because these choices dominate almost everything else you will optimise. We will happily spend a week benchmarking a database and then take the defaults on the three variables with the highest leverage over our lives.
The defaults are the problem. If you grew up somewhere, the default is to stay: same city, same friend group, take what life brings. That can be the right call, but it is still a choice, and it is worth noticing that it was made by inertia rather than by you. The problems worth working on cluster in certain companies and cities; ambition is contagious, and so is its absence; the people around you quietly set what feels normal to aim for. If those variables are stacked against what you decided you want in pillar one, then changing them, moving, switching companies, finding a different set of people, is uncomfortable and takes genuine courage, particularly when nothing is visibly wrong with the life you have. But these are also the levers where a single hard decision does more than years of incremental effort in the wrong setting.
This is where the direction work cashes out. Knowing what you want is only useful if you are willing to move the big variables to match it.
Build the skills that are not technical
The last pillar is the one technical people resist the most, me included. Steve Huynh, a former Amazon Principal Engineer, argues that what separates world-class engineers is not raw intelligence, which is table stakes at the top, but behaviour: how they operate, communicate, and choose problems, especially when things get difficult.6 One of his lines is worth keeping whole: a really good solution to the wrong problem is worse than doing nothing. Choosing the right problem is not a technical act. It requires understanding the business well enough to know which problems matter, and communicating well enough to get the people who own the budgets to agree with you.
This matters most in big, mature organisations. When the processes are established and the systems already work, moving the needle is rarely a matter of writing better code. It means navigating cross-functional teams that existed long before you arrived, translating technical work into business value, and winning buy-in from senior people who will never read the code. Two engineers with identical technical ability diverge completely here: the one who can do the translation ends up steering what gets built, and the one who can only execute ends up hitting roadblocks and wondering why the org will not listen. I think engineers underrate this because it pattern-matches to politics. It is not politics; it is the mechanics of leverage in any organisation larger than a single team, and it can be learned like anything else, which loops back to pillar two.
The five together
The titles will keep churning, and the tools attached to them will churn faster. I find that calming rather than threatening, because none of the five pillars depend on either. Work out what you actually want and work backwards from it. Get fast at learning by getting good at fundamentals. Keep choosing problems just past your edge, and check every month that you are still learning. Put yourself, deliberately, in the place, problem, and company of people that match what you want. And build the communication and business skills that turn technical ability into impact. Everything else about this career, the names, the frameworks, the ladders, is weather.
Sources & further reading
- OpenAI Distinguished Eng (IC9) On Advice After Reflecting On His Career Grind — Philip Su on The Peterman Pod; the full interview and Ryan Peterman’s written summary cover the IC9 climb, the voluntary step down, and the case for knowing your values.
- Mathematician gives advice to students, Terence Tao and Lex Fridman — the advice segment of Lex Fridman Podcast #472; strategic simplification and working at the boundary of your ability.
- Naval Ravikant on the three big decisions — the tweet quoted above; expanded in The Almanack of Naval Ravikant, including the point about spending a year or two on decade-long decisions.
- 5 Things World Class Software Engineers Do That You Don’t — Steve Huynh (A Life Engineered); behaviour over brilliance and problem selection. His companion essays on Substack expand the list.
- The 2% of Engineers Winning the AI Era (Ex-Meta L8) — Huynh’s interview with Kun Chen; the monthly growth test, and why engineering fundamentals still gate how far AI leverage takes you.
- Working With Coding Agents — my own account of how AI tools are reorganising the day-to-day of building software, and what that demands of the people doing it.
-
Philip Su’s trajectory and the London office scaling from roughly 12 to 500+ engineers are from Ryan Peterman’s interview with him on The Peterman Pod (2025) and Peterman’s accompanying writeup. ↩
-
Su recounts requesting the move from IC9 down to IC7 in the same interview, to prioritise hands-on technical work over the organisational duties the higher level demanded. ↩
-
From the advice sections of Lex Fridman Podcast #472 (2025). Tao’s phrasing: if there are ten things making your life difficult, find a version of the problem that turns off nine of the difficulties and keeps only one, solve that, and then combine. ↩
-
From Steve Huynh’s interview with Kun Chen on A Life Engineered, “The 2% of Engineers Winning the AI Era”. Chen describes using the monthly check to judge whether a role was still growing him, including in deciding when to leave. Huynh’s own “5 Things” essays list measuring growth on a monthly cadence as the first habit of world-class engineers. ↩
-
Huynh spent 18 years in software including a Principal Engineer role at Amazon. The framing that brilliance and hard work are baseline at the elite level, with behaviour as the differentiator, runs through his video and the companion Substack essays; the “wrong problem” line is from those essays. ↩