The failure factory

Over ten years of working with startups in different countries and at different stages, I have seen some patterns repeat. One that is very common is founders or people at the helm aiming for little and planning many things. That's not a successful pattern; it will only create a "failure factory".

This pattern invariably ended with a stressed-out engineering team, complex code bases everyone feared to touch, and little actual growth.

What are we talking about?

I think what I have heard the most in those cases is, "we have to ship faster" or "we have to ship more". The backlog and roadmap looked like a long list of wishes from a 6-year-old in November. And those two lists covered many domains within the product.

Whoever was at the helm kept asking for all those to be done, all equally important in their eyes. The claim is that all those things are needed for the product to be successful. Yet, trying to do it all at once, the team is spread thin and unable to stay focused long enough to do the work properly.

Let's see four typical symptoms of this:

1. a culture of handoffs
2. no link to core metrics in what is being done
3. change happens in large batches
4. a culture of shiny objects

A culture of handoffs

The engineering team is severely isolated from the rest of the company, and feature requests come through one person or gate. They usually come in the shape of a ticket, more or less prepared, with designs ready to go. This can also include sketched-out implementation steps so that the developer handling the ticket must only follow the little dots.

Finally, once the work is "done", the developer or the team releases it but has no contact with customer support, customers, or anyone. Until a bug report comes through the gate, that is.

Just like on a factory line: the order is prepared by isolated individuals along the line without communication between them. They are not working together, the order is just passing through each one of their station until it's handed to the carrier.

It's worth noting that the example provided in the previous paragraphs is an extreme case of the culture of handoffs that can occur in feature factories. In reality, many organizations exhibit milder versions of this culture, with some good integration between customer support and engineering teams.

No link to core metrics in what is being done

While marketing and sales might have shiny dashboards, the engineering and product teams never rely on those for their work.  There is no way for engineers to know the impact of their work and if it matters.

There is no concept of the weekly number of sign-ups or how fast the first page or the cart is loading. What matters most for a product isn't heard about. On the contrary, what matters most to the managers is heard about plenty.

No concept of metrics used to track what matters and discussed throughout the team's debates and used to make decisions.

Change happens in large batches

With a big pressure to get things out through the door and complete, there is no consideration for incremental releases. The work is released in a large batch once it's considered complete.

No chance to test out an idea piece by piece, it's all or nothing. As no metrics are involved, "testing" the idea or knowing if the change brought out has any effect is anyway impossible.

A culture of shiny objects

As any work being done behind the curtains is not visible, there is a big emphasis on what everybody can see, such as releases.

Big gold chains and shiny stones make a significant impact on small minds. Personal, internal growth is invisible to the naked eye. So releases are the shiny objects preferred to keep the buzz going.

This pattern, shown through 12 signs those 4 are usually part of, is also described as "Feature Factory". See https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory

The impact

What can be the impact of those four symptoms?

Hand-offs culture

Without much say in anything, the engineering team will have low ownership of their work and low engagement. This will result in a high turnover and difficulty in hiring. Productivity likely will be low too.

No link to core metrics in what is being done

The team has no clue about the impact of their work and its purpose. This will also make it worse on the ownership and engagement levels.

Team members won't grow interested in participating in the whole chain of value in the product.

Change happens in large batches

With large batches of code released occasionally, there is a high risk of breakage of the product and conflicts with another piece of work being done.

Such changes are also more challenging to review. Bugs and incoherence in the design will slip through.

A culture of shiny objects

With releases being the only thing that matters, source code will start to rot, and the technical debt will grow. This will eventually slow the team down whenever they want to work on the code base.

Let's summarise

Some companies focus too much on delivering new features and maximizing productivity, leading to a culture of handoffs and big-batch releases prioritizing short-term gains over long-term stability.

This approach creates technical debt, low morale, and high turnover rates.

While extreme cases may require stopping everything, regrouping, and cleaning up, most issues can be addressed by identifying and resolving critical areas that require immediate attention. This may involve temporarily pausing non-essential projects or delegating them to other teams while the critical issues are resolved. It's also essential to involve all team members in the cleanup effort and create a culture of code ownership and shared responsibility.

In part 2 of this series, we will delve into more detail on building sustainable practices prioritizing long-term stability over short-term gains.