Depuis que je construis des choses, j’ai toujours vécu dans un cycle sans fin d’optimisation — mes routines personnelles, la structure de mes équipes, les systèmes produits. Peu importe l’étape où j’en étais, une question revenait sans cesse, comme une obsession : Comment gère-t-on vraiment le temps ?

J’appartiens à une génération — et à une profession — où on a grandi avec la conviction qu’on pouvait apprendre et construire n’importe quoi. Les développeurs et les builders se sentent rarement limités par leurs connaissances ou leurs compétences. Avec de la curiosité et un accès à internet, tout semble possible. Ce qui nous arrête, c’est presque toujours le temps.

On peut créer n’importe quel produit si on dispose d’un horizon suffisamment large. On peut acquérir n’importe quelle compétence si le calendrier nous en laisse le temps. Mais dans le monde réel, les résultats dépendent largement de quand quelque chose est livré. Ce détail en apparence anodin change des carrières, des entreprises, et des trajectoires entières.

Un produit construit en un an n’a absolument pas le même destin que le même produit construit en trois ans. Idem pour des fonctionnalités retardées de quelques mois. Les opportunités se déplacent, les marchés évoluent, l’élan s’évapore. Les équipes qui passent la majorité de leur temps à réagir n’ont rarement l’occasion de façonner l’avenir. J’ai vu tellement de bonnes startups mourir malgré des idées solides et des fondateurs talentueux. Le runway s’épuise. Il faut assez de vitesse pour décoller avant qu’il ne soit trop tard. Certaines équipes n’y arrivent tout simplement pas à temps, pourtant elles en sont capables. Le produit finit par exister, mais le timing dérape, et la fenêtre se referme.

Au fil des années où j’ai dirigé une agence logicielle, managé des équipes d’ingénierie et piloté le développement produit, je me suis profondément intéressé à la façon dont le temps se comporte à l’intérieur du travail. Je ne cherchais pas tant à le mesurer qu’à le comprendre. Je voulais concevoir des environnements où le temps avancerait avec intention, plutôt que de se disperser dans tous les sens.

J’ai expérimenté avec des processus, des choix d’architecture, des rituels de communication, des roadmaps, et des rythmes d’équipe. Une grande partie de ce que j’ai appris est venu par intuition — des signaux que je ressentais, des ajustements qui rendaient tout plus fluide, des patterns qui émergeaient après de nombreux projets et décisions. Ces insights guidaient ma façon de travailler, mais ils étaient difficiles à décrire ou même à nommer. Ils existaient sous la surface.

Puis j’ai commencé à construire WebWork, un produit entièrement centré sur le temps. Pour la première fois, je ne réfléchissais plus à ces idées uniquement au sein de mes propres équipes — je bâtissais un système utilisé par des dizaines de milliers de personnes pour comprendre leur temps, l’améliorer, et façonner la manière dont le travail circule dans leurs organisations.

WebWork est devenu l’endroit où l’intuition a rencontré des données réelles. J’ai pu enfin voir les patterns que j’avais pressentis pendant des années : comment le temps s’échappe, où il s’accumule, comment le travail change de forme selon l’environnement qui l’entoure. Le produit a mis en lumière à quel point les équipes dérivent facilement, à quelle vitesse les priorités peuvent se dissoudre, et combien la clarté est déterminante.

Cette expérience a rendu une chose évidente : comprendre le temps demande bien plus que de compter des heures. Cela exige une conscience de la façon dont le travail s’écoule, dont les décisions se répercutent sur les équipes, et dont la structure influence l’élan.

Après de nombreuses années à construire, observer et étudier ces patterns, une idée est devenue centrale dans tout ce que je voyais : le temps se comporte comme un système. Il réagit à la structure, à l’environnement, aux attentes et aux habitudes. Laissé à lui-même, il tend à se disperser. Façonné intentionnellement, il crée du mouvement et de la progression.

C’est cette compréhension qui est devenue le point de départ de Builder’s Time.

Le livre est une tentative d’organiser une décennie de réflexions, d’instincts et d’observations en quelque chose de clair et d’utile. Il explore comment les équipes basculent dans des cycles réactifs, comment les produits perdent des années à cause d’un manque d’alignement, pourquoi la progression stagne souvent même quand les gens travaillent dur, et comment les builders peuvent créer des environnements où le temps se transforme en élan.

J’ai écrit ce livre pour mettre des mots sur les questions avec lesquelles je me débats depuis des années :
Pourquoi le travail prend-il le temps qu’il prend ?
Pourquoi certaines heures comptent-elles beaucoup plus que d’autres ?
Pourquoi des semaines entières disparaissent-elles sans progrès dans certains environnements, alors qu’elles s’accumulent rapidement dans d’autres ?
Et comment construire des systèmes qui donnent au travail les meilleures chances d’avancer ?

Beaucoup d’entre nous, qui avons grandi dans cette génération de builders, croyons sincèrement qu’on peut tout faire. La vérité plus difficile qu’on finit par rencontrer, c’est qu’on ne peut pas tout faire à temps. Apprendre à travailler dans cette réalité — la façonner plutôt que la combattre — est devenu le cœur de mon parcours.

Builder’s Time est le livre dont j’aurais eu besoin quand j’ai commencé. Mon espoir, c’est qu’il aide d’autres personnes à voir leur travail et leur temps avec un regard plus lucide.