Jean-Philippe Denis - The Qonto Tech and Product Operating system

[00:00:05] Hey everyone. So we are already reaching almost the end of the second day of the conference. Um so I hope you still have some energy left to get attention for more information and anything around the lead. So I'm here to present with you the Conto product and tech operating system.
[00:00:23] So, let's get started. And just to clarify what is Conto, if you don't know about us, you may have seen a few ads all around the European country lately. Uh, we've been starting the banking business, uh, to make it day-to-day banking easier for SMEs and freelancers, thanks to an online business account that's combined with invoicing, bookkeeping, and spend management tools. And last year, we reached 4.4 billion valuation after only six years of starting this business. So we grew super fast. And as you can imagine in this kind of business, we really cannot afford failing and when we ship something in production, it has to work. We cannot tell our clients, sorry, but for the next five days, you will not be able to use your your cards. That's not possible for us. So we have to be able to ship quality every time we do something. And now we have 450,000 customers and 1,400 contractors. So what I'm going to share with you may or may not apply to your own daily life because we already are quite big, we have structured our company with the needs we had. So our plan by 2026 is to become indisputable Pan-European winner. So we're going to talk mostly about how to build a killer product and how to create the process of actually designing and making this feature right first time as much as possible. So that our three pillars, building a killer product, stellar support and transparent pricing. A killer product, it's when you open your app and you realize there's a new feature that has been shipped and that will make you save time for something maybe that took you two hours every week to do and now it's just done for you with no extra effort. And just by doing it, you realize that it's going to make your life simpler, you may even share that to your friends that may start using the app. So it's all those marketing acquisition channel to grow the the client base to keep your clients, to up-sell your your clients. So building a killer product is absolutely key for a tech company. So I'm Jean-Philippe, um tech operation principal at Conto. I joined Conto at the very beginning of the adventure as first Android engineer and for the last two years, uh, I'm mostly focused on making our system and the way we work as efficient as possible. And my side activity is also to nuke bureaucracy as much as we can at Conto. And that's a very satisfying job to do and if you have some time to do it in your own companies, just do it. It's awesome. So, before we get started, I just want to share some results every twice a year, we spend sometimes.
[00:02:59] Taking feedback from the team with engagement survey to get results if the team is happy, feel satisfied with our ways of working. So just so you know that all I'm going to share with you today is actually working. We have 91% of people who strongly agree on the fact that the way we work makes the team grow and that's one of the main reason where we hire so many people so simply every day. So, let's get started.
[00:03:23] Maybe you know it, but we are very fun of the lean framework, so we build a bit of our own. And if you're familiar with the lean framework, you may recognize this lean temple. So we customized it a bit to put more contoway inside. But very shortly, everything is around our values, on top customer focus, teamwork, mastery, integrity, and ownership. And you can relate to some of those parts because the roof of this temple is the people satisfaction. So it's to reach a high NPS of satisfaction, maybe from clients, but also from your teams. And this is something we all need to care about when you have a company because that's how you keep your business alive. You need to take care of your clients and of your teams and the shareholders, of course. And all this by making sure that the team feels safe, there is no over pressure, no stress, everybody is happy to work there, quality, lead time, cost, and also environment, making sure that we take care of the carbon footprint and so on. And this relies on the basement on some very simple ideas that actually just make sense when we put names on top of them. We have five S, daily problem solving and total productive maintenance. This is in simpler word, is just to keep the workspace always clean, being able to find information within seconds and to get this information as you need when you need them without the need to look for them. Daily problem solving means whenever you face a broken window, a rework or something, you think about a way so that it cannot happen again. Total productive maintenance is you don't wait for the system to break to fix it. And all this then lays on two pillars, just in time and auto quality, where we want people to really understand that we are working in a chain, we have uh, we are working on a piece and we want that piece to be as good as possible. So we we are working in a flow. So if you build something and you keep, you give this piece to the next person in the line, that's respect and teamwork to give that person a piece that he can work with without the need to ask you more question about it. So this is about auto quality and when you don't get it, then you jeopardize the just in time. And everybody along the line might be under more pressure to fix something that gives people satisfaction. So as soon as any of those pillar is broken, that roof that needs to always be stable is no longer stable. So for that we have standards, visual management and this case in culture of continuous improvement that helps us every day. So we're going to see a bit of those things, but before everything, we have cyclic lives. When we build a new feature, you may say it's not cyclic, every new feature has its own fair share of uncertainties, we don't know how it's going to work, so it's always different. In a way, it's true, but in another way, it kind of follows a process. Where you have product managers that will start scoping the feature, then you will have a moment when product managers and tech people will specify the feature, then engineers will start coding the feature, then QA, then go live, then analyze of success. So we have cyclic lives. And when we realize that it's very cyclic, you want to start mapping this as a value chain. Because when you start visualizing all those steps and sub steps and so on, first just by mapping it, you may realize that your team has created by themselves some sub-systems in the systems and many teams may not work in the same way than other teams. So if you have one of those teams that ask another one to help them on a specific step, if they are working differently, we already have a problem. So just by mapping the value chain and that's something we are starting to do even beyond the tech and product department at Conto, we realize that we have many steps that are just completely useless and with a lot of bureaucracy around it. So once you map this value chain, you want to improve it to remove all the bureaucracy. And then when you have those steps, you want to make sure that you it's extremely clear for everybody that we have the same definition of done and ready. A simple example is if you consider your work being done when you are we are done with a specific step, but the next person in line expects it expects it to be shipped differently, then you will have a rework and you can't avoid that and then you break everybody's one piece flow and so on. So those definition of done and ready are really things to improve and to make sure it's aligned between every team. And once you have this cycle that is very well defined, this can translate very naturally into your visual management. When you have this Kanban that can move alongside the different steps, it should follow naturally those different steps. And it's quite simple in the end to have a visual management that is very straightforward and useful for everyone. What is the job of visual management?
[00:08:05] If you say reporting, I start crying right now. No, visual management is about teamwork. And visual management is about simplifying everybody's life. You need to have a simple visual management, it's here to help us doing our job in a simple way. If you feel like your visual management is painful, then maybe it's too complicated, maybe it's overly bureaucratic, or maybe it's not adding the value and information people are looking at when they are looking at it. And I will be honest with you, we just revamped our full visual management in the tech and product department, we removed hundreds of properties that were completely useless and now the team are actually filling every important information and everything is trustworthy. So visual management is really about teamwork, but it's also about learning. And this is something that is very key in the lean methodology. You want to be able to visualize whenever something needs to be improved. And when you have lead times, because you see all those steps, you can see how much time each step is taking. You can see when one of them is running late. You are expecting to be done at a specific moment, but you are not. It can immediately be visible on the visual management, triggering the question, what happened? And that's how then we can start getting learnings and improving the system. And the visual management is also about making sure everybody's just working on one piece at a time because people are usually very motivated to take so many subjects but in the end, it's not the most efficient way to work.
[00:09:35] Does this look familiar to anyone here? Let's have a look at it two, three times, just for pleasure. Okay? Does that trigger anything to you? Can you relate to that?
[00:09:48] Okay, let's keep him with these heads nicely in the sand. So this is us whenever we have a problem somewhere and we're not fixing it. We have cyclic lives. It's just that simple. If you are during the cycle facing a problem and you're not fixing it, during the next cycle, we will face the same problem. You yourself, but maybe other people. A stupid example that we can take is if you have a carpet poorly fitted on the floor and you just fall because of that, if you're not fixing it, you're going to fall again and maybe someone else or you can take five minutes and you fix it. It's the same logic whenever you have a problem at work on any kind of subject.
[00:10:29] We push this system of the red bean concept. I don't know if you're familiar with that. But in the chain of production, they tend to have those red bins where they can log all of the pieces that are broken or defect so that they can analyze them later on. And it works just the same for a tech company. We can just log anything that actually needed to have a rework. We built something, it's not right first time, we can't use it directly, it needs people to resynchronize, to to have another meeting, to redefine something to be able to move forward. So here, we are logging everybody at Conto, whenever we face a rework, we are logging it inside one database. And that's absolutely key for us to get better, to improve every day. We are we have been training all the team to do it and it took us quite a bit of time to be honest. Because when you start logging those red beans, it means you are logging something that usually you have done wrong. I've been working on something and I had to rework this thing, which could mean in the head of people, I'm telling everybody that I failed somewhere. Which is absolutely not the right mindset in the in the lean logic. The right mindset is, I failed here because the system is not bulletproof here. If the system was better, I would not have failed. So to to be very efficient, we need to have people who really master their job, but we also need to have a system that helps people moving forward in a very safe conditions. So any rework that we log inside this database is actually much value for everybody to improve the system. So this is the first step that really helped us getting this continuous improvement mindset at Conto and it took us a few years to get there.
[00:12:14] So if we just log all the reworks that we have. We have a big database full of reworks. What do we have? We just have like one massive amount of pain, but we just visualize that. But now we want to fix those things. We know about those problems. We know exactly where they stand in our operating system because we have all of those waste that match a specific step in the cycle of production. So we know which step is broken. So the more waste we have around that step, the more we know we need to improve that step. It's just logic.
[00:12:48] So how to fix this waste? So there are many methods that we didn't invent, we are just reusing them because they are super powerful when you use them correctly. That are the PDCA, the Kaizen and the A3. Just raise a show of hand, are you familiar with those concepts?
[00:13:03] Wow, nice. But whenever I ask the same question at Conto to people who are actually doing them, usually I have average results. So let's just quickly on them. So PDCA you know that, plan do check act, I'm not going to go too much deeper in there, but you just have one North star when you want to start one. It's you have a problem and your ambition is that this problem can never happen again anywhere in the company.
[00:13:27] And that's the anywhere in the company that matters a lot. Or at least, if you can't achieve a way that this problem can not happen again, find a way that next time it happens, it will be less painful, way less painful.
[00:13:40] A very quick example of a speaker who closed the presentation by mistake during an online in front of a lot of people. We just went down to the misconception that was that we gave that person a clicker that was just doing this job. The root cause was that the clicker had too many options, counter measure is tested locally, very simply, we use a new clicker very simple to use with just two buttons, so we can't make it fail at all. During the check, where we want to replicate the same problem to make sure that the counter measure worked, we tried to click on every buttons to make sure no one could close this presentation at all by mistake. It worked. And then we act on it, so we make sure that we clean the stock of risk of having this problem happening again later on by buying the same very simple clicker in every different office and then we make sure we protect also the future that it doesn't happen again, we update the standard of which clicker to buy for the future as well. So this kind of problem can no longer happen at Conto. But this is a very simple example, it can be much more complicated with a very technical part. But in all logic, it's always that simple. You get to a very clear problem statement, very factual, you get to a counter measure that is very cheap because you're not doing any analysis, you're getting to a counter measure that is very local, you just want to test it locally and then you act by implementing it everywhere. And at Conto, last year in 2023 in the tech department, we had 423 acts, so it means there are 423 problems that we will never face again hopefully in the future. So this is really to say that we have all of the teams at Conto that is completely trained at first logging the waste and second, getting the habit to run problem solving sessions to fix those waste forever. PDCA is not the only one.
[00:15:33] Now there is the Kaizen, this continuous improvement culture and here we are doing quite a lot of them at Conto. Because those are the best way to really get to the next level of mastery. A Kaizen is continuous improvement on the same subject, so you keep a subject that is problematic and we run improvement after improvement after improvement until you bring that level that that subject to the next level of mastery. And usually you set yourself a very ambitious goal. To give you an example, uh recently we ran a Kaizen about having the time, the build time on the CI that was about 10 minutes long, it was too long because engineers are waiting, it's costly. So we wanted to start a Kaizen to say this should be maximum three minutes and then we see every reason why it takes a bit of time and we crack all of them one by one until we get there. So 10 minutes, nine minutes, eight minutes and we stop when we are done. So this is a photo of our very first Kaizen that we did at Conto. And it was about all the build that failed on staging, we had quite a lot, it was very painful and this was before COVID, so it was still in the office on the world, it was very funny. Now we do that on Notion. Uh, and very quickly after less than a than a month and a half, we had zero occurrence of this problem anymore. So really this is something that isn't the teams, anything that is painful, it's our job to fix it. It's not the job of leads, manager or anyone to tell you this is a subject we need to crack. If it's painful for you, this is your responsibility to say, okay, I'm going to crack that now because it's painful for me, I want to make my life better. And others will benefit from it. That's really the key mindset that it's a personal practice to run those continuous improvement sessions. So today, we really are running quite a lot of Kaizen, we have more than 50 Kaizen going on around Conto. So it's really like the key mindset of everyone, not just tech and product. And if you can see this chart on the right, we are doing more and more at Conto, so the last line looks a bit lower, but we are just at the beginning of March, so normally we'll have more and it's keep growing and on the left, it's all examples of kind of Kaizen that we are running. To reach zero incident caused by a specific situation, zero defect on something else and for all of them, it's really bringing the next level of mastery for those specific subjects.
[00:17:53] And the last methodology that we use are the A3s. And the A3 is just like a super Kaizen where you want to drive a big change, usually align stakeholder and making a change that will be right first time. So to give you an example, please don't read it, it's just an example. Um when you start an A3, it means there is a situation in your system that is broken and usually you don't even know how much it's broken. So the first thing you want to do is to get that exact current situation and understand all the ramifications it may have because the day you want to change it, you don't want anyone to tell you, this solution doesn't work for me, about mission because all you thought about is not working for me. So the first step is to make this big analysis, so you look at all the waste, so luckily we log all of them in a database, so we just have to collect them, plus you go talk to a different key people to get all of their needs to make sure you're not forgetting about anything. And when you have this full picture, you make a big synthesis out of it and this synthesis is like your storytelling to onboard everybody who will be part of the needs for change. They may not even realize that there is a need for change, but just by reading it, they're on board. They want to change it, they're on the fact, it's we cannot move forward with this, it's broken. And then you build some solution with the key stakeholders. And then you write down the plan of action, the implementation plan and then it allows you to move forward and change the system in the right first time way. So A3 are usually a big alignment tool, making sure that you have the go from everybody and uh to to really change quite radically the system. So on the contrary of Kaizen, this one is like more one one shot action rather than Kaizen is more sequence of improvement. is like your storytelling to unboard everybody who will be part of the needs for change. They may not even realize that there is a need for change, but just by reading it, they are on board, they want to change it, they realize the fact, it's we cannot move forward with this, it's broken. And then you build some solution with the key stakeholders and then you write down the plan of action, the implementation plan, and then it helps you to move forward and change the system in a right first time way. So A3 are usually a big alignment tool. Making sure that you have the go from everybody and to to really change quite radically the system. So on the contrary of Kaizen, this one is like more one one shot action rather than Kaizen is more sequence of improvements. So now let's talk a bit about one piece flow.
[00:19:46] It's quite key to be able to ship in a safe way, to be able to focus on just one thing at a time. And for that there are a few key points how to build in one piece flow. Of course, if you build quality, it's it will help you staying focused on one piece at a time. Working just in time as well is important and your visual management itself can directly tell you if you are working on more than one piece at a time. So how do we protect one piece flow by just producing quality? First, if you have many incidents that jump into your your plate because you are shipping poor quality in production. If it's an incident, of course, you have to stop whatever you're doing and you need to fix it. Because that would be a priority, that means your clients cannot use the app as expected. So that would break your one piece flow and you don't have any other choice than to focus on this part. Any reworks as well along the way that you are building a new feature. If let's say you are an engineer and you receive a spec and you start working on this feature right now, you are coding it and you realize something isn't clear, then you need to sync with the product manager or product designer. To make sure that you understand it in the right way and you can move forward safely without creating more waste. So it means you will have to de-focus the one piece flow from the product designers or product manager.
[00:21:04] That may have started a new piece in the same time. So quality is very important. And of course, we know the cost of context switching, especially for engineers is quite high if you are focused on a specific branch, on a specific feature, and you need to change that. You need to stash your code, you need to pull a new branch, possibly merge some conflicts and so on and to rebuild the app, it can take more than half an hour. Just to change to one context and the same to come back to the initial context. So one piece flow is something that is quite painful for the team, so this is important to protect it.
[00:21:38] How do we work also at the same speed? How do we make sure that the teams, product and tech are actually aligned on working on? One piece at a time and we are synchronizing everybody. So what we try to do? If you look at this slide, ops, sorry I had to add colors to features. We're going to visually add colors to feature. Um, we have a code during while the tech are building the feature A, let's say. In the meantime, product people will start working on scoping the feature B, okay? And when the engineers will be done with coding the feature A, we will want to be exactly on time to start specifying together tech and product, the feature B. Which means as soon as the engineers are done with coding feature A, product managers and product designers should be ready with scoping the next feature to get ready to work together on specifying the feature B. And then engineers start feature B and product is starting to scope features and so on. So we need to make sure that this can happen. So for this, we are working with this Shape Up methodology, I don't know if you know this methodology. But it's helping us to define a fixed cost of how much time we plan to spend for engineers to build the feature. So this means by the end of scoping a feature, we decide how many weeks we're going to spend on building it. Which means we need to to design that feature in a way that will fit this cost. So of course, the volume of the number of screens and so on will depend on the amount of time we have to build this solution. So we need during this specification phase, what we call the value engineering, we will see that just after. We need to design this solution that will fit and match this constraint, so the fixed cost, of course, means the variable scope.
[00:23:36] And of course, when we know that the feature is in six weeks, product people know that by six weeks they need to be ready for the next feature.
[00:23:45] And now how do we enforce this with a simple supermarket? So this is a place where you have the the number of items that can be in stock for a specific subject. And here if you look at this slide, you have all of the items from the cross functional team pricing. And you can see that we have two pipelines here. Pipeline on top, pipeline on bottom, which means this team can work on two features at the same time. Not more than that, just two. And what this tells us, there are two information in there. There is a next availability date. And that next availability date is something that is filled by the tech people, the engineers who tells you, I'm still working on the previous feature until that date. Which means until that date, I'm busy. Don't give me another feature to start working on, I'm not free to start working on this. And here, this tells us a few information. We see that the back end engineers and the web engineers will be free to work on the 11th of March on a new feature. But iOS and Android engineers are still working on that feature until the first of April. So we know that the engineers from back end and web possibly could work on a web only feature. Or if we want to wait for a full stack feature, then we have to wait until the first of April and the web and back end engineers could work on scaling, continuous improvement or anything. And then the empty that you see just above is the next feature that is still under scoping. And that will be ready only by the time that we are ready to start working on it, to start specifying the feature. So this forces us to work at the same speed without a risk to have more than one item in a backlog. And we don't want to have a stock of features that are being scoped because if we have too many features and no one to code them, it's just stuck and possibly we know what happened with stock. It get deprecated, it get deprioritized and it's just wasting our time and energy. So this is how we enforce working on one piece flow.
[00:25:47] Now, I want to quickly talk about our value chain.
[00:25:51] So for us, how we build a feature, first, we have a phase that we call the value analysis, during this phase that mostly belong to product people, we will define what we want to achieve with the feature, I'm going to go into detail. Then a value engineering, which is the phase where we work together collaboratively product and tech people to fully design down to all high high fidelity specifications and then the delivery when we start coding.
[00:26:20] So the value analysis is a part that is super important. To make sure that we are doing things in the right way. So in this stage, and here you have an example of what is the standard at Conto, it's the definition of done of the outputs that are expected. So here the value analysis should be ended with defining a success. What which KPI, which metric are we planning to move? Um, because we want to build the feature for a specific reason. A prototype, so a concept design that should be as close as possible as what we will actually build later on.
[00:26:59] And a fixed delivery cost. So of course, depending on the success and the KPI we plan to move, we will be ready to invest more or less time building the feature. So now, the first step when we do a value analysis is of course to know what is the current situation of our own app. Because when you want to start building something, you have a starting point, you have you try to define a destination and you will need to build that bridge between the two. So the current situation is the first piece to know where we're starting from. Of course, we are listening to our customers, everything we do is for them. That's what they ask for, so we are just building what they need. Of course, we are looking at what the competition is doing, they are doing it too, it's fair game. Uh, we need to also make sure that we are not failing at checking all the dependencies. We are a big company now, we are like 500 tech and product people. So maybe we are just building a new feature for our own scope, but maybe we will also have impacts on other features, on other domains, and we need to make sure that what we plan to do isn't breaking anything anywhere, or at least that we need to know what kind of impact it will have. Then we need to make sure that our expert internally can tell us that we are not forgetting anything, maybe ops engineers, we need them as well. Uh, and then all the risk and compliance, legal and security teams will also sometimes for specific features, um making sure that everything is legal and we are doing it in the right way.
[00:28:27] So now, let's just play a quick game.
[00:28:32] Let's say I'm a product manager now, I just joined Conto. And I'm being asked to start working on a screen in the card section and I want to update this screen. And this is something that maybe all of us have lived quite a few times in our lives. So my first part is I want to get the current situation. And what would be my first move? I want to go to the app and I'm going to check that screen to get myself an idea of how it works. And this is what I see. I see this screen.
[00:29:01] So of course, the first question you should ask yourself is, is this screen exhaustive? Am I seeing something that is trustworthy? Can I start my the changes I want to build from that screen? Do I have a chance to be right first time if I just start my changes with this screen? Most likely, no, but at least you have the assumption that there probably are many different states that change the look of the screen. But how do you get this information? So the first thing you need to know is to have vision on an exhaustive screen. Second, you want to know the behavior of each element and any of those elements. Can give you information that you must absolutely not forget to make sure that the changes you are suggesting are not breaking existing situation and you also it could help you to define what you want to build. Because if there is specific status or element to consider and you're forgetting about them. Most likely, you have no chance to think about them if you don't read them on the on the next element.
[00:30:02] And the last question that you really want to make sure you are not breaking anything anywhere else. Is if you want to change a specific element inside this screen, you want to know if you will have an impact somewhere else in the app. We are building components, those components are being used all across the application, if you want to update one component on one screen, maybe you want it to be applied everywhere around the app, but maybe you don't. And if you don't know about that, then you're a bit lost. So knowing the current situation is not that obvious and it's mostly because of this reason. One screen usually is the combination of many features and each of those features had several specs. So if you look at one element in a screen, possibly it's a feature A that added it and then the next screen, the next element just below has been added through the feature B, all a different spec maybe six months later. So in the end, to get a full picture of how any screen is actually working, it's quite painful. And the only way that you get an actual answer is to ask the engineers because they have the code base and they have the source of truth. Otherwise, you may just have to dig for hours inside all the confluence or notion pages and maybe you won't even get the right answer. So we built a solution for that. Because we want to have this logic of one source of truth. So in the lean, we tend to talk about quality and just in time and a single source of truth and so on. But we also want to make sure that we work as efficient as possible. So the one source of truth we wanted to build. Was here to answer a few questions. The first one is, how do we simplify the onboarding of all the people who would join us in the tech and product department? You need to give them a way to have the full vision on all the app and we don't want to wait for many cycle of them building a features to get the full picture of how things work. So we want that source of truth that can be a very fast onboarding for them. Also if we can have one single source of truth, we will not have product managers and product designers to have the need to ping engineers. To answer them, how does this screen work? And if you do that, you break their one piece flow, they change context, context switching. Same story than before and it's also. The engineer might not give you a perfect answer because he might be answering quite too fast because he's busy on something else. So we need that source of truth. And same, maybe six months later after shipping a feature during the run of your feature while it's alive, you have a bug. And if you can't find a way the immediate place to tell you how it's supposed to behave, then possibly you will have your engineers struggling to know how it was supposed to work in the first place. So maybe Android team will ask iOS team, can you tell me how it works? While you should have this single source of truth very accessible.
[00:32:54] So we built something that is super straight forward, that is actually just very simple. We are using Figma, we most of us are using Figma. Uh, and the way we are building our designs now is to keep an always trustworthy single source of truth for any screen that would be the only place to look at if you have any question around the screen. So when you see a spec this way, it's nothing revolutionary. It's just like a screen with number on an item and next to it, you have a spec card where we have all the content about the behavior of each of those elements.
[00:33:31] And if you just look at it, you have how it works right now in production, you have all the details on the conditions. What API calls, what are the is it enabled, is it disabled, what happens on click, what tracker event am I sending and so on. So if I want to know how this screen work, I just have to go to this Figma page and I look at this screen and I know how it works. But how to keep it always up to date?
[00:33:56] We have a very simple solution, it's whenever we build a new feature that touches that one screen. We will directly add the new spec on top of that screen. Which means what you see here in blue is what is live in production and what you see here in orange, it's what is under process of being built. So that means, just by doing it, not only we keep it always up to date, but we also know that something is going under development. And since we are many teams with many functional domains and sometimes we have some teams that impact other teams, we already know that someone is changing something. And since the code has not yet been merged, still we know that there is a change coming in and we need to expect it to happen soon. So we need to consider the change coming soon. And when we are done with shipping the feature, we are converting those orange cards back into blue cards back to source of truth for anyone. So that's how we just keep this system to always be reliable. So this was a screen level.
[00:34:59] And those screen, if you zoom out a little, they exist as part of flow, of sequence where you see user stories here. So it could be an order of a physical card, let's say. And here you will see all the start and end points, how to get into this flow. So it could be a deep link, it could be a specific part from the app, could be a notification, could be anything. But at least you would see immediately all the starting points to enter this flow. And then you have this horizontal progression from the user journey. And then you see all of those screen one by one horizontally, like the default screen and vertically you have the different variants of the screens. So if you have, uh, usually you have screens that may have their state loaded, empty state, error state. And if you have all of them under each other, then you have the full visibility on how your app is actually working. And all of the specification for just the variants just holds the specification just for those variants, most of the information are on the default screen. So we don't duplicate the spec card. And just by doing it this way, by design, by forcing ourselves when we code a new feature to use this pattern, we have a fully exhaustive vision on how the application is actually working at Conto. And when we onboard someone in a specific team, they just have to go read all those things quite quickly and they have the full picture that they would never have otherwise. Except by reading all of the former notion documents and trying to recompile which one overrode which part of the previous one and so on.
[00:36:37] So this was for the front end. But we don't just have front end, we also have back end. So we really want to keep this logic whenever we build something to turn this into value. It's too simple to create documents and more documents to ship one feature. But shipping one feature is is part of our job. But we just have one big app that we have been maintaining for years and we will keep maintaining it for years. So all the document that we write when we are specifying a feature, we want to capitalize on them. So we are we just did the same kind of logic to have one source of truth for all the back end flow as well. And for this, it's very simple, we just, you know those whimsicle charts. You have services talking to other services and so on. We just keep the same logic, but we just add this logic of keeping them always up to date by design. So when we are building a new feature. We just added a color logic, if you turn a gray line which is the in production reality into red, it means you plan to delete it as part of a feature. And all the green lines you add are what you add as part of your feature. So what does that mean? If you are a data engineer or anyone, anyone else who is interested in knowing how the back-end flows are working? You just go to that source of truth of that back-end flow. And immediately you see how it works and you see the ongoing changes. And when the code is merged at the end of the feature, we remove the red lines and we turn back the green lines into black lines. And it's back to source of truth. So anyway, even when we want to ship a new features, backend engineers always write their architecture document. Where they do write those swim lanes and usually they rewrite and they redo those swim lanes every time for every new feature. This way, they just update the existing ones, which makes it much faster than before and also again helps everybody to to find information simpler.
[00:38:34] And one more thing here, in those uh codes that you can see here. You also see that we have the links to the old uh to the end points, so you can directly get the open API documentation of the code. So this is quite straightforward to get information.
[00:38:52] Last example of how we try to build features with this mindset of building for the future. Um, the deep links. This is something that we want to build for every new feature whenever we have to add an email to send us directly straight to a specific part of the application or a notification to send us somewhere specific. So it's quite simple when you start thinking in this logic of building just one time, not just in time, but just one time, um, if you just centralize this information somewhere. For the deep links, it's a very simple example. First, you know all the deep links that exist. So you don't have to recreate something that already exists because it's very simply available. And then you would directly see which stack are using it and all of the parameters properties that you need that exists already that you can reuse and you don't have to overthink how it works because since it's the one unique source of truth and place about deep links that we have.
[00:39:48] Naturally, you get all the answers you need whenever you start thinking about a deep link. So you don't need to overthink things too much to get this information. It's there. So that logic of building just one time is something that really accelerate the way we ship features. Secure secure us to make sure that we are working in the right first time way with all the learnings that we have before. because it's very simply available. And then you would directly see which stack are using it and all of the parameters, properties that you need that exist already that you can reuse and you don't have to overthink how it works. because since it's the one unique source of truth and place about deeplinks that we have, naturally you get all the answers you need whenever you start thinking about a deeplink. So you don't need to overthink things too much to get this information. It's there. So that logic of building just one time is something that really accelerate the way we ship features. securize securize us to make sure that we are working in the right first time way and with all the learning that we have before.
[00:40:16] So now we've been talking about um the value analysis phase. Okay? So now at this point, we have a prototype. We have a success that is defined and we have a fixed cost. So that's the input that we have that we must have when we start this value engineering phase. And the value engineering phase is when we have altogether taken product people who will need to specify very clearly everything in the design that we are building for this feature. By the end of the value engineering, we have all of the front-end functional spec that are perfectly aligned, so it's what I just show you before, those design and Figma with all those spec cards filled for every single element. So there is absolutely zero risk of rework at this point because we are writing down the specs together collaboratively taken product, so there's no risk of uh miscomprehension. that someone could understand a card in a way while the product manager understood it differently. So tech and product are completely aligned. We make sure that we thought about all the emails and pushes around this feature. All the backend flows, just the one I show you before are mapped, we know which flow we are changing, it's crystal clear that it works on the backend and we don't have any more question. We define the API contract between tech backend and front-end and we are clear on the migration and rollout strategy, feature flags and so on. And of course, when we are ready with everything, we can build the pull schedule, so how we are we will organize the teamwork over the weeks. So at the end of this value engineering, tech and product are fully aligned. The scope of the feature matches the the volume of weeks that we planned for the feature and the engineers are ready to get started coding in an autonomous way.
[00:42:07] And now starts the delivery.
[00:42:10] It starts with several different actions in parallel because we have been mapping our cycle, so we have been visualizing all of the steps that we have uh to produce to make sure that we are building a right first time feature. So, the first part we are doing in the tech department is before starting coding is to write a dive in, a dive in again to be in this logic of always working right first time. It's to write that kind of architecture document where we agree on how we plan to code this feature between engineers. Because you as you know, we are not just shipping code into production, we are building code, we have reviews from other engineers and then only when we agree, we can merge it and so on. So we make this first step of diving to make sure we are more right first time on every merge request that we will do later on. And we split all of this work into very small steps, so we are completely in control of our agenda. Then we groom those visual spec, so designers are clearly making sure that every element in the visual spec in the front end are perfectly aligned and everything is perfectly smooth, all the copy is the final copy. Then we ask for the localization in every languages, so we are in France, Spain, Italy and Germany, so as you can imagine, we have quite a few languages to handle in the app. So this is when it happens.
[00:43:28] Then we call for the brand assets, product managers and tech align on the QA plan and then only we can start coding the feature. And by the end of the delivery, we should have zero QA return. So that may look a little ambitious, but actually our objective is to have less than two QA returns per cycle and we are achieving this on more than 80% of our features. So it's actually very much aligned with our ambition to ship auto quality to have everybody very much responsible of what they ship. This teamwork and respect principles that I show you at the beginning. So all of this phase of value engineering empowers the engineers to make sure that we are not forgetting anything, we and that everything is under control. And very fun fact, um well, before there, when we can ship the feature, we go live and then the final step of making sure that the feature has been reaching its uh goal is that we will check if the success that we define in the first place during value analysis is actually achieved. So this is the final phase and usually it takes place 30 days after the go live of the feature.
[00:44:44] Uh, just one thing, we don't have QA engineers at Konto. And this is just a direct result of us shipping quality all the time. This is really our goal of shipping quality.
[00:44:55] Again, if we don't ship quality, we log this as a waste and then we go back into this continuous improvement mindset until we get to where we want to be. So this is really about uh auto quality and people shipping as much uh good element as possible. What about bugs in all of this operating system? Uh today we have 91 bugs logged at Konto. So if you look at it as a volume, 91, it might look big, but if you realize that we are 500 people in the tech and product department, it's approximately one bug for less than three engineers. So we are completely in control of our stock of bug and we want to keep it this way. And for this, we have ownership on the bugs. We are split in functional teams. We have we are split by domain. So if an engineer is working on a feature, if there is a bug that arise after the feature going live, that will be his job to fix it. So this is also a reason that since everybody is responsible for their scope, shipping a good feature also includes shipping no bug. So having this ownership and delegating this to a QA team and so on, and maybe another team who is in charge of fixing bugs, unforce our engineers to clearly have full ownership and control on what they ship. So that's how we really prevent bugs from happening. And we want to keep a low volume of bug and for this, we refuse to add a prioritization label on the bugs that we have because the day we need to actually add a prioritization level, then we have a bigger problem and then we need to maybe stop the production of feature to actually get back in control of what we do. Bug is clearly the fastest way to to lose quality visually for clients.
[00:46:33] So just a quick conclusion of this. Um, visualize your value chain. That's really a key element. It's very quick to do. Ask your teams to write down all the steps that they are having to do their job on a cycle. We have cyclic lives. Choose a specific subject. Here I show you a bit how we ship features, but we also ship scalings, we also fix bugs and so on. But when you have this mapping done, and you can play a game to ask another person in the same team to map their own value chain and you will see that there will be differences and just by mapping it, you already know how to fix a lot of waste. Then empower your team to improve everything. All this waste that we have everywhere along the way, train your team to log this waste. It's not about them, it's about the system. And then let them fix the system. Let them space to break the standards. Let them space to try new things and to make it turn into the new standard of tomorrow.
[00:47:32] And next, protect your team when peace flow. That's very important for the team mood and so on and don't create disposable content. When you create a feature, when you write documents, if you are writing a document somewhere and you are not using it after the very step you are working on, you are working something that will be depreciated the minute you're done with this document. So probably, if you need to write it, it can possibly be used in a way that can scale and remain a source of truth for later. And if you can just reuse a former source of truth to keep it a source of truth for future, then you win.
[00:48:09] So that's it. Uh, that's a quick glimpse of how we work at Konto. Uh, there's so much more to tell but uh we have a short time, so I don't know if you have any question.
[00:48:39] Thanks for the talk.
[00:48:40] Pleasure.
[00:48:41] Um, from your presentation, it looks like you've achieved perfection, but it can't be true. So what are your pain points actually and what are you working on regarding what you show us?
[00:48:55] So, um, going back to this table of waste that we log, today, in average, we log about 20 waste per day. So that's not what we can call perfection. Clearly, but at least we have almost perfect visualization on what goes wrong. So this is the first step to get better and actually uh when you see that we are working on more than 50 KAIZEN at the same time, it means there are 50 subjects that we believe are not where they should be. So clearly, we are not at perfection, but we visualize that very well and that's a great, great step forward. And this is, I want to say step zero to get started at getting better. So I don't know if you have this practice of logging all the waste, but if you don't, it's super powerful. Yes, so no, we are not at perfection at all and it's logged where we are not perfect. Thanks.
[00:49:55] Um, so, um, before logging all the waste, you have to be able to see it, and if it comes from your team, it means they, they can see it.
[00:50:08] Uh, in my team, I struggle with this. Um, um, I'm not perfect either, but um, it's it's very difficult to see waste when you're not used to the exercise. So, did you train people or how did that work?
[00:50:22] Clearly, we train people. We have a lean office at Kundo. We have two people there whose job is clearly to train all the managers. I have personally been training more than 300% individually at Kundo on how to do that, so it's a lot of time, a lot of effort. And before those training, we didn't do it and worse than that, we had people try to run those problem solving session PDCA and so on, but it was understood as a very pain point for everyone, like a punishment, the P of PDCA was punishment, okay? Because you fail here, you have to do a PDCA. So people didn't get the mindset that, okay, the system was broken here, how do we fix it? It's more like, you failed, now you're punished. So it took time and even when we run a poor PDCA, people could feel like it's just wasting their time. So if you don't get the proper methodology to run a PDCA, they will just do one, thinking it's just a waste of time. So training is mandatory here, it's true. Yeah, so that's how we got there, a lot of training, yeah.
[00:51:21] Okay.
[00:51:26] Other questions first?
[00:51:30] I have a question.
[00:51:31] Please.
[00:51:33] Uh thank you for the talk first. Um, how do you train people to your operating system?
[00:51:41] Okay, so uh there's many parts to it. How do we train people to our operating system? First, there is the onboarding session for any new joiners, where we spend a bit of time to explain why we build it this way, where we were a few months before, what changed since then and that it most likely will be very different in six months again. So how we train the people is we explain to them why we are doing it this way. It's not about each step, it's about what we are trying to achieve at each step. So if someone wants to do it differently, but the result is there, it's fine. So how we train them is just by onboarding and then on the Gemba when we go talk to people and see how it actually works by talking to people, then we can get training and improve everybody.
[00:52:28] And I have got a question as well.
[00:52:30] Yeah.
[00:52:33] Um, you started talking about it. My question is, how much energy does it take to maintain such ways of working? I mean, are you working alone with a team? Do you have team leaders in each team?
[00:52:42] Well responsible of applying the conto way in their teams? So, we have this conto way manager training. So every manager has this mindset now. That this is the way to to really improve ourselves. So this is not just about one person, it's about every manager showing the way. Again, it's a personal practice. But it starts from the founders. How we got started with this, it was with the the founders of Konto who started showing the way and then everybody is leading by example for this. So it's really about people getting the idea.
[00:53:12] Hm. Okay. And um how much resistance do you face? Like you have your onboarding sessions, but people are maybe coming from other companies with other habits to work and sometimes they can maybe forget to write the new spec in a range or stuff like that. And do you see it's a daily work? to be sure that everything is done as written in the contour way or it is smooth because all of the training and stuff like that.
[00:53:39] So it's very funny because actually most of the people who join us, it's because we explained to them during the recruitment process that it's the way we work. they just want to get to try it. So usually they are willing to test it by themselves. Of course, at the beginning, they are logging things wrongly and so on, but it's just fine, but at least it's the mindset. So it's just cool and uh that that moves quite fine in this way, yeah. Of course, we have managers who help people doing things right. But it's not a pain to convert people to working in the lean methodology because it's actually a no-brainer that it makes the company move so fast. And I really believe it's one of the reason why we grew so fast.
[00:54:14] Okay, thanks.
[00:54:19] No question. Thanks a lot.
[00:54:23] Thank you.
[00:54:24] Thank you, Jean-Philippe.

Transcript