Senior developer or tech lead: who is actually responsible for code quality in your team?

A situation that plays out in many software teams, in one form or another. The application keeps breaking in places nobody touched. The manager notices that some developers write tests and others do not, and turns to the most experienced person in the room: “You are the senior. Make sure everyone writes tests.”

The senior replies that they are happy to help, but that deciding what colleagues must do is not their call. The manager hears “not my job”. The senior hears “you are now responsible for other people’s work, without any authority over it”. Both leave the conversation frustrated, and nothing changes.

The problem is rarely the people. It is a role nobody defined. This article is for the person who can define it: the owner, the CTO, or the head of development.

Two different jobs with similar names

A senior developer is defined by technical depth: solving hard problems, making good design decisions, reviewing code, helping colleagues grow. Their influence comes from expertise. They can propose, explain and show, but colleagues are not obliged to follow.

A tech lead is defined by responsibility for how the team builds software: which standards apply, how code is reviewed, which technical debt gets paid off, and what happens when someone ignores an agreed rule. Their influence comes from a mandate given by management.

The same person can do both, and often does. But the second job does not come automatically with the first. It has to be given, and the team has to know it was given.

The question that reveals the gap

Ask one question about any standard in your team: what happens when a developer does not follow it?

• If the answer is “the tech lead raises it, and if needed it goes to management”, the standard has an owner.
• If the answer is “the senior should talk to them”, ask what the senior can actually do if the colleague says no. Usually: nothing, except escalate, which turns a colleague into a supervisor nobody appointed.
• If the answer is a shrug, the standard is a wish.

Who does what

A simple way to make it clear: for each kind of decision, write down who proposes, who decides, who makes it happen, and who deals with it when it is ignored.

Decision	Proposes	Decides	Makes it happen	When it is ignored
“New code needs automated tests”	Senior or tech lead	Tech lead, with management’s support	The whole team, with help from the senior	Tech lead, then management
How code review works	Tech lead	Tech lead	Everyone	Tech lead
Architecture of a new feature	Senior developer	Tech lead	The developers on the feature	Tech lead
Which technical debt to pay off this quarter	Tech lead	Management, on the tech lead’s advice	The team	Management
Priorities between features	Product owner or management	Management	The team	Management
Helping a colleague who is stuck	Anyone	Nobody needs to	The senior	Not applicable

If the “decides” column says “the senior” for things that affect other people’s work, and nobody in management has said so out loud, that is where the friction comes from.

What is reasonable to expect from a senior without a mandate

Situation	Reasonable to expect	Not reasonable to expect
Tests are missing	Point it out and propose a solution	Make colleagues write them
A colleague asks how to write a test	Show them	Check everyone’s work every day
The team needs a standard	Draft it and explain it	Decide it on everyone’s behalf
Someone ignores the standard	Mention it, once	Discipline them
A risky design is being built	Raise the concern with arguments	Block it alone

A good senior raises the quality of a team through example, review and help. Asking them to enforce rules on peers, without anyone saying they may, damages exactly the relationships that make that influence work.

Signs that the role is missing

You do not need an audit to see it. If three or more of these sound familiar, nobody really owns technical quality in your team:

• Every developer has their own idea of what “done” means.
• Code review happens when someone has time, and approving is mostly a formality.
• The same argument about tests or structure comes back every few months, and ends without a decision.
• Your most experienced developer is frustrated, and you are not sure why.
• Bugs that reach customers are discussed as bad luck rather than as a gap in the process.
• When you ask “who decided this?” about a technical choice, the answer is “it just happened”.

None of these is a disaster on its own. Together, they mean the team pays every day for a decision nobody has made: who sets the rules.

The one-page mandate

If you want someone to own technical quality, write it down. It does not need to be long. A page like this, agreed with the person and announced to the team, removes most of the confusion:

The last two lines matter most. Without the escalation path, the lead has responsibility without authority. Without time, the role becomes unpaid overtime, and the best developer slowly stops being one.

Three ways to set it up

• Name a tech lead inside the team. Usually the right answer for an established team with an experienced senior who wants the role. Give them the mandate and the time, and announce it.
• Make it a shared team agreement. For small teams, the standards can be agreed together and written down, and management handles exceptions. Nobody polices anybody; the rule belongs to everyone.
• Bring in an external senior for a defined period. When nobody inside wants the role, or the team is young, an experienced outsider can set up the standards, the tests and the review process, with a mandate from management, and hand it over to someone in the team. More on how that works day to day is in our article on what to do while you look for a senior .NET developer.

The conversation, without the misunderstanding

For managers, a better way to start than “make sure everyone writes tests”:

“I want automated tests to become standard for new code. Would you draft the rules and help the team adopt them? I will announce that they apply to everyone, and I will handle it if someone does not follow them.”

For seniors, a better answer than “that is not my job”:

“I am glad to define the standard and help everyone adopt it. Can we agree that it is an official rule for the team, and who deals with it when it is not followed?”

Both versions say the same thing as the original conversation. The difference is that responsibility and authority end up in the same place.

Why it matters for the business

Code quality is not a developer hobby. Missing tests and inconsistent standards show up as bugs in production, as features that take longer every year, and as systems only one person dares to touch. Our article on technical debt and slow development shows how that builds up.

Most of it is preventable, but only when someone is clearly responsible for preventing it, and has been told so.

It is also one of the most common reasons good people leave: responsibility without authority wears them down. More on that in why senior developers leave.

Questions we hear most

Is every senior developer expected to become a tech lead?

No. Many excellent seniors prefer to go deep technically and have no interest in leading. Both paths are valuable. Forcing the second one on someone usually costs you a good developer and gains you a reluctant lead.

Our team has five developers. Do we need a tech lead at all?

You need someone who owns the technical standards, even if it is a few hours a week. In small teams, a shared agreement and a manager who backs it are often enough.

Should the tech lead be paid more?

If the role takes real time and real responsibility, yes, in salary or in clearly reduced other work. A mandate without time or recognition does not last.

Can an external developer have this role?

For a defined period, yes, and it often works well: an outsider has no history in the team’s internal politics. The mandate has to come from management, and the goal should be to hand the role over to someone in the team.

How we work

ProCoding is a .NET studio in Split, Croatia. Besides development, we often help teams set up the technical side of working together: coding standards, automated tests, code review and the handover of knowledge, always with a clear mandate from management and with the aim of leaving it with your team. As a monthly block of days, or with a freelance .NET developer inside your team. The first step is a free 30-minute call.

Sources

• The standard of code review, Google Engineering Practices