Tech Lead in a Broken Team? What You Need to Do First

Dev Leader Weekly 150

Jul 27, 2026

TL; DR:

Learn before changing the system
Clarify your authority and expectations
Automate recurring release pain incrementally

Tech Lead in a Broken Team? What You Need to Do First

Imagine stepping into your first tech lead role and discovering that every release needs four to six hours of manual testing. Old bugs keep coming back. Delivery dates seem disconnected from the engineering effort. The team is overloaded, and overtime is starting to feel like part of the plan.

Where do you even start?

My answer is not, “Walk in and fix everything.” You do not have enough context yet, and trying to change the whole system immediately is a great way to burn trust before you understand why the system behaves this way.

You need to learn, align, build relationships, and then create momentum with one measurable improvement at a time.

You can check out my full thoughts on this in the video below:

Do Not Start By Rewriting The Team

When you inherit a struggling project, the problems are usually obvious before the causes are.

You can see the long manual test cycle. You can see the regressions. You can see the exhausted engineers and the aggressive delivery dates. What you cannot see yet is how the team arrived there, which constraints are real, and which previous attempts have already failed.

So the first move is observation.

Map out:

How work enters the team.
Who decides what gets prioritized.
What “done” currently means.
Where releases slow down.
Which defects keep returning.
What engineers believe is causing the pain.
What product and management believe is causing the pain.

That does not mean you sit quietly for six months while everything burns. It means you avoid prescribing a solution before you can explain the system.

Your other immediate job is clarifying the role itself. “Tech lead” means wildly different things at different companies. Are you expected to make technical decisions? Can you push back on scope? Are you accountable for delivery? Are you coaching engineers? When should your manager step in?

Ask your manager directly. Keep asking as new situations come up. This is not a one-time onboarding question.

I also think your manager should not be surprised by the problems you are seeing. Share the observations, explain what you are trying, and be clear about where you need support.

Actionable Tip: bring your manager a short list of current risks, the evidence behind each one, and the first experiment you want to run. Ask which decisions you own and where they want to be involved.

Build A Working Relationship With Product

It is easy to walk into this situation and decide the product manager is the problem.

They keep pushing dates. Engineering keeps taking shortcuts. Quality drops. Therefore, product must not care about quality.

Maybe. But that conclusion is not especially useful, and you probably do not have enough information to make it anyway.

The product manager may be responding to customer commitments, revenue pressure, executive expectations, or information the engineering team does not have. At the same time, engineering may be carrying risks that product cannot see clearly.

That is exactly why you need the relationship.

There should be healthy tension between product and engineering. Product pushes for customer value and delivery. Engineering pushes for feasibility, sustainability, and quality. I have written about what happens when that healthy tension between product and engineering disappears.

Your goal is not to defeat the product manager. Your goal is to help both sides make better tradeoffs.

I have had working relationships change when schedules and responsibilities shifted. Even when I already knew the product manager, I still needed to make time to understand what they needed from me and how I could support them better. It is mutual. I want them helping engineering, and I need to help them succeed too.

Actionable Tip: set up a recurring conversation with your product partner. Ask what outcomes matter most, which dates are truly fixed, what risks they are carrying, and what engineering information would help them make better decisions.

Make Release Pain Visible

Four to six hours of manual testing before every release is a giant warning sign to me.

But you cannot simply delete that testing. The team is doing it because it catches defects. If you remove it without replacing the protection, you have not improved the process. You have just hidden the risk.

This is where the team needs to slow down enough to speed up.

Start by documenting every manual release check:

What behavior is being verified?
How long does the check take?
What defects has it caught?
Can that behavior be covered at a lower test level?
What is the smallest useful slice you can automate?

Do not wait for the perfect test architecture. If the code is tightly coupled and the only practical first step is a clunky behavioral test, write the clunky behavioral test. You can improve it later. The immediate goal is to stop the same regression from surprising you again.

Unit, integration, functional, and end-to-end tests all protect different boundaries. Understanding how unit testing and functional testing complement each other helps you avoid trying to solve every problem with one giant UI test suite.

I have lived this at a startup. We had enough technical debt that we needed UI-level behavioral tests before we could safely refactor parts of the application. A big chunk of that debt was mine, so I am not blaming anyone else. Those tests were not the final destination, but they gave us enough confidence to start changing the code underneath.

The manual release checklist should only get smaller. New regressions should produce new automated coverage, not another permanent item for a human to click through at release time.

Exploratory testing can still be valuable. Just do not make the hour before release the only time anyone explores the product. If you only look for surprises at the release gate, you will keep finding surprises at the release gate.

Dates And Engineering Effort Need An Honest Tradeoff

There is nothing inherently wrong with a fixed release date.

There is also nothing wrong with estimating a body of work and letting the date move.

The problem starts when scope and date are both treated as fixed while quality is expected to remain unchanged. Something has to move.

If a feature needs a month of engineering effort and somebody wants it in a week, you have a few honest choices:

Reduce the scope.
Move the date.
Take a deliberate shortcut and document the debt.
Do not build it.

What you cannot do is pretend that a month of work somehow became one week because everyone agreed the date was important.

This is where I strongly prefer smaller vertical slices. Ship one thin, working path through the feature. Let customers use it. Learn from the feedback. Then decide what deserves the next investment. Vertical slice development can help teams deliver useful value sooner without pretending the entire feature fits inside an impossible deadline.

Sometimes you will still choose debt. That can be a valid business decision, but only if everybody understands the cost. If you rush a feature into a shape that cannot support the next iteration, say that clearly. The next change must include paying down the shortcut.

Otherwise, “we will clean it up later” becomes the permanent operating model. That is why technical debt has to be balanced deliberately, not treated like invisible work engineering will somehow absorb.

Actionable Tip: when somebody asks for a fixed date, respond with the smallest scope the team can confidently deliver by that date. Make the excluded scope and any accepted debt explicit.

Overtime Cannot Be The Capacity Plan

If the plan only works when engineers repeatedly work extra hours, the plan does not work.

That does not mean overtime can never happen. Production incidents happen. Unexpected customer problems happen. Teams sometimes make short-term pushes.

But sustained overtime is not additional capacity. It is borrowing energy from future delivery, quality, and retention.

As the tech lead, do not quietly absorb the gap. Make capacity visible:

Here is what the team can complete safely.
Here is the work that does not fit.
Here is the quality risk if we force it in.
Here is the decision we need from product and management.

If the pressure is already affecting people, talking to your manager about burnout should happen before somebody reaches the point where they cannot keep going.

Pushing back is not refusing to deliver. Good pushback gives decision-makers a realistic set of tradeoffs.

Ownership Means Following Through

One of the most important parts of this role transition is realizing that agreement is not action.

You can explain the testing problem to the product manager. They can nod and say it sounds reasonable. Then everyone returns to the same priorities, and nothing changes.

That does not automatically mean they do not care. It probably means this improvement matters more to you than it does to them, so you need to drive it.

Pick one change. Give it an owner. Put time against it. Define what better looks like. Report the result.

For example:

Choose the ten most expensive manual release checks.
Automate one of them this iteration.
Require a regression test for every recurring defect.
Measure the release time and escaped defects.
Share the result with engineering, product, and your manager.
Repeat.

That first win matters. People support changes more easily when they can see that the change saved time, reduced risk, or made delivery more predictable.

You do not need to repair the entire organization in your first month. You need to understand the system, clarify your authority, build the relationships, and prove that one better way of working is possible.

Then do it again.

Dev Leader Weekly

Discussion about this post

Ready for more?