No-one is going to hand you a career ladder.
Don’t get me wrong: have a conversation with your manager to understand where your interests align. But first, put in the work to understand what you actually want.
For two years I waited for my manager to draw me a ladder. Reading Cian Synnott’s How I think about career development, I realised I’d been thinking about it all wrong.
I recently did this exercise. I stepped back and thought about what I wanted from my career. I love writing. I enjoy teaching. I’m always enthusiastic about implementing designs and best practices that make sense and save a lot of headache later, like Architecture Decision Records (ADRs, for short). This probably explains my voracious reading habits: I’m always learning from much smarter people about how they’ve not only implemented well-architected solutions, but how they’ve also navigated the trenches of politics.
The politics matter more than the architecture: not everyone speaks the same tech language. They need the overview, not the deep dive.
Mentors#
Not every company will have a great mentor. Not every company will have great colleagues. Lois from Malcolm in the Middle put the reality better than any manager could. When her son Francis moaned that he was working for a moron, she replied:
“Of course you are, honey. Your boss is an idiot, your co-workers are incompetent and you are underappreciated. Welcome to the working world.”
— Lois, Malcolm in the Middle, “Hal Quits”
Some of us are very fortunate and have mentors within our company, sometimes even within our own teams. But what happens when we don’t have those? It can be extremely disheartening. I’d read Google’s and Spotify’s engineering blogs and feel the distance; their calibre of work was leagues from mine. I dreamed of working alongside those people.
We need not get disheartened. The beatific discovery is that there are plenty of well-versed people who are willing to share what they know. Just recently I learnt about AI-BOM through a webinar, and immediately started bugging our InfoSec team for it. One week later and we’re trialling PoCs, myself as the guinea pig.
I follow people like Tanya Reilly, Will Larson, and Addy Osmani, to name a few, but you’ll find your own mentors outside of your company, as well as hopefully within.
Even outside of your team, mentors will explain a concept or walk you through a codebase if you ask. They gain from the experience, too: not only because it helps broaden everyone’s understanding; it also solidifies their own. Explaining a decision forces you to justify it. Seneca said two thousand years ago: homines dum docent discunt — while we teach, we learn.
One of the best things about mentors is understanding what makes you follow them. For me with Osmani it’s the specific AI-related practices: I took his PR Contract framework and applied it across all our GitLab templates. Before that, we had hundreds of lines of Merge Request templates that had to be read to understand what had happened, and how much had been generated or assisted by AI.
We all need someone to model ourselves after. Study how they got there, not just where they are. Larson kept choosing scope over title, which is a path you can actually follow.
Maybe you want to give tech talks. Well, first you need to find an opportunity to give one at your company. Suggest a knowledge sharing session and get prepared. Maybe you want to write tech books. Start documenting everything now. Whatever your career development goals, you need to be actively working on the things you want to be doing in 5 years’ time. You need to make contacts, you need to always be professional, and you need to show you’re capable. But more than all this: you need feedback. You need to know what worked – and, more importantly, what didn’t.
Feedback#
If you’re not open to feedback as an individual, you’re going to fail as a collective.
At my current workplace we’ve introduced retros. There are a few different frameworks for how you conduct a retro. I personally like the simple Start, Stop, Continue framework. It gives everyone a chance to say what they think is going well, what they’d like to stop (it’s a running joke we write out support issues in production), and what they think we should start doing (more regular pay increases a mandatory sticky note here). Feedback is the fuel of iteration and growth.
Everyone’s a critic; not everyone’s a good critic. If someone’s feedback doesn’t help – or worse, stings – thank them and don’t go back (unless they can take feedback on their feedback). Giving good criticism is its own craft, always harder than taking it.
Feedback has a dosage. Seek it everywhere and you’ll paralyse yourself. Some people just work differently from you. That’s not a verdict on yours.
AI can be useful in giving a fair critique of your work if calibrated carefully, but again, don’t set the bar too high for success. I spent about a month designing and iterating over a Claude Skill to analyse every word and literary technique in my writing and rate each sentence out of 10 based on a style palette generated from my Kindle and Readwise highlights. It works, and it taught me a lot about loop engineering. But I never stopped to ask whether I should build it at all. Best intentions, meet road to hell. Learn to let go and strive for “very good”, not perfectionism.
Contacts#
Reach outside your company, too. The best engineers gather in places you can join, like LinkedIn or the Rands Leadership Slack, where I first saw how staff engineers operate in larger corporations and the challenges they face daily.
Keep in contact with good engineers as well. When good people leave, most are forgotten in a week. It’s sad, but true. But don’t let them be. Send a LinkedIn request with your goodbye, or take theirs. Don’t bug them repeatedly, of course. Chances are you’ll continue to learn from them even after they’ve left your direct circle of influence.
One of our top engineers left to explore other avenues. I stayed in contact with him and asked what books I should read to get near his level. He sent back two lists: what he thought I needed, and what he was reading himself. It suddenly felt more like a peer conversation than a mentor/mentee relationship.
One message from an old contact moved me from an IT support company to an in-house team, which introduced me to Cloud Engineering. You never know what a kept connection will bring.
Track Your Own Progress#
For years I wanted nothing more than to be a DevOps Engineer; I thought it was the coolest job in the world. Soon after that I wanted to focus on Platform Engineering. Then I discovered the role of a Staff Engineer, and the practices of people like Reilly and Larson. Much like the retro ceremony, careers need retros, too.
Whatever your method, track what you want to learn or do with a clear time limit – e.g. “By this time next year I want to do X.” A goal without a deadline is a wish. We hit the deadlines we set ourselves far more than the ones we leave open. The date is what turns ‘someday’ into ‘Friday’.
For Tanya Reilly, I read that she signed herself up to speak at a tech conference. She had never spoken at one before. She didn’t know whether she would get the opportunity. She did. Then she had to become that person who could give the talk.
Mentorship#
Be the mentor you wish you had.
Practice patience. Set aside time. Share your knowledge and how you work.
I’ve done this in every job I’ve had. I’ve asked for feedback on the onboarding process. I’ve written documentation and checklists for our repos. I’ve set aside time to pair with an engineer. For me, working on a Terraform deployment would be second nature and done within an afternoon. For a junior, it’s a milestone. It’s not only about getting the code working; it’s about ensuring they understand the why: the design patterns, the principles. When a new requirement comes in they’ll be able to apply those learnings.
If no-one handed you a ladder, be the one who holds it for the next person.