Saagie will be at the World IA Cannes Festival from February 9 to 11→ Come and meet us, contact our staff!


CTO opinion column: “Sorry, but it’s not the tech”

Often when launching a tech/IT project, a team will focus a lot of time and energy trying to figure out the best technologies to use for the job. As a CTO, I have learned that success is a lot less about the technologies you select and more about how you organize your teams to deliver your plan. Every chance I have, I tell people: “Stop focusing on managing a ‘project’ and start thinking in terms of ‘product development’.”

The story

As a startup we are in accelerators. Those accelerators often mix startup people with people from big corporations. And of course we talk to each other.

Recently, one of my contacts in a F500 asked me for some guidance on one of his projects. This is how our interaction went:

-“Hey Youen, my IT team has been working on a project based on Java for 8 months, and thus far, I am not pleased. So I asked a friend of mine who is a Node.js developer to take over. He only spent a week end on it and what he delivered was better than what we had. Can you help me find a way to encourage my IT team to use node.js please?”

-“Sorry, but I don’t think your answer is a matter of technology choice.” (disclaimer I am Java User Group Leader)

-“What do you mean?”

-“It’s not about node.js being better than Java or not. It’s not even about how good your developers are.”

-“Well… What is it then?”

-“It is mostly about how you approach things organizationally and set up your teams. In one case you had a “waterfall” approach with your teams trying to plan everything ahead of time. They wanted to make sure that everything had been thought about but they ended up distancing themselves from ‘users’. It was harder for them to gather their true requirements and to take into account the changes they would regularly request. In the other case, as the product owner/manager, you were directly talking to the developer and working closely with him in small iterations. Your main focus was always the project success with considerations such as “will it work for the users ?”, “is it adapted to the market ?”. In the end, the choice of the technology to be used was not what truly mattered, it was the approach you took with your friend.”

-“Alright, but what do I do ?”

-“Now even in java you can bootstrap an application really quickly, so you can compromise on the technology, but do not compromise on the approach. Don’t change the way you do things, keep your focus on the market, on the users.”

-“OK. I’ll give it a try.”

After a discussion with the IT team, not only did they change their approach in working together but he also got the budget to hire a freelance developer.


As a CTO, a former architect and still a developer, I have spent more hours than I can count in architecture meetings. I can say that 70% of the time those meetings are not as valuable as they should be and 90% of the time, the technical architecture defined does not resist the requirements of a real implementation, anyway. Moreover, tech solutions are like fashion trends, they change pretty quickly. But a cultural & organizational shift is very slow. As a matter of fact, this is exactly why we (Saagie) provide a maximum of no-cost/open source technologies, so you are free to change your plans whenever you want and switch technologies very easily. This way, you always have a variety of options available to adapt to your context and react to challenges.

The reality is too many IT projects still fail or are delayed or over budget. Many companies are still stuck in the good old “waterfall” approach. However, if you look at IT literature, even in the early days people were suggesting alternatives. This is the case with in the famous Mythical Man Month. If you go back to the 1950s, even the Edward Deming books can help a lot.

Sometimes, It can feel like our industry does not learn….

If you are interested in startups you probably noticed that in “the story”, I was alluding to the topics covered in the Lean Startup book of Eric Ries. Yes. Yes. Yes. Yes. Just don’t read it, do it!

To sum up the Lean Startup’s approach :

  1. Start with an idea.
  2. Design/Do a first scope
  3. Measure behaviour
  4. Learn and decide of new scope. Go back to “2”.

Lean Startup Circle

This is actually not so far from from PDCA/Deming’s wheel :

  1. Plan (Plan a new scope/idea)
  2. Do
  3. Check (Measure).
  4. Act (Decide on a new scope)
Deeming wheel, PDCA

One could say that ‘agile’ development is already mainstream and that I am not sharing anything new here. However, my point is not about giving attention to the “agile” methodology, it’s about companies making sure that they distinguish between trying to implement ‘agile’ and actually being agile. For example, the most common practice I observe in companies implementing ‘agile’ methodology (and that bothers me) is the scheduling of meetings for planning the approach. Why do I bring this up? Because those kind of meetings are the closest thing to a ‘waterfall’ methodology. By being agile, I am referring to having accomplished a cultural shift. At Saagie, meetings focused on planning are the last thing we will want to do. I am not suggesting that there are not useful or needed. Of course, we do have some of those meeting; But, at the beginning of an initiative, I only focus on iterative delivery (provide value) and code review (quality) not on planning.

If you want to read more stuff on the topic, there are now plenty of presentations and resources on Cargo Cult Agile.

If you want to gain more theorical knowledge, I advise you read this thoughworks article on the project mode versus product mode.

To sum up, project thinking is mainly associated with the waterfall cultural approach (plan everything & complicated organization), product development mode is mainly based on the lean startup & agile approach (get a stable team, a simple organization and adapt to the market and customers).

Today, this is one of the most important transformations for IT teams in big organizations to operate: Evolve from a project mode organization to a product mode organization. By the way, startups have had no choice, they had to adapt to their markets or die and naturally, they have adopted agile development for some time. The success of tech giants such as Google or Facebook in delivering the best products is the perfect illustration of the benefits that large corporations can yield, by adapting the way they do things. That is hopefully if they do it before, a new player takes their market share with products, based on ‘agile development.


Four months later after my initial conversation with my friend at the F500, we had a quick hallway conversation:

-“Hey, I saw that your website officially launched last week.”

-“Yes I am really glad, we worked very well and very hard with the developers.”

-“You do realize well that the real work starts now though? Now, you are going to need to iterate according to the response of your market.”

-“Yes I know. I am already looking at metrics to monitor the response from users.”