On the morning of 4 June 1996, the first Ariane 5 lifted off from Kourou in French Guiana. It carried the four Cluster science satellites, first proposed in November 1982. For about half a minute, all was normal.
Then, 36.7 seconds after the command to ignite the main engine, the backup inertial reference system, which measures the rocket’s attitude and movements, stopped working. About 0.05 seconds later the active unit stopped too, for the same reason, and sent the main computer a diagnostic bit pattern. The computer read it as flight data and swung the nozzles to full deflection. At about 39 seconds the rocket began to break up.
The unit that failed was not new. Its design was “practically the same” as the one flying on Ariane 4, “particularly as regards the software,” the inquiry board found. On Ariane 4 it had never failed this way. That was the point of reusing it.
A proven unit, a new flight
The failing code aligned the platform before launch. On Ariane 5 it had no job after lift-off, but it kept running for about 40 seconds, a holdover from Ariane 4 kept “for commonality reasons.” Ariane 5 picks up horizontal speed five times faster than Ariane 4 in those first 40 seconds. A number tied to that speed grew too big to convert into a 16-bit integer, and the unit shut itself down, as its specification required.
Nobody had shown the unit the new flight. It had been “jointly agreed” not to include Ariane 5’s trajectory in the unit’s requirements and specification, and its supplier “was only following the specification given to it,” the board wrote. In 1992 the programme had also decided to use simulated units in its full flight simulations, partly because the real ones “should be considered to be fully qualified at equipment level.” A ground test feeding the unit Ariane 5’s predicted flight, the board said, would have exposed the failure.
The board’s last recommendation was about the partners themselves: “Close engineering cooperation, with clear cut authority and responsibility, is needed to achieve system coherence, with simple and clear interfaces between partners.”
Close cooperation and simple interfaces sound like opposites. In 2019, two writers on software teams gave each its own name.
Three ways to deal with another team
In their book Team Topologies, Matthew Skelton and Manuel Pais describe three basic ways for teams to work together. In collaboration, two teams work closely “for a defined period of time to discover new things.” In X-as-a-Service, “one team provides and one team consumes something ‘as a Service’.” In facilitating, “one team helps and mentors another team.”
Teams can build together, serve one another, or coach. Each suits different work.
The Team Topologies website calls collaboration “high bandwidth, high cost” and a service “low cost, clear boundaries.” A service suits something stable. It goes wrong when the work is new and the boundary was drawn for the old. The Team Topologies newsletter says a good service “tends to emerge or evolve” through other modes, “such as ‘collaboration’ with potential users to understand what they truly need.”
In those terms, Ariane 5 ran its inertial unit as a pure service: a unit, a specification, simulated stand-ins in the tests. For a unit already flying on Ariane 4, that looked sensible. But the one fact it needed about the new rocket was the one the interface left out. The board’s sentence asks for both modes: cooperation to find the right boundary, then a simple interface across it.
Three years later NASA lost the Mars Climate Orbiter at a similar seam: Denver and Pasadena worked through a file and an interface specification, and its investigation board urged more face-to-face communication on the next Mars mission.
Where the labels stop helping
A mode doesn’t supply the missing fact. On Ariane 5, the decision to leave three risky variables unprotected was itself “taken jointly by project partners at several contractual levels.” Working together helps only if someone brings the new trajectory to the table. The board also blamed things no mode would fix, like the rule that any software error stop the processor.
Modes also drift. The newsletter calls permanent collaboration the most common misunderstanding of that mode: “hybrid teams” or “joint task forces” that never end, which it labels an “Undefined Interaction.”
The dashboard built for another question
Imagine an analyst who runs a weekly sales dashboard for store managers. It works as a service: they read it, she keeps it running, and they rarely talk. Then marketing starts judging its new loyalty program by the dashboard’s “repeat customers” figure, which was built to count store visits. Nobody told her about the program.
If she stays a service, the dashboard keeps answering its old question while marketing reads it as an answer to theirs. She could sit with marketing for two weeks, agree on a definition, then go back to serving it. Or she could coach marketing’s own analyst to query the data, and step away once he can. Staying a service costs nothing until the quarterly review.
Answers, partner or coach
A chat assistant can work in all three modes. In April 2025, Anthropic published an analysis of 574,740 conversations from Claude.ai accounts tied to university email addresses, filtered for coursework and research. About 47 percent were “Direct,” the student “seeking answers or content with minimal engagement.” The study covered one 18-day window, likely over-represents early adopters, and did not measure what students learned.
Six days earlier, Anthropic had launched a “Learning mode” that asks “How would you approach this problem?” instead of providing immediate solutions. In Team Topologies’ terms, that is facilitating, and the newsletter measures facilitating by how quickly the other side becomes self-sufficient.
You can check which mode you are in. To learn something, ask the model to question you rather than solve it. Then do the next similar problem with the chat closed. If you stall at the same step, that’s a sign the coaching isn’t finished.