Why I Will Never Be a Team Lead Again

I want to share my experience as a development team lead at a major bank, where traditional management approaches sometimes contradicted common sense. This is a subjective view of a real situation.

Career Path to Team Lead

My career began in the late 2000s as a network administrator while studying at university. Then came positions in development, DevOps, pipelines, and mobile development with Xamarin at regional companies.

After joining a fintech company — a major bank with higher salaries — I started mastering both DevOps and enterprise development. I noticed that my managers seemed lazy and lacking initiative, so I decided I could do better.

I quickly rose within the team, taking on the work of the lead who was happy to delegate responsibility. I was essentially building the entire team's workflow. My efforts were rewarded with top ratings and a bonus of nearly six salaries.

A New Project and the "Perfect Start"

I received an offer several levels above my position and agreed to build a team from scratch to deliver a client-facing product as part of a global transformation at another major bank. I brought experience with three different teams, plus knowledge of Agile, development, DevOps, and architecture.

My team:

• Development: 3 people
• Testing: 2 people
• Analysts: 2 people
• Mobile development: 2 people
• Frontend: 2 people
• Product owner, business analyst, and designer

The neighboring team (for comparison):

• Development: 8 people
• Testing: 6 people
• Analysts: 6 people
• Mobile development: 2 people
• Frontend: 6 people
• Product owner, business analyst, and designer

The neighboring team's lead I'll call "Zinochka" (a fictional name).

Setting Up Processes

The first thing I did was establish the workflow:

• Daily standups with cameras on, mandatory
• Strict time limits, cutting off long dialogues
• The team ran 15-minute dailies without sacrificing quality
• Analytics templates
• Bitbucket configured for pull request analysis
• Sonar integration
• Branch separation via GitFlow for different environments
• Demos, retrospectives, planning sessions, 1-on-1s, individual development plans, star maps

I started every standup by reporting on my own completed work and how I helped the team. In my experience, no other lead had ever done this.

MVP Results

The MVP deadline was 6 months. The team finished in 5, cutting most unnecessary features, aligning priorities with the business, and focusing on stress-testing the system's core pipelines. Despite minor hiccups, the project was delivered on time and the team earned recognition.

Problem 1: Exhaustion Without Visible Results

After the initial success, routine work began. I hit the first critical problem of being a lead: 8-10 hours of meetings per day.

I saw my primary role as being a "shield from the garbage" for the team — protecting developers from a flood of urgent tasks, political games, and pressure. This led to endless meetings, shouting matches, escalations, and attempts to cram tasks into the backlog that were either thrown out a week later or turned out to be unnecessary.

During standups it became increasingly difficult for me to report on anything of real value, and a depressive state set in: "You supposedly sat at the computer from 9 to 9, you're incredibly tired, but you accomplished nothing... How is that possible?"

Additional difficulty came from the product owner, who loved talking about tasks and complaining about life — and there was no stopping her.

Problem 2: Always the Scapegoat — The Amorality of the System

When urgent tasks landed — ones that genuinely required immediate action because someone had forgotten to communicate them on time — I proposed documenting the technical debt and explaining why the team couldn't keep up.

My boss responded: "Just do it like Zinochka. She sat a developer down to pull handles and manually feed data." I refused, suggesting we tell the truth. But my boss insisted that the lead should lie upward while he himself "only told the truth."

"Here's the truth. If you want to lie to the higher-ups, do it yourself, but I won't" — that was my position, which created a conflict.

Problem 3: Transparency Loses to the "Right" Approach

Two teams were building similar solutions but in different ways. My developers focused on clean code, modularity, and reusability. The neighboring team wrote spaghetti code without a single comment, which created nightmarish problems with even minimal code changes.

The neighboring team was "laying the groundwork to become irreplaceable employees." They barely worked on weekends, but would come in for double pay "basically every weekend" and generated "an incredible level of noise about their suffering."

Code quality was far from the only problem. While I chose to be the "shield," Zinochka chose to be a "sycophant." She lacked technical competence, so she spent her time spreading rumors and engaging in other "not very IT-related activities."

Zinochka's team constantly pivoted to the business's momentary demands: "today we're building feature A, tomorrow feature B, the day after we roll back feature A because integration isn't ready, and feature C needs to go to production today."

The volume of tasks was similar, but "because of our approach to process and development, we were relaxed while they were working like slaves."

When the workload grew and I asked for more people, my boss said that Zinochka "writes all the code herself" and couldn't understand "why you even need developers." When I tried to demonstrate our code quality, it turned out that "the most we could reuse here was the open firewall rules."

I couldn't prove anything because "it's hard to prove something to a person who doesn't want to listen."

Problem 4: People Are Complicated

As the load grew, I tried doing analytics myself, fixing bugs, reviewing pull requests, and "plugging holes with my own body wherever things were thin." I started seeing my child far less often, was sick almost constantly, but kept thinking "I'll just close this quarterly goal with the team, and then when there's time we'll do the refactoring."

The critical moment came during a call when a systems analyst declared: "I'm not going to do this task, it's complicated." When I offered to help and work through it together, the analyst simply left the Zoom call and told me where to go.

When I tried to discuss the situation, the analyst responded: "I'm not in the right headspace to talk to you." My first thought was that she had personal problems, but it turned out she simply didn't want to do a difficult task.

Only after reminding her that I was, in fact, her manager and could fire her was the task picked up.

The core of the problem: your team is made up of people. Very different people. And while as a developer you can limit your communication to pull requests and emails, as a lead you're forced to solve all the team's problems, often swallowing your own pride. Firing and quickly replacing someone is usually not an option.

How It All Ended

It ended "magnificently": despite achievements and never missing quarterly goals, in April 2022 — during COVID — while running a 40°C fever (and still attending work meetings), I was asked to write a resignation letter.

The reason: Zinochka said I was "a very bad person and generally toxic, ruining the tribe's atmosphere."

Evidence? My boss didn't even talk to the team or gather their opinions. "Thanks for shipping the product and two years of work, off you go. For your contributions, you can take the two months of accumulated vacation to look for another job."

I hoped that after my departure, the team would scatter, the project would shut down, and Zinochka would be fired. But "not even close": the team missed a couple of quarterly goals, the product owner made a snide remark at a standup — "too bad USERNAME isn't here, we could blame everything on him" — and everything continued as before.

Conclusion and Recommendation

With the benefit of experience now working as an architect, I can now spot people like Zinochka from a mile away — they are very dangerous people.

My advice to readers: if you want to grow but fundamentally refuse to lie, suck up, spread gossip and intrigue, throw your team under the bus instead of yourself, and generally not give a damn — then you're better off going into architecture after gaining experience in development, analytics, DevOps, and mobile.

There are few architects who come from systems analysis backgrounds with strong technical skills, and that background helps enormously in building thoughtful, elegant architecture. You have a tangible influence on the final result, and the Zinochkas of the world don't interfere with your work or bother you much. Win-win.