Edouard Kombo, good morning and thank you for accepting our interview request. For those who don’t know you yet, you are a CTO consultant with a singularity, despite being an experienced developer, you specialized yourself in coaching and management of teams of various sizes. You always accept a challenge when it looks impossible, or when a company is in crisis. This is a very counterintuitive approach, as your philosophy, that’s why it’s always a pleasure to discuss with you. Can you share with us your best experience in crisis management?
Thank you for these warm words.
My best experience in management was in fact coaching. I had to coach a 50 people tech department, in a Swiss company based in Zurich. The guys were constantly late on delivery, at such a point, the CEO asked for help.
In addition, the company lost 48% of their market a few months ago, many employees resigned, the only way to survive was to build new features to gain new segments of their market.
In this kind of situation, listening becomes the #1 aptitude of a leader and the first thing you have to do. While developers complained about unstable legacy code, bad technical choices, old framework technologies, management complained about a shortage of good developers.
The second thing you don’t want to do, is to ignore the purpose of employees involved. I proceed like this: “What are you doing and why are you doing it?”
The third thing you don’t want to do, is to question the tools. If a company succeeded to survive with specific tools, then tools are not the core problem, period.
The fourth thing you don’t want to do, is to throw suspicions of replacement at some people. Why? Because replacing some actors is not a guarantee for the theater piece to change.
Most of the time, when there is a shift between the goals of a company and its results, there is a dramatic shift in culture within the company. And in fact, this company never succeeded to define one.
What was the company trying to achieve? The answer was obvious, “retain his current customers” before anything else. Consequently, the company needed to cultivate a
“retention” and “conquest” spirit.
Now we identified the culture, the fifth thing you don’t want to do, is to run at the rescue of the company like a hero. Why? Because it is wartime, and not all generals are trained for the same wars. If you don’t self-assess your skills accurately, you are a criminal.
The sixth thing you don’t want to do, is to forget about numbers. War is made with money, for money. Every process that puts you away from the company’s culture, costs money to the company and should be treated like cancer. Make everything accountable, give costs to processes.
But be aware, some things cost money in appearance but serve the culture, as a free vendor machine, free breakfasts, etc. Those things should be treated as investments, depending on your culture. The danger is to send a bad signal based upon good intentions.
Seventh thing you don’t want to do, is not to start from a white page. No problems on earth
can be solved by the same spirit that created them. Identify how the company can achieve the best results, with the right investments in the culture, and in the people who incarn it.
Eight things you don’t want to do, is not to make or advise hard decisions. If people are not aligned with the new company’s culture, no matter their history with the company, founder,
co-founder, long-time friends or family, they will have better chances to express their talent outside of the company. It is a necessity.
Once done, only the first part of the job is done. The second part is to align vision with words.
How did you manage this part?
Everything within the company should reflect these traits of culture. It starts by empowering employees to come earlier, leave later through incentives like remote working policy, flexible working hours, social games, a celebration of victories.
The most important
investment to do was in bonuses. If the development team was able to solve all
technical issues within the next six months, build required features the six
other ones, and sales department was able to go 35% beyond their goal, I
convinced the CEO, to give back 20% of the company’s profits to all employees
the first year, and 30% the other one.
The bonuses should represent between 10 and 30k per employee over two years.
Guess what happened? We opened the doors for anyone to live, let go generously those who gave so much of them for the company but never fitted anymore, we created a brotherhood of soldiers, with highly inspired and hungry soldiers, working even on weekends. Everybody knew their what and why from then the how became obvious.
One year later, in 2019, from what I know, all teams smoked their goals, the company multiplied by 2.5 its gross incomes, and I’m really happy with that.
Let’s talk agile methodologies, what methodology do you use on a daily basis?
I’m not a fan of pre-made methodologies at all. The best methodology is the one suiting your teams within your context.
Consequently, I have absolutely no problems to use, sprints for one project, kanban for another one, and a custom made methodology for a third one. All that within the same company.
There are no rules, you have to define your own contextually.
The problem with your approach may be difficulties to deal with deadlines. How do you deal with them?
That’s an excellent question.
I hate the word “deadline”, it does not make sense at all for two reasons.
The first one is, the purpose of a startup is to die, and the purpose of a big company is to delay death. Consequently, you are sure to die personally, or as a company, one day.
The second one is, no one jumps on a task hoping to deliver it the latest possible, ages after the competition, it doesn’t exist.
approach is talk exceptions. I created this term of “exceptions book”. Why?
Because what you’ll face in your way to achievement is, successions of
You have to log them, control them, and not repeat them twice.
Aren’t you afraid of letting your teams perform over-engineering without this pressure of a deadline?
Well, over-engineering doesn’t exist, it’s a myth spread in the mind of engineers to prevent people from asking the right questions.
What do you mean?
If an engineer is a constructor of fortifications, and over means “above”, over-engineering means building a fortification above requirements.
If basic requirements are augmented without extra time, why the hell in the world should I punish someone for going above what was supposed to be delivered?
What people refer to as over-engineering is something inefficient, too complex, unnecessary. In those cases, there are four potential problems, being out of context, being unqualified, having weak guidelines, or having a terribly wrong code architecture.
Whether in a restaurant, at an airport or at a rental agency, no one in the world complains about being upgraded for the same price, yet it’s over-delivery.
Do you aim reaching CEO level position one day, and if yes, what makes you think you are built for this kind of position?
Firstly, you can’t wish to become a CEO unless you are completely crazy or criminal. Good CEOs are crazy in some way. Because the CEO has three main functions: “culture, vision placeholder of any unfilled position”, and one main requirement, “taking wrong decisions very fast”. Consequently, the level of dedication, discipline, and philosophy required goes beyond measures.
Secondly, sometimes it is good to be #2, because you get most of the advantages of the #1, without the inconvenient. If you absolutely want the #1 place, either you have an ego problem, or you are born for that, or both.
Thirdly, not all managers or executives are going to make unbelievable CEOs. And if at a point, you don’t have this feeling of being a sham, something may be wrong with you.
Finally, in my case, I have been preparing myself, day and night, for years, to take over a CEO position. Therefore, I’m walking the steps of knowledge, slowly but for sure.
Consequently, I made a huge amount of mistakes on my road, but also a huge amount of good decisions.