Operating models and transformation
Why AI adoption is not organizational transformation
Two hypothetical situations help distinguish getting new tools from changing how a software delivery system works.
Joan ArandaAI adoption can improve one person’s work without yet changing their team’s delivery capability. That improvement matters. The question is what makes it reproducible, understandable and sustainable within an organization.
I would use “adoption” to describe the effective incorporation of a capability into work. I would reserve “transformation” for changes in how people decide, coordinate, validate and learn. These are working distinctions that can coexist, rather than two stages every organization must follow in the same way.
Two situations using the same tool
Imagine two fictional teams maintaining a reservation application. Both have access to the same coding assistant. We make no claims about their measured speed, quality or results.
In team A, each developer prepares their own context and decides how to interpret the request. Questions about boundaries, states and existing behavior emerge during review. The reviewer has to reconstruct decisions made in a conversation they did not join.
In team B, relevant rules, acceptance cases and responsibility for resolving disagreements are established before implementation. Context decisions remain accessible. Review assesses the agreed behavior and records exceptions worth retaining.
Team B is not necessarily faster. It may overinvest in specifying a small task. Its distinguishing feature is that we can examine where scope was decided and what allows the result to be accepted.
| Decision | Situation A | Situation B |
|---|---|---|
| Interpreting the request | Individual conversation | Visible agreement proportional to the task |
| Providing constraints | Depends on each person’s context | Relevant constraints are accessible |
| Reviewing | Reconstructing intent and implementation | Assessing the proposal against agreed behavior |
| Resolving exceptions | Negotiation during review | Defined responsibility and an agreement that can be revised |
| Learning | Local experience | A useful decision available for another task |
Where I would invest next
If an organization has little adoption, better access, training and support may be the right investment. An entire delivery system does not need redesigning before someone learns to use a capability.
If generation increases but deliveries remain blocked, I would examine what happens after the proposal: waiting, review, integration, corrections or approval. The next step might be clearer acceptance, smaller changes or recovering knowledge currently held by a few people.
Adding tools remains an option. It needs an explanation of the problem it addresses. Without that explanation, the investment may increase capacity in a part of the workflow that is not limiting the outcome.
Four questions for leadership
- Which part of the work improves, and how do we assess that improvement?
- What effort moves into context preparation, supervision, review or correction?
- Can another team member understand and continue the work?
- Which decision changes because of what we have learned?
Counting licenses will not answer these questions. Nor do they require a huge measurement system. A small set of comparable changes can help identify where to investigate, provided it is not presented as universal causal evidence.
Transformation without unnecessary bureaucracy
A new process deserves to remain when it improves a decision or reduces important uncertainty. Requiring a lengthy specification for every correction may be counterproductive. Approving a document without reading it adds a signature, not an assessment.
Proportionality matters: a small task needs a brief agreement; a change spanning several parts of a system needs more explicit context and acceptance. The organization must also be able to revise the agreement when it learns something new.
The transformation I am interested in makes the delivery system easier to examine. It explains how a result is reached, which responsibilities remain human and what changes when a proposal fails. Adoption brings the capability into work; organizational integration determines how it can be sustained.
The distinctions and situations in this article are editorial proposals and hypothetical illustrations created for publication. They do not document client results or internal hiberus processes.