Tech Lead: A New Challenge for an Analyst

In October 2023, I was asked to create and lead a separate project: an early real-time configurator for personalised offers. This case preceded the Decision Engine project I joined in late September 2024.

Before that, I had moved from an analyst on the Mirion graph platform to IT lead for Big Data application services. The new role was no longer just about requirements and architecture. I was now accountable for the people, the delivery process, and the outcome.

I prepared this story for Analyst Days 2024. The proposal was accepted, but I never gave the talk: I did not have the time or energy to prepare it. I had taken on more than I could manage, and the material never reached the stage.

That experience belongs in an article about moving into leadership. Alongside a team, deadlines, and business expectations, you have to account for your own capacity. Here I return to the idea behind that talk and share what I learned in the new role.

What changes with the role

An analyst is responsible for understanding the problem well. An IT lead is responsible for turning that understanding into a product the team can actually deliver. Architecture, dependencies, hiring, quality, schedules, and business expectations all enter the same field of view.

My analytical background helped. I knew how to question assumptions, break down ambiguity, and discuss a problem in business terms. It was not enough on its own. I also had to understand engineering constraints, delivery mechanics, and team dynamics in much greater depth.

Building the team and its way of working

We formed the main team for the early real-time project in roughly two months. After that, we filled individual gaps and shaped our working practices around real delivery needs.

I looked beyond the technology list when hiring. Enterprise work requires people who can explain a decision, work with code they did not write, and negotiate across teams. A strong engineer who becomes the sole owner of critical knowledge is still a delivery risk.

The process evolved in the same way. We agreed how to make architecture decisions, where to record them, what “ready for development” meant, and who owned each integration dependency. Those rules only became useful once they answered problems the team actually had.

Estimating without pretending certainty

A lead’s early estimates are rarely precise. Delivery includes more than implementation: reviews, testing, environments, approvals, and dependencies all affect the date.

My working sequence is straightforward:

1. break the request into outcomes that can be checked;
2. state dependencies and assumptions separately;
3. review the estimate with the person doing the work;
4. decide what can be reduced without losing the purpose;
5. revise the plan when the facts change instead of defending an old number.

This does not make a forecast infallible. It does make the trade-offs visible to the business.

Learning to say no

A mature “no” does not reject the business need. It explains the consequence and asks for a priority decision.

If a new request moves an agreed release, the lead should show the connection and offer options: reduce scope, move other work, or change the date. “We will try” is comfortable in the meeting, but the team and the product pay for it later.

What happened next: a 2026 update

The early real-time product of 2023–2024 should not be confused with the new Decision Engine / SAS RTDM project.

I joined the new project as IT lead in late September 2024. By November I had formed the team. Development started in December, when I also became project director. We took the solution from the start of development to production in five months, from December 2024 to April 2025.

My scope expanded again in December 2025, when I became portfolio director and IT lead for the development cluster.

The move from analyst to IT lead, and later to project and portfolio management, was not a sequence of title changes. At every stage, the system I was accountable for became larger: first my own work, then a team, a project, and a portfolio.

---

An article drawn from the planned Analyst Days 2024 talk: the proposal was accepted, but the talk was never delivered. 20 October 2026 is the date of this revision; the exact original publication date has not been established.

Yours, DPUPP