Versagt: IT-Profis teilen hart erarbeitete Lektionen aus frühen Karrierestolpersteinen, die den Weg zu langfristigem Karriereerfolg geebnet haben. [...]
Coaches trainieren ihre Athleten, ein schnelles Gedächtnis für Fehler zu entwickeln, damit sie zum nächsten Spiel übergehen und erfolgreich sein können. Ebenso wird Führungskräften in der Wirtschaft häufig geraten, möglichst schnell zu scheitern und dann weiterzumachen. In beiden Fällen geht es darum, sich neu zu fokussieren und von vorn anzufangen, und das alles unter anhaltendem, enormem Druck – und dennoch Ergebnisse auf hohem Niveau zu erzielen.
Keine große Errungenschaft in der Technologie ist ohne ein paar Fehlstarts zustande gekommen. Die IT-Profis, mit denen wir gesprochen haben, raten uns, aus Fehlern zu lernen, in Echtzeit zu refaktorisieren und gleichzeitig Risiken zu managen, um Ergebnisse zu vermeiden, von denen man sich nur schwer wieder erholen kann.
Wenn also frühe Stolpersteine später zu Erfolgen führen können, was sind dann einige der denkwürdigeren und nützlicheren Fehler, die IT-Führungskräfte schon gemacht haben? Hier finden Sie die Geschichten darüber, wie frühe Fehltritte zu positiven Ergebnissen in der IT-Führung geführt haben.
Die Bedeutung der Iteration übersehen
Colin Earl, CEO von Agiloft, weist darauf hin, dass Sie alle Kästchen für die Lieferung eines Projekts oder Produkts abhaken können und es trotzdem zu wenig ist.
„Das wurde mir klar, als mein Team für die Implementierung eines Unternehmenssystems verantwortlich war“, erklärt Earl. „Wir haben es pünktlich und innerhalb des Budgets fertig gestellt. Und es hat alles erfüllt, was die Benutzer verlangt haben, und zwar genau in der versprochenen Weise. Aber als sie es einsetzen wollten, wurde ihnen klar, dass das, was sie wollten, nicht das war, was sie wirklich brauchten. Die Neuimplementierung des Systems, um alle neuen Anforderungen zu erfüllen und viele der alten Anforderungen zu eliminieren, bedeutete, dass das Projekt zu spät kam und über dem Budget lag, als es in den Produktionseinsatz ging, und die IT-Abteilung nahm die Schuld an diesem Misserfolg auf sich.
Earl weist dabei auf das Beste aus beiden Welten hin: später von den eigenen Fehlern zu profitieren und aus den Fehlern anderer zu lernen, damit man sie nicht wiederholen muss.
„Es gibt eine Fülle von Wissen und gesammelter Erfahrung darüber, was funktioniert und was nicht funktioniert, und es ist ein großer Irrtum, das alles zu ignorieren“, sagt er. „Fehler sind das unvermeidliche Ergebnis von Risikobereitschaft und etwas, das Führungskräfte als Preis für die für den Erfolg notwendige Veränderung akzeptieren müssen. Aber Risiken sollten nach Möglichkeit gemildert oder ausgeschlossen werden. Wenn man zum Beispiel ein [minimal lebensfähiges Produkt] statt eines vollständig ausgebauten Produkts schafft, verringert das das Risiko eines Misserfolgs nicht, wenn überhaupt, dann wird es mit geringerer Wahrscheinlichkeit akzeptiert. Aber es stellt sicher, dass der Misserfolg schnell und zu geringen Kosten eintritt, so dass das Gesamtrisiko für die Organisation insgesamt viel geringer ist.
Missverständnisse bei der Kommunikation mit Ihren Benutzern
Wie Earl erinnert Sarah Lahav, die Geschäftsführerin von SysAid, an ein Projekt, das die richtigen Elemente hatte, aber dennoch schief lief, diesmal aus einer verpassten Gelegenheit, seinen Zweck zu verdeutlichen.
„Damals in meinen frühen Tagen bei SysAid, als ich das Kundensupport-Team leitete, haben wir einen Chat gestartet, um die Kundenbetreuung zu beschleunigen“, erinnert sich Lahav. „Wir müssen unserer Zeit voraus gewesen sein – denn es war urkomisch, wie viele Leute nicht verstanden, dass der direkte Nachrichtenaustausch für den technischen Support gedacht war. Sie dachten, es sei nur ein neuer, zufälliger Chat-Raum. Die Leute schickten uns die seltsamsten Nachrichten. Uns wurde klar, dass wir bei jeder neuen Technologie sehr spezifisch sein müssen, wenn wir sie innerhalb des allgemeinen Produkts kennzeichnen wollen. Wir können nicht den populären Begriff einer Funktionalität verwenden, die sonst anders verwendet wird. Und dies ist ganz sicher bei verschiedenen Funktionen innerhalb von SysAid immer wieder aufgetaucht“.
Verbleibende Störungen
Sukhi Jutla, Mitbegründerin von MarketOrders, empfiehlt einen iterativen Ansatz für Technologieprojekte, um diese dann in Echtzeit zu testen.
„Fehler sind ein Nebenprodukt, wenn man den Weg zum Erfolg sucht oder, mit anderen Worten, wenn man herausfindet, was tatsächlich funktioniert“, sagt Jutla. „Es ist sehr unwahrscheinlich, dass Sie jemals ein perfektes Produkt auf den Markt bringen werden, aber Sie können ein Produkt auf den Markt bringen, das von jedem Benutzer ständig verbessert wird. Das führt auf lange Sicht zu kumulativen positiven Effekten.“
Jutla hat die Erfahrung gemacht, dass eine zu starke Konzentration auf die Anforderungen im Vorfeld eines Projekts zu Verzögerungen und zur Obsoleszenz führt, bevor es in Angriff genommen werden kann.
„In der Vergangenheit habe ich bis zu 7-8 Monate mit dem Team daran gearbeitet, die erforderlichen Anforderungen zu ermitteln, nur um dann festzustellen, dass beim eigentlichen Build viele Funktionen bereits veraltet waren“, erzählt sie. „Wir sollten so schnell wie möglich einen funktionierenden Prototyp entwickeln, um ein reales Feedback von echten Benutzern zu erhalten.
Jutla setzt nun die Scrum-Methode ein, weil sie damit Ziele und Pläne in Echtzeit neu ausrichten kann. „Man muss darauf vorbereitet sein, ein paar Mal auf die Nase zu fallen“, sagt sie, „auf ein paar Hindernisse zu stoßen und zu scheitern, aber man muss wissen, dass all dies wichtige Informationen sind, die man in seine nächsten Schritte einfließen lässt.
Aible CEO Arijit Sengupta stimmt zu, dass es wichtig ist, sich auf die Entwicklung und Verbesserung zu konzentrieren. „Das bedeutet nicht, dass Ihre ursprüngliche Idee ein Fehlschlag war“, sagt er. „Sie müssen die Vorstellung verinnerlichen, dass alles irgendwann mal aktualisiert werden muss. In der Welt der KI gilt: Je effektiver das KI-Modell, desto schneller ändert es sein Verhalten und desto schneller veraltet es. Das ist kein Misserfolg. Das ist nur die Realität, dass sich die Bedingungen ständig ändern“.
Sengupta sieht es als Risikomanagement vs. Risikobereitschaft. „Man baut Systeme, um mit so viel Unsicherheit wie möglich umzugehen, anstatt Systeme zu bauen, um Risiken zu vermeiden.“
Den Ozean zum Kochen bringen
Suresh Sambandam, CEO von Kissflow, stellte zu Beginn seiner Gründungsphase fest, dass das Unternehmen hoch – wahrscheinlich zu hoch – mit einem Plan für Störungen zielte, der von einem engeren Fokus profitiert hätte.
„Als wir unser Unternehmen gründeten, haben wir Software entwickelt, die wir für einzigartig hielten, aber zu diesem Zeitpunkt für die Menschen nur schwer verständlich war“, sagt Sambandam. „Wir versuchten, eine Kategorie zu schaffen – DIY Enterprise App in der Cloud – statt nur ein Produkt. Wir hatten nicht erkannt, dass es für ein Großunternehmen einfach ist, eine neue Kategorie zu erstellen, aber nicht für ein Startup. Wir mussten aufgrund dieser Technologiewetten, die wir gemacht haben, den Kurs ändern, als ob wir glauben würden, dass Selbstbedienungs-Business-Anwender die Zukunft sein würden – uns wurde das Gegenteil bewiesen.
Später verlagerte das Unternehmen seinen Schwerpunkt auf Software für Workflow-Management und hatte damit Erfolg. Sambandam ist jedoch der Meinung, dass die Korrelation zwischen Fehlern und technischem Erfolg an sich schon ein Fehler ist. Eine kürzlich vom MIT durchgeführte Studie bestätigt dies und argumentiert, dass bessere Ergebnisse durch eine Konzentration auf das Lernen und nicht durch Misserfolge erzielt werden.
„Es ist eher ein taktischer als ein direktionaler Ansatz“, sagt Sambandam. „Ich glaube, wenn man eine klare Vorstellung davon hat, was man tun will, wird man nicht so schnell versagen. Auf dem Weg dorthin können Sie jedoch neue Techniken ausprobieren und sehen, wie sie sich für Ihr Unternehmen bewähren. Wenn es nicht funktioniert, deklarieren Sie es und versuchen Sie etwas anderes.“
Vorausplanen, wenn es Zeit für einen Neuanfang ist
Dietmar Rietsch, CEO von Pimcore, erinnert sich, dass er in der Anfangszeit seines Unternehmens versucht hat, verschiedene Softwaresysteme zu integrieren, bevor er erkannte, dass ein neuer Ansatz erforderlich war.
„Wir haben verzweifelt versucht, die Bedürfnisse unserer Kunden zu erfüllen“, berichtet Rietsch. „Jahrelang führte dies zu langen Nächten, zum Burnout der Mitarbeiter, zu Geschäftsverlusten und zahlreichen Ineffizienzen. Während wir diese Herausforderungen schon früh erlebten, lernten wir auch eine Menge von den Lösungen, die wir versuchten und die nicht funktionierten, und hörten unseren Kunden zu, was sie brauchten.
Ihre Unternehmenssoftware musste überholt werden, wenn sie die Probleme lösen sollte, für die sie konzipiert war, erkannte Rietsch. Es war Zeit, neu anzufangen.
„Wir sind dann schließlich ein Risiko eingegangen und haben unsere Kräfte neu ausgerichtet, um unsere eigene Lösung zu schaffen, die diese Defizite überbrückt, Schnittstellen kombiniert und Unternehmen dabei hilft, die Daten unter Kontrolle zu halten“, meint er. „Durch diese Erfahrung von Trial-and-Error lernte ich, wie ich schnell scheitern und meinen eigenen Weg zum Erfolg schaffen konnte, anstatt darauf zu warten, dass mir eine Lösung ausgehändigt wird. Die härteste Lektion, die ich in meiner technischen Laufbahn gelernt habe, war, hart zu scheitern und diesen Misserfolg nicht zu fürchten.
Feinabstimmung der Technik zur Perfektionierung des Systems
Aibles Sengupta fand heraus, dass die Konzentration auf sein Fachgebiet ihn nur halbwegs dorthin gebracht hätte, wo er hinwollte, wenn die Prioritäten des Unternehmens nicht die treibende Kraft hinter der Entscheidungsfindung gewesen wären.
„Ich glaube, dass Fehler später in IT-Karrieren zum Erfolg führen können“, betont Sengupta. „Ich habe das erste Jahrzehnt meiner Karriere in der KI damit verbracht, zu glauben, dass Modellgenauigkeit das Wichtigste ist. Aber letztendlich erkannte ich, dass ein extrem genaues Modell den Wert des Unternehmens zerstören kann, wenn man die einzigartigen Kosten-Nutzen-Kompromisse und betrieblichen Zwänge des Unternehmens nicht berücksichtigt. Mein Fokus liegt darauf, mit KI einen Geschäftseffekt zu erzielen, anstatt in die Falle zu tappen, dass das genaueste Modell notwendigerweise das beste für jedes Geschäftsproblem sein muss.“
Erzwingen einer technischen Anpassung
Vaclav Vincalek, CEO bei Pacific Coast Information Systems, blickt auf seine frühe Karriere zurück und erinnert sich an einen Fehler, von dem er glaubt, dass er mehr als nur ein paar junge technische Führungskräfte ins Straucheln gebracht hat.
„Ganz einfach, ich dachte, eine bestimmte Technologie sei cool“, sagt Vincalek. „Aufgrund meiner Begeisterung für dieses Spitzentool habe ich es einem Unternehmenskunden aufgedrängt. Erst später habe ich gemerkt, dass es für ihre Umgebung nicht gut geeignet war. Zum Glück für den Kunden erkannte der CIO des Kunden diesen Fehler ziemlich schnell und passte den Projektverlauf an.“
Das Problem? Vincalek hatte die Geschäftsanforderungen und die aktuelle IT-Umgebung nicht berücksichtigt. „Sicher, meine ‚coole‘ Lösung hätte funktioniert“, meint er. „Aber sie hätte auch zusätzliche Kosten, Anstrengungen und Risiken für ihre IT-Prozesse mit sich gebracht, die einfach nicht nötig waren. Ihr interner CIO listete seine Gründe auf, warum sie eine andere Richtung eingeschlagen hatten, und wir machten von da an weiter.
Es war eine Lektion, an die er sich noch lange erinnern würde, und die ihn dazu gebracht hat, sicherzustellen, dass die vorgeschlagene Lösung und die geschäftlichen Bedürfnisse und Fähigkeiten des Kunden eng aufeinander abgestimmt werden müssen.
„Es wird immer eine neue, coole Technologie geben“, so Vincalek, „aber es geht darum, etwas zu wählen, das für das Unternehmen geeignet ist, damit es wachsen kann. Das ist ein wichtiger Teil der Strategien, die ich als CTO für Start-ups und Unternehmen heute umsetze.“
*Paul Heltzel ist Schriftsteller und Redakteur bei CIO.com, der früher bei Discovery News, National Geographic, NPR und der Zeitschrift PC World tätig war.
Be the first to comment