The iZettle Example: Decentralized Tech Development in Practice

Written by Michael Gothe originally published in Crisp

Don’t stand in the way of great employees. 

That’s one of the operational mantras that guide the finance technology company iZettle.
Two others are “Keep the startup spirit strong” and “Stay adaptable to changing market needs.”

In this blog post, we share some of the things we are implementing and tweaking at iZettle to keep producing great results and attracting in-demand, talented developers. My role has been to assist the tech development organization in making this work.

(Another blog post coming soon will cover the transformation of making the whole company agile, while this post focus on the practices that are put in place to keep a high performing, decentralized tech development organization at iZettle.)

Let’s begin by facing the reality of fast-growing startups.

DevOps

The organizational challenges for most fast-growing startups 

Most startups want a flat organization to keep their entrepreneurial juices flowing, but when new employees join in a steady stream there eventually comes the point where the founders or upper management feel overwhelmed by chaos.

Things get confusing.
Employees aren’t seen.
No one seems to know what’s going on.

What usually happens for most start-ups at this point is that bureaucracy processes start piling up. Layers of management are added, and project managers are introduced to coordinate the chaotic environment. And so are written reports for managers to send to upper management, and silos are building up between different departments.

And decisions are taken somewhere else.
And then what happens?

Usually, entrepreneurial enthusiasm suffers and so does talent motivation and speed of innovation.
And that is exactly what iZettle wants to prevent.
But that is easier said than done when a company grows like a wildfire.

How iZettle has grown 

When iZettle launched its first product in 2011, the company was a team was just six people.
Today the startup has 450 employees, with 45 nationalities, an annual transactional volume of 3,5 billion euro, and 1 000 new businesses are signing up every day.

The business idea has expanded – from ”just” making it super-easy for small businesses to accept payments anywhere (by just attaching a small device to a smartphone or an iPad) to also taking care of the transactional related needs of small businesses: receipt printing, cash handling, accounting integration and so on.
The growth puts some heavy pressure on the organizational design.

The call for an updated organizational design at iZettle 

Kalle Persson, Development Director at iZettle, joined the company when there were only 20-25 people on the tech and product side of the company:

“Things like workflow, culture, and expectations had managed itself pretty well in the organization up to that point, as they can do in a small startup if you are lucky, if people know each other pretty well, and if the right people were recruited. But as you grow to more than 60 people, the game is different. When I joined, there was no development process what so ever. Delivery times were getting longer due to too much work in progress at the same time, and we felt a growing need to coordinate different teams and to get an overview to make sure we did the right things.”

Setting up a traditional management structure was never on the agenda, though, according to Adam von Corswant, CTO at iZettle:

”We don’t want to implement traditional management structures. We never did, and we still don’t. Centralizing power would make us slow in adapting to the complex and changing world we are in. And employee engagement wouldn’t be the same”.

Adam is today the only formal manager of the 80 employees in the development part of the company.
However, as the company expanded, the company needed to do … something.
It was critical not only from a development perspective but also from a people standpoint.

Sara Ekström, deputy CTO, explains:

”Adam and I shared a role of making sure everyone was happy by having 1-1 talks with everyone every once in a while. That worked when we were 40 people, but as we grow… there wasn’t time for that anymore. It just didn’t scale”.
Other challenges were difficulties in making decisions that affect other teams, for example, the architectural aspects of databases, and the lack of feedback to new developers, what they needed to do to improve their work.

What I noticed very soon

Pretty soon after I joined iZettle in summer of 2016 to work on their organizational challenges, I noticed how deep the principle of no bureaucracy was rooted.
Sometimes I challenge my clients to “hack their organization” to get rid of waste, such as unnecessary processes or activities, and I thought I would do the same with a group at iZettle.
“What do you mean?” they said when I introduced the idea of getting rid of unnecessary processes and activities.
”You know… waste like unnecessary time reports and things like that”, I clarified.
”Time reports? What is that?”
They didn’t know.

Most organizations suffer from heavy structures. iZettle had the exact the opposite problem.

From past experience, I have learned that a growing decentralized organization needs some minimal structures to keep growing in an effective way.
And that’s what we have been working on in iZettle.

The minimal structures we added to keep iZettle development decentralized 

Here are some of the practices we have been putting in place:

Chapter coaches

