Debugging-Teams

Kapitel 1. Der Mythos des genialen Programmierers

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Da dies ein Buch über die sozialen Gefahren der kreativen Entwicklung ist, macht es Sinn, sich auf die eine Variable zu konzentrieren, die du definitiv kontrollieren kannst: dich.

Menschen sind von Natur aus unvollkommen. Aber bevor du die Fehler deiner Mitarbeiter/innen verstehen kannst, musst du die Fehler in dir selbst verstehen. Wir werden dich auffordern, über deine eigenen Reaktionen, Verhaltensweisen und Einstellungen nachzudenken - und hoffen, dass du im Gegenzug einen Einblick bekommst, wie du ein effizienter und erfolgreicher Softwareentwickler wirst. Am Ende wirst du weniger Energie darauf verwenden, dich mit menschlichen Problemen auseinanderzusetzen und mehr Zeit damit verbringen, guten Code zu schreiben.

In diesem Kapitel geht es darum, zu verstehen, dass Softwareentwicklung ein Teamsport ist. Und um in einem Entwicklungsteam - oder in jeder anderen kreativen Zusammenarbeit - erfolgreich zu sein, musst du dein Verhalten nach den Grundprinzipien Demut, Respekt und Vertrauen ausrichten.

Bevor wir etwas überstürzen, wollen wir zunächst einmal beobachten, wie sich Programmierer/innen im Allgemeinen verhalten.

Hilf mir, meinen Code zu verstecken

In den letzten zehn Jahren haben wir beide oft auf Programmierkonferenzen gesprochen. Nachdem wir 2006 den Open-Source-Dienst Project Hosting von Google eingeführt hatten, bekamen wir viele Fragen und Anfragen zu diesem Produkt. Mitte 2008 bemerkten wir einen auffälligen Trend bei den Anfragen, die wir erhielten:

Könnt ihr Subversion auf Google Code bitte die Möglichkeit geben, bestimmte Zweige auszublenden?

Könnt ihr es möglich machen, Open-Source-Projekte zu erstellen, die zunächst für die Welt verborgen sind und dann offengelegt werden, wenn sie fertig sind?

Hallo, ich möchte meinen gesamten Code von Grund auf neu schreiben. Kannst du bitte den gesamten Verlauf löschen?

Kannst du ein gemeinsames Thema bei diesen Anfragen erkennen?

Die Antwort ist Unsicherheit. Die Menschen haben Angst davor, dass andere ihre Arbeit sehen und beurteilen könnten. Das liegt in gewisser Weise in der menschlichen Natur - niemand mag es, kritisiert zu werden, vor allem nicht für Dinge, die noch nicht fertig sind. Diese Einstellung hat uns auf einen Trend in der Softwareentwicklung aufmerksam gemacht. Unsicherheit ist eigentlich das Symptom eines größeren Problems.

Der Mythos des Genies

Wir beide lebten in den 1990er Jahren in Chicago und wurden Zeuge der unglaublichen Serie von Meisterschaftsgewinnen der Chicago Bulls. Die nationalen Medien waren jahrelang mit Berichten über dieses fantastische Basketballteam übersättigt. Aber worauf konzentrierten sich Fernsehen und Zeitungen wirklich? Nicht so sehr auf das Team, sondern auf Michael Jordan, den Superstar. Jeder Spieler auf der Welt wollte wie MJ sein. Wir sahen ihm zu, wie er um andere Spieler herumtanzte. Wir sahen ihn in Werbespots im Fernsehen. Wir sahen uns alberne Filme an, in denen er mit Zeichentrickfiguren Basketball spielte. Er war ein Star, und jedes Kind, das auf dem Platz Basketball spielte, wünschte sich insgeheim, einmal in seine Fußstapfen zu treten.

Viele Menschen haben den Instinkt, Idole zu finden und zu verehren. Für Softwareentwickler/innen könnten das Linus Torvalds, Guido Van Rossum oder Bill Gates sein - alles Helden, die die Welt mit Heldentaten verändert haben. Linus hat Linux doch selbst geschrieben, oder?

Eigentlich hat Linus nur die Anfänge eines Unix-ähnlichen Kernels geschrieben und ihn einer E-Mail-Liste gezeigt. Das war keine kleine Leistung und definitiv eine beeindruckende Leistung, aber es war nur die Spitze des Eisbergs. Linux ist hundertmal größer als das und wurde von Tausenden kluger Leute entwickelt. Linus' eigentliche Leistung bestand darin, diese Leute zu leiten und ihre Arbeit zu koordinieren. Linux ist das glänzende Ergebnis nicht seiner ursprünglichen Idee, sondern der gemeinsamen Arbeit der Gemeinschaft. (Und Unix selbst wurde nicht komplett von Ken Thompson und Dennis Ritchie geschrieben, sondern von einer Gruppe kluger Leute in den Bell Labs).

Hat Guido Van Rossum persönlich alle Pythons geschrieben? Sicherlich, er hat die erste Version geschrieben. Aber Hunderte von anderen trugen mit Ideen, Funktionen und Fehlerkorrekturen zu den nachfolgenden Versionen bei. Steve Aufträge leitete ein ganzes Team, das den Macintosh entwickelte, und Bill Gates ist zwar dafür bekannt, dass er einen BASIC-Interpreter für frühe Heimcomputer schrieb, aber seine größte Leistung war der Aufbau eines erfolgreichen Unternehmens rund um MS-DOS. Dennoch wurden sie alle zu Führungspersönlichkeiten und Symbolen für die kollektiven Errungenschaften ihrer Gemeinschaften. Der Genie-Mythos ist die Tendenz von uns Menschen, den Erfolg eines Teams einer einzelnen Person/Führungsperson zuzuschreiben.

Und was ist mit Michael Jordan?

Es ist die gleiche Geschichte. Wir vergöttern ihn, aber Tatsache ist, dass er nicht jedes Basketballspiel allein gewonnen hat. Seine wahre Genialität lag in der Art und Weise, wie er mit seinem Team zusammenarbeitete. Der Trainer des Teams, Phil Jackson, war äußerst clever - seineCoaching-Techniken sind legendär: Er erkannte, dass ein Spieler allein niemals eine Meisterschaft gewinnt, und so stellte er ein ganzes "Dream Team" um MJ herum zusammen. Das Team war eine gut geölte Maschine - mindestens so beeindruckend wie Michael selbst.

Warum also vergöttern wir immer wieder die Person in diesen Geschichten? Warum kaufen Menschen Produkte, die von Berühmtheiten empfohlen werden? Warum wollen wir das Kleid von Michelle Obama oder die Schuhe von Michael Jordan kaufen?

