Individual contributor or manager; how to actually decide

Someone asks whether you’ve thought about leading the team. You say you’ll think about it, and then you go looking for advice, and the advice is all the same shape: a list of manager qualities, an encouragement to try, and a reassurance that you can always go back.

Most of that advice was written inside large American technology companies, where a senior individual contributor ladder runs deep — staff, senior staff, principal — and genuinely pays as well as middle management. That structure is the exception rather than the rule, and it’s much rarer at Dutch and European employers. Advice built on it travels badly.

Here’s the version that survives contact with a mid-sized employer in Amsterdam, Utrecht or Eindhoven.

What actually changes is the unit of work

The usual summary is that management means more meetings. That’s true and it doesn’t help. The real change is what counts as your output.

As an individual contributor, your unit of work is an artefact: a merged pull request, a migration that ran clean, a design someone can build from. You made a thing, the thing exists, and the evidence is right there. As a manager, your unit of work is an outcome produced through other people. You’ll go whole weeks without personally producing anything you could point at, and the question “what did I actually do this week?” becomes genuinely hard to answer.

That difference has a second effect most people underestimate: the length of the feedback loop. An engineer usually knows within a day whether a decision was good. A manager’s decisions — who to hire, how to split the team, which project to protect — report back over months. How well you tolerate that delay predicts who stays in the role better than any skill does.

The three questions that predict it

Skills questions — “am I good at giving feedback?” — are the wrong test, because those are learnable and you’ll be bad at them at first either way. The questions that actually predict who thrives are about values: what you want, not what you can do.

What do you want to be accountable for when it goes wrong? Not when it goes well; everyone enjoys that. When the release fails at 2am, do you want to be the person fixing it, or the person who has to explain it, absorb it, and protect the team from the fallout? Both are hard. They’re hard in completely different ways, and most people have a clear preference once the question is put this bluntly.

Where does your energy come from — solving, or enabling? After a day of unblocking other people, making introductions and rewriting someone else’s proposal so it’ll pass review, do you feel spent or charged? This isn’t about whether you like people. Plenty of warm, sociable engineers are drained by a day of enabling, and plenty of quiet ones are energised by it.

What are you willing to get worse at? This is the one nobody says out loud. Your technical depth will decay. Not immediately and not irrecoverably, but within about eighteen months you won’t be the person who knows the codebase best, and you’ll feel it in code review. If that thought produces real grief rather than mild regret, take it seriously as information.

Management isn’t a promotion out of engineering. It’s a lateral move into a different profession that happens to pay attention to the same problems.

The Dutch complication

There’s a specific reason this decision is harder in the Netherlands than the internet’s advice suggests.

At many Dutch employers — especially outside the handful of large product companies — the senior technical ladder simply stops earlier than the management one. There may be a vakspecialist or senior engineer grade, but above it both the salary bands and the influence thin out, while the leidinggevende track keeps going. The American reassurance that you can grow just as far as an IC is, at a lot of Dutch organisations, quietly untrue.

Two consequences are worth naming plainly. Some people take a management role they don’t want, because it’s the only door marked up. And this is a fact about your employer, not about the profession — which makes it one of the strongest arguments for changing companies rather than changing tracks.

Consultancies and product companies differ sharply here too. In consultancy, senior technical people often keep growing, because billable expertise is the product. In a smaller product organisation the ceiling arrives sooner.

Soon you’ll be able to check this instead of guessing

Until now, whether the technical track at your employer actually pays has been folklore — you compare notes with two colleagues and extrapolate.

The EU pay transparency directive changes that. Once the Dutch implementation is in force, you’ll be able to ask your employer for pay levels broken down by category of work, and you must be told the pay range before you negotiate for a role. That turns “does the IC ladder go anywhere here?” from a rumour into a question your employer is obliged to answer.

The law is late and still moving through parliament. We’ve set out where it actually stands and what you can ask for separately.

How reversible is it, really?

More reversible than the fear suggests, less than the reassurance implies. Going back after one to two years is routine and costs you little beyond some rust. Going back after five is a real re-entry: the tooling has moved on, and you’ll be interviewing against people who never left. The people who return most easily are the ones who kept a small, real, hands-on commitment throughout — not a hobby project, but something with a deadline and other people depending on it.

Test it before you commit

You don’t have to decide in the abstract. Each of these is available without a title change, and each isolates a different part of the job:

• Tech-lead one project end to end. Tests the outcome-through-others shift without the personnel work.
• Run a hiring loop. Screening, interviewing and making a call on an ambiguous candidate is a surprisingly complete preview of managerial judgement.
• Take the incident review. Owning the write-up and the follow-through — including the uncomfortable conversation about what went wrong — is the accountability question in miniature.
• Mentor formally for two quarters. Long enough to feel the delayed feedback loop, short enough to stop.

Do two of them. Then ask yourself the three questions again and notice whether your answers moved.

The three questions are values questions, and values are hard to read from the inside — most people answer with what they think they should want. That’s what the Collaboration Scorecard is for: it profiles what you actually value in a work context, and then talks it through with you.

— Zoran