--- title: "Second-Order Change: Assimilated or Rejected" canonical_url: https://alpineintelligence.ch/en/blog/assimilated-or-rejected/ language: en --- *October 2026* # Second-Order Change: Assimilated or Rejected A transformation team without authority over the existing rules is either assimilated or rejected. Why that happens and what a contract has to settle before the team starts. The [previous article](https://alpineintelligence.ch/en/blog/second-order-change/) described a development team that writes code faster with AI but still releases on the same schedule, because every change waits for the next change board meeting. Changing that requires someone with the authority to change the rule. This article looks at what happens when the people asked to bring about such a change lack that authority. Suppose the company appoints a transformation team to introduce generative AI and explore how work could be organised differently. The team is expected to fit into existing workflows and take its proposals through the established decision-making bodies. One possible application is AI agents carrying out clearly defined tasks independently. The team proposes a trial in which suitable changes are released without waiting for the change board's approval. The proposal comes back: the approval is mandatory and must also apply during the trial. The change board may have good reasons for that rule, such as protecting against faulty releases. The question is how the organisation could find out. It judges the proposed workflow by whether it follows the old rules. Whether those rules are still necessary for the new way of working cannot be tested on that basis. ## Why the existing rules limit change In *Change* (1974), Watzlawick, Weakland and Fisch distinguish changes within a system from changes to its rules. In the first case, an approval is better prepared or processed more quickly. In the second, someone decides whether that approval is still needed for certain tasks. This is the second-order change from the first article. Their discussion of a system caught in what they call a “Game Without End”, one that can only play by its own rules, identifies the limit: it “cannot produce the rules for the change of its own rules” (1974, pp. 22–23). Applied to our case, a procedure that checks compliance with an approval requirement can only reject a proposal that omits that approval. As long as the requirement itself remains beyond question, the new workflow fails the check. Making the check more efficient does not break the cycle. To assess the proposal, the organisation has to step outside that procedure and put its underlying requirement up for decision. It needs criteria such as the quality of the results and the time to completion, against which the existing approval can also be assessed. People inside the organisation can initiate this step, as can external consultants. “Outside the system” here means a perspective outside the rules currently in force. Where someone comes from does not guarantee that perspective. ## Why the team is assimilated The existing rules also determine how the transformation team may work. It needs access to information, decisions and resources. If these are available only for proposals compatible with existing procedures, its ability to act depends on adapting to those procedures. In their theory of organisational socialisation (1979), Van Maanen and Schein describe how new members learn an organisation's norms and expectations. Applied to our example, the team learns which proposals move forward and which are blocked by the mandatory approval. If it adjusts its work accordingly, it may stop proposing anything that questions the approval in the first place. Nobody needs to instruct it explicitly to abandon its purpose. The team has been assimilated: it still exists, but it no longer asks the question it was set up to investigate. An external consultant can lose an outside perspective in the same way. The consultant is still engaged externally but selects recommendations according to the organisation's internal criteria. Eventually, the proposals are easy to implement because they presuppose the existing order. In the AI example, agents are introduced while every release still waits for the change board. During delivery, the assignment has narrowed to first-order change. ## Why the team is rejected If the team continues to insist that the approval itself should be examined, the conflict remains. The change board and the managers accountable for release quality are now being asked to allow a trial that could make part of their role unnecessary. As long as compliance is all that is required, the team appears disruptive from the perspective of the existing procedure: it repeatedly asks for something the procedure does not permit. The dispute may then shift from the proposal to the people making it. The team is labelled “unable to work with the organisation”, the consultant “alarmist”. If those labels end the discussion, there is no need to discuss the approval itself. Excluding people from decision-making meetings or allowing the engagement to expire eventually removes those who keep asking for it to be examined. In *Overcoming Organizational Defenses* (1990), Chris Argyris describes defensive routines that protect against embarrassment or threat while preventing their causes from being examined. In the sequence described here, exclusion serves that function: the conflict disappears from the meetings while its cause remains. The people involved do not have to agree to obstruct change. Each party insisting on its existing responsibilities is enough to keep the proposal blocked. Assimilation and rejection are thus two consequences of the same condition: the existing order remains the binding standard for an assignment intended to change it. A proper evaluation must be able to conclude that the approval is still necessary. The mechanism described here prevents that evaluation from taking place at all. ## What breaks the cycle In *Flawless Consulting* (1981), Peter Block describes contracting as the agreement between consultant and client on the assignment and how they will work together. For a transformation team, that agreement must specify which existing rules it may put to the test, and it must be settled before the team starts, because afterwards its access to information and resources already depends on those rules. It requires leadership willing to authorise a trial even when it conflicts with existing responsibilities, and with the authority to change those responsibilities. For the team at the start, this would mean permission to release clearly defined changes without waiting for the change board during the trial. Together with those responsible for operations, it would compare quality and completion time with the existing procedure. Whoever has authority over the approval rule, such as the head of IT or the executive board, commits to assessing the results and deciding whether to adopt the new approach. The team can then work with the organisation without having to abandon the question it was asked to investigate. Without that agreement, the pilot may end up demonstrating exactly what it was required to assume from the outset: even with AI, every release still waits for the change board. ## References - Argyris, C. (1990). *Overcoming Organizational Defenses: Facilitating Organizational Learning.* Boston: Allyn and Bacon. - Block, P. (1981). *Flawless Consulting.* San Diego: University Associates. - Van Maanen, J. & Schein, E. H. (1979). Toward a Theory of Organizational Socialization. *Research in Organizational Behavior*, 1. - Watzlawick, P., Weakland, J. H. & Fisch, R. (1974). *Change: Principles of Problem Formation and Problem Resolution.* New York: Norton. Quotation: pp. 22–23. ### Let’s discuss your AI application. I help you assess your situation and identify the next steps. [Request a Conversation](https://alpineintelligence.ch/en/executive-triage/)