Berühmtheit ist ein großer Teil davon. Der Mensch hat einen natürlichen Instinkt, Führungspersönlichkeiten und Vorbilder zu finden, sie zu vergöttern und zu versuchen, sie nachzuahmen. Wir alle brauchen Helden, um uns zu inspirieren, und auch die Programmierwelt hat ihre Helden. Das Phänomen der "Techie-Prominenz" ist fast schon in die Mythologie übergegangen. Wir alle wollen etwas Weltveränderndes wie Linux schreiben oder die nächste brillante Programmiersprache entwickeln.

Insgeheim wünschen wir uns alle, ein Genie zu sein. Die ultimative Geek-Fantasie ist es, von einer genialen neuen Idee überrumpelt zu werden. Du verkriechst dich wochen- oder monatelang in deiner Batcave und arbeitest an der perfekten Umsetzung deiner Idee. Dann lässt du deine Software auf die Welt los und schockierst alle mit deiner Genialität. Deine Kollegen sind erstaunt über deine Cleverness. Die Leute stehen Schlange, um deine Software zu nutzen. Ruhm und Reichtum sind die logische Folge.

Aber Moment mal: Zeit für einen Realitätscheck. Du bist wahrscheinlich kein Genie.

Nichts für ungut - wir sind sicher, dass du ein sehr intelligenter Mensch bist. Aber ist dir klar, wie selten echte Genies wirklich sind? Sicher, du schreibst Code, und das ist eine knifflige Fähigkeit, die dich wahrscheinlich über einen Großteil der menschlichen Bevölkerung stellt. Aber selbst wenn du ein Genie bist, istdas nicht genug. Auch Genies machen Fehler, und brillante Ideen und erstklassige Programmierkenntnisse sind keine Garantie dafür, dass deine Software ein Erfolg wird. Entscheidend für deine Karriere ist, wie gut du mit anderen zusammenarbeitest.

Es stellt sich heraus, dass dieser Genie-Mythos nur ein weiterer Aspekt unserer Unsicherheit ist. Die meisten Programmiererinnen und Programmierer haben Angst davor, ihre Arbeit, mit der sie gerade erst begonnen haben, mit anderen zu teilen, weil das bedeutet, dass die anderen ihre Fehler sehen und wissen, dass der Autor des Codes kein Genie ist. Um einen Programmierer aus Bens Blog zu zitieren:

Ich weiß, dass ich SEHR unsicher werde, wenn die Leute gucken, bevor ich etwas gemacht habe. Als ob sie mich verurteilen und für einen Idioten halten würden.

Das ist ein sehr verbreitetes Gefühl unter Programmierern, und die natürliche Reaktion ist, sich in einer Höhle zu verstecken und zu arbeiten, arbeiten, arbeiten. Niemand wird deine Patzer sehen; du hast immer noch die Chance, dein Meisterwerk zu enthüllen, wenn du fertig bist. Verstecke dich, bis alles perfekt ist.

Ein weiterer Grund, sich nicht in die Karten blicken zu lassen, ist die Angst, dass ein anderer Programmierer deine Idee aufgreift, bevor du sie umsetzen kannst. Indem du sie geheim hältst, kontrollierst du die Idee.

Wir wissen, was du jetzt wahrscheinlich denkst: Na und? Sollten die Menschen nicht arbeiten dürfen, wie sie wollen?

Eigentlich nicht. In diesem Fall behaupten wir, dass du es falsch machst, und das ist eine große Sache. Hier ist der Grund dafür.

Verstecken wird als schädlich angesehen

Wenn du die ganze Zeit alleine arbeitest, erhöhstdu das Risiko des Scheiterns und betrügst dein Wachstumspotenzial.

Zunächst einmal: Wie kannst du überhaupt wissen, ob du auf dem richtigen Weg bist?

Stell dir vor, du bist ein begeisterter Fahrraddesigner und hast eines Tages eine brillante Idee für eine völlig neue Art der Gangschaltung. Du bestellst die Teile und vergräbst dich wochenlang in deiner Garage, um einen Prototyp zu bauen. Als dein Nachbar - ebenfalls ein Fahrradfan - dich fragt, was los ist, beschließt du, nicht darüber zu reden. Du willst nicht, dass jemand von deinem Projekt erfährt, bevor es nicht absolut perfekt ist. Es vergehen wieder ein paar Monate und du hast Probleme, deinen Prototyp richtig zum Laufen zu bringen. Aber da du im Geheimen arbeitest, ist es unmöglich, deine mechanisch begabten Freunde um Rat zu fragen.

Eines Tages holt dein Nachbar sein Fahrrad aus der Garage, das einen radikal neuen Schaltmechanismus hat. Es stellt sich heraus, dass er etwas ganz Ähnliches wie deine Erfindung gebaut hat, allerdings mit der Hilfe einiger Freunde aus dem Fahrradladen. An diesem Punkt bist du verzweifelt. Du zeigst ihm deine Arbeit. Er weist dich darauf hin, dass dein Entwurf ein paar einfache Fehler hat, die du in der ersten Woche hättest beheben können, wenn du es ihm gezeigt hättest.

Hier gibt es eine Reihe von Lektionen zu lernen. Wenn du deine großartige Idee vor der Welt verbirgst und dich weigerst, jemandem etwas zu zeigen, bis die Umsetzung ausgefeilt ist, gehst du ein großes Risiko ein. Es ist leicht, schon früh grundlegende Designfehler zu machen. Du riskierst, das Rad neu zu erfinden.¹ Und du verlierst auch die Vorteile der Zusammenarbeit: Hast du bemerkt, wie viel schneller dein Nachbar war, wenn er mit anderen zusammengearbeitet hat? Das ist der Grund, warum die Leute ihre Zehen ins Wasser tauchen, bevor sie ins kalte Wasser springen: Du musst sicher sein, dass du an der richtigen Sache arbeitest, dass du es richtig machst und dass es nicht schon vorher gemacht wurde. Die Wahrscheinlichkeit eines frühen Fehltritts ist hoch. Je mehr Feedback du frühzeitig einholst, desto geringer ist dieses Risiko.² Erinnere dich an das bewährte Mantra "Früh scheitern, schnell scheitern, oft scheitern" - auf die Bedeutung des Scheiterns gehen wir später in diesem Buch noch ausführlich ein.

Beim frühen Austausch geht es nicht nur darum, persönliche Fehltritte zu vermeiden und deine Ideen zu überprüfen. Es ist auch wichtig, das zu stärken, was wir den Bus-Faktor deines Projekts nennen.

