Why is People Development our strategy? (Part II)
At Qonto, we believe that the quality of our work will only come from great thinkers and that we will prevail only if people grow as the company grows. This article tells you more about our journey to build our company model as we scale.
Click here to read Part I of this article.
The following sections give four examples of how we take inspiration from the Toyota Production System (TPS) principles as a baseline to trigger People Development in four different Qonto teams (HR, Tech, Product and Customer Support). Each team has its own methods of doing things (built organically) but within the same core practice.
1) Creating alignment: visual management
At some point, Qonto’s HR manager, Sarah, had to deal with 38 job openings with only two talent acquisition managers in the team (Marjorie and Tanguy). 38 job openings! But how do they know what to do at any point in time and avoid chaos?
Agile methodologies implement what is called “Daily” meetings. The three major problems we’ve seen are the following: (1) people tend to do Daily without having the business priorities in mind (e.g. “yesterday I did this and today I’ll do that”), (2) managers don’t take the time to solve team problems every day (they wait for the retrospective meetings once every two weeks), and (3) the team is more focused on making the process work rather than actually thinking. Welcome to the dark side! So how do we simply solve that?
At first, Sarah set up an environment in which she could engage spontaneously with Marjorie and Tanguy. She decided to shift to visual management to represent the pace at which hirings should be done, to visualize our Kanban board with ongoing candidates, and to have a clear view on priorities. Before that, she tended to exclusively use SaaS, such as Trello or Lever (ATS), to organize her team’s work but it created problems: key priorities were easily lost in a black box, and most importantly, the HR team did not share a single point of truth about what should be done next. Without a crystal-clear interface, no one could communicate naturally.
The second thing Sarah did was to set up an environment in which the team could engage more often. In order to do that, we decided to meet every day:
- In the morning (for 15 minutes), to agree and visualize on what would be our individual success(es) of the day, and make sure that they were in line with Qonto’s priorities, and reachable. It usually started by checking the candidates which were the closest to “Offer submitted” in the Kanban board, standing next to the Success Board.
- In the afternoon (for 5–10 minutes), to discuss potential problems encountered in the morning, and to solve them on-the-fly so everybody can succeed.
It is worth saying that Qonto uses the notion of time to know whether someone is late (rather than a productivity KPI), and consequently as an alert to notify there is a problem the management could help fix (in the same way you would worry if your friend is late for lunch!).
What are the benefits of our Success Meetings? We meet in front of our visuals and we ensure as a team that everyone’s success is aligned with the company’s priorities. In addition to creating alignments between the team and the customers, visual management helps align the manager’s success with its teammates’ goals. The manager’s main responsibility becomes quite clear: helping the team succeed on the right topics.
2) Building trust: Andon
In typical tech project, poor-quality inputs are not detected and solved along the flow but rather at the end or in between big milestones. This has two negative effects:
- The team focuses more on reworking than on creating value for the customers.
- Coworkers are left alone with their problems for a long period of time, preventing them from delivering a piece of work regularly and that they should be proud of. In short, they don’t have the tools to reach success.
I’m sure you are all familiar with one of these situations: a designer did not provide all the needed assets, a product guy did not write the spec taking into account certain aspects (and Jira tickets are put “on hold” as the development already started!), a dev started to code without anticipating the complexity of a feature, and so on. Worst case scenario, the management keeps putting pressure to maintain the deadline and ends up shipping the feature without fixing the problems. It creates bugs and increases the number of CS tickets: everybody gets upset, some people resign… Big drama! In the end, a simple feature that should have taken a single week to develop can take up to six weeks to ship, and in the process, you increase the risk to kill the trust you built between teams and with your customers. Go explain your board :)
That’s why at Qonto, we aim to deliver everything right the first time. The recipe is to leverage the Jidoka’s stop-and-fix philosophy, called Andon. Marc-Antoine, our CTO, implemented Andon in the tech team as soon as he joined the company: every time his teammates encounter a quality issue (an “abnormal” situation), they stop working right away, understand what is going wrong and why, fix the problem, and then, go back to their work. Part of Marc-Antoine’s responsibility along with the tech Leads is to be available to help them find solutions.
Why is that so important? On top of creating a more efficient team, Andon develops a strong bond between the management, which is committed to react and help, and the team: it’s called Trust, with a capital T.
3) Setting stability: pull-system
Now, let’s focus on our product team. The production cycle is generally split into two big phases: (1) the product part, during which the customer demand is confirmed and the solution proposed, and (2) the tech part, during which developers code the chosen solution. One year ago, we were in a situation in which the product team delivered specifications at a pace the tech team could not keep up with. As a consequence, the stock of features waiting for development was getting a lot bigger.
This became a huge problem. As for any product builder, Qonto’s inventory is expensive because it creates obsolescence. For instance, a dev starts coding a feature which was specified three months ago but soon realizes that a large part of that is actually outdated and requires a lot of rework. Therefore, instead of creating value for the customers, the dev now starts to spend most of the time patching the spec.
By applying the Pull-system principle, we found ways to make the different teams work at the same pace, reducing the stocks at each step. Our CTO along with the Head of Product and our tech Leads decided to give it a try.
The first thing they did was to make the stock visible. In a team with 50 developers and 10 product people, it becomes really hard to know if we work on the right things and what are the features ready for development. They decided to use Kanban cards to show the stock of features for each of our teams, and the features the product team was currently working on.
Then, they decided to limit the stock to two features for each tech team. If the stock is full, the product team has to work on features for another team. If all tech teams’ stocks are full, the product team just stops working on new features — they always have plenty of other things to do :) When a spot is available, the product team receives a signal that it can start working on the next feature. And so on.
What are the benefits? First, we eliminated the rework due to obsolescence. Second, we created visibility because the product team now knows what it should be working on next and align with the tech team. As a consequence, we bring stability to the team.
4) Building a problem-solving culture: Kaizen
At Qonto, we strongly believe that we cannot succeed without improving every day. Basically, we give our people time to improve the way they work and to solve problems. We see three main objectives to that:
- Training people to get better at their job and evolve to real problem solvers
- Creating a compact social graph in which teammates engage with managers on concrete everyday problems and test new ideas
- Breaking the silos between functions that are bound to emerge over time
We call Kaizen (literally “improve for better”) our way of achieving these goals. Now, I am not talking about a problem-solving session done once in a while during a 3-hour meeting in an actual meeting room. On the contrary, it is to the core a daily routine, in the open space, consisting in analyzing problems and testing/implementing solutions.
Practically, how does that work? A few months ago, our Customer Success team noticed that 31% of tickets were reopened tickets, and the more reopened tickets we had, the more our customer satisfaction rate was decreasing (which is quite bad…). We saw a potential and decided to start a Kaizen to reduce that figure by 90%:
- We assembled a team of four composed by Anne-Charlotte (CS agent), Astrid (CS manager), Xiway (project manager) and Germain (operations director).
- We started to meet 30 minutes per day to analyze each reopened ticket one by one and to offer solutions for each root cause.
- After a few weeks, the Kaizen team noticed that reopened tickets were generated mostly because the quality of our answers was not good enough: customers problems not understood, lack of clarity in our answer, FAQ not updated, and so on.
- They began to ask themselves: what’s a good CS answer? And after coming up with a proposal, all of them started to test their theory and to train others growing their knowledge on how to write a good ticket.
After six weeks, the number of reopened tickets decreased from 31% to 20%. At the same time, we noticed that people attending this Kaizen started to develop not only strong know-how on their job but also training skills to spread their knowledge. More recently, Anne-Charlotte asked us if she could participate in another one to keep improving. Wow, I know Kung-fu!
You get the point: when embracing the Kaizen spirit, we do not try to exclusively solve business or operational problems; we invest time in growing people and in building a problem-solving culture.
Why it creates alignment? Because pretty much all teams at Qonto are running Kaizen, meaning that they speak the same “language” and can challenge each other in a healthy environment. What is it so powerful to scale a team? Because we invest a lot of time to coach people in learning the practice, and in return, they teach it to others, with no processes or bureaucracy.
If you want to learn more about how our tech team uses Kaizen, feel free to read and clap to Marc-Antoine’s article about the topic!
How to create people development?
When Marc-Antoine tries to solve quality issues, he is, in fact, trying to make his teammates think profoundly about how they should work to create value right the first time. When Sarah speaks about Just-in-Time, she is making her teams think about ways to work better together and at the same pace. And when Germain tries a different approach, he is actually more interested in the growth of his team rather than the actual results of the Kaizen.
“At Qonto, we believe that the quality of our work will only come from great thinkers”
Toyota says that “Good Products Come from Good Thinking”. At Qonto, we also believe that the quality of our work will only come from great thinkers. Because talent is not something we have but something we grow, we believe our success is deeply tied up to our capacity to foster a learning environment in which everyone can become better every day and be proud of their work. We call it People Development, and it is our strategy.
