Tech Lead: A New Challenge for the Analyst

October 2023. I'm told: "Build a team from scratch — new initiative, a configurator for personalized offers." For several years I'd been growing on the Mirion graph platform — from senior analyst to IT lead, living through the merger of the Big Data application-services teams. And now — a blank sheet: no people, no architecture, no processes. The first thing I do is open my work messenger and write to my manager: "Got it. Starting to hire." The second thing I do is close the messenger and stare silently at the monitor for ten minutes, realizing that none of my analyst experience prepared me for this.

I'm an analyst. Or rather — I was an analyst. And now I have to assemble a development team from scratch and lead it. I prepared this story for Analyst Days 2024: how an analyst first becomes an IT lead, and then a cluster manager. No sugar-coating — with the botched interviews, the wildly off estimates, and the first honest "no" to a stakeholder.

The Fork You Don't See

An analyst who has outgrown the "write the spec" level — what's next? I know at least six directions, and each one breaks your habitual way of thinking in its own way:

Direction	Focus	What to build up
Product Manager	Market, metrics	Business strategy, unit economics
Product Owner	Backlog, priorities	Scrum, stakeholder management
Tech Lead	Team, architecture	Code, CI/CD, people management
Architect	System design	Integrations, NFRs, patterns
Account Manager	Client, contract	Negotiation, finance
Consultant	Expertise, methodology	Public speaking, frameworks

Most analysts don't even consider the technical branch. It seems like you need a computer science degree behind you and ten years of dev experience. That's a myth, and I'm living proof.

Why Tech Lead Specifically

My path was nonlinear. I knew the full development cycle not from books but from practice — I automated things myself, deployed them myself, debugged them myself. I worked with data at Nestlé, built data quality processes at Kerama Marazzi, then became a lead analyst at VTB. At every stage I dug deeper than the role required: where an analyst usually stops at the process diagram, I went to see what was happening in the code.

An analyst sees the product through the eyes of the business. A developer — through the eyes of the code. A Tech Lead has to see through both at once. If you came up through analysis, your business eye is already trained. All that's left is to build up the technical one. That's easier than a developer learning to understand the business — I've confirmed it on my own experience.

Building from Scratch: Five Months of Pain

From October to February — five months of nonstop hiring and dozens of interviews.

The first two candidates — perfect résumés. Senior developers with enterprise experience. In the interview both answered by the book. I was thrilled, until I asked one question: "Tell me about a time you disagreed with a team decision. What did you do?" The first replied: "I do what I'm told." The second: "I usually work alone, I'm more productive that way." Both were technically strong. I turned both down.

The worst interview — a candidate who lied about his experience with graph databases. I figured it out in the third minute of a technical question, but I ran the interview to the end out of politeness. Then I spent an hour angry at myself for the wasted time. Since then I made it a rule: if within five minutes I realize someone isn't a fit, I say so honestly and wrap up. Respect for other people's time beats social comfort.

The moment the team "clicked" — January. By then a core of four people had come together. We sat down to discuss the architecture of the graph platform, and for the first time in three months I felt that I wasn't dragging the process along alone. People argued with each other, proposed alternatives, built on each other's ideas. They weren't nodding — they were thinking. That was the moment I understood: there is a team.

The main lesson of hiring: building a team isn't about "hiring the best." It's about "hiring the ones who'll work together." (More on the patterns I learned to spot in interviews — in red flags in hiring.) A star developer who can't communicate will destroy a team faster than he creates value.

The Skills I Didn't Have

Moving into a leadership role exposed gaps I hadn't noticed as an analyst. I'll list them honestly — not for a nice narrative of "I learned it all," but because knowing the specific gaps saves months for anyone who walks this path.

CI/CD nuances. I knew a pipeline existed, I knew its stages. But when a developer comes to you asking why the build fails at a specific stage — you have to dig in at the configuration level. Not fix it yourself, but understand what's going on — that's mandatory. My first month I spent evenings studying Jenkins and GitLab CI configs so I wouldn't look like an idiot at the morning standups.

The depth of code review. Glancing at a pull request and actually reviewing code are different planets. At first I missed architectural problems, catching only stylistic ones — bad variable names, missing comments. The serious stuff — leaky abstractions, SOLID violations, inefficient queries — slipped right past. I had to develop an eye for it: read other people's code systematically, ask myself "and what happens if the load grows tenfold?" on every merge request.

Estimating tasks. An analyst estimates his own work — one variable. A lead estimates the team's work — a system of equations. Dependencies, parallelism, risks, technical debt. My first estimates were monstrously inaccurate. For one task I budgeted a week — it took three. For another — three days, it took two weeks. Over time I worked out an approach:

