Questions people actually ask.

Growth is about the gap between what you're actually doing and what your current role already expects of you. In most cases I've seen, people are operating at a fraction of that expectation without realising it. Promotion is a separate thing entirely, and it's the easier of the two: if you've genuinely outgrown the role you're in, you already know. You'll be looking for harder problems because the current ones stopped teaching you anything.

So do them in that order. Close the gap first. The title argument gets much shorter when there's nothing left to argue about.

Now the part nobody does. Every company has its own competency framework, its expectations per level, its KPIs. Most of them are broadly the same underneath. Go and read yours properly, not the summary someone pasted in a deck. Then be honest about where you sit against each line of it.

From there, build a one year plan, split into quarters. Not a wish list. Specific things you'll have done by the end of each quarter that move you from where you are to where the next level starts.

Then take it to your manager. This is the step people skip, and it's the one that makes the whole thing work — because a plan your manager has seen and agreed to becomes the thing you're both measuring against, instead of you guessing and them deciding at review time. Lock the progress in at your 1:1s and at skip-levels.

If you do only one thing from this, do that last part. A quarterly plan your manager knows about is worth more than two years of quietly doing good work and hoping somebody notices.

Most 1:1s are chit chat. Status updates that could have been a message, a bit of weather, and out. Thirty minutes a fortnight, for years, spent on nothing.

Drive it yourself. Turn up with an agenda you wrote, made of things that benefit you — where you're stuck, what you want to be doing in six months, what you need from them to get there.

And claim your feedback rather than waiting to be given it. Waiting means you hear it at review time, when it's already been written down somewhere and it's too late to act on it. The sentence to use is:

"What would you need to see from me this quarter to say I'm operating at the next level?"

Ask it out loud, then write down the answer, then work on it. That last bit matters. Feedback you collected and did nothing with is worse than not asking, because now they've told you and they'll be watching.

The first thing to work out is which room you're standing in, because the right move changes completely. In some workplaces you say the thing directly in the meeting and you're respected for it. In others the same sentence gets you quietly filed as difficult, and the actual conversation was always going to happen somewhere else. Advice that ignores this is worse than no advice.

The second thing: most conflict at this stage isn't really about the thing being argued over. It's about not yet having the vocabulary for disagreement. You've been heads down delivering for two years, which you're good at, and delivery has clear answers. Disagreement doesn't.

That's why I usually push people here towards system and platform design, and towards trade-offs. Not because it settles the argument, but because it changes what you're arguing about. "I think my approach is better" is a fight. "These are the two options, here's what each costs us and what each buys us, here's the one I'd pick and why" is a decision. The second one is very hard to be difficult about.

You won't be making those calls for years yet. Doesn't matter. This is where the groundwork starts, and the people who start it here are the ones who are ready when it's their call to make.

Before I can say anything useful I need to know what you're actually interested in and where you see yourself. Most people asking this haven't been asked that yet, and when they try to answer it out loud they find the ambiguity themselves. That's most of the work done.

Here's the thing about being new that nobody tells you: you are the most flexible you will ever be. You have the least context, and that's a strength, not a gap. You just came out of years of full time learning, so picking up something new costs you almost nothing. You can slot into any company. People further along have all of that loaded with history and opinions and it genuinely slows them down.

That's also why freshers are the change creators in most teams I've been in. You'll ask why something is done a certain way, and half the time nobody has a good answer.

So don't optimise for the stack. Stay open, and spend some of that learning capacity on something that isn't code: how companies actually work. How decisions get made, who makes them, why a thing you think is obviously right doesn't happen. That knowledge compounds for thirty years. A framework choice compounds for about three.

And for the work itself — take what's thrown at you and try to build something that lasts. Not something clever. Something that's still standing, and still understandable, two years after you've moved on.

Yesterday you were responsible for your work. Today you're responsible for someone's career. Those are not the same job and they barely use the same skills, but nobody hands you a gap between the two.

Two things to build, and neither of them is a process.

Empathy, which mostly means accepting that people are not you. Not everyone works at your pace. Not everyone has your experience, your background, or the particular set of lucky breaks that got you here. The person who takes three days over something you'd do in an afternoon is not underperforming. They are at a different point, with different context, and possibly something going on at home that you'll never hear about.

And patience, which is the harder one for engineers. Your instinct will be to fix it. You'll see somebody struggling with a problem you solved years ago and want to just take it. Don't. Every time you do that you get one thing shipped and take away one thing they would have learned.

Expect to unlearn a lot. Most of what made you good at the last job is either irrelevant or actively in the way here, and the sooner you accept that, the shorter the bad six months will be.

That surprises people, because they expect me to ask what they enjoy. But the question is nearly always framed as permanent, and it isn't. You're treating it as a door that locks behind you, and that framing is doing more damage than either choice would.

Treat it as an experiment. You have a hypothesis: that you'd be good at this, or that you'd hate it. Run it. If B doesn't give you the result you predicted, your A side is still there. The technical depth you spent ten years building does not evaporate in eighteen months of managing people. I've watched several people go across and come back, and every one of them came back better at the IC job than they left it, because they finally understood why the decisions around them were being made the way they were.

The asymmetry is what decides it. Going across and coming back costs you some time. Never going and wondering costs you the rest of your career.

One thing to be honest with yourself about before you try it. If what you actually like is being the person who knows the most, management will make you miserable, because the job is being the person who knows the least in the room and is fine with it.