High Performance IT Business–Lessons from French Grande Armée

By Ostap Soroka

IT businesses going through a digital transformation face challenges, including integrating legacy systems and services with newly-build digital products. Agile, DevOps, and product development approaches became a de-facto standard across the industry. Traditional IT management frameworks are under criticism for being bureaucratic, slow, and process-oriented. This whitepaper provides a best practice guide for IT managers on dealing with a range of issues, from traditional IT management frameworks to agile software development.

Two approaches to systems development

Traditionally, IT systems were developed in top-to-bottom mode to include requirements gathering, design, implementation, and maintenance phases. The project-based approach was common practice, with long work-in-progress queues. Methods deriving from manufacturing industry were used to plan and measure development efficiency and performance. Somewhere around the break of the century, an agile movement emerged, followed by Lean and DevOps.

Paradigm was shifted—desired software features were to be discovered, not designed.

Continuous value delivery, user-feedback, and continuous improvement became cornerstones of software development. Probably the most extreme differences can be seen between pre-designed and evolutionary approaches to systems development. Both approaches facilitated weaker points.

Pre-designed approach

A top-down design approach, usually associated with a waterfall methodology, is unreliable for developing complex systems. A pre-designed approach was associated with formal and time-consuming processes of design reviews and approvals, enforced by IT governance. Often, architects became a bottleneck in the digital product development process. Promises of solving complexity up-front were mostly unfulfilled. The pre-defined approach contradicts with the discovery model, and is conceptually closer to the “command and control” approach.

Evolutionary approach

The speed of software development is the cornerstone of agile methodologies. In pursuit of velocity metrics, other aspects of development are sacrificed—such as following security standards or re-using company-wide platforms and vendors. An agile methodology is more focused on reading and understanding the source code rather than attention to detail. By having a high turnover rate of IT professionals, a business is not only likely to suffer financially but also risk having gaps in software projects because of the lack of a smooth project handover from one employee to another.

Integrating two worlds

Both the pre-designed and the evolutionary approach can be accommodated—high-performing IT businesses should adopt the best of both approaches. This document goes in depth with topics ranging from cross-functional teams, decentralized command, teams coordination, to data management.


To better illustrate approaches being advocated, this research highlights similarities between modern approaches to digital product development, and organizational design of the French Grand Armée. Comparable principles were applied by Napoléon Bonaparte, a French statesman and military leader who rose to prominence during the French Revolution and led several successful campaigns during the French Revolutionary wars across Europe.

Napoléon designed a new type of versatile and robust military organization called Grande Armée, which later became a standard adopted by other nations.

Motivated individual

Post-revolutionary French Grande Armée was successful in multiple battles. Part of the success of the Grande Armée was due to character of its soldiers and officers. French revolution broke the long-standing social class system, and opened an opportunity to military service to all social classes. It was merit-based organization, with a strong pride in the French Republic and its principles. Grande Armée differed from other armies, which often consisted of unmotivated individuals, lacking common vision, and goals.

Jacques Antoine Hypolite, Comte de Guibert, an eighteenth century influential military thinker, proposed the concept of citizen armies in 1770. He predicted the national army would easily defeat the mercenary army and advocated for permanent divisions, with high mobility capabilities. Napoléon studied Comte de Guibert’s work and applied the same principles to Grande Armée by paying special attention to the troop’s morale and welfare. Army regiments weren’t dismissed after campaigns and regiment group identity was welcomed (this practice lives in many of the world’s armed forces today).

200 years later, motivated and productive people still are prerequisite for success, especially in a highly competitive digital industry. Historically, the software industry had a mixed reputation in regards to employee motivation and engagement. This was reflected in popular culture in the Dilbert comics and the Hollywood movie, Office Space. Industry corrected itself and came up with the Scrum methodology. There are clear analogies between principles advocated in Scrum and principles of Grande Armée.

Scrum methodology advocates for self-motivated, cross-functional, and customer-focused team members. Scrum also emphasizes the necessity of having a permanent, long-term team. This collides with the idea of employing very specialized professionals, and temporary project-based teams, which prevailed in the software industry.

Presence of group bonding, mutual trust, unity, and cohesion remain crucial in the digital economy.

Cross-functional team

The basis of the Grande Armée organization was army corps—combination of infantry, artillery, and a brigade of cavalry, plus detachments of engineers. Army corps was an autonomous, independent, and self-sufficient fighting detachment because army corps could operate on a distance from other units, and with little supervision from headquarters. Grande Armée was not a functional organization—there was no “Chief Artillery Marshal” supervising artillery units in the organization.


In software development, cross-functional teams were introduced by the Scrum methodology and re-emphasized later by DevOps movement. Despite the industry adoption and scientifically recognized benefits, not all enterprises adopted this approach, especially for product development teams.

Similar to Grande Armée’s ideas, the Large-Scale Scrum (LeSS) framework emphasizes an avoidance of functional offices. Requiring team members with programming skills to report to the development manager and QA-skilled team members to report to QA-manager will not create great teams. Conflicting loyalties are undesirable both in military organization and in a digital product company.

Autonomous team

