The 6 Habits of an Effective Information System
A manifesto for an IT organization that serves the business, the collective, and the long term.
In 80% of organizations, IT is not the business. It is a means to an end. Yet this means often consumes enormous resources, delivers slowly, and sometimes ends up hindering the very ambitions it was supposed to support. The financial cost is well known. The human cost is less visible: it is the energy spent, at every level of the organization, compensating for what was not done, not maintained, or not understood.
This manifesto points fingers at no one. It proposes six habits—six practices to cultivate over time, individually and collectively—to build an information system that truly serves. And to return to the collective the energy that is currently wasted on patching and compensating. Each habit requires personal commitment. None of them works in isolation.
If you already practice these habits, say so. This text is open.
Habit 1 — Verify Understanding Before Building
Talking together is not the same as understanding each other. Translating a business need into technical language is the riskiest act in any project—and often the one treated with the least rigor. We assume. We move on. Six months later, we discover that we delivered an electric Ferrari for someone who needed a tractor for the harvest.
The habit to develop: make verification of understanding a formal, brief, structured, and non-negotiable step. It is not another meeting. It is what makes all the others useful.
What we gain when this habit becomes standard: two to three weeks saved per project, teams that no longer carry the mental burden of uncertainty, and business stakeholders who stop discovering six months later that the solution is not what they requested.
I commit to verifying that we truly understand one another before building—and to treating that verification as an integral part of the work, not a luxury.
Habit 2 — Maintain a Clear Framework, Because Structure Creates Freedom
We have come to oppose structure and autonomy, as if one destroyed the other. The reality is the opposite. A team without a clear framework is not autonomous—it is alone. It spends its energy constantly arbitrating decisions that should have been made once and for all. It lives under a double constraint: being asked to move fast and deliver quality, without being given the means to choose.
The habit to develop: establish a clear framework when leading others, and respect the framework that is established for you—even when challenging it through the appropriate channels, never by bypassing it. A framework is not a prison. It is an energy-saving mechanism. It is what makes autonomy real because it provides a clear and understandable space in which it can be exercised.
What we gain: the end of the feeling of impossible trade-offs, teams that can make decisions without guilt, and innovators who know where innovation belongs instead of innovating secretly within projects that never called for it.
I commit to establishing a clear framework when I lead, and to respecting the framework established for me—even when I challenge it through the proper channels, never by circumventing it.
Habit 3 — Serve the Need, Not Your Technical Preferences
The customer’s need is not always exciting. Sometimes you must develop in Java, using technologies that are no longer fashionable, within a framework that offers little technical glamour. That is not a failure. It is the job.
We are not always working on innovation. We are part of a team serving a business product, within a budget, using the organization’s tools. And that budget, let’s be honest, indirectly funds salaries, bonuses, and collective prosperity. When budgets remain under control, collective purchasing power remains under control as well.
The habit to develop: deliver what is requested within the agreed framework, while openly proposing—not secretly introducing—technical debt reduction and modernization efforts. A team that anticipates technical debt is not a team that complains. It protects next year’s budget.
What we gain: genuine alignment between what is delivered and what is useful, teams that do not exhaust themselves innovating where innovation was never required, and technical debt that no longer consumes future budgets.
I commit to serving the need as it is, not as I wish it were—and to proposing improvements openly rather than imposing them in the shadows.
Habit 4 — Document and Share Knowledge, Because We Are Only Passing Through
One day, each of us will leave our position. The rocket will remain. And if no instructions have been left behind, the successor will struggle—then add another stage to the rocket, abandon the old engine room, build a new one, and charge the business for it again.
The habit to develop: treat documentation and knowledge transfer as part of the work, not as an optional extra. This is not administrative overhead—it is an act of trust in the collective. A well-equipped successor is not a competitor; they are a lifelong ally. They may thank you ten years later in a proposal, a recommendation, or an unexpected conversation.
What we build with company resources and for company purposes belongs to the company. Operational knowledge, architectural decisions, and the rationale behind choices are collective assets—except for what must remain confidential or protected as intellectual property.
What we gain: months of productivity at every transition, projects that are no longer rebuilt multiple times because institutional memory was lost, and the freedom to move on without the guilt—or the misplaced satisfaction—of leaving behind a system that only you could understand.
I commit to documenting, sharing, and making accessible what I build—because I am only passing through, and what I leave behind speaks about me longer than what I say.
Habit 5 — Treat AI as a Governance Topic, Not a Tooling Topic
By reflex, IT has often treated AI as if it were simply another Git repository, another programming language, another framework to learn. Everyone was expected to jump into Python, Markdown, or Mermaid. But AI is not just another tool. It represents a paradigm shift in how value is produced, controlled, explained, and audited. It changes the boundary between what humans do and what machines do.
Applied to a fragile information system, AI is little more than a bandage on a broken leg—or an accelerator of chaos. Built upon a healthy information system—with quality data, secure systems, strong expertise, and clear governance—it becomes a genuine game changer. It frees time, improves judgment, and enables faster and better decisions. But only if the foundational work has been done.
The habit to develop: treat AI as a governance issue before treating it as a tooling issue. Learning how to use the tools is useful and relatively straightforward. What transforms an organization is not the accumulation of individual skills. It is the collective ability to decide what AI should do, on which data, with which guarantees, under whose responsibility, and in service of which ambition.
Learning the tools is an individual effort. Transformation is a collective project.
I commit to treating AI as a governance topic before treating it as a tooling topic—and not to confuse writing prompts with transforming an organization.
Habit 6 — Treat the Information System as a Common Good
The previous habits share one characteristic: none of them stands on its own. Structure without translation is blind. Translation without transmission is temporary. Knowledge transfer without well-governed AI becomes obsolete. AI without structure is dangerous.
An effective information system is not the sum of virtuous individual behaviors. It is a system in the truest sense of the word. It works when every link in the chain fulfills its responsibilities and when the collective has established the moments where those responsibilities are reviewed and verified.
This requires two things in equal measure: that each person accepts being one link in the chain, and that those who guide accept the responsibility of guiding—without confusing facilitation with decision-making.
The habit to develop: consider the information system as a shared asset of the organization and fulfill your part in work that only functions collectively. Working within a clear and shared framework does not reduce autonomy. It increases energy—the energy currently wasted compensating for what no one took responsibility for.
What we gain collectively: time, energy, trust, clarity, and incidentally budget—the budget no longer spent on duplication, over-engineering, or rebuilding projects multiple times. Budget that can return to the business, genuine innovation, or collective rewards.
I commit to treating the information system as a shared asset of the organization—and to fulfilling my part in work that only succeeds collectively.
Manifesto Poster
An Invitation
This manifesto is not a rulebook. It is an open text.
If you practice these habits—at your level, in your role, with your constraints—say so. Reuse it, share it, sign it, challenge it if you wish, but above all, make it circulate. A manifesto is only worth the hands that carry it.
IT is only a means. But it is a means that influences budgets, careers, organizational trajectories, and a small part of the planet itself. Perhaps it deserves to stop being treated, at every level, as an individual matter.
—
Laurence Poussard, Enterprise Architect
First signatory — manifesto open for co-signature
To sign or respond: laurence.poussard63@gmail.com