During the early stages of a company the focus is to move fast. It’s a matter of survival. The founders have probably left some lofty careers, the money is limited and the competition feels very threatening. In an environment like this, where speed is the name of the game, quality is not exactly the number one priority. To be honest, that’s the right approach. A mediocre product that’s in front of users now is better that a very well written that never sees the light of the day.

As the company grows though this strategy stops being a good one. Slowly but steadily the team has to go back and start fixing technical debt, but that’s challenging. The team has survived working a certain way, product work, most of the time, is still king. Product people want more features, developers want that too but in a pleasant technology stack. To achieve pleasant though you need to be slower in your product execution and that is a taboo conversation to have. How am I going to measure my value if not by new features?

Fast forward a few years, the size of the team is in the triple digits. The technical debt is a mountain. The developers start to complain, as their productivity is decreasing. Tensions are starting to appear too. The product people are pushy, the developers are slow. The other one is evil.

Why?

Leo Tolstoy said “All happy families are alike; each unhappy family is unhappy in its own way.”. In our case, every team is different but I feel that there are some common symptoms.

The first is about measuring performance. Especially the performance of product people. The easier way to measure their performance is by how many new features are delivered. New shinny design pushed out every developing cycle. That goes down to your developers that will oblige because most probably their performance is dependant on the same metric. Also, no one likes that guy that complains about technical debt, or maintaining existing features.

Confirmation bias is the second common theme to blame. By now you surround yourself with people that believe in what the company does. You are alike. You have your culture that it’s so precious and you need to keep intact. Some may say that the company is borderline a cult. The problem with cults is that there is fear. There is fear to open up and voice an opinion that is in direct contrast with the mainstream. So early signs of trouble, concerns and radical suggestions are getting lost. And everyone is losing.

How do you solve this?

There is no easy answer to this. The root of the problem is with the culture and the processes of the company, and these are hard things to change. You either need to identify these problems very early on, and tackle them, or wait for a tragedy to happen. Sometimes tragedies can make you stronger. Most of the times they will make you weird, others they will kill you. So don’t wait for a tragedy.

Building candour is another very important ingredient of the solution and it can definitely help, but it’s not enough. If the voices are isolated and people are not opening up whenever the opportunity arises nothing will happen. These voices will get alienated. For this to work the leadership team needs to give the example, as well as individual teams. Companies like Bridgewater Associates and their ex-CEO Ray Dalio are excellent examples of being open and raising your voice.

In more practical terms, we as developers shouldn’t passively wait for things to change. More often than not, people need to just understand what’s the impact of indecision and inactivity on the technical aspect of a product. Helping them understand that technical excellence, along with good design, is what makes a quality product is very important. To achieve that simple steps like pairing to do a task, going through your train of thought, debugging an issue or making them write some code goes a long way. People are rarely evil. We are all trying to do our best in our realm of understanding. Try to expand your and their realm.

Quality = Technical excellence + Great design.

An other excellent solution is data. Conduct A/B experiments of small parts of your product where in one instance you have reworked a feature to be super performant, and in the other instance put the same feature prior to the improvement. Measure the user satisfaction, present your findings. You’ll be more successful if you tie these findings with KPIs like conversion, retention, satisfaction or whatever else you care the most.

Finally you need to remember that not all fights can be won. You might need to accept a strategic defeat and move on. One swallow doesn’t make a summer.