At iZettle, some of the team members are also chapter coaches. These chapter coaches are spread out among the teams and are associated with a certain area of specialization. So for example, an Android chapter coach is an Android developer.
One of the main focuses of the chapter coach is to be a buddy for other developers with the same expertise (Android, in this case), making sure each developer is seen, heard and enjoys going to work. With the chapter coach, you can discuss how to approach difficult personal situations, among other things. Since the chapter coaches have insights across teams, this is the go-to person to make requests to change teams, and to bring up specific issues related to your expertise.
Does every developer get the support they need? Is everyone feeling well? These are examples of questions to be highlighted by the chapter coaches.

Sara Ekström says:

“The chapter coaches are a really important group for us to make sure we are doing the right things and that people are satisfied here. This group can take decisions to make things better”.

The twelve chapter coaches, who each have about eight colleagues to connect to in this way, are introduced to a Learning program with bi-weekly “Learning Labs.” The Learning Lab is a safe place to grow, where I coach them to become more successful in their role.

Rather than appointing the chapter coaches, we have been experimenting with a special “role selection process” where the developers themselves select the person they think will do an awesome job as a chapter coach.

Kalle Persson with the chapter coaches.

Kalle Persson with the chapter coaches.

Agile coaches

In a decentralized organization, leadership is expected from everyone. However, there are some key roles that take on roles that in traditional organizations are done by line or project management. In addition to the chapter coaches iZettle have product owners who lead in the product dimension — and agile coaches who challenge, support and coach the teams to grow into high performance.

The agile coaches have learning community just like the chapter coaches to accelerate their learning and performance as coaches. They also drive cross team improvements.

Big Room Planning in the iZettle kitchen supported by the Agile Coaches

Big Room Planning in the iZettle kitchen supported by the Agile Coaches

Consent decisions, not consensus

To speed up the decision-making process, we are implementing the habit of going for consent instead of consensus.
So, instead of trying to find solutions that everyone can agree on, which can take forever, the developers now look for solutions that are ”good enough for now, and safe enough to try.” Before giving a green light, the question is: ”Is there any reason why we can’t go ahead with what is being proposed?
”One huge benefit is how much we speed up iterations and decisions,” says Adam.

Consent flipchart

Explicit expectations

As Sara Ekström says:

”Sometimes it can be tough for new people who are used to have a manager to go to when problems escalate. Here it’s up to yourself to initiate solutions and drive other processes. That’s the other side of working in an environment like this, where no one tells you what to do.”
We are still in the process of making everyone understand what personal leadership means. This is also addressed much explicit in the recruitment process.
“We are not looking for people who wants to manage other people, but who are good to lead themselves, together with others. We want developers who rather take initiatives than complain, and have the drive to make changes”, says Sara.

Feedback loops for new employees

To avoid the ”no one told I did something wrong” syndrome that is common in many companies, a new routine has been set up that each new employee is responsible for asking for feedback every month.
The next step is to roll out a similar feedback loop for the all the in-house agile and chapter coaches, and after that to everyone in the organization. We are also providing on-demand training in more effective communication, feedback and conflict handling. Key skills for everyone in a flat and decentralized organization when you don’t have a manager to depend on for feedback and to solve your conflicts.

The teams are now responsible for introducing new members to a new onboarding process

The teams are responsible for the welcoming their new team members and for the setup of the Training Deck where each new member quickly pull the knowledge needed from the team to get a flying start as a new team member. (A separate blog post on Training Deck is coming soon)

But …what about control?

If you are in a leadership position in another company, you might have some concerns.
How about … controlling the performance of each employee?”
How do iZettle make sure that no one cheats?
The answer is simple.
They don’t.
Instead of controlling, they trust their employees to be accountable for their behaviors as well as holding colleagues accountable for keeping their commitments.
”With only one formal manager on tech development, the risk of someone looking over your shoulder is very small. Culture is the steering mechanism we have in this regard”, says Kalle Persson.
Is it worth it?
Well… I would say so.
Just look at their success so far, with employees as the engine.

What’s the takeaway?

When Adam is being asked what he is most proud about within the iZettle organization, the CTO answers:
”I’m proud of the fact we are autonomous. Every individual is extremely engaged in their work, being part of discussions, and many spend extra evening hours without being asked to do so. Everyone sees what is needed, and keeps going to get it done”.

Footnote: The practices of Consent Decision Making, Feedback loops and the “Role selection” originate from Sociocracy 3.0 (but there the Feedback loop practice is called Role effectiveness review).

Republished by permission of the authors.

Featured Image/Graphic link added by Enlivening Edge Magazine.