Fehler und Expertentum und technische Narrative

Bislang gibt es nur wenige organisations-ethnologische oder soziologische Untersuchungen, die sich mit der Bedeutung von Pannen in derartigen fehleranfälligen und interdependenten technischen Systemen beschäftigen. Zu nennen sind vor allem Orrs (1996) Untersuchung über Wartungstechniker von Kopiermaschinen und Potthasts (2001) Beschreibung der Arbeitspraxis von Wartungstechnikern für die Koffertransport-Anlage am Flughafen Paris-Roissy.¹⁰⁵ Ein besonders folgenschweres Beispiel des Umgangs mit technischen Eigenschaften, die von der gewünschten Norm abweichen – also mit Fehlern, liefert Vaughan (1996) in ihrer historischen Ethnografie des Challenger-Desasters. Nach ihrer Argumentation führten etablierte Mechanismen der Mediation von problematischen Situationen (insbesondere Abweichungen von Shuttle-Eigenschaften im Tests), über einen jahrelangen Prozess hinweg zur kulturellen Normalisierung eines im Nachhinein nicht zu normalisierenden Fehlers in einem Dichtungsring des Shuttles – welcher letztendlich die Explosion der Challenger verursachte.

Alle genannten Arbeiten zeigen auf, dass vor dem Hintergrund einer Realität, in der der drohende Fehler das Schlimmstmögliche und zugleich allgegenwärtig ist, kollektive Identität zu einer Kategorie der Arbeitspraxis wird¹⁰⁶: Ob jemand dazugehört, ist daraus zu ersehen, ob er im richtigen Moment – im Moment der Krise und des Fehlers – das Richtige tut. Dieses Richtige ist dabei weniger eine technisch eindeutige Entscheidung (denn die kann es ja gar nicht geben), sondern eine interpretative Deutung samt einer Performanz, für die ein kollektives Handlungsrepertoire bereits vorhanden sein muss. Der dazu notwendige Habitus der Expertise muss einander immer wieder neu versichert werden.¹⁰⁷

Potthasts (2001) Wartungstechniker demonstrieren beispielsweise im Fall einer Panne durch betont sportliches Auftreten und Kultivierung körperlicher Fitness „Sportsgeist“ (wie Potthast es nennt), während sie ihre Arbeit als Team erledigen. Entscheidend ist für sie nicht primär, was sie tun, um die Panne zu beheben, sondern, wie sie es tun. Gleichzeitig (er)finden auch sie einen unwissenden Anderen, der den Fehler verursacht hat, und lehnen diesen ab, beispielsweise, weil er unsportlich ist: Nämlich die Gruppe der Informatiker, die das System programmieren, aber von seiner realen Verhaltensweise aus Sicht der Wartungstechniker keine Ahnung haben. Hier geht es also um mehr als die von Bourdieu (1976) genannten

105 Weitere Arbeiten, die sich zumindest teilweise mit dem hier diskutierten Problem beschäftigen, sind Nothnagel (2001), der kommunikative Stile in einer internationalen Wissenschaftskultur untersucht, und Bucchiarelli (1994), der sich mit dem Selbstverständnis von Design Ingenieuren befasst..

106 Zum Ansatz, Naturwissenschaft und ihre Anwendungen als Praxis zu verstehen, siehe Pickering (1992).

107 Zum Habitus-Konzept und zur Theorie der Praxis siehe Bourdieu (1976). Zum Kulturbegriff in einer Theorie der Praxis siehe LiPuma (1994).

„feinen Unterschiede“ zwischen gesellschaftlichen Schichten, sondern um die große Abgrenzung gegenüber den eigentlich Mächtigen innerhalb der organisatiorischen Hierarchie.

Denn selbstverständlich sind es die Informatiker, die den Wartungstechnikern die Anweisungen erteilen. Nach dem gleichen Muster wird bei ChipTech-OI das eigene Management als der unwissende Andere konstruiert.

