The Shoemaker’s Own Shoes: Rebuilding My CV

This October 2026 revision develops a note first published in 2025. The career timeline below includes the later move into portfolio leadership in December 2025.

For several years, I helped colleagues improve their CVs while updating my own by adding one more line at a time. The document contained plenty of experience but did not answer the main question: which role should someone consider me for now?

It presented an analyst, a data engineer, a project manager, an IT lead, and a long technology list at the same time. Every part was true; together they created noise.

My direction today is CTO-level technology leadership across a substantial product environment: strategy, product, architecture, delivery system, and teams. The rebuild began with that sentence.

1. Lead with the role, not the biography

A CV does not need to give every career stage equal weight. Its opening should explain which problem the person can solve today.

For a CTO direction, “manager” is not specific enough. The evidence needs to connect business need, product and technology planning, team formation, and delivery into production.

Positioning does not permit invention. It changes the order of proven facts; it does not create new ones.

2. Show one trajectory inside one group

Several roles in the same corporate group can look like a series of short jobs. I brought my experience at Innotech, part of T1 Group, into one career line: data analysis, analytics leadership, Big Data IT leadership, project management, and then responsibility for a portfolio and development cluster.

The dates and role changes remain visible, but the reader no longer has to reconstruct the progression.

3. Put outcomes above task lists

The technology stack demonstrates depth, but it does not replace an outcome. An executive CV should answer four questions:

• what was within my scope;
• which decision did I make;
• what did the team change;
• what evidence supports the result.

Technology belongs beside the relevant case or in a compact capability section. Three screens of libraries do not make a CTO profile more convincing.

4. Describe scale with care

An executive CV needs numbers, but each one must survive a follow-up question. I label estimated effects as estimates. When a metric belongs to a product and a team, I do not present it as the work of one person.

I also reconcile dates, roles, and project names across the PDF, website, and public articles. A small timeline conflict can damage trust more than the absence of another impressive metric.

5. Keep practical details visible

Contact details, working model, and language level should be easy to find. My CV now states Telegram and email, availability for office, hybrid, or remote work, and English at B2 level.

A language level is best described plainly and in a way that can be tested. Self-deprecating humour adds ambiguity where the reader needs a useful working fact.

Designing for the first minute

An executive or recruiter rarely begins by reading every line. I therefore made the top of the document a self-contained answer to three questions.

The first is who I am now. A target role and one sentence about the professional profile work better than a list of every plausible title.

The second is which scale I have already handled. The reader needs a few anchors: a product environment, team or portfolio responsibility, production delivery, and a business outcome that can be explained.

The third is why the rest is worth reading. In my case, it is the combination of product management, technical depth, and the ability to establish an end-to-end software delivery system.

If those answers appear only on page two, the structure is doing too little. The detailed chronology should support the first impression, not create it from scratch.

Choosing evidence

Every strong claim in a CV should lead to a case that can be examined in an interview. I test each line with five questions:

1. What was the starting context?
2. What did I personally own?
3. Which decision did I make?
4. What did the team do?
5. Which observable result followed?

This removes two common extremes. One is a list of duties without an outcome: “managed,” “coordinated,” and “participated.” The other is presenting a team result as if one person produced it alone.

Some detail belongs in the conversation rather than the document. A CV should not disclose an internal banking architecture, sensitive measurements, or every step of a decision. It should provide enough verifiable context for the interviewer’s next question to be substantive.

What I removed

Cutting material mattered as much as rewriting it. I removed repeated capabilities, tools with no connection to a result, early tasks that no longer explained the current level, and broad attributes such as “responsible” or “communicative.”

I also reconsidered visual emphasis. A large number attracts attention before its explanation, so it needs a precise meaning beside it: what was measured, over which period, and whose result it was. If the explanation cannot fit, a calmer sentence is often more credible.

Different opportunities may justify several versions of the document, but all versions need one factual base. A CTO version changes order and emphasis; it does not change the timeline or the substance of an achievement.

The result

The shorter CV did not lose the analytics, data, or engineering background. Those parts now support the CTO proposition instead of competing with it.

A useful test is to give the document to someone who does not know you and, one minute later, ask three questions: who is this candidate, what scale have they already led, and which problem could you trust them to own? If the answers do not match the intended position, do not add more copy yet. Remove the noise first.

---

Originally published on my Telegram channel @it_underside.

Yours, DPUPP