3 Lügen, die Ihr Technikteam Ihnen (und sich selbst) erzählt

Jede dieser Aussagen ist eine Lüge, die Ihr Technikteam Ihnen – und sich selbst – erzählt. Diese sehr verbreiteten Missverständnisse beruhen auf einem grundlegenden Fehler, der unter Ingenieuren endemisch ist: dem Glauben an das „Bessere“.

Besser ist nicht für jeden besser

Im Inneren eines Computers herrscht das Reich der Einsen und Nullen. Es gibt keinen Zweifel oder Unsicherheit über Arithmetik und logische Gatter, und abgesehen von dem einen oder anderen kosmischen Strahl ist die Maschine vollkommen deterministisch und folgt immer wieder demselben Ablauf, wenn Sie dieselben Eingaben machen. 

Sogar die scheinbare Zufälligkeit in Spielen oder Simulationen ist in Wirklichkeit nur eine Illusion. Wenn Sie zum Beispiel einen bestimmten „Pseudorandom Seed“ in Minecraft angeben, erhalten Sie bei jedem Spieldurchlauf exakt das gleiche Verhalten. Es ist hilfreich, sich daran zu erinnern, dass jedes Mitglied Ihres IT-Teams einen Beruf gewählt hat, in dem diese Art von Gewissheit und Vorhersehbarkeit eine Rolle spielt; es ist buchstäblich unmöglich, ihre Arbeit zu erledigen, ohne streng nach den Grundprinzipien zu denken.

Aber außerhalb der Computerwelt treffen wir auf unberechenbare Menschen – und alle Wetten sind dahin. Kein Vertriebsteam käme auf die Idee, jedem potenziellen Kunden die gleichen Folien oder dasselbe Verkaufsgespräch zu präsentieren, und jeder Anruf im Kundenservice ist anders und voller Überraschungen. Skripte und Schulungen helfen Ihrem Team zwar, für Konsistenz zu sorgen, doch ist es wesentlich, den Ansatz jeder Situation anzupassen – wie so viele Unternehmen feststellen mussten, als sie versuchten, Holokratie oder Lean-Methoden einzuführen, um den Erfolg von Zappos und Toyota nachzuahmen – und damit kläglich scheiterten.

Das gilt in der Softwareentwicklung ebenso wie in Betrieb, Finanzen oder Strategie: Es gibt keinen einzig richtigen Weg, einen Login-Bildschirm zu entwerfen, einen Bericht zu bauen oder herauszufinden, für welche Funktionen Kunden bezahlen würden. Das ist der Grund, warum Ingenieure eine schwindelerregende Vielzahl von Software-Methoden entwickelt haben – etwa Scrum, Kanban, ShapeUp, das Spotify-Modell, SAfE und Hunderte weitere – die in manchen Fällen erfolgreich sind, in anderen hingegen versagen.

Jetzt verstehen Sie, warum wir Technikbegeisterten in die Besserismus-Falle tappen. Jeder von uns würde es attraktiv finden zu glauben, dass irgendwo eine Steintafel existiert, auf die die Lösung unserer Probleme eingemeißelt ist – aber Gewissheit ist gefährlich verlockend, wenn man jeden Tag mit Werkzeugen und Maschinen arbeitet, deren Funktion zwingend auf absoluter Konsistenz beruht. Doch wie entkommt man dem binären Denken?

Stellen Sie zuerst beharrlich Fragen

Für so viele von uns ist Technik einfach schwarze Magie. Die Ingenieure murmeln seltsame Beschwörungsformeln über Kubernetes und Zettabytes – und aus dem Nichts tauchen Websites, E-Mails und Kreditkartenzahlungen auf. Wenn die Zauberer dann mit Autorität behaupten, sie würden „Best Practices“ befolgen, wer sind wir, daran zu zweifeln?

Die Antwort sind SIE! Wie alle anderen Teammitglieder brauchen Softwareentwickler Rückmeldung darüber, ob ihre Pläne und Ergebnisse auf die Unternehmensstrategie einzahlen. Sie müssen sich nicht des Tech-Jargons bedienen, um Rückmeldung und Orientierung zu geben; es ist ihre Aufgabe, genug über Ihren Markt und Ihre Ziele zu lernen, um Ihnen gegenüber mit normalem Deutsch Rechenschaft ablegen zu können. Scheuen Sie sich nicht, alle Fragen dazu zu stellen, was priorisiert wird, warum die eine oder andere Technologie gewählt wird – und ganz besonders, wie der Rest des Unternehmens davon profitieren soll. 

Ich bin so sehr davon überzeugt, dass man Fragen stellen sollte, dass ich aufwendig gestaltete Zertifikate mit Goldrand habe drucken lassen, die die offizielle Erlaubnis erteilen, Ingenieuren jede erdenkliche Frage zu stellen – und ich verteile sie, wann immer ich kann. Unten sehen Sie ein Beispiel. Wenn Sie eins bei sich an der Wand haben möchten, schicken Sie mir einfach eine E-Mail; ich sende Ihnen gerne eines zu (gratis!) 