Bei Orrs (1997) Kopiertechnikern gestaltet sich der Fall schwieriger. Denn diese sind bei der Behebung der Panne jeweils alleine unterwegs, daher ist ihre Wartungsarbeit für andere Techniker kaum sichtbar. Wie Orr zeigt, greifen die Mitglieder daher zu Narrativen zurück, ausgedehnten Erzählungen über die Probleme, die sie schon gelöst haben. Zeit und Ort derartiger Erzählungen ist die gemeinsame Kaffeepause, hier lernen die Jungen von den Alten, hier wird Erfahrung sichtbar und ausgetauscht, hier entstehen Erzählungen über die großen Wartungshelden früherer Zeiten und ihre tollkühnen Taten. Durch derartige geteilte Erzählungen – narrative Konstruktionen – wird laut Orr Erfahrungswissen interpersonal sichtbar gemacht und kollektive Identität reproduziert.

Auch bei ChipTech-OI bleibt die Arbeit des Einzelnen für die anderen Mitglieder der Gemeinschaft unsichtbar. Zur Überprüfung von Expertentum, von Kontextwissen und der richtigen Art zu denken, müssen daher müssen Narrative der Expertise genügen. Eine derartige narrative Interaktion findet erstens statt im problematischen Fall des Fehlers, da dieser aus Einzelkämpfern in der sicheren Tiefe ihres Themas Team-Mitglieder macht, die an den problembehafteten, unklaren Schnittstellen zwischen Themen rasche Lösungen finden müssen. Zu beobachten ist zweitens eine Form von narrativem Imponiergehabe¹⁰⁸, mittels dessen der einzelne Ingenieur den anderen vorab bereits versichern, dass er im Ernstfall, im Fall des Fehlers, richtig handeln wird. Wenn also beispielsweise ein Ingenieur einen Fehler in seinem Thema besonders gut gelöst hat, wird er hierzu nicht nur deshalb ein technisches Narrativ geben, damit die übrigen Ingenieure lernen, sondern auch deshalb, damit seine Fähigkeiten für alle deutlich sichtbar werden. Besondere Heldentaten, etwa solche, bei denen eine Person eine besonders gute Lösung gefunden hat oder einen technisch besonders anspruchsvollen bug zur Strecke gebracht hat, werden beispielsweise durch spontane Zusammenkünfte geteilt: Ein Ingenieur würde anfangen, einem Kollegen zu erklären, was es mit seiner aktuellen Aktion am Computer auf sich hat, dazu zieht der Kollege üblicherweise seinen Stuhl zu dem ersten Ingenieur hinüber, und gemeinsam sehen sie auf den Bildschirm.

Vielleicht rufen sie auch noch ein, zwei andere Mitarbeiter hinzu, „für die das Problem interessant sein könnte“. Oder sie sagen den Doktoranden und Diplomanden des Teams

108 Ähnliche Mechanismen des Imponiergehabes, allerdings in einem anderen Kontext, beschreibt Liell (2001).

Bescheid, „damit die so etwas auch mal sehen“. Sehr schnell bildet sich so spontan eine community of practice, die den einzelnen Experten bewertet und gleichzeitig Expertenwissen distribuiert. Wird es besonders interessant, beschließt man eventuell, dass der erste Ingenieur

„darüber mal einen Vortrag hält“. Dann trifft man sich mit seinen Kaffeebechern in einem Raum und diskutiert das aktuelle Problem. Es werden mathematische Formeln und Diagramme an ein Whiteboard gemalt, alles redet durcheinander. Ein technisches Narrativ folgt auf das andere, man lernt und wächst zusammen, Experten erfinden sich und einander immer wieder neu. Wie Bruner (2002: 100) sagt:

“We are, as Claude Lévi-Strauss remarks, bricoleurs [im Original hervorgehoben, A.d.V.] improvisors. We improvise in how we tell about ourselves to ourselves, improvise in the interest of keeping our investment in our balance from getting undone. And here too we have a stock of stories, old stories, to draw on for representing our imbalances to ourselves. When in doubt, we can even fall back on the old saw about being basically all right though in a bad patch. Just as our opposable forefingers and thumbs enable us to use many tools, our narrative gift gives us access to the culture’s treasury of stories.”

Aus Sicht der Beteiligten bei ChipTech-OI sind derartige Zusammenkünfte schlicht und ergreifend eine technische Notwendigkeit. Ein Ingenieur formuliert das Problem wie folgt:

