How To Get Clarity With a New Tech Team
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.
More articles
Why Time Units Beat Story Points Every Time
Story points, t-shirt sizes, and fibonacci numbers. We have created an entire vocabulary to avoid saying what we actually mean. The truth is simpler: we should just use time units.
This realisation emerged from years of watching teams struggle with abstract estimation systems. The solution was right in front of us all along.
Your Code Is A Liability
Every chunk of code you commit is more for someone else to read, digest and understand.
Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.
Every line you add limits your project’s responsiveness to change.
Your code is a liability. Never forget this.
Read moreAlways Be Unblocking
The most impactful engineers I know do not just write code. They remove obstacles for others.
Your impact is not measured by the code you write. It is measured by how much faster your entire team moves because of you. At Cherrypick, we call this “always be unblocking” and it has become one of our core values.
How To Avoid Bad Startup Culture
If you are not paying attention to your startup culture, I have news for you: you are already building a culture into your company. Chances are that is not the culture you want.
Every company has a culture. It is a summation of all the habits and practices that make up the work. It is every choice, good or bad, made by every person involved. Every action sets a precedent, a “how we do things here.”
This is how we are wired. We are naturally social beings and are strongly predisposed to fit in to the group we find ourselves in, and to emulate their behaviour. This reinforces culture further, and compounds when more people are involved.
A culture grows like plants in a garden. You cannot stop the life from growing, but you can decide how and where it grows. Left unattended, weeds will grow alongside the flowers. The key is recognising this and putting in the work to shape it.
Here is a quick primer on how to do the minimum to avoid bad culture, and how to get good culture going with a little attention every so often.
Read moreThe Job Is Not To Build
Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.
Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.
You might do this through building software, but you might not need to.
Here is a story of how I did this wrong, and how you can do it right.
Read more