Busfaktor (Substantiv): die Anzahl der Menschen, die von einem Bus überfahren werden müssen, bevor dein Projekt komplett zum Scheitern verurteilt ist.

Wie weit ist das Wissen und Know-how in deinem Projekt verteilt? Wenn du die einzige Person bist, die weiß, wie der Prototyp-Code funktioniert, ist das zwar eine schöne Jobsicherheit, aber es bedeutet auch, dass das Projekt im Eimer ist, wenn du vom Bus überfahren wirst. Wenn du mit einem Freund oder einer Freundin zusammenarbeitest, ist der Busfaktor doppelt so hoch. Und wenn du ein kleines Team hast, das gemeinsam entwirft und Prototypen herstellt, ist es sogar noch besser: Das Projekt ist nicht vorbei, wenn ein Teammitglied verschwindet. Erinnere dich: Teammitglieder werden vielleicht nicht buchstäblich von Bussen überfahren, aber andere unvorhersehbare Lebensereignisse passieren trotzdem. Es kann sein, dass jemand heiratet, wegzieht, das Unternehmen verlässt oder sich um einen kranken Verwandten kümmern muss. Du musst den Erfolg deines Projekts für die Zukunft absichern, indem du den Bus-Faktor in den Griff bekommst.

Abgesehen vom Busfaktor geht es auch um das allgemeine Tempo des Fortschritts. Man vergisst leicht, dass die Arbeit allein oft ein hartes Stück Arbeit ist, viel langsamer, als die Leute zugeben wollen. Wie viel lernst du, wenn du alleine arbeitest? Wie schnell kommst du voran? Das Internet ist ein großartiger Abladeplatz für Meinungen und Informationen, aber es ist kein Ersatz für echte menschliche Erfahrungen. Die Zusammenarbeit mit anderen Menschen erhöht direkt die kollektive Weisheit, die hinter den Bemühungen steht. Wenn du bei etwas Absurdem nicht weiterkommst, wie viel Zeit verschwendest du dann, um dich selbst aus dem Loch zu ziehen? Stell dir vor, wie anders die Erfahrung wäre, wenn du ein paar Gleichgesinnte hättest, die dir über die Schulter schauen und dir sofort sagen, was du falsch gemacht hast und wie du das Problem umgehen kannst. Das ist genau der Grund, warum Teams in Unternehmen der Softwareentwicklung zusammensitzen (oder im Pair Programming arbeiten): Du brauchst oft ein zweites Paar Augen.

Hier ist eine weitere Analogie. Überlege mal, wie du mit deinem Compiler arbeitest. Wenn du dich hinsetzt, um eine große Software zu schreiben, verbringst du dann tagelang damit, 10.000 Zeilen Code zu schreiben, und drückst dann, wenn du denkst, dass alles fertig und perfekt ist, zum ersten Mal auf den "Compile"-Knopf? Natürlich tust du das nicht. Kannst du dir vorstellen, was für eine Katastrophe daraus entstehen würde? Als Programmierer arbeiten wir am besten inengen Feedbackschleifen. Schreibe eine neue Funktion, kompiliere. Füge einen Test hinzu, kompiliere. Refaktoriere etwas Code, kompiliere. Wir beheben Tippfehler und Bugs so schnell wie möglich, nachdem wir den Code erzeugt haben. Wir möchten, dass der Compiler bei jedem kleinen Schritt an unserer Seite ist und uns unterstützt. Manche Umgebungen können unseren Code sogar kompilieren , während wir tippen. So halten wir die Qualität des Codes hoch und stellen sicher, dass sich unsere Software Stück für Stück korrekt weiterentwickelt.

Die gleiche Art von schneller Rückkopplung ist nicht nur auf der Code-Ebene, sondern auch auf der Ebene des gesamten Projekts erforderlich. Ehrgeizige Projekte entwickeln sich schnell und müssen sich im Laufe der Zeit an veränderte Rahmenbedingungen anpassen. Projekte stoßen auf unvorhersehbare Hindernisse bei der Gestaltung oder auf politische Gefahren, oder wir stellen einfach fest, dass die Dinge nicht wie geplant funktionieren. Die Anforderungen ändern sich unerwartet. Wie bekommst du diese Feedbackschleife, damit du sofort weißt, wenn deine Pläne oder Entwürfe geändert werden müssen? Antwort: Indem du im Team arbeitest. Eric Raymond wird oft mit dem Spruch zitiert: "Viele Augen machen alle Fehler flach", aber eine bessere Version könnte lauten: "Viele Augen sorgen dafür, dass dein Projekt relevant und auf dem richtigen Weg bleibt". Menschen, die in Höhlen arbeiten, wachen auf und stellen fest, dass ihre ursprüngliche Vision zwar vollständig ist, die Welt sich aber verändert hat und das Produkt irrelevant geworden ist.

Ingenieure und Büros

Vor zwanzig Jahren war die gängige Meinung, dass ein Ingenieur nur dann produktiv sein kann, wenn er sein eigenes Büro mit einer geschlossenen Tür hat. Nur so konnte sie sich in großen, ununterbrochenen Zeitabschnitten ganz auf das Schreiben von Code konzentrieren.

Wir denken, dass es für die meisten Ingenieure nicht nur unnötig ist³ nicht nur unnötig, sondern auch gefährlich ist. Software wird heute von Teams geschrieben, nicht von Einzelpersonen, und eine schnell verfügbare Verbindung zum Rest deines Teams ist sogar noch wertvoller als deine Internetverbindung. Du kannst alle Zeit der Welt haben, aber wenn du sie für die falsche Sache verwendest, verschwendest du deine Zeit.

Leider hat es den Anschein, dass moderne Tech-Unternehmen das Pendel genau in das andere Extrem ausschlagen lassen. Wenn du in ihre Büros gehst, findest du oft Ingenieure in riesigen Räumen - 50oder 100 Personen zusammen - ohne jegliche Wände. Dieser "offene Grundriss" ist heute ein viel diskutiertes Thema. Jede noch so kleine Unterhaltung wird öffentlich, und die Leute reden nicht mehr, weil sie ihre Nachbarn verärgern könnten. Das ist genau so schlimm wie private Büros!

Wir denken, dass der Mittelweg wirklich die beste Lösung ist. Setze Teams von 6 bis 12 Personen in kleinen Räumen (oder großen Büros) zusammen, damit es einfach (und nicht peinlich) wird, spontane Gespräche zu führen.

