A Career in IT: My Model for Choosing the Next Move

Careers are often drawn as ladders: the next title, more responsibility, and higher pay. That model is too flat for IT. A strong move can go upward, into a deeper specialism, or into a project where the title barely changes but the scale of the problem does.

I compare options through four questions. They do not make the decision for you, but they quickly expose when you are following someone else’s definition of progress.

1. Which outcome do I want to own?

This is not a question about a title. It is about the scope of responsibility.

• A specialist owns the quality of a difficult solution.
• An IT lead owns a team’s result and its engineering environment.
• A product or project leader connects a need, priorities, and delivery.
• A portfolio leader makes choices across several products and shared resources.

As that scope grows, there is less time for personal execution. That is not a ranking of people; it is a change of profession.

2. What work do I want to do every week?

An ambitious title may not match the work you want in an ordinary week.

If you enjoy going deep into a technology and finding the solution yourself, an expert path may offer more than management. If you prefer assembling context, setting priorities, and enabling other people to perform, leadership is a better fit.

A useful test is to notice which tasks give you energy and which ones you consistently postpone even when you can do them well.

3. Which price am I willing to pay?

Every move has a cost:

• management means less hands-on technical work and more conflicting expectations;
• deep specialisation can narrow the market for particular roles;
• entering a new field temporarily reduces speed and expert status;
• rapid progression can create overload before experience catches up.

Pay matters and needs no apology. But compare the whole exchange: income, interest, autonomy, workload, learning, and life outside work.

4. What evidence will exist in six months?

“I want to become a CTO” is a direction, not a plan. A plan begins with evidence: a launched product, a team built, an architecture adopted, a delivery process improved, or a larger scope of responsibility.

I phrase a next step like this:

In six months, I want experience in X by taking ownership of Y, with Z as evidence of the result.

If the right task is not available in the current role, it may exist in an adjacent project, mentoring, a conference talk, or a personal product. A new title without new evidence rarely solves the career problem.

Three kinds of movement

Management movement increases the scale of responsibility: specialist, lead, and then leader of several teams or products.

Expert movement increases the ability to solve a class of problems and influence others through architecture, standards, and advice.

Project movement changes the domain or type of product. It may look horizontal on a CV while creating the experience required for the next level.

These paths can be combined. My own move from analytics to IT leadership came through projects that required business understanding, data, architecture, and team delivery at the same time.

Making the choice

I would not begin with a five-year map. Choose one testable move for the next few months:

1. name the scope of responsibility you want;
2. compare it with the actual weekly work;
3. accept the cost of the transition;
4. choose a task that will create evidence of the new experience;
5. set a date to review the decision.

A career rarely follows the diagram drawn in advance. The next move can still be deliberate: choose it by the outcome you want to become capable of creating, not by how impressive the title sounds.

Try leadership before changing the title

A strong engineer receives a team-lead offer. The title is appealing; the day-to-day work remains untested: priorities, feedback, dependencies and enabling other people’s results.

A bounded experiment can help. Coordinate one small delivery with explicit authority and support: agree on the outcome, plan with colleagues, manage dependencies and organise acceptance. Responsibility without decision rights tests very little.

Afterwards, review more than the deadline. Which activities provided energy? Could you delegate? What happened to hands-on engineering? Would you want this kind of week repeatedly? Discovering that an expert track fits better can be a successful result.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP