Freitag, 9. Januar 2026
Continuos Coordination
Unter den vielen verschiedenen agilen Frameworks dieser Welt ist Continuous Coordination in einer Hinsicht etwas Besonderes: es ist nicht als abstraktes Konzept aus Rollen und Regeln entstanden, die man dann später versucht hat, durch prozessunterstützende Software zu formalisieren (so wie es mit Scrum und Jira passiert ist), sondern am Anfang stand eine prozessunterstützende Software (Steady), aus deren Anwendungs-Erfahrungen irgendwann ein eigenständiges methodisches Vorgehen entstanden ist.
Die Idee dahinter dürfte gewesen sein, dass eine Koordinations-Software (genau wie jedes andere Tool) auch missbräuchlich oder versehentlich falsch genutzt werden kann. Um dem entgegenzuwirken entwickelten mehrere Entwickler und Nutzer mit der Zeit ein Set von Prinzipien und Praktiken, die eine Anwendung im ursprünglichen Sinn sicherstellen sollen. Und da diese auch mit jeder anderen Software umsetzbar sind, wurde Continuous Coordination zu etwas Eigenständigem.
Bedingt durch diese Entstehungsgeschichte finden sich in diesem Framework einige Besonderheiten. Zum einen ist es (genau wie die Software aus der es entstanden ist) für asynchrone Zusammenarbeit gedacht, also für eine in der die Kommunikation in Textform die meisten Meetings ersetzt. Zum anderen besteht es vor allem aus relativ abstrakten Prinzipien, die weniger einen Anleitungs-Charakter haben und eher die zugrundeliegenden Ideen klar machen sollen. Es sind die folgenden:
01: Keep a steady beat
Im Grunde eine Abwandlung des Constant Pace aus dem Manifest für agile Software-Entwicklung. In regelmässigen Abständen (meistens täglich) schreibt jeder in gemeinsame Chat-Gruppen oder Kanäle woran er arbeitet, wo Abhängigkeiten sind, wie der Fortschritt ist, etc. Teamübergreifend sind die Frequenzen seltener, z.B. wöchentlich.
02: Lead with context
Führung in diesem Zusammenhang ist nicht nur disziplinarische Führung, es kann auch hierarchiefreie fachliche oder technische Führung sein. Wichtig ist in allen diesen Fällen, dass schriftlich explizit gemacht wird, welches Ziel, welche Abhängigkeiten und welche Rahmenbedingungen oder eine Anforderung hat. Die Umsetzung soll dann selbstorganisiert erfolgen, ohne Anleitung und Kontrolle.
03: Work in the open
Aufbauend auf dem letzten Punkt stellt sich die Frage, wie Fehler, falsche Annahmen und Ähnliches in diesem Modus entdeckt werden können. Die Antwort: durch maximale Transparenz der eigenen Arbeit. Alle Anforderungen, alle fachlichen Diskussionen, Deployments und Dokumentationen stehen allen anderen in Schriftform in Wikis, gemeinsamen Laufwerken oder Versionshistorien zur Verfügung.
04: Tell the future
Entlehnt von der Intent-based Leadership aus David Marquets Buch Turn the Ship around kann jeder durch regelmässige Absichtserklärungen transparent machen, wie und woran er als nächstes arbeiten wil. Wer Fragen, Ergänzungen oder Einwände hat kann die dann äussern und klären, und so ggf. Konflikte vermeiden bevor sie überhaupt entstehen.
05: Spare the meetings
Bevor falsche Ideen aufkommen: Continuos Coordination legt Wert darauf, dass Meetings existenziell wichtig sind, aber eben nicht alle. Während z.B. Retrospektiven, Kreativ-Sessions oder Wissenstransfer-Termine auf jeden Fall stattfinden sollten, können Dailies, Status-Meetings, Feedback-Sammlungen oder Informationsveranstaltungen auch asynchron in Schriftform stattfinden.
06: Write it down
Gemeint ist hier nicht etwa ein Ergebnis-Protokoll, sondern im Gegenteil ein im Voraus stattfindendes Aufschreiben von Zielen, Erfolgsfaktoren, Zusammenhängen und angestrebten Effekten. Das hilft zum einen bei der Strukturierung der eigenen Gedanken und hilft zum anderen bei der Erfolgsmessung. Übernommen ist es von Amazons Press Releases.
07: Track output, not input
Zuletzt ein klarer Bruch mit vielen klassischen Management-Praktiken. Statt zu messen und steuern zu wollen, wie viel Arbeitszeit und Ressourcen in eine Aufgabe hineingehen soll der Focus von Messungen das erzeugte Ergebnis sein, und das nicht etwa in Form von des Zählens von Features oder Code-Zeilen, sondern von Ergebnissen wie Kundenzufriedenheit, Nutzungsintensität oder Profitabilität.
Trotz ihrer Abstraktheit haben diese Prinzipien bei Befolgung deutlich spürbare Auswirkungen, und sorgen dafür, dass eine Organisation die sie befolgt sich deutlich von anderen unterscheidet - sowohl von agilen als auch von nicht-agilen. Kern-Element ist dabei die möglichst intensive Nutzung von asynchroner, schriftlicher Kommunikation und die Beschränkung von synchroner Kommunikation auf der Tonspur auf wenige, dafür aber zentrale Formate.
Für jeden, der sich von zu vielen Meetings von der Arbeit abgehalten sieht wird dieser Arbeitsmodus sofort attraktiv erscheinen, und er kann auch sehr gut funktionieren, er kommt aber mit einem Preis - die Arbeit wird auf diese Weise unpersönlicher, abstrakter und für viele Menschen gefühlt einsamer. Dessen sollte man sich zu Beginn bewusst sein, und man sollte in regelmässigen Abständen überprüfen ob und wie die Beteiligten damit klarkommen.
Und zuletzt: dieser Modus benötigt einfach bedienbare, für alle zugängliche, wenig reglementierte digitale Tools. Auch die müssen erst mal da sein.
Montag, 5. Januar 2026
Brooks’s Law
 |
| Bild: Wikimedia Commons / David.Monniaux - CC BY-SA 3.0 |
Von den so genannten "Gesetzen der Softwareentwicklung" oder "Gesetzen des Projektmanagement" gibt es mittlerweile unübersehbar viele, allerdings stehen einzelne deutlich aus dieser Menge heraus. Eines davon ist Brooks's Law, benannt nach seinem Verfasser, dem amerikanischen Informatiker Frederick Brooks1, der es 1975 im Essay The Mythical Man-Month in seinem gleich benannten Buch zum ersten mal veröffentlichte. Es lautet:
Adding manpower to a late software project makes it later / Das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt sorgt für noch mehr VerspätungFrederick Brooks, The Mythical Man-Month, S.25
Der Grund dafür, dass Brooks diese Gesetzmässigkeit verfasste war der, dass das übliche Management-Verhalten in Software-Projekten damals genau gegenläufig war.2 Tatsächlich erscheint es auf den ersten Blick auch naheliegend - jede einzelne Person kann eine bestimmte Menge Arbeit pro Zeiteinheit erledigen, wenn man also weitere Personen hinzufügt könnte man davon ausgehen, dass in der selben Zeit mehr Arbeit erledigt werden kann. Aber so einfach ist es nicht.
Brooks nannte gleich mehrere Gründe, die dafür sorgen, dass statt einer Beschleunigung eine zusätzliche Verspätung auftritt. Der erste und offensichtlichste: neue Kollegen müssen zuerst eingearbeitet werden um arbeitsfähig zu sein, und das kann in der Regel niemand anderes tun als eine der Personen, die bereits länger mitarbeiten. Für die Dauer der Einarbeitungszeit kann er daher selbst nur eingeschränkt produktiv sein, die Arbeitskapazität nimmt also zunächst ab.
Selbst wenn die Einarbeitung abgeschlossen ist, gehen die verzögernden Effekte aber weiter. Wenn ein Vorhaben ursprünglich für eine geringere Umsetzungsmannschaft ausgelegt war, müssen als nächstes die Umsetzungsplanung und Aufgabenteilung überarbeitet werden, um sicherzustellen, dass synchrone und sequenzielle Abhängigkeiten berücksichtigt werden. Auch das benötigt wieder Arbeitskapazität, die dann bei der Umsetzung fehlt und diese dadurch verzögert.
Nun könnte man davon ausgehen, dass diese Verlangsamungs-Faktoren nur temporär sind. Irgendwann sind Einarbeitung und Umplanung abgeschlossen, und es kann mit erhöhter Geschwindigkeit weitergehen. Aber zum einen ist in den meisten verspäteten Projekten die dafür notwendige Zeit gar nicht gegeben, und zum anderen gibt es noch einen weiteren Faktor, der nicht temporär sondern dauerhaft sind, und der speziell mit den Abläufen der Softwareentwicklung zu tun hat.3
Wenn bei der Entwicklung einer Software neuer Code geschrieben wird, muss dieser danach in den bestehenden integriert werden. Um sicherzustellen, dass dieser danach noch immer funktioniert, sind Tests notwendig, und bei steigender Menge von Code schreibenden Entwicklern steigen auch Frequenz und Umfang der durchzuführenden Tests. Aufgrund dessen wird ein immer grösser werdender Teil der Arbeitskapazität dafür benötigt, die Tests aktuell zu halten, durchzuführen und auszuwerten.
Selbst wenn Softwareentwicklung heute etwas anders funktioniert als zu Brooks Zeit (sein Gesetz ist mittlerweile schon über 50 Jahre alt) haben sich die von ihm beschriebenen grundlegenden Zusammenhänge bis heute erhalten. Man kann daher noch immer davon ausgehen, dass das Hinzufügen von Arbeitskräften zu einem verspäteten Projekt nicht für eine Beschleunigung sorgt, sondern für noch mehr Verspätung, und das nicht nur kurzfristig, sondern dauerhaft.
2Was sich bis heute in weiten Teilen leider nicht geändert hat
3Brooks hat sein Gesetz auf Softwareentwicklungs-Projekte bezogen
Mittwoch, 31. Dezember 2025
Kommentierte Links (CXXXV)
 |
| Bild: Pexels / Ekam Juneja - Lizenz |
James Shore: The Best Product Engineering Org in the World
Eigentlich war ich mir ziemlich sicher, das Video von James Shore's Keynote auf dem Regional Scrum Gathering Tokyo irgendwann mal in einen Post auf dieser Seite eingebunden zu haben. Da ich es nicht finde, ist hier das Transkript. Anscheinend ist seine Firma, die er hier beschreibt, einer der mittlerweile seltenen Fälle, in denen Extreme Programming der offizielle Arbeitsmodus ist - und wenn man ihm glauben darf, mit durchschlagendem Erfolg.Charles Lambdin: Why Agile Is Losing Steam
Artikel über die Ursachen der zur Zeit abnehmenden Beliebtheit agiler Arbeitsweisen gibt es viele, die meisten davon allerdings nur mit geringem Tiefgang, bzw. mit der offensichtlichen Absicht, mit einer Alternative zu Geld oder (unternehmensintern) zu mehr Macht zu kommen. Charles Lambdins Text hat wesentlich mehr Tiefgang, da er auf einer systemischen Betrachtung der umgebenden Gesamt-Organisationen aufbaut, mit denen die agilen Teams und Methodiker oft eher unglücklich interagieren.Itamar Gilad: Embracing Uncertainty - A Modern Take On Strategy, Goals, and Roadmaps
Itamar Gilad setzt mit seinen Überlegungen an einem häufigen Problempunkt an: wenn die Märkte und Technologien sich ständig ändern, wie kann man da planen? Und umgekehrt - wie soll man ohne Planungen in der Lage sein, ein Unternehmen zu führen? Seine Ausführungen fassen einige bewährte Praktiken zusammen, mit deren Hilfe man diesem Dilemma entkommen kann, verbunden mit einigen hilfreichen Tools und Visualisierungen.Steve Denning: How Networks Of Competence Help Avoid The Trauma Of Reorganizations
Dass Reorganisationen grosser Unternehmen auf viele Mitarbeiter traumatisierend wirken können ist einer der dunklen Aspekte des Change Managements, über die eher selten gesprochen wird. Steve Denning sieht die Ursache dafür in dem typischen Organisationsdesign, in dem Identifikation und Expertenstatus sich aus der Zugehörigkeit zu Organisationseinheiten ableiten (und mit ihnen verloren gehen können). Seine naheliegende Lösung: die Entkoppelung dieser Aspekte von der Firmenstruktur.Tobias Mayer: A simple Guide to Scrum
Um zu verstehen, warum das eigentlich sehr einfache Scrum-Framework von vielen Menschen als kompliziert und unverständlich empfunden wird, muss man sich die offiziellen Scrum-Regeln wie eine Legacy-Software vorstellen, die seit mehr als einem Vierteljahrhundert ständig erweitert und angepasst wird. Das was Tobias Mayer gemacht hat, kann man im Rahmen dieser Metapher als Refactoring verstehen: die Funktionsweise ist die gleiche geblieben, aber der Aufbau ist wesentlich klarer.Charity Majors: In Praise of “Normal” Engineers
Der Hintergrund dieses Artikels ist ein Mythos, und zwar der des so genannten "10x Engineer", also einer Softwareentwicklers, der zehnmal besser ist als der Durchschnitt, und der daher der ideale Angestellte einer IT-Firma ist. Charity Majors relativiert diese Wunschvorstellung und ordnet sie ein: in einem so grossen und sich so stark ändernden Berufsfeld wie der IT ist es praktisch unmöglich, dauerhaft 10x Engineer zu sein. Besser als trotzdem nach einem zu suchen ist es daher, ein Umfeld zu schaffen, in dem auch normale Entwickler das Beste aus sich herausholen können.Benji Weber: Teamwork & XP in the era of Genies
Um Missverständnisse zu vermeiden: wenn Benji Weber von "Genies" spricht, dann meint er nicht geniale Menschen, sondern die Softwareentwicklung unterstützende KI-Programme, die für ihn Geister (englisch: Genies) sind, die man nicht wieder in ihre Flasche zurückbekommt. Was er herausstreicht: der beste Arbeitsmodus für sie ist der, der auch bei menschlichen Programmierern der beste ist - kleine Releases, kleine Codebase, schnelle Tests, viel Automatisierung und verständlicher Code.Mike Fisher: How Culture Scales (or Doesn’t)
Von vielen Menschen wird (Unternehmens-)Kultur als etwas gesehen, das einfach da ist und sich nicht gezielt verändern oder gestalten lässt Die Organisationssoziologie und -psychologie würde widersprechen: es geht, allerdings mit dem Haken, dass es nicht einfach ist - vor allem in grossen Organisationen. Zum Glück hat Mike Fisher gerade für die einiges an Ratschlägen parat, mit deren Hilfe man sich dieser verdienstvollen Aufgabe annehmen kann.Melissa Suzuno: The Product Operating Model Explained
Zum Product Operating Model, dem v.A. von Marty Cagan popularisierten Arbeitsmodus der kalifornischen Tech-Firmen, ist schon viel gesagt und geschrieben worden. Was diese Erklärung von Melissa Suzuno aus dieser Masse heraushebt ist die Mischung aus Struktur und Ausführlichkeit. Man muss sich etwas Zeit nehmen, aber dann weiss man nicht nur wie das Ganze gedacht ist, sondern auch wie man versuchen kann, es bei sich einzuführen und was man dabei beachten sollte..Jeff Gothelf: What if there’s no behavior change to measure?
Zu den grossen Mantras der Objectives und Key Results (in der Produktentwicklung) gehört es, dass sie auf eine Verhaltensänderung der Käufer oder Nutzer eines Produktes abzielen sollten, und zwar auf eine, die gemessen werden kann. Das macht erstmal Sinn, wirft aber die Frage auf, wie man dann im Fall von Refactorings oder nichtfunktionaler Anforderungen mit OKRs arbeiten kann, schliesslich soll dabei ja keine Änderung spürbar sein. Jeff Gothelfs eigentlich naheliegende Antwort: in solchen Fällen sollte darauf hingearbeitet werden, dass Käufer oder Nutzer ihr Verhalten nicht ändern. Eigentlich einfach.
Montag, 29. Dezember 2025
Kommentierte Links (CXXXIV)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
John Cutler: Product Operating Models vs Operating Systems (Part I, Part II)
In den letzten Jahren ist das "Product Operating Model" zu einem beliebten Buzzword in der Welt der Manager und Unternehmensberater geworden, häufig verbunden mit der Ankündigung, es im eigenen Unternehmen, bzw. beim Kunden einführen zu wollen. Das das nicht ganz so einfach ist, kann man sich denken, und John Cutler zeigt auf warum: ein Operating Model ist per Definition so abstrakt, dass es an den jeweiligen Kontext angepasst werden muss. Da beginnen dann die Schwierigkeiten.Roman Pichler: Should Product Teams be Self-Managing?
In den Produktmanagement- und Agile-Communities dürfte diese Frage fast durchgehend mit ja beantwortet werden - (gute) Product Teams müssen selbstorganisiert sein. Wie das im konkreten Fall aussehen soll ist dann schon weit weniger klar (siehe oben). Roman Pichler nennt daher einige zentrale Erfolgsfaktoren: die Team-Zusammenstellung, das Zusammenarbeitsmodell, den Handlungsspielraum, die Führung und die Förderung.Andi Roberts: Why Tuckman’s model may no longer serve 21st century teams
Wenn wir über Tuckmanns Phasen-Modell sprechen (Forming, Storming, Norming, Performing, Adjourning) muss uns bewusst sein, dass es keine empirisch überprüfbare Regelmässigkeit ist, sondern ein in der Realität kaum auftretendes Ideal. Alternative Ansätze wie dieser hier von Andi Roberts sind daher hochgradig sinnvoll, allerdings handelt es sich in seinen eigenen Worten zunächst nur um ein mögliches Vorgehen, also eines, für das noch Erfahrungswerte fehlen.Jessica Wolfe: Rethinking “The Developer” - Builders, Modernizers, Orchestrators
Um die oft komplexe Realität für uns begreifbar zu machen, neigen wir Menschen zur Bildung von Kategorien oder Gruppen, denen wir dann gemeinsame Merkmale zuschreiben. Dass wir dabei manchmal über das Ziel hinausschiessen, zeigt Jessica Wolfe am Beispiel der Gruppe der Software-Entwickler. Die ist in der Realität keineswegs einheitlich, sondern umfasst verschiedene, sehr kontextspezifische Ausprägungen, mit denen jeweils eigene Interaktionsformen Sinn machen.Mike Fisher: When Change Outruns Us
Eine der Regeln für den totalen Stillstand in Unternehmen lautet, dass die Geschwindigkeit auf der Beschlussebene höher sein sollte als die Geschwindigkeit auf der Umsetzungsebene. Mike Fisher zeigt in diesem Text auf, dass das mehr als nur eine Pointe ist - in vielen Firmen ist es ein ernsthaftes Problem, das dort die Profitabilität, Innovationsfähigkeit und Handlungsfähigkeit massiv einschränken kann. Und er gibt auch Ratschläge, wie sich Veränderungen nachhaltiger gestalten lassen.Freitag, 26. Dezember 2025
Silent Code
Es ist ja die besinnliche Zeit - passend dazu gibt es besinnliche Musik.
Dienstag, 23. Dezember 2025
Überwintern
 |
