Un seul être vous manque et tout est dépeuplé.
– Lamartine
Disclaimer : This article is a translation of an article originality written in French. So it contains some screenshot with French language in it. You have been warned.
Introduction
At enioka Haute Couture, we build software hand in hand with our clients’ teams. We bring our expertise in application design and in structuring development activities.
As such, it’s quite common in our engagements to set up a team composed of an experienced Tech Lead supervising both the client’s developers and Haute Couture developers.
This organization aims to create applications that are tailored to needs, reliable, and fully mastered by the client. We hand over the keys to the application at the end of the mission, without locking in our clients (see the enioka Haute Couture manifesto).
To achieve this, we advocate for development methods that promote knowledge transfer through written documentation.
You’re probably thinking: « Here we go again, another blog post where the author pats themselves on the back or polishes their company’s image. »
If we believe everything we read on medium.com, everyone writes tests, everyone keeps their documentation up to date!
Yet we all know that’s rarely the case. Otherwise, we’d know about it, or at least we’d see it.
Honestly, most of the time, when a project is documented — which isn’t often – we get something like this at best.
So we won’t brag too much, but we did have a rather painful opportunity to put our model on test in a way that was as sudden as it was brutal.
And « Poof » Goes the Tech Lead
In early 2026, we were working on a development mission for a lab management application for one of our clients.
We put together a team consisting of a Tech Lead and a developer from enioka Haute Couture, along with a developer from the client.
After a few workshops with the stakeholders, a design was finalized, the backlog was initiated, and the project kicked off following an agile process.
Sprints came and went, the application’s foundations were in place, and the CI/CD pipeline allowed us to test and deploy the application in the first test environment.
However, the application wasn’t fully defined yet: some features were still being discussed in workshops with the business. Certain tough issues remained and were being addressed iteratively.
Then came the Easter weekend. Everyone headed off for the long weekend, with the promise of returning to work well-rested, on Tuesday.
But when the weekend ended, disaster struck: the Tech Lead didn’t come back.
Accidents happen quickly, and not just when you’re doing risky activities. It can happen on any project, at any time.
Consider how many people on your team go skiing, horseback riding, do DIY projects, or simply drive a car ?
Multiply that number by the number of limbs (arms, legs), and you get an idea of the odds of someone just getting hurt !
In our case, our Tech Lead engages in all of these pastimes and still has all four limbs to this day.
One Day to Take Back the Reins
To address this exceptional situation, enioka Haute Couture mobilized to provide a Tech Lead to assume project leadership. Having been notified of the accident during the holidays, the replacement was arranged within the week.
But the new Tech Lead didn’t know the project, hadn’t participated in the workshops, and yet needed to become operational quickly.
Fortunately, good documentation practices had been established from the start of the project. The new Tech Lead, like the rest of the team, had access to multiple levels of documentation to grasp the complexity of the solution being built.
Project Description
This is the first level of information. At enioka Haute Couture, we have an internal wiki where each project is described with:
- The mission’s subject, its stakes, and expected outcome.
- Identification of project stakeholders, their roles, and contact information.
- Communication channels.
- Tools provided by the client: email, knowledge base, ticket manager, code repository.
- Documentation entry points.
Logbook
A shared logbook, in addition to the one maintained by the Tech Lead, provides the project’s history.
It recalls past and future milestones, as well as significant project events (first delivery, incidents, etc.).
We also keep track of meeting notes.
Architecture Document
During design phases, we create an architecture document that describes how the application works, its integration with external components, and its internal organization.
This is the document the team refers to for understanding the solution.
This document follows the C4 model formalism to describe the solution from the most general view down to implementation details when necessary.
It also contains other information in the form of diagrams:
- Data model
- Deployment diagram
- State machines for main processes
This document is then adjusted and expanded throughout the project to reflect the application’s reality.
Explanations of Specific Mechanisms
In addition to the architecture document, the team produces articles explaining special or unusual parts of the application.
For example, the authentication mechanism, a complex business process…
It provides a discursive explanation of how a component works to achieve a fine-grained understanding.
For this project, we had articles explaining the authentication part, how the breadcrumb works, and the mechanism for tracking user actions.
README
An introductory document lists all the information needed to contribute to the project.
This document describes required dependencies, common commands (e.g., schema migration, tests), naming rules and conventions in use, etc.
Development practices are either described in this document or reference external resources.
Generally, this document lives in the code repository, conventionally named « README ».
It facilitates project onboarding. In this situation, the new Tech Lead could get the solution running locally quickly.
It’s complemented by tutorials that explain specific tasks.
Tutorials
Some development tasks may require knowledge that isn’t acquired or mastered by all members of the development team.
For example, how to spin up a complete environment on a local machine, how to debug a tricky part, how to maintain a section of the code.
These tutorials are generally written by the whole team, ease the arrival of new people on the project, and complement already automated elements (docker-compose, .editorconfig, etc.).
API Documentation
API documentation is published from documentation tags in code structures written by developers. It’s the reference to the production code.
It’s generated with a tool capable of extracting information from source code (docstrings, XmlString, javadoc). Depending on the language, we can choose from Doxygen, DocFx, Sphinx…
It allows exploring the solution’s structure and consulting the values and usage of certain constants without the code.
If well-constructed, it can also indicate how to use structures and therefore ease the onboarding of a new contributor.
Automated Tests
Every change comes with one or more tests that must ensure adequate code coverage. Tests ensure that developments were done as expected and prevent regressions.
Existing tests formalize behaviors that might have escaped formal description, or represent choices made locally by developers.
Thus, a contributor is warned when their changes have broken a feature they weren’t aware of.
CI/CD
Setting up automation from the start of the project enables easy execution of development tasks and application publication.
This way, the team can package and deploy the application just by pressing a button.
Automating the systematic execution of tests, linting, and static code analysis helps maintain a predefined application quality regardless of team members.
Documentation publishing is also part of a step in the CI/CD pipeline.
Operations Manual
The operations manual gathers all the information needed to run the application.
It builds on the deployment diagram, adding the names and addresses of required equipment (VMs, databases, etc.).
All procedures for maintaining operational conditions are described step by step. For example, restarts, database backup and restoration.
This document is by nature a knowledge transfer document, as administrative actions are generally delegated to operations teams or managed service providers.
For the new Tech Lead, it helps understand how the application should be deployed.
Backlog
An organized and up-to-date backlog also constitutes part of the project’s ephemeral documentation.
It allows team members and business stakeholders to track project progress and get an indication of what’s left to do. Breaking it down by functional domain helps organize work according to priorities to deliver the requested features.
Before going on vacation, the initial Tech Lead had done some backlog grooming and thus prepared the work for the team to tackle upon return from skiing.
The initial motivation was to lighten his mental load when returning from vacation, but it proved beneficial in this case for two additional reasons:
- for the development team, who continued working on the project without interruption,
- for the new Tech Lead, who could get a clear view of what remained to be done.
Conclusion
Of course, we don’t intentionally hurt our colleagues to test our resilience.
No need, they go skiing on their own, without any incentives.
In this case, exceptional but not so rare, the availability of all these documentation sources enabled an on-the-spot replacement.
For the fresh new Tech Lead, it took a good day to get up to speed on the most important elements of the project.
For the team, since the backlog was already ready, development could continue during the new Tech Lead’s ramp-up time.
The variety of documentation forms, aided by automation elements and decent software quality, made it possible to hand off the project under unfavorable conditions. Despite the sudden loss of the person in charge of the project, there was no break in progress.
Thus, the project continued without interruption and according to the original plans because the concepts didn’t remain as ideas nestled only in the Tech Lead’s head. They were shared and preserved in written form. It’s the co-constructed and released documentation that provides the resilience allowing the project to survive the people.
However, building it is a thankless task because it can never be completely exhaustive. It must be complemented by other information sources, such as tests, backlogs, scripts…
It’s the outcome of the team’s collaborative effort in building a common knowledge heritage.
Our goal is always to hand over the keys, and for that, documentation is necessary but not sufficient. The care put into building an application, through rigorous design and clearly organized code, also contributes to the solution’s quality and ease of transfer.
Thus, implementing development practices based on collaboration and knowledge sharing puts us in a position to transfer the application heritage at any time, at the end of the project or in case of a skiing accident.