Deshalb haben die meisten Teams, die wir kennen, eine Methode entwickelt, um mitzuteilen, dass sie gerade beschäftigt sind und dass man sie nur selten unterbrechen sollte. Wir haben früher in einem Team gearbeitet, in dem es ein stimmliches Unterbrechungsprotokoll gab: Wenn du reden wolltest, sagtest du "Haltepunkt Mary", wobei Mary der Name der Person war, mit der du reden wolltest. Wenn Mary an einem Punkt war, an dem sie aufhören konnte, drehte sie ihren Stuhl um und hörte zu. Wenn Mary zu beschäftigt war, sagte sie einfach "ack" und du konntest mit anderen Dingen weitermachen, bis sie mit ihrem aktuellen Kopfzustand fertig war.

Andere Teams verteilen Kopfhörer mit Geräuschunterdrückung an die Ingenieure, um ihnen den Umgang mit Hintergrundgeräuschen zu erleichtern - in vielen Unternehmen ist das Tragen von Kopfhörern sogar ein gängiges Signal, das bedeutet: "Störe mich nicht, es sei denn, es ist wirklich wichtig. Wieder andere Teams haben Token oder Stofftiere, die die Teammitglieder auf ihren Monitor legen, um zu signalisieren, dass sie nur im Notfall unterbrochen werden dürfen.

Versteh uns nicht falsch - wir sind immer noch der Meinung, dass Ingenieure ungestörte Zeit brauchen, um sich auf das Schreiben von Code zu konzentrieren, aber wir glauben, dass sie genauso eine reibungslose Verbindung zu ihrem Team mit hoher Bandbreite brauchen. Das richtige Gleichgewicht zu finden, ist eine Kunst.

Es läuft also darauf hinaus: Allein zu arbeiten ist von Natur aus riskanter als mit anderen zusammenzuarbeiten. Du hast vielleicht Angst davor, dass jemand deine Idee klaut oder dich für dumm hält, aber du solltest viel mehr Angst davor haben, einen großen Teil deiner Zeit mit der falschen Sache zu verschwenden.

Leider ist dieses Problem des "Sich-an-die-Brust-klammerns" nicht nur in der Softwareentwicklung anzutreffen, sondern zieht sich durch alle Bereiche. In der Wissenschaft zum Beispielsollte es um den freien und offenen Austausch von Informationen gehen. Aber die verzweifelte Notwendigkeit, "zu veröffentlichen oder unterzugehen" und sich um Fördermittel zu bewerben, hat genau das Gegenteil bewirkt. Große Denker teilen ihre Ideen nicht. Sie halten wie besessen an ihnen fest, forschen im Verborgenen, verheimlichen alle Fehler auf ihrem Weg und veröffentlichen schließlich eine Arbeit, die so klingt, als sei der ganze Prozess mühelos und selbstverständlich gewesen. Und die Ergebnisse sind oft katastrophal: Sie haben versehentlich die Arbeit eines anderen kopiert, oder sie haben früh einen unentdeckten Fehler gemacht, oder sie haben etwas produziert, das einmal interessant war, aber jetzt als nutzlos angesehen wird. Die Menge an verschwendeter Zeit und Mühe ist tragisch.

Werde nicht zu einer weiteren Statistik.

Es geht um das Team

Also lass uns jetzt zurückgehen und all diese Ideen zusammenfügen.

Wir haben darauf hingewiesen, dass Einzelkämpfer im Bereich der Programmierung extrem selten sind - und selbst wenn es sie gibt, vollbringen sie keine übermenschlichen Leistungen im luftleeren Raum; ihre weltverändernde Leistung ist fast immer das Ergebnis eines Funken der Inspiration, gefolgt von einer heroischen Teamleistung.

Das eigentliche Ziel ist es, ein Superstar-Team zu bilden, und das ist teuflisch schwierig. Die besten Teams setzen ihre Superstars hervorragend ein, aber das Ganze ist immer größer als die Summe seiner Teile.

Lasst uns diese Idee in einfachere Worte fassen:

Softwareentwicklung ist ein Teamsport.

Das mag zunächst ein schwieriges Konzept sein, denn es widerspricht direkt unserer inneren Genie-Programmierer-Fantasie. Versuche, es als Mantra zu rezitieren.

Es reicht nicht aus, genial zu sein, wenn du allein in deiner Hackerhöhle bist. Du wirst nicht die Welt verändern oder Millionen von Computernutzern begeistern, wenn du deine geheime Erfindung versteckst und vorbereitest. Du musst mit anderen Menschen zusammenarbeiten. Teile deine Vision. Teile dir die Arbeit auf. Lerne von anderen. Bilde ein brillantes Team.

Überleg mal: Wie viele weit verbreitete und erfolgreiche Softwareprodukte kannst du nennen, die wirklich von einer einzigen Person geschrieben wurden? (Manche würden vielleicht "LaTeX" sagen, aber das ist wohl kaum "weit verbreitet", es sei denn, du betrachtest die Anzahl der Menschen, die wissenschaftliche Arbeiten schreiben, als einen statistisch signifikanten Anteil aller Computernutzer!)

Wir werden dieses Konzept des Mannschaftssports im Laufe des Buches immer wieder wiederholen. Gut funktionierende Teams sind Gold wert und der wahre Schlüssel zum Erfolg. Du solltest diese Erfahrung machen, wo immer du kannst; darum geht es in diesem Buch.

Die drei Säulen

Der Punkt mit der Teamarbeit ist also geklärt. Wenn Teamarbeit der beste Weg ist, großartige Software zu entwickeln, wie kann man dann ein großartiges Team aufbauen (oder finden)?

Ganz so einfach ist es nicht. Um das Nirwana der Zusammenarbeit zu erreichen, musst du zunächst die "drei Säulen" der sozialen Kompetenz erlernen und verinnerlichen. Diese drei Prinzipien sind nicht nur dazu da, die Räder von Beziehungen zu schmieren, sondern sie sind die Grundlage für jede gesunde Interaktion und Zusammenarbeit.

Demut

Du bist nicht das Zentrum des Universums. Du bist weder allwissend noch unfehlbar. Du bist offen für Selbstverbesserung.

Respekt

Du kümmerst dich aufrichtig um die Menschen, mit denen du arbeitest. Du behandelst sie als menschliche Wesen und schätzt ihre Fähigkeiten und Leistungen.

Vertrauen

Du glaubst, dass andere kompetent sind und das Richtige tun werden, und es ist für dich in Ordnung, sie fahren zu lassen, wenn es angebracht ist.⁴

Gemeinsam bezeichnen wir diese Prinzipien als HRT. Wir sprechen das als "Herz" und nicht als "Schmerz" aus, denn es geht darum, Schmerzen zu verringernund nicht darum, Menschen zu verletzen. Tatsächlich baut unsere Hauptthese direkt auf diesen Säulen auf:

Fast jeder soziale Konflikt lässt sich letztlich auf einen Mangel an Demut, Respekt oder Vertrauen zurückführen.

Es mag zunächst unglaubwürdig klingen, aber versuch es doch mal. Denke an eine unangenehme oder unangenehme soziale Situation in deinem Leben, die du gerade erlebst. Verhält sich jeder auf der untersten Ebene angemessen bescheiden? Respektieren die Menschen einander wirklich? Gibt es gegenseitiges Vertrauen?

Wir glauben, dass diese Prinzipien so wichtig sind, dass wir sogar dieses Buch um sie herum aufgebaut haben.

Dieses Buch beginnt mit dir: Es bringt dich dazu, die HRT anzunehmen und wirklich zu verinnerlichen, was es bedeutet, die HRT in den Mittelpunkt deiner Interaktionen zu stellen. Darum geht es in diesem ersten Kapitel. Von dort aus schaffen wir immer größere Kreise des Einflusses.

In Kapitel 2 gehen wir auf die Herausforderung ein, ein Team auf der Grundlage der drei Säulen aufzubauen. Die Schaffung einer Teamkultur ist der entscheidende nächste Schritt zum Erfolg - das ist das "Dreamteam", von dem wir bereits gesprochen haben.

Dann untersuchen wir Menschen, die täglich mit deinem Team interagieren, aber vielleicht nicht Teil der Kernteamkultur sind. Das können Kollegen aus anderen Teams sein oder einfach Freiwillige, die ihre Hilfe bei deinem Projekt anbieten. Viele von ihnen missachten nicht nur die HRT, sondern können geradezu giftig sein! Das Wichtigste ist, dass du lernst, dein Team vor ihnen zu schützen. Das ultimative Ziel sollte es jedoch sein, ihnen die Zähne zu ziehen und sie in deine Kultur aufzunehmen. Das ist eine großartige Möglichkeit, ein Team zu erweitern.

Die meisten Teams arbeiten innerhalb eines größeren Unternehmens, und dieses Umfeld kann oft genauso hinderlich sein wie giftige Menschen. Zu lernen, wie man diese organisatorischen Hindernisse überwindet, kann den Unterschied zwischen der Markteinführung eines Produkts und dessen Absage ausmachen.

Schließlich denken wir auch an die Nutzer deiner Software. Manchmal vergessen wir, dass es sie gibt, aber sie sind das Lebenselixier deines Projekts. Ohne die Nutzer hat deine Software keinen Zweck. Die gleichen HRT-Prinzipien, die in deinem Team Anwendung finden, können und sollten auch auf die Art und Weise angewandt werden, wie du mit deinen Nutzern interagierst - die Vorteile sind enorm.

Lass uns für einen Moment innehalten.

Als du dieses Buch in die Hand genommen hast, dachtest du wahrscheinlich nicht, dass du dich für eine Art wöchentliche Selbsthilfegruppe anmeldest. Wir können das nachempfinden. Mit sozialen Problemen umzugehen, kann schwierig sein. Menschen sind chaotisch, unberechenbar und oft nervig im Umgang. Anstatt Energie darauf zu verwenden, soziale Situationen zu analysieren und strategische Schritte zu unternehmen, ist es verlockend, die ganze Mühe abzuschreiben. Es ist doch viel einfacher, mit einem berechenbaren Compiler abzuhängen, oder? Warum sich überhaupt mit dem sozialen Kram beschäftigen?

Hier ist ein Zitat aus einem berühmten Vortrag von Richard Hamming ( ):⁵

Indem ich mir die Mühe machte, den Sekretärinnen Witze zu erzählen und ein bisschen freundlich zu sein, bekam ich hervorragende Hilfe im Sekretariat. Einmal waren zum Beispiel aus irgendeinem idiotischen Grund alle Vervielfältigungsdienste in Murray Hill blockiert. Frag mich nicht wie, aber sie waren es. Ich wollte etwas erledigen. Meine Sekretärin rief jemanden in Holmdel an, sprang in den Firmenwagen, fuhr eine Stunde nach Murray Hill, besorgte die Vervielfältigung und kam dann zurück. Das war die Belohnung dafür, dass ich mich so oft bemüht hatte, sie aufzuheitern, ihr Witze zu erzählen und freundlich zu sein; diese kleine Extraarbeit hat sich später für mich ausgezahlt. Indem du erkennst, dass du das System benutzen musst und lernst, wie du das System dazu bringst, deine Arbeit zu erledigen, lernst du, wie du das System an deine Wünsche anpassen kannst.

Die Moral von der Geschicht' ist: Unterschätze nicht die Macht des sozialen Spiels. Es geht nicht darum, Menschen auszutricksen oder zu manipulieren; es geht darum, Beziehungen zu knüpfen, um etwas zu erreichen, und Beziehungen überdauern Projekte immer.

HRT in der Praxis

All diese Predigten über Demut, Respekt und Vertrauen klingen wie Predigtstoff. Lass uns aus den Wolken kommen und darüber nachdenken, wie wir diese Ideen im echten Leben anwenden können. Wir sind auf der Suche nach praktischen Vorschlägen und werden deshalb eine Liste mit konkreten Verhaltensweisen und Beispielen durchgehen, mit denen du beginnen kannst. Viele davon mögen auf den ersten Blick offensichtlich klingen, aber wenn du erst einmal darüber nachdenkst, wirst du feststellen, wie oft du (und deine Mitschüler/innen) sienicht befolgen.

Verliere dein Ego

OK, das ist eine etwas einfachere Art, jemandem zu sagen, dass er nichtbescheiden genug ist, um seine Haltung zu verlieren. Niemand will mit jemandem zusammenarbeiten, der sich ständig so verhält, als sei er die wichtigste Person im Raum. Selbst wenn du weißt, dass du die klügste Person in der Diskussion bist, solltest du das den anderen nicht unter die Nase reiben. Hast du zum Beispiel immer das Gefühl, dass du bei jedem Thema das erste oder letzte Wort haben musst? Hast du das Gefühl, jedes Detail in einem Vorschlag oder einer Diskussion kommentieren zu müssen? Oder kennst du jemanden, der so etwas tut?

Beachte, dass "bescheiden sein" nicht bedeutet, dass man ein absoluter Fußabtreter sein sollte: Selbstvertrauen ist nichts Schlechtes. Du solltest nur nicht als Besserwisser dastehen. Noch besser ist es, wenn du stattdessen ein "kollektives" Ego anstrebst. Anstatt dir Gedanken darüber zu machen, ob du persönlich großartig bist, solltest du versuchen, ein Gefühl der Teamleistung und des Gruppenstolzes aufzubauen. Die Apache Software Foundation zum Beispiel hat eine lange Tradition in der Bildung von Gemeinschaften rund um Softwareprojekte. Diese Gemeinschaften haben eine unglaublich starke Identität und lehnen Leute ab, die sich nur um ihre Selbstdarstellung kümmern.

Das Ego zeigt sich auf vielerlei Weise, und oft steht es deiner Produktivität im Weg und bremst dich aus. Hier ist eine weitere tolle Geschichte aus Hammings Vortrag, die diesen Punkt perfekt veranschaulicht:

John Tukey war fast immer sehr leger gekleidet. Wenn er ein wichtiges Büro betrat, dauerte es lange, bis sein Gegenüber merkte, dass er ein erstklassiger Mann ist und besser zuhören sollte. Lange Zeit musste John diese Art von Feindseligkeit überwinden. Das ist vergebliche Mühe! Ich habe nicht gesagt, dass du dich anpassen sollst; ich habe gesagt: "Der Anschein, dass du dich anpasst, bringt dich sehr weit." Wenn du dich dafür entscheidest, dein Ego auf irgendeine Art und Weise durchzusetzen: "Ich mache es auf meine Art", zahlst du während deiner gesamten beruflichen Laufbahn einen kleinen, stetigen Preis. Und das summiert sich über ein ganzes Leben hinweg zu einer enormen Menge an unnötigem Ärger. [...] Indem du erkennst, dass du das System benutzen musst und lernst, wie du das System dazu bringst, deine Arbeit zu erledigen, lernst du, das System an deine Wünsche anzupassen. Oder du kämpfst dein ganzes Leben lang unentwegt dagegen an, wie in einem kleinen, unerklärten Krieg.

Lerne, Kritik zu äußern und mit ihr umzugehen

Joe hat einen neuen Job als Programmierer angefangen. Nach seiner ersten Woche fing er an, sich mit dem Code zu beschäftigen. Weil er sich dafür interessierte, was vor sich ging, begann er, andere Teamkollegen vorsichtig nach ihren Beiträgen zu fragen. Er schickte einfache Codeüberprüfungen per E-Mail, fragte höflich nach Designannahmen oder wies auf Stellen hin, an denen die Logik verbessert werden könnte. Nach ein paar Wochen wurde er in das Büro seines Direktors gerufen. "Was ist das Problem?" fragte Joe. "Habe ich etwas falsch gemacht?" Der Direktor sah besorgt aus: "Wir haben eine Menge Beschwerden über dein Verhalten, Joe. Anscheinend warst du sehr hart zu deinen Teamkollegen und hast sie immer wieder kritisiert. Sie sind verärgert. Du musst dich etwas mäßigen." Joe war völlig verblüfft. In einer starken HRT-Kultur hätten Joes Codeüberprüfungen von seinen Kolleginnen und Kollegen begrüßt und gewürdigt werden müssen. In diesem Fall hätte Joe jedoch sensibler mit der weit verbreiteten Unsicherheit des Teams umgehen und subtilere Mittel einsetzen müssen, um Codeüberprüfungen in die Kultur einzuführen.

In einer professionellen Softwareentwicklung ist Kritik fast nie persönlich - sie gehört einfach dazu, um ein besseres Produkt zu entwickeln. Der Trick besteht darin, dass du (und dein Umfeld) den Unterschied zwischen konstruktiver Kritik an der kreativen Leistung einer Person und direkten Angriffen auf den Charakter einer Person verstehen musst. Letzteres ist nutzlos - es ist kleinlich und fast unmöglich, darauf zu reagieren. Erstere ist immer hilfreich und gibt Hinweise, wie man sich verbessern kann. Und vor allem ist sie von Respekt geprägt: Die Person, die die konstruktive Kritik äußert, sorgt sich wirklich um die andere Person und möchte, dass sie sich oder ihre Arbeit verbessert. Lerne, deine Mitschüler/innen zu respektieren und konstruktive Kritik höflich zu äußern. Wenn du jemanden wirklich respektierst, wirst du motiviert sein, taktvolle und hilfreiche Formulierungen zu wählen - eine Fähigkeit, die du dir mit viel Übung aneignest.

Auf der anderen Seite des Gesprächs musst du auch lernen, Kritik anzunehmen. Das bedeutet nicht nur, dass du bescheiden mit deinen Fähigkeiten umgehst, sondern auch, dass du darauf vertraust, dass dein Gegenüber dein Bestes im Sinn hat (und das deines Projekts!) und dich nicht für einen Idioten hält. Programmieren ist eine Fähigkeit wie jede andere auch. Sie wird durch Übung besser. Wenn ein Kollege dich darauf hinweist, wie du dein Jonglieren verbessern könntest, würdest du das als Angriff auf deinen Charakter und deinen Wert als Mensch verstehen? Wir hoffen nicht. Genausowenig sollte dein Selbstwert von dem Code abhängen, den du schreibst - oder von einem kreativen Projekt, das du entwickelst. Um uns zu wiederholen: Du bist nicht dein Code. Sag das immer wieder. Du bist nicht das, was du machst. Das musst du nicht nur selbst glauben, sondern auch deine Kolleginnen und Kollegen überzeugen.

Wenn du zum Beispiel einen unsicheren Mitarbeiter hast, solltest du Folgendes nichtsagen: "Mann, du hast den Kontrollfluss bei dieser Methode völlig falsch verstanden. Du solltest das Standardmuster xyzzy verwenden, wie alle anderen auch." Dieses Feedback ist voller Gegenmuster: Du sagst jemandem, dass er "falsch" liegt (als ob die Welt schwarz und weiß wäre!), verlangst, dass er etwas ändert, und wirfst ihm vor, dass er etwas entwickelt hat, das gegen das verstößt, was alle anderen tun (wodurch er sich dumm fühlt). Die Reaktion von jemandem, der in die Defensive gedrängt wird, wird übermäßig emotional ausfallen.

