You have just taken over a new tech team. There is pressure to deliver, not much signal, and everything feels urgent. Perhaps the roadmap is packed. Perhaps the team seems busy. But is anything really working?
This is your field manual. If you are overwhelmed and trying to get clarity, start here.
Step 1: Find the Signal
There are only two things you really need to understand:
1. How quickly can the team deliver a change to get customer feedback?
This is cycle time. It is your single clearest indicator of team health. If you ask for a trivial, non-urgent change today, how long does it take to reach customers?
Strong teams: minutes to hours. Troubled teams: weeks to months.
If the answer is more than a few days, that is your first clue. Nothing else matters if the team cannot deliver.
2. Is the team improving how they work?
This is continuous improvement. Is the team regularly reflecting, adjusting, and trying new things?
Consider these points:
- When was the last retrospective meeting?
- What changes emerged from it?
- How visible are those improvements?
Without this loop, problems pile up and the team stagnates, even if delivery looks acceptable on paper.
Step 2: Use These Questions to Go Deeper
These are not diagnostic checkboxes. They are prompts to spark real conversations.
How is work tested?
Are there automated tests? Who writes them: developers, QA, both? Can the team refactor safely?
Is QA involved early?
Do testers help shape stories, or just validate finished work? Are edge cases discussed upfront?
Is there a product vision?
Can anyone on the team tell you what the product is really for? Is there a clear, shared understanding of priorities?
Who owns decisions?
Do developers feel empowered to shape solutions? Does the Product Manager lead with context or just assign tasks?
Is the team cross-functional?
Are engineers, testers, designers and product all part of the same team? Do they feel accountable together for outcomes?
How long are planning meetings?
Is planning quick and adaptive, or bloated and theatrical?
Does the team use story points?
If so, do they help, or create more confusion? Can you simplify with time-based estimates (for example days/weeks) instead?
Step 3: Act
You do not need to fix everything at once. Just start here:
- Measure cycle time. If the team does not know how quickly they can deliver, track it over a few weeks.
- Join the next retrospective. Watch. Listen. Ask if anything changed since the last one.
- Pick one question from the list above. Use it to spark a conversation.
Improving team performance does not start with a framework. It starts with seeing clearly.