Seven Pieces of Career Advice I Wish Someone Had Told Me

I have an unofficial rule on this blog: no listicles. Consider this post a rule-breaker: seven pieces of career advice, gathered the hard way. I recently crossed the ten-year mark in tech, and these are the things I find myself repeating to mentees — and honestly, to myself on the days I forget them.

1. Finding the right problem is the hard part

Early in your career, problems arrive pre-packaged: a ticket lands, and your job is to solve it well. Somewhere around senior, that quietly inverts – the job becomes converting ambiguous messes into well-formed questions, and the solving is often the easy part.

When a problem is genuinely hard, it's almost never because the code is hard. It's because nobody has figured out what question we're actually trying to answer. Are teams disagreeing about the data itself, or about what the data means? The trap is that problem formulation is invisible – the work of realizing the team was asking the wrong question rarely gets much credit. If you want to grow past solving tickets, practice the skill of writing the ticket.

2. Your biggest impact comes from making other people faster

You have maybe six good focus hours a day. Your team collectively has fifty. A week spent making ten engineers 10% faster creates more value than a month of your own heads-down output.

This is multiplier work: internal tooling, paved paths, documentation that actually gets read. The biggest projects I've worked on weren't flashy launches – they were tools that removed toil from everyone else's day. It's the highest-leverage work most engineers do, with a catch – the impact shows up in everyone else's metrics, not yours. So instrument it like a product: adoption, cycle time before and after, incidents that didn't happen. That evidence is the difference between multiplier work being your promo case and being a rumour.

3. Measure whatever you build

The advice I'm most qualified to give, because measurement is literally my job: if you ship something and can't say what changed, you can't defend it, improve it, or get credit for it.

I've watched good projects die in review because nobody could prove they worked. This is especially true for infrastructure, reliability, and tech debt, where the value is real but easy to miss. "The team seems happier" is a vibe; "median backfill time dropped by 60%" is a fact. The discipline is boring: capture a baseline before you ship, define what "better" means up front, be honest about counterfactuals, and measure adoption. If my job has cemented one belief, it's that trust is a measurement problem.

4. Visibility matters, even if you hate self-promotion

I hate self-promotion. For years, I treated visibility as optional – good work should speak for itself. But in a large organization, work that isn't made legible is easy to forget, misunderstand, or attribute to the wrong person.

Promotions run on legible evidence, and your manager won't remember the migration you quietly de-risked in March. So market your work: demo it, announce it in Slack, write the post nobody asked for. I used to cringe whenever I had to do this, but I've recently reframed it: when done factually, it's not bragging – it's keeping people informed.

The standard advice is to keep a "brag doc". I still think that's useful, but AI has changed what it's for. What matters now is legible exhaust: GitHub issues, pull requests, design docs, and Slack updates that clearly state the problem, the change, and the impact. Write those artifacts well and the work starts to document itself. At review time, an agent can follow the trail and help turn it into a story. The record-keeping is easier than it used to be, but deciding what mattered is still on you.

5. Communication is the most underrated skill in engineering

Engineers rarely train communication deliberately. We'll spend weeks shaving seconds off a query, untangling a migration, or learning the sharp edges of a new tool, but far less time practicing how to write, present, or explain our work – even though past a certain level, that's where the marginal returns are.

AI makes this more obvious, not less. It can help draft the README or clean up the design doc, but the hard part is still human: knowing what context matters, what tradeoffs to surface, and how to make a complex system legible to someone who wasn't in the room.

The costs are concrete. A confusing README doesn't waste an hour once; it wastes that hour again for every person who reads it. And you can build the most impressive thing in the world, but if you can't explain what it does and why it matters, it won't get the recognition it deserves.

6. Every yes closes a hundred other paths

This “map of a life” by Wait But Why’s Tim Urban is one of my favourite charts, and I think about it often as career advice:

Behind you, a single green line: the route you actually took, every unchosen fork greyed out. Ahead, a wide green fan: everything still possible from where you stand.

My interoperation of it, as career advice: every yes is a hundred no's. Say yes to one path and you're also saying no to others: the startup, the sabbatical, the move abroad, the quiet year, the pivot – at least for now. Every commitment collapses some of the branches around it.

That sounds bleak, until you flip it. The point is not to keep every branch open forever (you can't). The point is to notice that the green fan is always drawn from where you're standing today. The paths behind you were always going to close. The ones ahead are still open. My filter for choosing between them is narrative: when I look back at the line I've drawn, which branch makes it a story I'd want to tell? The next branch should be worth collapsing the others for.

7. Leave some space unoptimized

A career rewards deliberate choices, but you still need some space where you aren't optimizing for anything.

If every hour is pointed at a goal, the only possible destinations are the ones that were visible from the start. Some of my best ideas have come from following something simply because it was interesting. Flora started as pure curiosity about a rendering problem. Nobody assigned it, and it didn't fit neatly into any plan I had. But it taught me more about where my field is heading than anything I could have scheduled.

Exploration doesn't compete with deliberate choice; it makes better choices possible. A branch can't be chosen if it has never been seen. So curiosity needs a line item in your week, without demanding an ROI before it has had a chance to become anything

Careers are often framed as a ladder: solve harder problems, get promoted, repeat. I don't think that's quite right. The biggest changes in my career came from changing how I worked rather than simply working harder – choosing better problems, making other people faster, measuring what mattered, communicating clearly, saying yes on purpose, and leaving enough room for curiosity to surprise me.

I'm still trying to get all of this right. These are simply the ideas I return to whenever I feel stuck. If you have any advice that you'd like to share, drop it in the comments. 🙌

Until next time!