| Bild: Pixabay / Fabio Piccini - Lizenz |
Es gibt Phasen, in denen machen agile Transitionen eine Pause. Ein neues Management kommt, will durchregieren und alles kontrollieren, langfristige Detailplanungen machen, die Arbeit in Gewerke oder Wasserfall-Stufen aufteilen, Herrschaftswissen aufbauen und dergleichen mehr. Das ist unschön, zumindest in grossen Organisationen aber temporär - der nächste Management-Umschwung kommt so sicher wie der nächste Frühling. Irgendwann gibt es dann wieder Transparenz und Selbstorganisation.
Die typische Reaktion von Konzernmitarbeitern mit Neigung zu solchen Arbeitsweisen ist es, in einen "Überwinterungszustand" zu gehen. Man zieht sich von der Vorderbühne der Organisation zurück, sucht sich einen geschützten Raum (Projekte, Abteilungen, etc), in dem der Veränderungsdruck erträglich erscheint, und bildet dort mit anderen gleichgesinnten eine Schläferzelle, die wieder aktiviert werden kann, wenn der Management-Wind sich erneut dreht.
Derartige Überwinterungen werden häufig vom Management eher kritisch gesehen, da hier ein Unterlaufen der aktuellen Unternehmensführung gesehen wird. Man kann aber auch eine positive Sicht darauf haben - wer in die Überwinterung geht, macht die Bühne frei für andere, die vom aktuellen Vorgehensmodell überzeugter sind, gibt ihnen die Chance sich zu beweisen, bewahrt aber die eigene Expertise, für den Fall, dass sie doch gebraucht wird.
Die spannende Frage, die sich daraus ergibt, ist aber, wie der Expertisen-Erhalt in einer Überwinterungs-Phase stattfinden kann? Der offizielle Arbeitsmodus ist schliesslich ein anderer, so dass Learning by Doing (oder Sustaining by Doing) nicht mehr so einfach möglich sind wie vorher. Und auch das Budget für Weiterbildungen und Schulungen wird jetzt für andere Zwecke eingesetzt. Hier sind einige praxiserprobte Ideen wie das gelingen kann.
Agile Ausgestaltung anderer Termine und Prozesse
Auch in einem formal nicht-agilen Arbeits-Setting spricht nichts dagegen, den Tag mit einer Morgenrunde zu beginnen, in dem jeder ein Update dazu gibt woran er gerade arbeitet, wie er vorankommt oder wo er Hilfe brauchen könnte. In Status-Meetings kann man Feedback integrieren, in Abteilungs- oder Projektmeetings Verbesserungsideen, etc., etc.
Arbeit an technischer Exzellenz
Ein spannender Fall von notwendiger und hinreichender Bedingung: man kann ohne technische Exzellenz nicht agil arbeiten, aber ohne agil zu arbeiten technische Exzellenz vorantreiben. Von Clean Code über hohe Testabdeckung bis hin zu klarer Architektur - das alles hilft in jedem Arbeitsmodus, und es kann später wieder eine gute Ausgangsbasis für iterativ-incrementelles Arbeiten sein.
Lösungsorientiertes Vorschlagswesen
Selbst wenn man in einem hierarchisch organisierten Umfeld vieles nicht selbst entscheiden kann - Vorschläge machen kann man immer. Und wenn die zum Gegenstand haben, dass sich irgendetwas mit vertretbarem Umwand so umstellen lässt, dass es schneller, billiger oder in besserer Qualität fertig wird, dann ist die Wahrscheinlichkeit gross, dass man Gehör findet.
Nutzung leichtgewichtiger Tools
Es müssen nicht immer Jira und Miro sein, in fast jeder Firma finden sich mittlerweile Tools, die kollaboratives Arbeiten ermöglichen. Um ein einfaches Beispiel zu nennen: geteilte Präsentationen in Google Docs oder Microsoft 365 können mittlerweile in Meetings ähnlich genutzt werden wie Miro oder Conceptboard (siehe hier). Man muss nur bereit sein, etwas herumzuprobieren.
Feedback auf dem kurzen Dienstweg
Nur weil es keine Sprint Reviews gibt heisst das nicht, dass man mit Kollegen und internen Anwendern nicht sprechen kann. Vom schnellen Abstimmungscall über gemeinsames Kaffeetrinken bis hin zum Sitzen an benachbarten Arbeitsplätzen (wenn es im Büro flexible Platzwahl gibt) ist vieles möglich, um einfache und schnelle Kommunikation möglich zu machen.
Über den Tellerrand blicken
Auch über die unmittelbare eigene Arbeitsumgebung hinaus gibt es Möglichkeiten, die eigene "agile Expertise" zu erhalten und auszubauen. Geld für Konferenzen und Schulungen mag keines da sein, aber in fast jeder grösseren Stadt gibt es einen Scrumtisch, einen Lean Coffee oder ähnliche Meetups auf denen man sich austauschen und dazulernen kann.
Wie immer bei derartigen Listen ist es auch bei dieser so, dass sie noch lange weitergehen könnte, die Grundidee ist aber klar: auch in einem offiziell nicht-agilen Arbeitsumfeld lässt sich viel machen, um auch während einer Überwinterungsphase noch agil arbeiten und lernen zu können. Gegebenenfalls nicht mit den sonst üblichen Begriffen, Tools und Methoden, aber orientiert an den darunterliegenden Ideen und Prinzipien. Und das ist schliesslich das eigentlich Wichtige.
Und ganz nebenbei: auch wenn es länger dauern sollte bis auch offiziell wieder agil gearbeitet werden kann - die Dinge die weiter oben stehen machen auch jeden anderen Arbeitsmodus effektiver. Ein weiterer Grund dafür, sie zu tun.
Freitag, 19. Dezember 2025
The agile Bookshelf: Range
Falls jemand noch ein Buch zum Verschenken sucht - Range: Why Generalists Triumph in a Specialized World ist sehr empfehlenswert. Geschrieben wurde es vom amerikanischen Journalisten David Epstein, und er hat mit ihm das Kunststück vollbracht, ein Werk zu schreiben, das für gleich mehrere unterschiedliche Bereiche relevant ist: Erziehung, Karriereplanung, Persönliche Entwicklung, Personalentwicklung, Organisationsentwicklung und mehr.
Der Entstehungshintergrund des Buches ist eine zu Beginn des 21. Jahrhunderts stattfindende Debatte darüber, ob eine möglichst frühe, und idealerweise bereits in der Kindheit beginnende, Spezialisierung der beste Weg zu überdurchschnittlichen Leistungen in einem Wissensgebiet oder Tätigkeitsfeld ist. In der allgemeinen Wahrnehmung wurde das eher bejaht, und mit Verweisen auf "Wunderkinder" wie Tiger Woods oder Wolfgang Amadeus Mozart belegt.
In dieser Zeit fiel Epstein bei seinen Recherchen zu seinem vorherigen Buch The Sports Gene auf, dass es zahlreiche Fälle von Spitzensportlern gab, deren Karriere genau gegenteilig verlief - bis in in ihre jungen Erwachsenenjahre wechselten Sie zwischen verschiedenen Sportarten, bevor sie sich für eine entschieden. Und sie benannten diese grosse Bandbreite nicht etwa als ein Hindernis für ihren Erfolg, sondern sogar als einen der wichtigsten Erfolgsfaktoren.
Aufmerksam geworden begann er zu recherchieren, ob diese Abweichungen von der angenommenen Wahrheit der sinnvollen frühen Spezialisierung auch ausserhalb des Sports auftraten, und wurde auch dort fündig. Egal ob in Wirtschaft, Wissenschaft, Kunst oder anderen Bereichen, überall gab es Karrieren, in denen sich Schwerpunkte erst spät oder nur temporär herausgebildet hatten, von Charles Darwin über Albert Einstein und Roger Federer bis Mark Zuckerberg.
Alleine die Erkenntnis, dass frühe Spezialisierung nicht der beste oder einzige Weg zum Erfolg ist, war bereits bemerkenswert, darüber hinaus fand Epstein aber einen Bereich, in dem vielfältig, generalistisch oder fachfremd ausgebildete Menschen bessere und schnellere Lösungen fanden als die, die sich schon früh auf nur ein Thema focussiert hatten - bei neuartigen oder komplexen Problemen. Hier war es offensichtlich von Vorteil, einen breiten Erfahrungshorizont zu haben.
Range: Why Generalists Triumph in a Specialized World ist eine Leseempfehlung, weil es eine seltene Kombination verschiedener Aspekte ist. Es regt zum Denken an und hinterfragt scheinbare Gewissheiten, es ist mit zahlreichen Fakten und Belegen untermauert, es ist flüssig und unterhaltsam geschrieben und es enthält Anstösse, die man im eigenen Berufs- und Privatleben umsetzen kann.
Montag, 15. Dezember 2025
Trust as Infrastructure
Trotz aller künstlichen Intelligenz - am Ende sind es Menschen, die Software erstellen. Auf diese Prämisse baut Bryan Cantrill seinen Vortrag auf, in dem er das Vertrauen in die Menschen in den Software-Entwicklungsorganisationen zu einer zentralen Infrastruktur der IT-Industrie erklärt. Dieses Vertrauen muss gegeben sein, da in einem komplexen Umfeld vollständige Kontrolle nicht möglich ist.
Spannend ist dabei, dass Cantrill das Thema Vertrauen von seiner verbreitetsten Interpretation löst, nämlich dem, dass es eine auf einzelne Personen bezogene positive Erwartung ist. Stattdessen arbeitet er heraus, dass es in Organisationen oder Bewegungen (wie der Open Source-Bewegung) ein ganzes Geflecht verschiedenster Vertrauensbeziehungen innerhalb zwischen verschiedenen Gruppen geben muss, wenn irgendetwas funktionieren soll.
