Author: Marc-Antoine Lacroix, Chief Product Officer at Qonto
As a manager or a team member, how can you scale your team without compromising on efficiency or quality? How do you avoid falling into the “big company” trap? In this article, I share what I’ve learned from growing several teams from just a handful of members to over a hundred.
Building quality fast is hard. Scaling a team is tough. Doing both things simultaneously is the biggest challenge we’ve faced at Qonto, where in the past five years we’ve grown from a start-up of just 10 people to a scale-up of over 600.
This challenge is not unique to the hyper-growth phase. When a company gets to around the 30-employee mark, founders and C-level execs start seeing waste everywhere: lead times get longer, overall quality suffers and it all feels like the company is slowing down. Management meetings begin to throw up the same old frustrated observations:
“I don’t get it. There’s twice as many of us than there was before, but we’re shipping half as much!”
“The team is working on useless stuff and I can’t understand why.”
“This task is not complicated! Do I really need to check everything if I want something done properly?”
Confronted with such issues, senior managers have a natural reflex: they want to figure out what process they can put in place to rectify the situation and return to their previous level of efficiency. However, this approach doesn’t work. The new processes will likely create more bureaucracy, more waste and poorer quality. The chances are they’ll make the scaling efforts stall.
Why? Because processes do not scale.
Implementing a process is difficult and energy-sapping
Anyone who has tried to put a new process in place knows just how much of a grind it can be. Designing a process on a whiteboard is always exciting; you get the impression you’re solving problems with every stroke of your pen. Yet, when it comes to actually implementing the process, reality bites. It consumes a tremendous amount of your energy, as you need to create the tools, teach your team the rules and synchronize everyone to ensure they all adopt it at the same moment.
The worst thing is that much of the time, most of the people affected by the new process never actually asked for it in the first place. This makes it even more of a chore to enforce.
And putting the process in place is just the beginning…
A process starts dying the minute you implement it
No sooner have you launched your new process, you notice that not everybody respects it. Perhaps they don’t stick to it the way you’d imagined. Maybe they challenge it. Some might even ignore it altogether. Of course, many employees will try to make it work simply to please you, their boss. But if they’re not clear on the rationale, if they don’t truly get ‘what’s in it for them’, they will not follow the process the way it’s meant to be followed. Consequently, as soon as you launch your new process, it will start dying. And it will continue to degrade very quickly.
One countermeasure is to have your managers spend a huge amount of energy policing the process. You can have them check every hour that it’s being followed to the letter and, if it’s not, have them speak to the team to remind once again them of the new rules.
But your managers have other things to do, right? So they, in turn, will hire people dedicated to enforcing the rules and maintaining the integrity of the process. If you’ve thought about hiring a Scrum Master or an Agile Coach in the hope that they’ll help you impose new methods, then this is probably a situation you’ve been familiar with.
This is exactly what bureaucracy is: adding low-value layers to an organization just to enforce inefficient rules. Your instinctive attempts to streamline procedures can often end up creating more noise, higher cost, longer delays and lower quality. Even worse, it can destroy employees’ willingness to think for themselves and use their initiative.
Process doesn’t scale. But knowledge does.
So, if processes don’t scale well, what does? From our experience, the answer is knowledge. If you manage to teach someone something valuable about their core skills (e.g. how to carry out good product discovery, how to write good code), then they will apply it every day in their job. They will adopt and embrace it. They will practice it. Their knowledge will grow organically.
One of the best things about knowledge is that it can easily flourish within a team, for the simple reason that when someone learns something, they will naturally evangelize it to those around them. When you help someone achieve mastery in their work, you can be confident they’ll be proud of it and want to demonstrate it to others.
This is why our scaling strategy is to focus on creating and sharing knowledge. It makes people better at their job and allows them to build better products faster. “Good thinking, good products,” as they say at Toyota.
It’s easier said than done, of course. Here are three practices we’ve developed at Qonto to scale knowledge:
1- A “bad news first” culture
“Having no problem is the biggest problem of all.” — Taiichi Ohno
To build a knowledge-driven team, you first need to foster a “bad news first” culture. The goal is to orient team discussions around the problems those team members face, because a problem is where the potential for knowledge lies. Without problems, there can be no improvement. There can be no new knowledge.
So, concretely, this means:
Build your tools so that they highlight problems. For instance, on Qonto’s Product team, early in the product development process we ensure that each feature has a clearly defined success metric. This allows us to visualize at a glance whether a feature is performing as expected. It reveals a problem and provides us with the knowledge we need in order to improve.
Did the feature succeed? After the launch, the Product Manager will visualize the performance of a feature with 🟢,🟠 or 🔴 based on the extent to which the feature met its primary success target.
Empower those people who identify and try to solve problems, not those who conceal them. If someone in your team is telling you there are no problems, then you have a problem. Make sure your teammates are comfortable sharing issues with you and that they’re confident they’ll be rewarded (and not penalized) for doing so.
This “bad news first” culture is key to everything. Without it, what follows is irrelevant.
2- The “Gemba walk”
You can’t simply highlight problems without having a consistent means of solving them and proving to staff that they’re improving.
The “Gemba walk” practice (meaning “Go and see in the field”) was developed by Taiichi Ohno, the Japanese engineer who formalized the Toyota Production System. He used to escort managers to a line of workers on the shop floor and draw a circle on the ground. He placed the managers inside the circle and instructed them to stay there until, together, they’d found a way to solve a problem that worker was facing.
This is our main managerial practice at Qonto. Rather than simply multiply the number of 1-to-1 meetings, our managers spend their time on the Gemba, with their teammates, looking together at what they’re currently working on (a design, copy, a discovery, a merge request) and solving problems with them.
“When you are out observing on the Gemba, do something to help them. If you do, people will come to expect that you can help them and will look forward to seeing you again on the Gemba.” — Taiichi Ohno
In fact, solving a problem is not even the main goal. What’s more important is for the manager to understand where the team member has a knowledge gap (i.e what they need to learn to become better at their job) and to teach them how to improve in the field.
I recently did a Gemba with a Product Manager who was struggling to define the success metrics for her new feature. Together, we looked at the feature in question and discussed her first proposed metric. Thanks to this discussion, we were able to identify the metric together, solve her issue and allow her to move forward. This didn’t just solve her problem; she also understood the value in the Gemba. Then, we identified and formalized her knowledge gap: she was not clear that a feature’s success target is primarily about setting the ambition of the team, and not estimating the potential impact of a feature. We took the time to discuss this point in detail, making sure she understood why the difference is key and how to apply this in different contexts.
What matters is training someone in the field, rather than discussing high-level points during a 1-to-1, when the subject is more abstract.
This is how we scale our team: every day, managers go in the field to solve issues with their team members and build knowledge together. As a CPO, I need my 20 product leaders to do this, rather than spend their time and energy designing and enforcing new processes.
It took me a long time to understand that in order to scale, you do not need big theories on scaling, you just need to go in the field and help the team. Every day. Always. Whatever the size of your team.
3- Training sessions
“No goal, regardless of how small, can be achieved without adequate training.” — Taiichi Ohno
Once you’ve put in place a knowledge flow within your team, the next step is to consolidate and supercharge it — and this is the role of the training programs at Qonto. On the Product team, we have two Principals focused on building training programs for their teammates.
These programs are 100% based on the Gemba. With one Gemba, you are focused on one person and one topic only. After 20 Gembas, a pattern emerges of what your team does not master and what it needs to learn. These recurring knowledge gaps are what you must address in your internal training programs.
Today, our training programs focus on what a Product team member should master in order to build features that drive great customer value at high speed. Each new joiner follows the program, and each existing team member will repeat it periodically — because knowledge evolves all the time. This is our way of making knowledge flow faster and ensuring that every new learning gets shared within the team. It means fewer processes and more training.
Following these simple principles can help you scale your team or company without creating bureaucracy. The core principle is to rely on your teammates’ ideas and abilities, and not on your managers’ capacity to enforce processes at all cost.
So where do you start if you want to follow this path? The beauty of this approach is that there’s nothing to plan or to frontload. Simply ‘go to the Gemba’ with one of your team members. Find one problem. Coach one thing at a time. Then repeat this every day.
