Während meiner Masterarbeit habe ich Lightbulb Learning entwickelt, ein SaaS Tool für die Bewertung von Lernfortschritten. Dieses Produkt war der Versuch, ein echtes Produkt, mit Mehrwert, Geschäftsmodell und Kunden, zu erschaffen, gleichzeitig aber auch Gegenstand meiner Thesis. Zwei Fliegen mit einer Klappe, dachte ich. Dabei habe ich eine wichtige Lektion gelernt:
Es geht um die Rechtfertigung von Leistung, entweder durch eine Autorität, oder durch die Realität. Mit Rechtfertigung von Leistung ist die Erklärung Außenstehenden gegenüber gemeint, warum Leistung zielführend ist. Dieses Problem tritt bei vielen kognitiv-zentrierten Arbeiten auf: Woher wissen andere, dass das, was ich gerade tue/denke/schreibe/programmiere tatsächlich einen Mehrwert liefert, und dadurch den Aufwand rechtfertigt? Dafür gibt zwei grundlegend unterschiedliche Ansätze:
1. Rechtfertigung durch Autorität (RDA)
Wenn ich einem Experten durch Argumente oder Demonstrationen glaubhaft machen kann, dass das, was ich tue, zielführend ist, so kann meine Leistung durch die Autorität des Experten Außenstehenden gegenüber gerechtfertigt werden. Um beim Beispiel meiner Thesis zu bleiben: Wenn ich es schaffe, meinem Professor meine Tätigkeit als sinnvolle Arbeit im Sinne der definierten wissenschaftlichen Ansprüche glaubhaft zu machen, so erhalte ich dafür eine gute Note. Die Note sagt dann potentiellen Arbeitgebern: Robert hat zielführende Arbeit geleistet (und könnte es wieder tun).
2. Rechtfertigung durch Realität (RDR)
Wenn meine Leistung tatsächlich die unmittelbaren Effekte in der Realität hervorruft, welche die ursprüngliche Intention der Leistung waren, so kann man von Rechtfertigung durch die Realtität sprechen. Auch hier ein Beispiel: Hätten erst einzelne, dann dutzende und schließlich hunderte Menschen Lightbulb Learning verwendet, um eine pädagogisch sinnvolle Alternative zu traditionellen Klausuren zu haben, dann würde das eine sehr klare Sprache sprechen: Die Idee funktioniert. Dadurch habe ich zwar noch nicht meinen Professor überzeugt, aber ein funktionierendes Produkt, auf welchem ich ein Geschäftsmodell aufbauen kann.
Jetzt der eigentliche Punkt: Ich behaupte, dass die beiden Rechtfertigungsarten im Bezug auf die Vorgehensweise einander widersprüchliche Verhalten belohnen. Jede Art von Entwicklung lebt von Feedback. Man präferiert sehr frühes, ehrliches und auch hartes Feedback, wenn man tatsächlichen Mehrwert schaffen will (RDR). Das Feedback kann dabei aus funktionierenden und öffentlich verfügbaren Teile der Leistung entstehen, welche der Zielgruppe angeboten werden, wie beispielsweise ein Minimum Viable Product. So werden Denkfehler, Relevanz und Benutzbarkeit direkt offengelegt und man kann Kurskorrekturen vornehmen oder alles abbrechen.
Will man hingegen Autoritäten überzeugen, so würde man eher viel Zeit bis zum nächsten Feedback bevorzugen, um mehr Fortschritte machen zu können, diese auf in polierten Präsentationen zum Besten geben zu können, und dadurch eine höhere Evaluation zu erlangen. Ob alles was man sagt genauso stimmt, ist dabei weniger wichtig, als ob alles stimmig wirkt. So ist es einem Elektrofahrzeughersteller mal gelungen, zeitweise eine höhere Evaluation als Ford zu haben, ohne je ein einziges dieser Gefährte regulär verkauft zu haben.
Der Feedbackzyklus unterscheidet sich nicht nur in der Ehrlichkeit und Iterationsdauer, sondern auch in der Qualität: Während die Realität einfach die Realität ist, mit all ihren Entscheidern, Kontexten, (un)sichtbaren Zusammenhängen, Details und (fehlenden) Informationskanälen, so ist die Meinung einer oder weniger Experten sehr, sehr viel einseitiger und anfälliger für persönliche Präferenzen, unterbewusste Biase und starke Vereinfachugnen. Ich habe über 5 Jahre studiert und eben so lange in Softwareprojekten gearbeitet: Erfahrungsgemäß verschwimmt im Verkaufen eines Inkrements die Vergangenheit mit der Zukunft: Innovationen, die noch garnicht skalierbar sind, werden als Fundamente für Entscheidungen akzeptiert. Dies ist in einer Welt der RDR völlig ausgeschlossen: was noch nicht funktioniert, funktioniert überhaupt nicht, egal, ob es voraussichtlich bald funktionieren wird. Auch strategische Entscheidungen werden in der Welt der RDA argumentativ ausgefochten, während in der Welt der RDR Daten, beispielsweise aus A/B Testing, herangezogen werden können.
Die beiden Strömungen sind sicherlich auch an einigen Stellen gut miteinander vereinbar, ich will in diesem Artikel eher auf die Widersprüche hinaus, die sich ergeben, wenn man wie ich versucht, beides gleichzeitig zu erfüllen. Auch hat beides seinen Platz: In der Projektentwicklung oder der akademischen Welt wird man eher auf die Rechtfertigung durch Autorität stoßen, während man in der Produktentwicklung eher durch die Realität gerechtfertigt werden möchte. Mein Appell, vor allem an mich selber: Man sollte sich des Kontexts, der Art der Rechtfertigung, und der Widersprüchlichkeit dieser beiden Strukturen und ihrer jeweiligen Einflüsse auf die Feedbackzyklen, bewusst sein, und es vermeiden, zu versuchen, beide Fliegen mit einer Klappe zu schlagen.
PS: Meine Masterarbeit erhielt die Note 1.0, fand als Produkt jedoch kaum Adaption, und entspricht damit einer Rechtfertigung durch Autorität, aber nicht durch die Realität.