If you are looking for excuses as to why development is delayed in your case, you are in the wrong place. However, if your motivation is different and you want to understand the most common root causes, I can help you.

Before we start exploring different aspects, there is one point I would like to emphasize. I don't believe in a strict boundary between technology and business. Instead, I see them as a tandem, working together towards success. Whenever we create a gap between these two aspects, we risk failure.

If you are a startup founder, you are part of your tech team. Similarly, if you are a tech team member, you are part of the startup.

With that said, let's explore what causes the return on investment (ROI) in software to decrease.

As I said, we are not looking for excuses, but focusing on ourselves and what we can improve. That’s why I will intentionally skip external aspects, such as blockers from third parties.

1. Not understanding what effect we count on

It is important to understand that software outsourcing does not define a legal partnership between two parties. Software is outsourced when there is no constant communication among those who define business goals, those who explore how to achieve them, and those who actually build the software solution. This lack of understanding limits the range within which the team operates. Setting expectations that the team is supposed to build X also limits their thinking. While they may build what is expected, there is a missed opportunity to build it simpler, faster, and cheaper.

How to recognize symptoms?

• Developers don't understand why they are building a feature.
• The Product Owner communicates that a feature is needed because Stakeholders want it.
• There is a high dependency on the Founder, and the team gets stuck in their absence.

Where the delay is generated?

Not thinking about the expected outcome frames thinking of the team around the given solution. The team is unable to decide what is crucial in the scope and what can be postponed. This makes them build the solution as it was designed in the first place, and trust me, you are not able to predict all the consequences of introducing changes beforehand. Things pop up and it’s hard to decide if we should tackle them or work around them because we don’t know how it will affect the expected result.

How to fight that back?

We have to accept that things will pop up. The only way to make us resilient in those situations is to keep an eye on the goal. Be able to decide quickly - how this affects our goal, what's the effort investment, is there any other smarter way to achieve the same effect.

To get back to the root cause, the team needs to understand what we aim to achieve both on the business and product levels. Technology should follow our goals, not the other way around.

A good practice here is to use a hypothesis in communication. For instance, if we build Z, Product Metric Y will increase by about 10%, which will help us achieve our business goal X.

2. Slow feedback loops

Leaving a team alone for weeks or months so they can develop "what's needed" is not the best approach. It's not because they will get lazy, but because we cut them off from feedback loops. Without constant feedback, it’s difficult for the team to be sure they are building the right things. The days of developing software strictly according to the specification are over. Specifications become outdated very quickly, and the modern approach is to validate ideas quickly. However, to validate ideas, we need feedback loops.

How to recognize symptoms?

• Deliverables are not discussed on a weekly basis
• Founder/Stakeholders are not present
• There is no one who supports the team as the domain expert

Where the delay is generated?

Users are the best source of feedback, but startups may not have users yet. In this case, domain specialists (often the founder) or focus groups can be used as a workaround. Delaying feedback can force the team to redo work, causing distractions and slowing down progress.

How to fight back?

If you have the ability to connect the tech team to the users, you are halfway there. The tech team should be able to validate what they deliver on a weekly basis, at all levels: concept, design, and ready-to-test solutions. If they can't, the founder can bridge that gap and use their domain knowledge. One thing is for sure, the tech team needs to be structured in a way that allows them to deliver things to be validated each week.

3. Team performance

Building a team is not just about hiring specialists. There are various aspects that determine whether the team meets expectations or not, not to mention high-performing teams that can deliver 2 or 3 times more compared to groups that don't even work as a team. The team needs to be aware of how they are doing and reflect on their performance.

How to recognize symptoms?

• The team is not able to spot weaker periods
• There is no discussion about how the team is doing
• Stakeholders are not aware of what the team is dealing with

Where the delay is generated?

A team that does not reflect on their work is unable to assess their performance and adapt to changing circumstances. They may continue to work as they always have, ignoring new constraints. In larger teams, it's easy for underperforming individuals to go unnoticed and bring down the entire team. Constantly changing requirements can also put a lot of stress on the team, causing different reactions from team members. Some may throw themselves into work, while others may feel paralyzed. Without special attention paid to these issues, the whole team can become demotivated and lost in their work.

How to fight back?

To ensure the team's performance is on track, we need feedback loops. Simple metrics like DORA, burn-down charts, and velocity can help us spot signals that something is happening. However, for me, the most powerful tool is to conduct retrospectives about how we work and expose problems to the team. I find it very useful to involve all stakeholders in retrospectives to bring their perspectives about how they perceive team performance.

What aspects should we look at? I think the most important is: Are we meeting expectations? If not, why? What do we have to improve? Are we delivering on quality and time?

In this aspect, the Team Leader plays a crucial role. They must create an environment in which the team knows exactly how they are doing and help the team become the best version of themselves.