„Wenn jemand an seinem Thema etwas ändert und er mit mir eine Schnittstelle hat, dann ist es für mich noch keine relevante Information zu sehen: ,Oh, da ist eine Änderung’. Ich muss mich darauf verlassen, dass er mir die Änderung erklärt, damit ich verstehen kann, was diese Änderung technisch bedeutet. Aber gerade, wenn man nicht weiß, wer der Owner eines Themas ist, ist es schwer, an Erklärungen ran zu kommen.

Man muss sich einfach kennen, die Owner einschätzen können. Und das geht nur durch Reden miteinander. Ich weiß gar nicht, wie ich das sagen soll, manchmal denke ich mir auch: ,Immer dieses Diskutieren die ganze Zeit, muss das sein?’ Aber wenn man mal vergisst, den Anderen zu sagen, was man sich denkt, dann merkt man das sofort: Dann ist man irgendwie abgekoppelt. Dann ist da keine Schnittstelle mehr.“

Persönlicher Kontakt und persönlicher Austausch sind daher entscheidende Voraussetzung, um die Arbeit eines Anderen und ihn selbst verstehen zu können. Und in der Tat sind Ausdrucksmöglichkeiten von digitalem Code, der rein technischen Ausdruckform der Arbeit Anderer, sehr begrenzt. Er lässt nur zwei Aussagen zu: 0 und 1, Ja oder Nein. Diese digitalen Aussagen müssen einschätzbar werden – das können sie aber nur durch den persönlichen Kontakt und den narrativen Austausch. Ein Ingenieur erläutert das Dilemma:

„Zum Beispiel hat jeder einen anderen Stil, Code zu schreiben. Diesen Stil muss ich kennen, nur so kann ich den Code dieser Person verstehen. Zum Beispiel, [Ingenieur A], der hat immer [so und so programmiert], der war auch so ein Typ dafür, der hat

sehr sprunghaften Code geschrieben, aber zum Beispiel [Ingenieur B], der arbeitet eher bodenständig.

Wenn ich also weiß, wer den Code geschrieben hat, mit dem ich arbeiten muss, dann kann ich eher einschätzen, welche Schwächen er hat. Und wenn ein Fehler auftritt und ich die Art zu denken der Person kenne, die den Code geschrieben hat, dann weiß ich eher, in welche Richtung ich denken muss, um den bug zu fixen.“

Code ist niemals eindeutig, es gibt stets eine Vielzahl von Möglichkeiten, ein und dasselbe Objekt symbolisch zu repräsentieren. Es gibt eleganten Code, bodenständigen Code, genialen Code – je nach Persönlichkeit und Geisteshaltung des jeweiligen Experten. Problematisch wird dies im Fall der Änderung von Code innerhalb eines Themas, das in einem interdependenten System, wie es das Product-Help-System es ist, Fehler in den Themen anderer hervorrufen kann. In diesem Fall will man und braucht man die Information hinter dem Code – durch narrativen Austausch. Auf diesen Austausch verwenden die Experten bei ChipTech-OI einen Großteil ihrer Zeit und sind daher der festen Überzeugung, dass jede Persönlichkeit ihre Daseinsberechtigung hat – so lange sie nur einen Habitus der Expertise an den Tag legt. Ansonsten aber kann ein Ingenieur sein wie er möchte, denn schließlich hat jede Art von Code ihre Vor- und Nachteile (und Code ist ja Resultat der Persönlichkeit).

Dementsprechend unerwünscht ist eine digitale Persönlichkeit, die diese Pluralität der Gruppe und inneren Freigeist nicht zulässt. Das siehst Du zu digital oder Du denkst zu digital lautet die übliche Ausdrucksweise für eine häufige Kritik an unerfahrenen Mitarbeitern. Die Empfehlung an sie lautet dann etwa: Du musst auch die Befindlichkeiten berücksichtigen oder Du musst auch die Historie berücksichtigen. Diese Kritik ist berechtigt: Denn um selbst als Experte arbeiten zu können, muss man in der Tat die individuelle Kombination aus Erfahrung, Wissen und Persönlichkeit der übrigen Experten innerhalb des interdependenten, fehleranfälligen Systems kennen. Man muss also wissen, wie der andere tickt, ein Gefühl für die Lage bekommen, verstehen, was die Aussage bedeutet – alles Ausdrücke dafür, die Art zu denken einer Person und somit deren Expertise abfragen zu wollen.