Ein besserer Weg, das Gleiche zu sagen, wäre: "Hey, ich bin verwirrt vom Kontrollfluss in diesem Abschnitt hier. Ich frage mich, ob das xyzzy-Code-Muster das Ganze nicht klarer und einfacher zu pflegen machen könnte?" Beachte, dass du mit deiner Bescheidenheit die Frage auf dich und nicht auf ihn beziehst. Er hat nicht Unrecht, du hast nur Probleme, den Code zu verstehen. Der Vorschlag ist lediglich eine Möglichkeit, die Dinge für dich zu klären und möglicherweise die langfristigen Ziele des Projekts zu unterstützen. Du verlangst auch nichts - du gibst deinem Mitarbeiter die Möglichkeit, den Vorschlag friedlich abzulehnen. Die Diskussion bleibt im Bereich des Codes selbst und dreht sich nicht um den Wert oder die Programmierfähigkeiten von jemandem.

Schnell fehlschlagen und iterieren

Es gibt eine bekannte (und klischeehafte) urbane Legende in der Geschäftswelt über einen Manager, der einen Fehler macht und beeindruckende 10 Millionen Dollar verliert. Am nächsten Tag geht er niedergeschlagen ins Büro und fängt an, seinen Schreibtisch zusammenzupacken. Als er dann den unvermeidlichen Anruf erhält, dass der Vorstandsvorsitzende dich in seinem Büro sehen möchte, stapft er in das Büro des Vorstandsvorsitzenden und schiebt ihm leise ein Stück Papier über den Schreibtisch.

"Was ist das?", fragt der Geschäftsführer.

"Mein Rücktritt", sagt der Geschäftsführer. "Ich nehme an, Sie haben mich hierher gerufen, um mich zu feuern."

"Dichfeuern?", antwortet der Geschäftsführer ungläubig. "Warum sollte ich dich feuern? Ich habe gerade 10 Millionen Dollar für deineAusbildung ausgegeben!"⁶

Das ist natürlich eine extreme Geschichte, aber der Geschäftsführer in dieser Geschichte weiß, dass die Entlassung des Geschäftsführers den Verlust von 10 Millionen Dollar nicht ungeschehen machen würde und dass der Verlust einer wertvollen Führungskraft, die diesen Fehler mit Sicherheit nicht noch einmal machen wird, den Schaden noch vergrößern würde.

Eines unserer Lieblingsmottos bei Google lautet: "Scheitern ist eine Option". Es ist allgemein anerkannt, dass man nicht innovativ genug ist oder nicht genug Risiken eingeht, wenn man nicht hin und wieder fehlschlägt. Scheitern wird als goldene Gelegenheit gesehen, um zu lernen und sich für den nächsten Anlauf zu verbessern. Thomas Edison wird oft mit den Worten zitiert: "Wenn ich 10.000 Möglichkeiten finde, wie etwas nicht funktioniert, bin ich nicht gescheitert. Ich lasse mich nicht entmutigen, denn jeder verworfene Fehlversuch ist ein weiterer Schritt nach vorn."

Bei Google X - der Abteilung , die an "Mondlandungen" wie Google Glass und selbstfahrenden Autos arbeitet - ist das Scheitern bewusst in das Anreizsystem eingebaut. Die Leute kommen mit verrückten Ideen und die Kollegen werden aktiv dazu ermutigt, sie so schnell wie möglich zu verwerfen. Einzelne werden belohnt (und treten sogar gegeneinander an!), um zu sehen, wie viele Ideen sie in einem bestimmten Zeitraum widerlegen oder entkräften können. Nur wenn ein Konzept wirklich nicht von allen Kollegen am Whiteboard entkräftet werden kann , wird es zu einem frühen Prototyp weiterentwickelt.

Der Schlüssel, um aus deinen Fehlern zu lernen, ist die Dokumentation deiner Misserfolge. Schreibe "Postmortems", wie sie in unserer Branche oft genannt werden. Achte besonders darauf, dass das Postmortem-Dokument nicht nur eine nutzlose Liste von Entschuldigungen oder Ausreden ist - das ist nicht sein Zweck. Ein ordentliches Postmortem sollte immer eine Erklärung darüber enthalten , was gelernt wurde und was sich aufgrund der Lernerfahrung ändern wird. Stelle sicher, dass du den Bericht an einem leicht zu findenden Ort aufbewahrst und die vorgeschlagenen Änderungen auch wirklich umsetzt. Denke daran, dass es für andere (gegenwärtige und zukünftige) Personen einfacher ist, zu wissen, was passiert ist, und zu vermeiden, dass sich die Geschichte wiederholt. Verwische deine Spuren nicht - beleuchte sie wie eine Startbahn für diejenigen, die dir folgen!

Eine gute Autopsie sollte Folgendes beinhalten:

• Eine kurze Zusammenfassung

• Eine Zeitleiste des Ereignisses, von der Entdeckung über die Untersuchung bis zur Lösung

• Die Hauptursache des Ereignisses

• Bewertung der Auswirkungen und Schäden

• Eine Reihe von Maßnahmen, um das Problem sofort zu beheben

• Eine Reihe von Maßnahmen, um zu verhindern, dass sich das Ereignis wiederholt

• Gelernte Lektionen

Zeit zum Lernen lassen

Cindy war ein Superstar - eine Softwareentwicklerin, die ihr Fachgebiet wirklich beherrschte. Sie wurde zur technischen Leiterin befördert, bekam mehr Verantwortung und nahm die Herausforderung an. Es dauerte nicht lange, bis sie alle um sich herum anleitete und ihnen die Grundlagen beibrachte. Sie hielt Vorträge auf Konferenzen zu ihrem Thema und leitete bald mehrere Teams. Sie liebte es, die ganze Zeit die "Expertin" zu sein. Und doch begann sie, sich zu langweilen. Irgendwann hörte sie auf, neue Dinge zu lernen. Der Reiz, die klügste und erfahrenste Expertin im Raum zu sein, wurde immer geringer. Trotz aller äußeren Anzeichen von Beherrschung und Erfolg fehlte ihr etwas. Eines Tages machte sie sich an die Arbeit und stellte fest, dass ihr Fachgebiet einfach nicht mehr so relevant war; die Leute hatten sich anderen Themen zugewandt. Was hatte sie falsch gemacht?

Seien wir ehrlich: Es macht Spaß, die wissendste Person im Raum zu sein, und andere zu betreuen kann unglaublich lohnend sein. Das Problem ist, dass du aufhörst zu lernen, sobald du in deinem Team ein lokales Maximum erreicht hast. Und wenn du aufhörst zu lernen, wirst du langweilig. Oder du wirst versehentlich überflüssig. Es ist sehr einfach, süchtig danach zu werden, ein führender Spieler zu sein; aber nur wenn du dein Ego aufgibst, wirst du jemals die Richtung ändern und dich neuen Dingen aussetzen können. Auch hier geht es darum, die Demut zu erhöhen und bereit zu sein, sowohl zu lernen als auch zu lehren. Verlasse ab und zu deine Komfortzone; suche dir ein Fischglas mit größeren Fischen als du und nimm die Herausforderungen an, die sie dir stellen. Auf lange Sicht wirst du viel glücklicher sein.