1. Decompose down to tasks no bigger than three days — at that level the error is predictable
2. Add a 20–30% buffer for integration surprises
3. Account for the "invisible" tasks: code review, deployment, sign-offs, sick days
4. Check the estimate with whoever will do the work — a lead always estimates worse than the doer

The Ability to Say No

This deserves its own section, because "no" is the most underrated skill a manager has.

A concrete case. The business comes with a task: they need a new report in the decision-making system. Urgently. "By Friday." It's Tuesday. I look at the backlog — the team is loaded a sprint ahead, one developer is out sick. The old me, the people-pleasing analyst, would have said "we'll try." The new me says: "No. If we squeeze this into the current sprint, we push the platform release back two weeks. Let's talk it through: is this report more important than the release?"

The stakeholder wasn't happy, of course. But once I showed the dependencies on the board — the specific tasks that would have to be moved, the specific risks — the conversation turned constructive. The report went into the next sprint. The release shipped on time. And from then on the stakeholder came not with "I need it by Friday," but with "what are your nearest open windows?"

Every "yes" given without weighing the consequences is a debt that piles up. The team burns out, quality drops, technical debt grows. A leader who can't say "no" isn't a leader — he's a buffer between the business and the team. A single-use buffer, at that.

Retention: How Not to Lose the People You Spent Five Months Assembling

When the market is stormy, competitors are poaching, and corporate processes are grinding you down — retaining your key people becomes priority number one. Losing them after five months of hiring is unthinkable.

The first thing that worked — a competency matrix. Not a formal little table for HR, but a working tool we discussed at every one-on-one:

Competency	Now	Target	How to build it up
System Design	low	high	Architecture reviews
Kafka, streaming	medium	high	A dedicated task in the sprint
SQL optimization	high	high	Maintain the level
Mentoring	low	medium	Onboarding a newcomer

Everyone sees their own profile: where they're strong, where to grow, which tasks in the upcoming sprints will help close the gaps. When a person sees a development trajectory, they have fewer reasons to go looking for one elsewhere.

The second — transparency. I didn't hide the project's difficulties from the team. When people understand the context of decisions, they accept hardships as part of the work rather than as the boss's arbitrary whim. "We're taking this task because without it we won't pass the audit" lands very differently from "we're taking it because I decided so."

The third — task rotation. A developer who spent six months grinding on nothing but ETL gets an API task. Slower in the moment, but it holds their interest and broadens their expertise. A person who's bored already has one foot in an interview at another company.

The result: in the hardest quarter, we didn't lose a single key developer.

The Career Paradox

The irony: analytical skills are the best preparation for a leadership role, but analysts don't know it. The ability to decompose a problem, ask the right questions, see the whole system — that's the core of both professions.

The difference is in scale:

Skill	Analyst	Tech Lead
Decomposition	Requirements and user stories	Strategy and roadmap
Questions	To stakeholders	To yourself and the team
Systems view	The product	People + processes + technology
Communication	Business ↔ Development	Team ↔ Management ↔ Business
Responsibility	For a document	For the team's outcome

What I'd Do Differently

If I could go back to that October and give myself three pieces of advice:

Hire slower. I rushed to close positions because a deadline was breathing down my neck. Because of that rush I had to part ways with one person after two months — he didn't fit. That's more painful and more expensive than waiting an extra month.

Ask for help sooner. For the first two months I tried to figure everything out myself — CI/CD, architecture, processes. Out of pride. Until I realized that asking a fellow team lead for advice isn't weakness — it's a normal working tool.

Don't drop technical practice. When you plunge into management, your hands stop writing code. And then, at code review, you can't give proper feedback because you've fallen behind the stack. You have to carve out time for technical tasks, even if it's two hours a week.

The path from analyst to development cluster manager isn't a promotion. It's a change of profession. You lose the superpower of the expert and gain the superpower of the multiplier: everything you can do now works through other people. And the product you're doing it all for — a realtime system with minimal latency — won't get built without that transformation.

It's scary, unfamiliar, and sometimes lonely. But if you want to influence not documents but a product and people — I don't know any other path.

If you're on the path from analyst to tech lead yourself and want to accelerate your growth — I do mentoring precisely for transitions like this.

---

Based on a talk for Analyst Days 2024 that never happened — the proposal was accepted, but the presentation didn't take place for lack of time to prepare it. This piece is written from that same experience.

Yours, DPUPP