The starting point isn't the ideal Scrum team from a seminar, but the real organization: a role mix that sometimes fits and sometimes doesn't, political jockeying, crisis mode as the normal state. AI doesn't replace leadership here — it makes friction visible before it costs a project.
Brilliant mind, completer, critic: this isn't a random observation, it lines up with Belbin's nine team roles (among them the Plant — the idea generator, the Completer Finisher, the Monitor Evaluator — the sober critic). Belbin's core finding was already clear in the 1980s: it isn't individual talent that decides, but composition — a team of nothing but geniuses often fails just as often as one without a single one.
Make politics disappear, switch off crisis mode, or fill Belbin roles optimally like a type-case. Organizations are not optimization problems — that would be goldplating at the wrong end again (Rule 1).
Make friction visible early: who gets systematically talked over in meetings? Where do blockers pile up around the same interface? Where is the completer missing from the role mix while three geniuses circle the same idea? Patterns from communication data, ticket history, and meeting cadence that a single PM would otherwise only notice after months.
The point isn't to know the model — it's to deliberately behave differently in each phase, the way you always have as a PM. AI reinforces exactly this phase-sensitivity instead of replacing it.
What used to run informally over a shared meal and a few glasses has become rare today for several reasons — not just tax rules (entertainment expenses now require stricter documentation), but culturally too: mixed teams, different life models, less tolerance for alcohol as a relationship catalyst in a professional context.
The habit, adopted from the American context, of not starting a meeting straight with the agenda but with a few sentences about something personal — that's not lost time, it's the compressed replacement for the dinner: a small, repeated dose of relationship work instead of a large, rare one. Precisely these small, honest moments of contact are Rule 2 (feedback cadence) at the relationship level — blockages often don't dissolve through the next argument, but through the next grain of trust.
AI's role: not to replace the small talk, but to help prepare for it — e.g. summarizing relevant, non-private common ground or current context points before an important meeting, so the first sentence lands instead of being a stock phrase.
The largest controlled field trial to date: 61 companies, roughly 2,900 employees, UK, coordinated by Autonomy/4 Day Week Global (2022) — full-time pay for 80% of working time, on the condition that output counts, not attendance.
Source: UK pilot project 2022 (Autonomy/4 Day Week Global), summarized among others by Multiplier and the World Economic Forum. Concrete revenue/productivity figures vary by company; the consistent finding is "at least as productive with an output-focused instead of time-focused way of working" — not a blanket productivity boost.
Google's "Project Aristotle" studied for years what actually makes hundreds of internal teams effective — with a result that surprised many: it wasn't the composition of talent that decided, but how the team worked together.
1. Psychological safety — being able to raise risks without fear of exposure. 2. Dependability — commitments are kept. 3. Structure & clarity — clear roles, processes, goals. 4. Meaning — a sense of purpose in one's own work. 5. Impact — one's own contribution visibly counts.
Psychological safety came out far ahead. Fear is structurally its opposite: anyone afraid to voice a mistake or a dissenting opinion delivers exactly what Rule 5 (truth before comfort) is meant to prevent — reassuring signals instead of honest ones. Fear "works" short term as obedience, but destroys precisely the channel through which a team catches its own mistakes early. The same dynamic exists mechanically: sycophancy loops in AI systems arise from exactly the same lack of psychological safety — only in the human raters instead of in the team.
Source: Google re:Work, "Understand team effectiveness" (Project Aristotle).
A personal connection, not name-dropping: Prof. em. Dr. Dr. h. c. Hans Gruber (today at the University of Regensburg, Faculty of Human Sciences) and I know each other from a completely different world — both players in the ZOMP zither orchestra, him additionally as conductor — the orchestra a repeated first-prize winner at the German Orchestra Competition, once even on a US tour. We didn't study together: I was at TU Munich in the middle of Module B3 Cybernetics (Electrical Engineering and Information Technology), while he was already well into his academic career at LMU Munich, at the time working on chess strategy. What remained were conversations on equal footing, without prejudice between fields that at first glance had nothing to do with each other — drawing arcs, transferring insights, applied GEB, long before I knew there was a name for it. His later research group empirically studied exactly what Google's Project Aristotle would confirm years later from the other side: how teams deal with mistakes decides their capacity to learn — not whether they make them.
Gartmeier, Bauer, Gruber & Heid coin the term negative knowledge in "Negative Knowledge: Understanding Professional Learning and Expertise" (Vocations and Learning, 1(2), 87–103, 2008): experience-based knowledge of what does not work in a work situation and should be avoided. Their core thesis: experts differ from beginners not just by knowing more, but by having explicit knowledge of which approaches are suboptimal — safety, efficiency, and reflection arise precisely from this negative side of experience, not only from the positive.
Gartmeier's Regensburg dissertation (2009, first reviewer Hans Gruber) backs this empirically: in a banking study with 84 employees, error competence, learning from mistakes, and reflecting on mistakes significantly predicted personal initiative — mediated by psychological safety. Two entirely independent lines of research, German educational science and Google's internal team research, arrive at the same mechanism.
Source: Gartmeier, Bauer, Gruber & Heid, "Negative Knowledge: Understanding Professional Learning and Expertise," Vocations and Learning 1(2), 87–103 (2008) · Prof. em. Dr. Dr. h. c. Hans Gruber, University of Regensburg
The name ZOMP (Zitherorchester München-Pasing e.V.) itself comes from this same well — an association name that carries recognition and pride (repeated first prize at the German Orchestra Competition, a US tour), even though in content it merely describes what it is.
At Siemens there was the counterpart in a business context: ADMOSS LAN was simply standard drop cabling with a hub for the ADMOSS directory/switching system on the EWSD — technically nothing you couldn't have gotten at any electronics retailer around the corner. Because it was tightly coupled to ADMOSS/EWSD and carried its own product name, even Siemens units from Singapore wanted to source it exclusively. The name alone had turned a commodity into an apparent unique selling point.
The lesson for PM and product: a good name doesn't just describe, it creates a fixed point on which perceived value attaches — independent of the technical substance underneath. That's as true for an orchestra as for a cabling system as for an AI product.
The same picture in almost every project: the official org chart isn't current, and the real effort of even identifying the right stakeholders in the first place regularly drags on over the first two months — before the actual project even begins in substance.
These two months usually vanish invisibly into "project ramp-up" — they're never tracked as their own metric, even though they repeat identically project after project. Across several projects a year this adds up to a substantial but never budgeted block of time — exactly the massive optimization potential that gets lost in day-to-day business because it's never seen as a whole.
Instead of relying on the outdated org chart, reconstruct who actually decides from actually lived traces: communication patterns (who is actually included in which threads), approval histories, ticket assignments. The result is a solid stakeholder map in days instead of months — and the necessary precursor to the PIS vector (Power/Interest/Status) from the rollout plan: you can't cleanly place someone by power and interest if you haven't even correctly identified them first.
Anonymized: the company, end customer, software vendor, and location are not named for confidentiality reasons. The structural lesson remains unchanged.