When we think about what will enable us to carry out a technical project successfully, we often focus on budget, technology, and scheduling. We too often overlook the human side of things.
The pioneer phase
The pioneer phase is when you bring together a small team of highly skilled people to deliver a first version of the product or system. The goal is not yet scalability, exhaustive documentation, or the perfect process: it is to make something concrete exist, quickly.
In this phase, the people involved are usually experts or highly autonomous. They can make technical decisions on their own, write code or build infrastructure without waiting for approval at every step, and adapt as they go. Communication is often informal, direct, sometimes blunt but effective. Roles are fluid: everyone pitches in, from design to production. Mutual trust and shared technical competence serve as the framework.
This dynamic makes it possible to move fast and validate an idea or an architecture without getting bogged down in meetings and process. On the flip side, knowledge often stays in people’s heads, technical choices are rarely written down, and what has been built can become hard to hand over or evolve when the team grows or changes. The pioneer phase is therefore both essential for getting a credible first version off the ground and fragile if you do not plan to consolidate the human and organisational foundations as soon as the project gains momentum.
The consolidation phase
The consolidation phase begins when the first version exists and the project has to go the distance: new joiners, scaling up, long-term maintenance. The aim is no longer to “make something exist” but to make what has been created reproducible and shareable, without burying the team under bureaucracy.
In practice, this means capturing knowledge: documenting the architecture and technical decisions, formalising deployment and operations procedures, and writing down what was implicit for the pioneers. Roles become clearer over time—without necessarily becoming rigid—so that everyone knows who to turn to and what to expect. A minimum of process is introduced (code reviews, runbooks, alerting, retrospectives) to make deliveries safer and reduce dependence on a few individuals.
On the human side, this phase is often tricky. Pioneers may experience formalisation as a loss of freedom or a lack of trust in them; newcomers need reference points that the old hands never had to spell out. The challenge is therefore to consolidate without rigidifying: keep the team spirit and the ability to take initiative while making the system understandable and maintainable. When consolidation is done well, the project gains resilience and the ability to welcome new talent; when it is ignored or pushed through in an overly top-down way, you end up either in chaos or in process overload. The human dimension remains central: the goal is to provide a framework that empowers, not one that constrains.
I often work in this phase. My role is to define processes so that the team can deliver faster and better. By taking concerns such as deployments, security, or scalability off their plate, we free people’s minds and increase the team’s capacity to look ahead to new tools, markets, and possibilities.
Maintaining trust
Whether in the pioneer or the consolidation phase, one thing remains essential: keeping human contact and making sure teams feel that everyone is moving in the same direction with the same goals. Process and documentation structure the work, but they do not replace direct exchange—regular check-ins, informal moments, the ability to ask a question without opening a ticket. When people stop talking or no longer understand where the project is heading, motivation drops, effort fragments, and silos reappear. Sharing the vision, priorities, and results, and recognising contributions all reinforce the sense of being in the same boat. Without that connection and shared clarity, even the best teams and the best process eventually run out of steam.
DevOps: extending the concept to all teams
DevOps is not just about tools or a dedicated team. It is first and foremost a culture: bringing development and operations closer together, sharing responsibility for the application lifecycle, and breaking down the walls that leave “dev” to deliver and “ops” to deal with the fallout. For it to really work, this concept must be extended to all teams—not only dev and ops, but also product, design, security, and support. Everyone should be able to understand how their decisions affect the rest of the chain and contribute to a common goal: delivering value in a reliable and sustainable way.
In practice, this means encouraging cross-team exchange, cross-training, occasional involvement in runbooks or deployments, and shared visibility on metrics (availability, performance, user feedback). When DevOps remains the preserve of a handful of people, silos simply move elsewhere. When the whole organisation embraces this logic of collaboration and shared responsibility, projects move forward more smoothly and teams genuinely feel aligned. Once again, the human factor is at the centre: tools and process are not enough unless they are embraced and lived by every team.
Conclusion
In the end, the success of an IT project comes down to one thing: maintaining an environment of trust and mutual support within the team. Good technology, budget, and scheduling matter, but without this human foundation, blockages pile up, unspoken tensions weigh heavy, and energy scatters. When people can trust each other, ask for help without fear of being judged, and know they have support, technical and organisational difficulties become manageable. It is this collective dynamic—trust and mutual support—that makes it possible to get through the pioneer phase, consolidate without stifling, and make DevOps a reality day to day. Everything else depends on it.