We see teams blindly following Scrum, Kanban, or the Spotify model and introducing roles into teams (such as a Site Reliability Engineer) because other companies blogged about it. These models and roles are created because of specific struggles these companies faced.

While all these processes thus contain valid solutions to these problems, your company might not face the same problems at all. Which means: following these processes adds overhead without providing any value. Blindly copying processes never leads to reaching the same results.

As a software engineer, I’ve personally felt the pain of following these rigid processes. While working in teams that fell into this trap, it is difficult to realise a productive way of working. This is often frustrating to members of the team. We’ve managed to help these companies become a lot more efficient by providing a better way of working.

Related: guide teams to a better way of working

What to steal from Spotify or Netflix?

The thing we should instead steal from companies that come up with these new models, such as Spotify, Netflix, or Google, is the culture of self-improvement. The fact that they became big using such unique ways of working is not because of these processes, but because they continuously challenge themselves. Being self-critical, experimenting with potential improvements to your processes and critically evaluating them is how efficient teams are born.

How efficient teams are born

There are a few things you can work on as a team to adopt this culture of self-improvement and experimentation. First of all, it is important to become aware of the problems you are facing as a team. A common way of tackling this is by introducing retrospectives where you’ll look back as a team on what went well and what went wrong.

It is important to keep these retrospectives as a safe place to constructively work together so that everyone on the team dares to bring up the issues they are facing. This reflection can then become part of the culture and be continuously applied, also outside of these meetings.

Once you’re aware of the pain points in your team and organization, you can start thinking about how you can take them away. A common thing to do is choosing one or two experiments every retrospective that can be tested out. Ideas for these experiments can be taken from what the big players like Spotify and Google do, but blindly copying without an evaluation step is where it most often goes wrong.

What’s often forgotten is that it is important to evaluate these experiments and decide as a team if you want to continue with it or not. But how do you evaluate them? A good way to do this is to not only look at the improvement but also if it affects the “what went well” items that came out of the retrospectives. The advantages should be weighed against the potential negative side effects to see if it’s there to stay.

Related: how efficient is pair programming for your team?

“Find the simplest thing you could try to improve on, try it for a short time, and evaluate.”

— Mathias Verraes

Measuring team performance and efficiency

At madewithlove, we try to avoid measuring performance or efficiency in a quantitative way. If there is enough trust, the need for measured performance should vanish, so we’d rather focus on creating trust. Adding performance metrics works counter-productively here because it does not give a team the feeling that it is trusted.

Trust usually builds up if a team can be transparent on progress. This can be done by changing your process towards short release cycles, creating clear priorities and goals, and communicating regular updates from the product team to the rest of the company. Having these processes well-documented so that other departments can understand what to expect from a product team can also help to build company-wide trust.

If you’re looking into measuring performance and efficiency of teams anyway, one way to do so is by keeping track of customer satisfaction. The end goal of your teams is to produce customer value anyway, so if your customers are happy, this probably means the engineering and product teams are doing a good job.

If you want to measure the efficiency of processes themselves, it’s also interesting to look into the enthusiasm of the team members about the process. If processes are helping your team to go forward, people within a team tend to become passionate about them really quickly. Remember measuring performance might show a problem but not the root cause.

“The role of a creative leader is not to have all the ideas; it’s to create a culture where everyone can have ideas and feel that they’re valued.”

— Ken Robinson

The efficiency of an engineering team also directly correlates with the quality of the information they get to work with. Some information is required to provide a good solution such as clear problems to solve with a realistic time budget to solve them, access to stakeholders, and efficient ways of reviewing scope. You will never achieve efficiency if you throw questions with deadlines over the wall to the dev team and then expect them to just build it.

Read this if you want to read more about seniority in software engineering.

Are you ready to make your processes your own?

It’s nice to look up to companies that are doing well and following their examples, but let’s try to avoid falling into the trap of copying processes. It is time for each team to take processes into their own hands and shape them to the problems they are actually facing. Go ahead, bring your team together, and experiment. I’m sure it will make your teams thrive.

Need advice on how to hire a good CTO for your startup? This great post will get you started.