Youen Chéné
Transcript (Translated)
Hello everyone.
During the holidays, I wanted to read a book that Dimitri Bailey, one of the organizers, had given me.
It was that famous book. Who has tried to read it, that one? Who made it to the end?
I'm still on the second chapter.
So I read another book, which is the story of Jajinsky, redone by an American based on writings that were republished last century. And as a result, I'm going to draw a parallel between the Mongol Empire and start-ups, with everything that... Which is similar to the Lean approach, the Kanban approach, and all that.
Let me introduce myself, I'm Youn Chiné, I'm the Technical Director of Sagi. We are a publisher based in Rouen, Normandy, and we have the entire R&D team there. And I am particularly active in everything related to coders on stage, DevOps for Kids, and associations with startups like NWX.
We'll do this in five parts. A first part to really show you the parallel. Then, what we did and how we did it. And after that, what we learned and how we move toward growth later.
The first point is the Mongol Empire. Why this parallel? The Mongol Empire is an empire that was created in less than 80 years, around the year 1200. They had a logistical system that allowed them to cover between 200 and 300 km per day. They traveled very light; it was already very lean at the time. And they went from the edge of Korea, the edge of China, all the way to the edge of Ukraine, Czechoslovakia, and so on. And they had a hyper-growth economic model based on loot, essentially the plundering of cities to take resources, but also to acquire knowledge. When they had a city or a village, they took the village, sorted the people by trade, and incorporated those with the skills they were interested in into their teams. And then, the city lived autonomously. And they kept going, kept going, kept going. As a result, a great deal of wealth arrived, traveling along the Silk Road and eventually reaching Mongolia.
And it happened very, very quickly. It's comparable to a start-up that goes out to conquer as many markets as possible, establishing a first monopoly on a market very quickly.
They were very innovative in what they implemented. They had a military organization that was highly scalable but also quite autonomous.
And they especially defeated old empires. They were the first to bring down Baghdad, a city reputed to be impregnable in the Middle Eastern world, which was very wealthy at the time. They were the first to do so, and often they were outnumbered two to one by warriors with heavy armor and the like.
And you'll see the parallel throughout this presentation.
My bag is here.
So the first part is very short. Now, we'll have two big parts for this.
The first part is that, like the Mongols, we attack large empires.
We create a platform as a service in big data. So there are already at least two buzzwords in the title. And our competitors at our clients' sites will be IBM, Oracle, and SAP with Business Objects. The goal is to bring down Business Objects. And it will also be Microsoft. Everyone is a competitor of Microsoft. After that, it's different.
And they have a big advantage: they have a lot of money in the bank. They can execute whatever they want with as much money as they want. They have a big disadvantage: they are not fast.
The vision has been somewhat lost. We see this with the change at Microsoft; the vision is clearer, but execution is slower. And the customer is just a number.
We can make a difference by being agile and fast because we are attacking a market. We don't engage in politics because we sell a service to a customer. We attack a market. And the other point of these details is also to take care of our customers so they are no longer just a number.
And so, there is a study available on TED, you have the link at the bottom, you'll have the presentation, about what makes a start-up successful. So, he conducted a statistical study on quite a few things. And what was revealed was that timing was the most important factor. It's not the amount of money raised, it's not necessarily the idea or the business model, but it was really the timing.
For the more detail-oriented, the score is also over 100 because there are multiple possible answers each time. And how do we achieve this timing? What am I going to use? Am I going to use a good V-cycle? By designing, doing, testing, and putting into production. I like the English translation, which is 'waterfall,' meaning you always fall to the bottom.
It doesn't recover.
And why agility? Because for a start-up, it's a matter of survival. If you release your product too late, you spend 500,000 euros, 1 million, 1.5 million, 2 million in budget for R&D. If you arrive too late and everyone has taken the market, you've lost the money. It's really a matter of survival.
Are the people you've brought on this adventure—salespeople, developers, marketers, HR—all those you've brought on, coming for nothing? It's really a matter of survival. So we have Scrum, which is essentially iterative in stair-step fashion. We set the pace and improve.
Personally, I'm not a big fan of Scrum. It's good to start with because there are rules that reassure, especially for large groups and so on. I needed something that took more context into account. So we went more with Kanban, meaning we start from a current way of working at 2-3 and improve the process based on the context. Context is something that will come up again in the presentation. How do we adapt to the context? Context is important. How do we adapt to the terrain? How do we adapt to the team we have?
And to always be ready to change and adapt. You always have a matter of survival.
Because I'm going to take the Darwinian part, meaning it's not the smartest who win. If we look at companies that have succeeded, often there are not very smart people at the top, but they just executed, they didn't ask too many questions. They adapted very quickly to the terrain instead of making big plans to predict everything.
And the other point is that we did lean start-up, meaning we delivered a first product that wasn't too expensive to develop. We put it in the hands of, and even sold it to, first customers and users. We gathered data and corrected as we went along. And we evolved our roadmap as we went along. We still had a vision, but we enriched it over time. The goal is that we started with what we call a minimum viable product. So often, you must not forget either the minimum or the viable. The minimum, we tried to put everything in it, or the viable, in fact, it's useless, it has no value. It must bring value, something for the customer. We'll see how we did it. And since we're at The Family, one of the accelerators, it's 'fake it until you make it,' meaning everything doesn't have to work behind the scenes. I take companies like Full Contact, or like many assistants, Full Contact scans your business card and automatically enters it for you. Behind it, there will be deep learning algorithms.
But the truth is, when the machine can't handle it, it goes to a human who will write it, essentially, to teach the machine. Except that for you, it's transparent; you don't know it. And so, they mimicked part of the functionality to see if the market would accept it or not.
And it can be very hard to realize after a certain point.
It's a real pain for those in the back.
And especially, we come from French engineering schools and universities where we learn to get it right the first time.
There is a company called Michelin. The motto for production is to get it right the first time. It's difficult to apply that to computer science. So the goal is to create something that works, even if it's not perfect, but it doesn't address the 5% of needs on the side to make trade-offs. And when you put a product on the market, you're not embarrassed by the product. Maybe you'll deliver too late. Maybe you'll polish things too much. This isn't valid for everyone. If you're making high-performance hardware, you need it to be almost perfect the first time. If you're making software that's released in a fast-moving market with a lot of competition, you have to test the market. And above all, you have to take the feedback loop. That's the most important thing in a startup. It's really about taking the data, doing it, doing it, doing it. Here, we're going to deliver a version based only on feedback from clients, integrators, and those who work internally with clients.
From June, July, August. We took that, took all the changes, and integrated them so they would be available. And above all, we talk to the client, we go for it. That is, I go in the mode of not selling anything, just taking feedback and seeing what's wrong. Everyone focuses on user experience.
For example, in the 2000s, you had a lot of applications. You'd take IBM to install something, it's full of next, next, next, you don't read anymore, it's not pretty, you're lost, there's too much information on the screen. It requires working on something more pleasant on the screen.
How did we do that? Because the goal, no matter the agile method we use, is to deliver value at every stage. How do we make an incremental version that is usable? Moving from 'I assemble components at the last moment' to 'I have something that works.'
This is Sagi Manager, it's used to manage your Big Data production with all the data science processing jobs on top of it. This is version 1.0, the first long-term support version we delivered in September.
We started with a first version, I dug up the screenshot a few days ago, and it looked like this back then.
I think it was me who did the overall design.
And we had two main functions for the first client, which was to run Talend jobs and Java jobs. That's all. After that, we had the entire storage part, but that was okay. And we sold that to a first client. The first version was close to a first client.
And that was version 0.4. Versions 0.1 and 2.3 never worked. Those were the first prototypes. They didn't work together. And it was really version 0.4 that we had something working. It's called Darwinian. It has to survive. Two months later, we delivered a second version where we added Spark. It's the most hyped framework in Big Data for the past year and a half, for those who don't know, and other functions.
Then, we came out with a new interface that's a bit prettier, a bit more visible with a little less information. We added R, we added Docker. R is for statistics. And now we're on version 0.6, we should be in November-December from memory. And then another version after 7.5 months. So you see, it's one or two months each time. Be careful, it's a platform as a service. Meaning it's not just a mobile app that we deliver, it's a platform to host applications. So it has to work, and it has to be stable. Given that the first client came from retail, so for those who don't know retail, it's not very expensive, but it's very demanding. So it has to work.
And finally, we made another delivery with a new client, we added security. Because it was a bank. And we suffered a bit, we took an extra half month, a full month. And even the next version, we added more security. To ensure everything was well secured, identification, authentication. So we're always on a cadence of one to three months. And since we're a startup and we want to attack the market, we even made hardware.
A first version of hardware. It wasn't us who made it; we outsourced it. But to have something ready for January 16th in Las Vegas, we had to hustle, cut some features, but we had something presentable, deployable, and that brought value. That is, having your data
in the clients' data centers, without it going into Google's or Amazon's cloud. For example, in banking, by regulation, they can't take data out for certain types of data, or they'll be fined within a month.
After that, we released another version. So, we had our nice bike with lots of advanced features to have well-managed and versioned jobs like an Android app, etc.
So we took names from space conquest. So Asterix is the first French satellite deployed in space. You'll see with the name at the end. And now we have more than 10 instances in production, so we have a bit more revenue coming in, all that. We do POCs with clients.
And we're gradually getting closer to 1.0. Well, it was almost ready, so we released an intermediate 0.10 because the timeline was starting to stretch, so we said, OK, we have 4 features, we release them, we have a version, we deploy. We had value to deliver that was in stock. If your development is in stock, it has no value.
And we made a new interface to finally reach A0, so Apollo 11, the moon landing, which was the CEO's dream from the start. And with final features like data pipelines and all that. So that's still every 3-4 months. And finally, this month, we did a Series A, we raised 4.2 million. To be able to attack the market with hordes of salespeople, hordes of marketers, and new developers to strengthen the team. To be able to attack that, to be able to attack the empires we had seen. But instead of doing a two-year project, we delivered value every two or three months.
So it's beautiful like that, but how did we do it?
So we're going to tackle the third part.
Basically, the art of war. What you see is a diagram of the tactics that were used almost on the spot by the Mongols. Where, in fact, a small troop lures the enemy army. They flee to a point they had decided beforehand. And then, there are armies that attack from the side.
That's how they defeated large armies on horseback, with heavy armor in Ukraine and all that. And along the way, they stopped in this part of Europe because Europe was a very poor region at the time. The economic model was loot, it was plunder. So they stopped there; otherwise, they would have gone as far as France and all that. Because in the Middle East, it was much richer. Basically, the art of war. What you see is a diagram of the tactics that were almost improvised on the spot by the Mongols. Here, in fact, there is a small troop that lures the enemy army. They flee until a point they had decided beforehand. And then, there are armies that attack from the side.
That's how they defeated large armies on horseback, with heavy armor in Ukraine and all that. And along the way, they stopped in this part of Europe because Europe was a very poor region at the time. The economic model was loot, it was pillaging. So they stopped there; otherwise, they would have gone as far as France and all that. Because in the Middle East, it was much richer.
You can do anything—V-cycle, Kanban, Scrumban, Scrum. What matters is the code you deliver.
If your code isn't good, if it smells bad, if every time it's hard to add a feature, to do everything you want, you won't be agile, you'll take time to release new things. You're falling behind. This is a presentation by Venkat, who is undoubtedly an heir of the Mughals. Basically, it's an old part of the Mongol Empire that arrived in India and ruled India for three centuries. Who gave a presentation at the last DevOps. It's in English; I've put the link for you. Basically, you can't be agile if your code isn't good. To do everything you want, you need to work on your code. So we're going to talk about technical debt. How do we manage this technical debt? How do we ensure we can deliver things? Basically, if you have too much technical debt, you have a big ball and chain on your foot.
And in 18 months, you're dead because you can no longer deliver new features. It takes 2, 3, 4 months longer, and competitors catch up. And we saw that we arrived a little early. For the past six months, we've had quite a few competitors showing up. So how do we stay as agile as them? Because they just started, so they have no code, no legacy.
After that, you can say no technique. I'll do my thing perfectly with best practices and all that. After that, there are plenty of best practices in computer science.
If you do that, you're a living dead. Meaning you'll never release your product. And you're dead, but you don't know it yet. Anyway, you'll arrive after the others.
And finally, one of the other flaws I find we have in France is over-engineering. I went to a mechanical engineering school where we made diagrams with bearings and all that. So we were very good at making complicated things.
And over-engineering means you never finish because it will never be released. And above all, it's a matter of context. What interests me in business is adapting to the context. Meaning you won't go mountain biking with this. I'm telling you right now, it's an airplane.
It won't be adapted to the context.
And so the goal is to have the right level.
How did we implement this?
What you need to know here is the different tactics that were implemented by the Mongols.
Attacks, circular attacks around the enemy, repeated attacks so there's never a stop, feigning retreat.
There's an important point in this organization: in fact, you have autonomous teams.
Here, in fact, you have autonomous teams, other autonomous teams, other autonomous teams, which can adapt to the terrain.
The goal is to start building autonomous teams with a specific mission. We give them the why, what they need to achieve. This revisits things we saw yesterday, for example. The goal is to adapt to the terrain.
They can choose their language, their Kanban, their way of working, etc. And above all, they are responsible for technical debt.
Because they feel the pain of it. They're the ones who have the problems. They're the ones who make it so that when you need to add a red button in a certain place that does something, if it's complicated to do, they feel it. So for now, they have one day a week. My dream is to make it two or three days.
To rework this, to make it faster and all that. And it goes even further: they even added a team for small new features that I hadn't seen or asked for, but which are very useful for a user. For example, they halved the time it takes for statuses to appear. And when the salesperson did the demo, they were happy because it was much more dynamic. But it wasn't requested in the stories. They did this in addition because they reworked the engine behind it. So it creates a bit of local innovation.
And above all, what I ask is not to ask for permission to do something. If you see something isn't good, you need to fix it right away. Or plan to fix it. Because it's the survival of the company that's at stake.
We're not in a bank or an insurance company where money comes in on its own. Here, we're searching for an economic model. It's more complicated. So we need to release this on time.
So we've set aside time every week. And after that, the goal is that we're going to talk about code. So we're talking about automatic testing, unit testing, testing parts of the code, integration, testing the operation of blocks. If you don't have any, so at the beginning, we're a startup, we're 24 years old, we do Node.js, we go at full speed, we make the first thing. After a year, it becomes complicated because every time we do something, we break something else. We're not good enough at this yet. And the problem, if we don't do it, it's going to be complicated for everyone.
Meaning in the end, it won't be released either. So it requires work, it requires being an expert in your craft of coding, in your art of war.
Continue with another part.
We have the software part, but we also have deployment parts, support parts, even recruitment parts. We have internal Kanbans to do this. We follow the flow. Recruitment is when someone submits their CV, they are selected or not. Then they have a qualification interview, then with the team, then with HR, then there's negotiation, then hiring, etc. So it's a flow where we eliminate step by step.
And it's quickly a lot of volume. And what we do is that at the beginning, we experiment with Kanbans using Trello because it's very fast, easy to do, and all that. It's the same, in fact. Not at the same date, but it's the same. And after, once we're roughly stable, once everyone has understood how we do it, we productize it, if I may use the anglicism,
in Jira because in Jira I can do lots of statistics. And most importantly, I can extract the data much more easily than on Trello. And it's fully configurable.
And since we work with big data, we have an internal data lake where I dump all of Jira, I dump all of Jenkins, all the time tracking, so I can have the support percentages and all that, and we can do statistics. And what we're trying to do with the project managers here is to not base the estimates we make for our clients' era on how long it takes to test such a value and so on. Basically, in the past, such a type of story took so much time to complete at 80% or 50%. Basically, what we can say is that if we sell support, if you have so many days, you have a 70% chance we won't exceed the time.
If you sell your day, you're at 90%, so you're good. If you sell your day, you're at 40%. The goal is to share the fact, the risk of committing or not. And that's based on statistics.
We'll come back to this a bit later. Finally, what you need to know is that what made the Mongol Empire successful was logistics.
That is, it was a pre-internet, meaning they knew how to travel light, and in fact, they were originally on the Silk Road. And in fact, as they conquered more, they created many routes where their goal was to bring the maximum of wolves, goods, to the center, to the equivalent of Ulaanbaatar at the time. And for that, they had to circulate information very quickly, but also circulate goods and techniques. In fact, they never invented anything. However, they knew how to reuse what was available to the maximum. They integrated several religions, they integrated catapult techniques and so on. They integrated new methods for forging swords and so on, but they took that as they conquered. That is, when they took a village, they kept the engineers of the time, the craftsmen, to do craft and improve it.
The equivalent internally is that I am currently building support teams to try to accelerate the others. For UX design, for operations, soon for HR.
To accelerate the other teams' Kanbans, to bring specialties, to accelerate the others. This reflects one part of the Spotify organization. Basically, the goal is not for QA and operations to be bottlenecks in operations, in delivering things, but to be accelerators. So they are more like support teams. The goal is you do it, you put it into production. You are responsible all the way. If you code poorly and you have a lot of support, it will be your fault. However, you can't be an expert in UX design, you can't be an expert in Linux, in networking at the same time. So there are teams to help them internally, to try to accelerate that.
You should know that the Mongol Empire lived like this for a long time, and it was also the cause of their downfall. Because in fact, why did the Empire collapse at one point? It's because the plague appeared in Europe. And since they had very significant logistical means, where the slightest good came from the other end of Asia, from the other side, it also brought the plague at the same time.
And so, when they realized after 50 years that it was the source, they cut off the communication routes. When they cut off the communication routes, They cut off the wealth.
And when there was no more wealth, the populations revolted. And it collapsed like that. It collapsed because the logistics were very good. Because it wasn't isolated, it was very communicative. And now, the upcoming challenge is really how I make admins 6 communicate with developers so that it works, because I'm changing the scope of admins 6 a bit.
Fourth part, now we'll see everything we've learned. It will be quite short. Check the time.
So, wartime, peacetime.
In armies, there are always two organizations to be fast and then to hold people accountable. If you read many management books, many are books by American military personnel.
We'll see one shortly. And like the Mongols, I attended another presentation, that of Café Netflix, not very long ago, on their culture. Well, it's not 2001. About their culture, it's how they functioned internally. So there are different points. And I will talk again about context, the context and control part. Because then, we created autonomous groups, but for some groups it worked, for others it didn't.
Basically, the principle, if you make a team autonomous, instead of telling them, as in yesterday's keynote, to build the bridge, it's go to the other side of the river. Then, the team is autonomous to solve this problem. That is, if there are problems on the ground, they can adapt to it because they know the ultimate goal.
And the goal of managers is that the context is good enough for people to adapt, for people to be heroes and competent in their work.
And so the context allows... It's basically the new management methods. We will provide a context, we will be able to measure what happens, we will be able to give autonomy and have a learning organization. Control is you do this, this, this, this, this, this, and you don't go beyond, it must be executed. Basically, this comes from Taylorism, it's for all that is productivism. Except that producing software is code, it's not productivism. That is, we do something new every time. If it's the same, we make a loop.
And the problem is that we apply methods from the last century, but which are for factories where we always make the same part, where there is a takt time, a pacing, and it must come out.
It's more complicated here. However, in the field, sometimes there are exceptions. And the exception we had was when people are learning their craft, are learning their different levels.
We had some problems.
And so, we must always adapt to changes.
And in fact, we had teams, especially on the product, we hired experienced developers.
Where the autonomous context worked very well. In textian management, there wasn't much to do. There were a few arbitrations, but it worked very well. We have younger teams, especially in the data science part. If you want to hire data scientists, it's hard to find experienced people. And it was more complicated there. So we have two different contexts. Here, we will keep what I presented previously, but for now, we will put more control in place while people learn. This reflects the shu-ha-ri which comes from martial arts that we often use. Shu, I learn the rules. Ha, I master them. And ri, I go beyond the rules to invent. Here, I have people between Ha and Ri, and here, I have people who are learning. And in this context of autonomy, we had quality problems, deadline problems, many things were not going well, so we put more control in place. It's, you use these tools, you do this, this, this, your behavior is this, this, this, we standardize it. Whereas here, they have their behavior, they modify it according to their needs, according to their problems. And here, we are more in a coach, mentor position to make it work. At the beginning, it's really the apprehension period. Maybe in a year, six months, it will move from here to there, we will free up more things. We had to put more control back on certain parts. And that's really what the field taught us. Right now, I have people between A and R, and here I have people who are learning. And in this context of autonomy, we had quality problems, deadline problems. There were a lot of things that weren't working. And so, as a result, we added more control. You use these tools, you do this, this, this. Your kanban is this, this, this. We standardize it. Whereas here, they have their order, they modify it based on their needs, based on their problems. And here, we are more in a coach or mentor position to make it work. At the beginning, it's really the apprehension period. So maybe in a year, six months, it will shift from here to there, we will free up more things. We had to add more control to certain parts.
And that, it's really the field that taught us.
Last part, how do we scale? The problem with a startup is having good scalability. Because why do we raise money? It's to run faster than the other.
Otherwise, we create an SME and grow organically, but we will grow little by little. Here, the goal is to go very fast, to run with the horses across the entire steppe so we can cover all of Asia and Europe. The Mongols were very disciplined in their approach. That is to say, they traveled very light, they had dried meat so it would be as light as possible. And then, they had resupply points when they paid villages, of course.
And so we will go toward Japan, which the Mongols never managed to conquer. There was the sea to cross, and they weren't in their usual context, they never succeeded. They lost a lot, a lot of men over that. Muda is waste, but in the broad sense of the term. It's not that I produce something useless, it's also that I do something useless. I do something that doesn't add value.
We are in a startup, I work in large companies, it allows us to get rid of negative people, people who don't ensure quality, and especially not to hire them in the first place. And here, we are in a particular moment, we raised a lot of money, we are no longer visible, so as a result, we have quite a few parasites showing up. We need to be able to select from that. And without seeming like it, that helps things run smoothly. I don't know, do you know the fable of the chicken and the pig or not, here? No?
Actually, it's a chicken that asks a pig, can we start a bacon and eggs restaurant?
And the pig doesn't want to because it's his ham, it's himself who will be sold. And the chicken just lays eggs. So he's not involved, he doesn't lose anything. For example, when you make a cream delight and all that, the chickens are those who come but aren't involved in the project, who have nothing to lose. So they can make a mess, anyway, they aren't impacted.
The goal, since we are small, is to eliminate that. My job before, as a development team manager, was to isolate the team from parasites. It took 50% of my time. And I wasn't producing any value. I also removed all architecture meetings.
In companies, you have people in ivory towers who decide on the architecture for everyone. Here, it's the team that chooses its architecture.
And it's a fundamental trend.
For example, groups like Criteo, their architecture meeting is a mailing list where they launch things. For us, it's a Slack channel where people change things. We test, it works, it doesn't work. It's really a Darwinian approach.
There is no QA as such. Here, we will integrate testers, but to speed up, to help teams test better. To do part of the test plan, but certainly not to block production. So as not to slow down. It's a difficult challenge, but we often see companies with a quarter of testers for three-quarters of developers, and it doesn't work, there's a bottleneck. At Apple, it's almost the opposite.
In the product part, I remove project managers. The teams are autonomous. We have project managers to handle POCs with clients, to manage the relationship, to do some estimation, etc.
But here, the profession is even changing. We are moving more toward product management, support on needs, and all that.
And finally, the first one who gives me an estimate or a glove on an internal product gets a severance package.
For me, that has no value. We won't deliver the product faster.
And we can do it because we are small, because there isn't much politics and all that.
When we work with schools, it's a bit more complicated because that's what they teach them. We do projects with schools, with students to test things. And here, we are working with the university. And here, I'm waiting for them to finish the specifications because that's what the professors ask of them. I would just like to have a demo to see if it works or not.
Anyway, I like to move the team by saying stop overthinking, execute what you know how to do. Footballers train 80% of the time for 10% of the match. To do the little pigeon assists, they train a lot. In development, it's the inverse proportion.
I want unit tests to be almost automatic, that we know how to do them. Rather than asking questions about how I architected this or that. That way, the time dedicated to brain time is dedicated to value-added things. That is to say, you have to train your teams to go faster afterward.
And of course, we have plenty of kanbans everywhere. It goes on our products, on the era, on support, deployment, whether it's deployment tasks or continuous improvement projects on the infrastructure.
We have about 20 boards internally, including client POCs. In fact, they follow them, we pop in, they follow everything.
And so on the product, we have...
No, it's good.
Knock, knock, knock.
Well, it's not the right one, but I'll illustrate it orally anyway.
So the goal is that the first thing is opportunities. I did a bad copy-paste this morning. We put stories, which are ideas, like this. Then there's a parking lot, where we'll do that later, because it's legally blocking, because it's too expensive, etc. Then there's the part 'I write the story.' And after, it's ready for a release. And then, I put it in a prioritized column for all the teams.
Where the goal here is, you see here, here 1 is 9, 4, 1, 1, 2, 1. Here I'm talking about mini-releases with the minimum of things available. Before we had 15, 20, so we put 1, you saw it took 2 months, 3 months to do. Here the goal is to reduce to the minimum.
And then, it arrives very smoothly for them. They display only the releases that interest them. And then, it's a fairly classic part. I do, it's blocked. The validation part, where then, myself and then the product managers will validate the overall functioning of the story, if it matches.
And then, there is a code review. After that, it goes to testing. After that, it goes to release. And then, NRT stands for non-regression testing. It's for all non-regression testing, not on new features, but on what existed before.
And finally, it's delivered to the client, and then it's ready in a delivery wagon to be deployed to our environments, on the clients' appliances.
For the clients' era, we have something a bit simpler overall. Here, you review the opportunities and all that. I can display the client because it's one of our investors, so I no longer have an issue with it. And here, we will have refused, in progress, in review, done. So something a bit simpler. Basically, it's Scrum-like in terms of columns.
And in deployment, we have something even simpler, where basically, I create a new platform, I add users, I add such an option, I add security to such a platform.
And here, it's more about infrastructure operations. So, there will be something very simple for now. And for example, for the infrastructure part, it's a job I know less well. So what I asked the administrative team is that when you do a task, you create a Jira ticket for me, so I can see what a task is for you. And in any case, you fill this out, it just helps me to know. Then after, once we're well-practiced, we'll organize this a lot. Because it's something that is less in the culture of administration, the administrative team, and so on. And yet, how to be very well-adapted?
And finally, I have a CTO board where I can see everything that's happening everywhere.
With a filter on everything that allows me to identify what is blocked, what is in progress, to see if there are too many things in progress or not.
And notably here, I have a problem.
Anyway, I've never talked to you about the physical board. We still have one left. And it is destined to disappear.
Because actually, we have...
Jira automates everything. We have a lot of things in it. We will...
Often, there are people who are remote, traveling, and the usefulness of tracking tasks is less and less. Basically, we will remove the post-its, which are the cargo cult of agility. The cargo cult is mimicking thinking it does the same thing. We will hardly have any post-its left. However, I think we will add more information radiators.
On lead time, time to deliver, quality, etc. And so, there is a video projector that will arrive to replace the last physical board.
However, I have a large Jira bill.
Like many startups, it's a bit my central infrastructure.
And especially in France, worldwide, it's hard to recruit developers, talents, good developers. So we will start with a first team to recruit remotely. GitHub is organized this way, 37signals now, Basecamp is organized this way, so it's a model we will test on one team. It's difficult to change the culture. Which means we need to be more formal in what we share and so on. When we are remote, we need to communicate more. But we will do this with a team of seniors at first, with teams, to improve this. And when we have remote work, it means that physical boards necessarily disappear because they are less up to date.
And especially for support, it allows us to expand everywhere. Let's return to the Mongol.
Here, you have the scalability algorithm of the Mongol army. Basically, you have squads of 10.
These 10 squads come together to elect their leader, who is the Zoun, who themselves are grouped by 10 for orders, who will be with the Mingam, and then go on to the Tumène. So here, we are at 10, 100, 1,000, 10,000, and above, you have the Khan.
So the emperor, the king, and so on. And so here, you have a very fast command chain to be able to give information and give an order. And then, you have squads that, however, have a mission and have the power to adapt to the terrain based on that mission.
So Spotify didn't invent anything, basically.
It was said a while ago. And so how do we achieve this scalability? The goal, as I said, is to have autonomous teams, in their technology, in their Kanban process, and so on, but also in recruitment. In recruitment, I act as a recruiter and at the end, I handle the negotiation. In the middle, it's the team that chooses its... Next collaborator or the other way around.
And basically, this allows for autonomy, making people responsible. What we will change is that instead of having teams of juniors and seniors, we will try to mix them, so there will be more automatic learning and fewer autonomy issues.
To this, I add a layer of management. So here, I will talk about the tools of the manager, Manager Tools, which comes from a former American military officer. Where there are fairly simple techniques that allow for recurring communication throughout the year with your collaborators.
With one-on-ones, meaning you see someone every two weeks, every three weeks, every week, it depends, where the first quarter-hour is dedicated to the collaborators. And you are in a listening position. And in a position to prompt to open up topics and so on. Then, you can give feedback. Feedback is when you have such behavior,
then it's good because the team works better and it's rewarding for everyone. However, when you have such behavior, there is such a person who is offended, sulks for two days, and you don't work. And you don't get along. So it's really about behavior. And finally, there is the coaching part to evolve toward new positions, to develop new skills, and so on, for the long term. And when you do this, the annual review becomes almost a formality, because normally all problems have been addressed beforehand, if you have done your job well.
Because usually, annual reviews are a bit like a pressure cooker.
And finally, you have two techniques, like the DISC. I gave you a link to a site that does it. DISC, meaning Dominant, Influential, Steady, Conscientious. These are communication styles of people.
For example, I am more dominant, my financial director is more steady. So sometimes we clash a bit. And that's life. And so we try to adapt. And generally, CEOs, salespeople, we tend to be more I's, influential, relying on the network.
And the goal is to have scalable management. That is, I differentiate the part
managing a roadmap, managing a project, and so on, from human management.
The person who is responsible for executing the roadmap doesn't want to do management for me. However, there is one person who really likes that.
And who, right now, is at 4 people and will firmly increase to 7-8. And then, we will train a new Padawan who will start with 1, 2, learn, make mistakes, learn, and climb up to 7, 8, and so on. We will create management circles. The goal is that if there is a problem, it can be reported within almost a month so that we can resolve it.
Because when you are a manager, the goal is not to know about the problem afterward, but to know about it as early as possible.
We also have an internal tool that allows us to gauge the team's morale.
I think there are good correlations with Monday, Friday, and the weather for now. Or production deployments.
And so, at the management level, there is the sales part, there is the finance part. And my role as CTO is to ensure that the roadmaps delegated across all teams are well aligned.
But before doing that, we will remain humble and just try to deliver several times a month. To deliver value even faster. That's why what you saw had 1, 2, 1, 2 stories per release. Whereas before, where I was before, it was more like 40, 50, and there I had 10, 15, and that's still too big. We deliver value incrementally.
There are companies like Criteo, Les Furet, that do 1600 per month.
Well, those are not the same teams.
And our goal is that we are still a small team, but if we deliver something several times a month, we can deliver value more quickly and especially not have to support old versions and all that. And so, with less support, more features, and engaging the virtuous cycle, we almost did it in October, we hit a big snag, and once we fixed that snag, it should be good. Because actually, there is version 1 that needs to be released, and there are 3 developers on top of that trying to solve the problem. Meanwhile, having 4 or 5 people on it is useless. So there is one person who started version 1.2, and version 1.2 is almost finished, in fact. Because, as a result, it is on good foundations. But version 1 just needs to be released because it is the internal engine. It's the unsexy thing that nobody sees and that needs to work very well. If it doesn't work, there's no point in doing the rest. And if we just manage to do that, we will be happy and maybe Judge Inskan will be proud of us. Thank you for your attention.