Geduld lernen

Vor Jahren schrieb Fitz ein Tool, mit dem er CVS-Repositorys in Subversion (und später in Git) konvertieren konnte, und stieß dabei aufgrund der Unwägbarkeiten von CVS immer wieder auf bizarre Fehler. Da sein langjähriger Freund und Kollege Karl CVS sehr gut kannte, beschlossen er und Karl, dass sie zusammenarbeiten sollten, um diese Fehler zu beheben.

Ein Problem trat auf, als sie mit der Paarprogrammierung begannen: Fitz war ein "Bottom-up"-Ingenieur, der sich damit begnügte, in den Dreck einzutauchen und sich herauszuwühlen, indem er viele Dinge schnell ausprobierte und die Details überflog. Karl hingegen war ein Top-Down-Ingenieur, der sich alles genau ansehen und in die Implementierung fast jeder Methode auf dem Aufrufstapel eintauchen wollte, bevor er den Fehler in Angriff nahm. Das führte zu einigen epischen zwischenmenschlichen Konflikten, Meinungsverschiedenheiten und gelegentlichem heftigen Streit. Es ging so weit, dass die beiden nicht mehr gemeinsam programmieren konnten: Es war für beide zu frustrierend.

Allerdings hatten die beiden eine lange Geschichte des Vertrauens und des Respekts füreinander. In Kombination mit ihrer Geduld half ihnen das, eine neue Methode der Zusammenarbeit zu entwickeln. Sie setzten sich gemeinsam an den Computer, identifizierten den Fehler, teilten sich auf und gingen das Problem aus zwei Richtungen gleichzeitig an (von oben nach unten und von unten nach oben), um dann wieder zusammenzukommen und ihre Ergebnisse in der Mitte zu präsentieren. Ihre Geduld und ihre Bereitschaft, neue Arbeitsweisen zu improvisieren, retteten nicht nur das Projekt, sondern auch die Freundschaft.

Sei offen für Einflussnahme

Je offener du bist, desto mehr kannst du beeinflussen; je verletzlicher du bist, desto stärker wirkst du. Diese Aussagen klingen wie bizarre Widersprüche. Aber jeder kennt jemanden, mit dem er zusammengearbeitet hat, der einfach wahnsinnig stur ist. Egal, wie sehr man versucht, ihn zu überzeugen, er verbeißt sich noch mehr in die Sache. Was passiert dann mit solchen Teammitgliedern? Unserer Erfahrung nach werden sie am Ende einfach "umfahren" wie ein Hindernis, das alle für selbstverständlich halten. Ihre Meinung und ihre Einwände werden nicht mehr beachtet. Das willst du auf keinen Fall, also denk immer daran: Es ist in Ordnung, wenn jemand anderes deine Meinung ändert. Wähle deine Kämpfe sorgfältig aus. Erinnere dich daran, dass du anderen zuerst zuhören musst, wenn du richtig gehört werden willst. Wenn es darum geht, sich beeinflussen zu lassen, sollte dieses Zuhören stattfinden, bevor du einen Pflock in den Boden steckst oder dich fest für etwas entschieden hast - wenn du deine Meinung ständig änderst, halten dich die Leute für einen Wischiwaschi.

Was die Verletzlichkeit angeht, so erscheint auch das zunächst etwas seltsam. Wenn jemand zugibt, dass er von einem Thema keine Ahnung hat oder nicht weiß, wie man ein Problem löst, wie glaubwürdig ist er dann in einer Gruppe? Verwundbarkeit ist ein Zeichen von Schwäche, und das zerstört Vertrauen, oder?

Das stimmt nicht. Wenn du zugibst, dass du einen Fehler gemacht hast oder einfach nicht in deiner Liga spielst, steigert das deinen Status auf lange Sicht. Es ist ein Zeichen vonDemut, es geht um Verantwortlichkeit und Übernahme von Verantwortung, es ist ein Signal, dass du der Meinung anderer vertraust, und im Gegenzug respektieren die Leute deine Ehrlichkeit und Stärke. Manchmal ist es das Beste, wenn du einfach sagst: "Ich weiß es nicht".

Berufspolitikerinnen und -politiker sind dafür berüchtigt, dass sie niemals Fehler oder Unwissenheit zugeben, selbst wenn es offensichtlich ist, dass sie bei einem Thema falsch oder unwissend sind. Aus diesem Grund glauben die meisten Menschen Politikern kein einziges Wort. Dieses Verhalten kommt vor allem daher, dass Politiker/innen ständig von ihren Gegnern angegriffen werden. Wenn du Software schreibst, ist es jedoch unnötig, sich ständig zu verteidigen - deine Teamkollegen sind Mitarbeiter und keine Konkurrenten.

Nächste Schritte

Wenn du es bis hierher geschafft hast, bist du auf dem besten Weg, die Kunst des "guten Zusammenspiels mit anderen" zu beherrschen. Du musst damit beginnen, dein eigenes Verhalten zu untersuchen und zu reflektieren. Sobald du diese Strategien in dein tägliches Leben integriert hast, wirst du feststellen, dass die Zusammenarbeit viel selbstverständlicher wird und deine Produktivität in der Technik spürbar steigt.

Die wichtigen Veränderungen beginnen bei dir und breiten sich dann auf andere aus. Im nächsten Kapitel werden wir darüber sprechen, wie du eine HRT-Kultur in deinem unmittelbaren Team schaffen kannst.

¹ Buchstäblich, wenn du tatsächlich ein Fahrraddesigner bist.

² Wir sollten anmerken, dass es manchmal gefährlich ist, zu früh im Prozess zu viel Feedback zu bekommen, aber das werden wir in einem späteren Kapitel behandeln.

³ Wir erkennen jedoch an, dass ernsthaft Introvertierte wahrscheinlich mehr Ruhe, Stille und Zeit für sich selbst brauchen als die meisten Menschen und von einer ruhigeren Umgebung profitieren können, wenn nicht sogar von einem eigenen Büro.

⁴ Das ist unglaublich schwierig, wenn du dich in der Vergangenheit daran verbrannt hast, dass du an inkompetente Leute delegiert hast.

⁵ "Du und deine Forschung ", http://bit.ly/hamming_paper

⁶ Im Internet finden sich ein Dutzend Varianten dieser Legende, die verschiedenen berühmten Managern zugeschrieben werden.