The idea behind the corps system was to create an organization that could function autonomously. Every individual corps was a self-contained army, led by a marshal and staff corps, including all military elements, internal command, and control networks. While independent, each army corp commander knew the overall strategic plan, current commander’s intent, and acted in alignment with those plans. Marshal was required to act in accordance with the strategic plan, but at the same time this person was free to decide how to best prepare for an upcoming engagement.

The same approach is adopted by IT professionals in product development teams—they are largely autonomous in tactical decision-making, and are driven by outcomes, not by outputs. Overall direction for product development effort is derived from a business’ mission and vision.

Priorities for development of new features are customer driven. Daily decision-making is pushed down from higher levels of the business down to team level, alongside responsibility for outcomes.

Team coordination and cadence

Next innovation of Grande Armée was the ability to coordinate movements and concentrate forces in decisive moments of the battle. Despite having capabilities to act autonomously, all army corps were in constant communication with headquarters. In the days of active troop movements, every army corp staff would produce a daily report and deliver it back to general staff. After disseminating and analyzing incoming reports, headquarters would issue marching orders to individual corps for the upcoming day.

The unique capability Grande Armée possessed was to “march divided, fight united”. French coordinated movements of army corps across vast distances and were able to confuse and out-maneuver his adversaries’ armies.

Team of teams is a widely used term to describe the collaboration between independent and autonomous groups working towards a common goal. Naturally, there is a need to coordinate efforts of multiple teams on a regular basis (cadence). The cadence of release trains is used to integrate complex systems developed by independent asynchronous teams.

For more tightly integrated teams there are frameworks and methodologies which addresses the specific question of multiple product teams’ coordination. Ironically, failure to coordinate efforts of multiple teams (army corps) was one of the reasons for defeat at Waterloo—while the French had troubles with directing movements, adversaries have beaten them in their own game.


Extreme product ownership

Stakes were high for Napoléon—the fate of French Republic depended on military successes of Grande Armée.

Napoléon carried a packet of poison with him and was willing to commit suicide to avoid being captured. He even attempted suicide in 1814 at Fontainebleau after being abdicated, but had survived after taking an expired poison.

From a military standpoint, Napoléon acted as his own operations officer. He required no advice from his generals and carried ultimate responsibility for his decisions.

If we look at software development, the Scrum methodology introduces a product owner role. Emphasis is put on the fact that this is a single person, with the main function of managing the product backlog and ensuring the value of work that Scrum team performs. A good product owner combines contradictory traits of a doer, a visionary leader, and a team player at the same time. Organizations have a hard time finding people with sufficient breadth and depth of experience and skills to fill a product owner’s role.

A common mistake is to substitute a single product owner with a committee of multiple people, without anyone in charge. Most often than not, the committee is lost in long meetings, usually consisting of company politics and conflicts.

Napoléon was an eminently qualified product owner because he transformed post-revolutionary France to strong state with a stable economy and a world-class army. Through Napoléonic wars, his adversaries were coalitions of monarchies but often lacked unity of command. As a supreme commander (i.e. product owner), Napoléon was able to react quickly to tactical situations, while his enemies were busy negotiating amongst themselves in the same manner as product owners committees often do in software development.

General staff

Another key element of a Grande Armée business was the general staff. It would serve as the backbone of a command and control network. It was led by Marshal Berthier and included a large number of knowledgeable officers who provided all types of information necessary for military planning.

Berthier’s aides provided information on types of roads, layouts of towns, and the quality of equipment carried by enemy units. The chief of staff’s duties consisted of maintaining situation reports, dispatching orders, maintaining an army’s war diary and maps, keeping registers, and conducting inspections.


In modern businesses, the general staff can be related to various information systems, governed by data architecture. Any digital organization must acquire, analyze, de-conflict, and internally disseminate incoming information before conducting actions (see OODA loop). Often, there is a dedicated governing body, overseeing multiple teams of teams. Various business designs result in a variety of potential shapes and forms of this governing body.

Executive action team (EAT) can be viewed as one of the examples. Traditionally, the same function was carried by enterprise architecture and IT governance. This function is closely related to the business’s operating model, business architecture, and the business mission and vision.

SoftServe expertise

SoftServe has long-standing experience building cross-functional agile teams. SoftServe is co-creating innovation via the services of product management, product development, and setting-up coordination for multiple Scrum teams. The pragmatic marketing approach is practiced, alongside multi-stage discovery phase, for developing new digital products.

SoftServe facilitates transformations from the traditional IT enterprise business to high-performing IT businesses that support a new way of working.


Digital enterprise requires new organization design, and organizations are facing challenges to transform to a new way of working. Digital value delivery demands a paradigm shift, from project-based, top-to-bottom designed, batch-based value delivery to continuous, bottom-up, emergent products.

The subtle balance should be maintained between agile development methods, traditional activities from enterprise architecture domains and software architecture. Top-to-bottom and bottom-up approaches should be the sweet spot.

There is no single recipe or practice applicable to all businesses, as every business context is different. Still, any methodology will fail if a business lacks it’s most valuable capital—the human capital. Napoléon believed the secret to success in military campaigns was 75 percent “esprit de corps”, and a mere 25 percent was devoted to the number of troops and quality of equipment.

200 years after Grande Armée, Agile Manifesto stated the following principle:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Regardless of what your business is doing, motivated individuals are pre-requisite to succeed in a never-ending campaign of a modern economy.

Завантажити PDF