Als Nächstes: Spielen Sie das Warum-Spiel

Wenn Sie die Angst vor dem Fragen überwunden und sich mehr über den Ansatz Ihres Technik-Teams angeeignet haben, ist es an der Zeit, das Warum-Spiel zu spielen. Die Regeln sind simpel und jedem Fünfjährigen vertraut: Sie fragen zunächst, was ein Entwickler gerade macht, und fragen anschließend immer wieder „Warum?“. 

„Ich ersetze unsere Bezahlseite.“

„Warum?“

„Weil sie ineffizient ist.“

„Warum ist sie ineffizient?“

„Wir machen überflüssige Prüfungen, die unsere Antwortzeiten verlangsamen.“

„Warum ist Geschwindigkeit wichtig?“

„Weil Nutzer abspringen, wenn sie zu lange auf die Bezahlung warten müssen.“

Das Signal zum Aufhören ist erreicht, wenn es ums Geld geht. Sobald Sie hören: „weil es die Konversionen erhöht“, „weil mehr Kunden upgraden werden“ oder „weil wir die Forschungskosten drastisch senken“, haben Sie gewonnen. Falls Sie niemals an diesen Punkt gelangen und stattdessen mit „Ich weiß es nicht“ oder „weil Jane es gesagt hat“ enden, dann haben Sie (nicht der Entwickler) das 'Warum'-Spiel verloren. Suchen Sie nach Wegen, Ihr Tech-Team deutlich enger an die Geschäftsergebnisse anzubinden, damit beim nächsten Mal alle als Gewinner hervorgehen.

Nach einigen Runden des „Warum“-Fragens werden Ihnen Muster und Lücken auffallen. Zum Beispiel habe ich mit einem Team gearbeitet, das sich ganz auf die Steigerung der Konversionsrate konzentriert und dabei die Kosten völlig ignoriert hat. Kein Wunder, dass sie mit ihren hyper-optimierten Social-Ad-Strategien weit über das Budget hinausgeschossen sind – und das alles für eine einfache Weihnachtskampagne.

Sicher, ihre ausgeklügelten Algorithmen waren „besser“, wenn es darum ging, winzige Preisvorteile bei bestimmten Keywords herauszuholen, aber die Facebook-Rechnung war ein schonungsloser Realitätscheck (einschließlich Gebühren dafür, dass manche facebook.com Ad-Server durch zu viele Anfragen tatsächlich abgestürzt sind!). Wenn Sie auf solche blinden Flecken stoßen, setzen Sie die Prioritäten neu, streichen Sie Überflüssiges und machen Sie klar, dass Technologie eng an Ihre Unternehmensziele geknüpft sein muss.

Sorgen Sie schließlich für Verantwortlichkeit

Nachdem Sie nun die „besseren“ Technologielösungen gefunden und ausgemerzt haben, die in Wahrheit keine Wirkung zeigen, geben Sie den Entwicklern einfache Möglichkeiten, Ihnen regelmäßig zu zeigen, dass sie auf Kurs bleiben. Beachten Sie, dass ich nichts von „das Tech-Team zur Verantwortung ziehen“ gesagt habe – ein Ansatz mit erhobenem Zeigefinger, der mich immer unter den nächsten Schreibtisch kriechen lässt. Stattdessen sollten Sie Ihre Entwickler in die Lage versetzen, selbst Verantwortung Ihnen gegenüber zu übernehmen. Zum Beispiel:

• Planen Sie wöchentliche Demonstrationen von IT-Verbesserungen ein, bei denen Teamleiter den geschäftlichen Nutzen erläutern und Feedback von Ihnen und anderen aufnehmen.
• Richten Sie ein Dashboard ein, das wichtige Kennzahlen wie Systemverfügbarkeit oder beantwortete Anrufe zeigt, und bitten Sie die Entwickler, regelmäßig zu erklären, wie ihre Arbeit diese Werte verbessert.
• Erstellen Sie eine Glidepath, um den Fortschritt bei Schlüsselprojekten zu verfolgen und schnell reagieren zu können, falls entscheidende Elemente verzögert werden.

Eine klare Strategie für häufiges Feedback und ein Fokus auf echte, greifbare Geschäftsvorteile stellen sicher, dass Ihr IT-Budget nicht für clevere, aber nutzlose „bessere“ Projekte verschwendet wird. Und wenn Sie – wie die meisten Unternehmen, mit denen ich arbeite – Millionen für Technologie mit bestenfalls unklaren Ergebnissen ausgeben, lohnt es sich doch, die Rendite dieser riesigen Investition zu messen, oder?

Abonnieren Sie den Newsletter des CTO Clubs für weitere Tipps aus unserer Community.