Die Fehler, die ich als neuer CTO gemacht habe

Dinge beginnen normalerweise aus einem Grund, und so habe ich Madison Technologies ins Leben gerufen. Allzu oft vergessen wir, dass es Gründe gibt, warum wir Dinge tun. Ich genieße es, durch Versagen zu lernen. Um zu scheitern, muss man ein Idealist sein, um den Weg zu wählen, den man gehen möchte. Ich habe diesen Weg gewählt wegen der Lektionen, die ich als Gründungs-CTO von GOJEK gelernt habe (jetzt GoTo genannt und öffentlich an der indonesischen Börse notiert.)

Ich trat GOJEK im Dezember 2014 bei. Ich war der neue CTO und kam kurz vor dem Start der mobilen App an. Wir waren ein fröhliches Team von 3 Kerningenieuren, und ich war die neue Ergänzung. Die harte Arbeit, um die App zu bauen, war bereits erledigt, und ich war bereit, das Ruder zu übernehmen, als wir starteten. Rückblickend gab es Aufregung, aber ich war damals überfordert. Es fühlte sich an, als gäbe es so viel zu tun und keine Zeit oder Arbeitskräfte, um es zu tun. Trotzdem machte ich mich an die Arbeit und teilte meine Zeit so gut ich konnte, um schließlich zu starten.

Eines unserer ersten Launch-Events beinhaltete das Versammeln einer kleinen Gruppe von Journalisten in einem Restaurant in SCBD, Jakarta. Nadiem, unser CEO, hielt eine Präsentation, wonach wir die Journalisten einluden, die App herunterzuladen und die Buchung von Gojeks aus erster Hand zu erleben. Während dieser Zeit stießen wir jedoch auf einen lästigen Bug: Der Dienst, der die Karte mit allen Fahrern anzeigte, stürzte ab, wodurch alle Fahrer von der Karte verschwanden. Das bedeutete auch, dass niemand eine Fahrt buchen konnte und wir den Dienst neu starten mussten.

Und dann, 5 Minuten bevor Nadiem seine Präsentation beendete, warf ich einen Blick auf mein Handy und sah, dass die Fahrerkarte leer war. Ich sprintete zu meinem Laptop, so schnell meine wackeligen Beine mich tragen konnten, und betete, dass die 3G-Verbindung von meinem Handy mir zumindest erlauben würde, per SSH auf den Server zuzugreifen, um den Dienst neu zu starten. An diesem Tag war das Glück auf meiner Seite, und ich schaffte es, den Dienst gerade noch rechtzeitig neu zu starten und saß dort hyperventilierend, als die Journalisten aufgeregt wurden, dass sie ihren Fahrer reservieren konnten. Hier ist ein Foto von uns am Ende des Launch-Events.

Von links nach rechts: Sam, Kevin, ich, Nadiem, Mikey und Rio

Es gab viele Geschichten wie die oben genannte. Die App war unser Hauptfokus, und damals hatten wir viele Brände zu löschen. Als unsere Benutzer wuchsen, stießen wir auf Fehler und Bugs, die wir noch nie zuvor gesehen hatten.

Während dieser Phase übernahm ich eine taktische Rolle, arbeitete direkt mit dem Code und versuchte, Probleme zu debuggen, die auftauchten. Einmal analysierte ich den Speicher des gleichen Fahrerdienstes, weil es schien, als würde der Garbage Collector den gesamten Dienst (bereits bei 98% CPU-Auslastung) zum Absturz bringen. Es dauerte so lange, dass ich beschloss aufzugeben und die API von Java nach Go umzuschreiben, sie hinter unserem Load Balancer auszutauschen und mit Erstaunen zuzusehen, wie die CPU-Auslastung für diesen Server auf 3% sank. Es fühlte sich großartig an, aber es war nicht das, was ich tun sollte.

Ich brauchte mehr Leute, und ich brauchte sie schnell. Ich hätte viel mehr Aufmerksamkeit auf so viele andere Bereiche des Unternehmens schenken sollen, die Hilfe brauchten. Zum Beispiel unser operatives Dashboard, wo wir das Onboarding und die Verwaltung von Fahrern verfolgten, brauchte dringend eine Überholung. Würden Sie glauben, dass wir Post-Its verwendet haben, um einige unserer Datenbankfelder zu verfolgen? Wirklich:

Und dann gab es unsere Analysen, um zu verfolgen, wie unsere Werbeausgaben liefen. Wir verwendeten viele SDKs, aber hier ist ein Einblick in einen Austausch, den ich damals mit dem AppsFlyer-Team hatte:

So viele andere Bereiche, die meine Aufmerksamkeit brauchten, bekamen sie nicht. Ich steckte in dieser Einstellungskrise fest und in einer Denkweise, die mich nicht dazu gebracht hätte, unser bereits knappes Geld auszugeben.

Zunächst hätte ich viel mehr Zeit damit verbracht, ein Netzwerk intelligenter Personen aus dem Tech-Bereich aufzubauen. Personen, mit denen ich Ideen austauschen oder bei Bedarf um Hilfe bitten konnte. Ich stellte mir vor, dass ich all mein geheimes IP streng bewachen und mit niemandem sprechen musste. Schlimmer noch, ich bin ein Introvertierter, und Gespräche kommen nicht natürlich. Infolgedessen könnte ich besser darin sein, Kontakt zu halten und Beziehungen zu pflegen. Hätte ich daran durch mein Netzwerk gearbeitet, wäre es erheblich einfacher gewesen, Hilfe oder Empfehlungen für Einstellungen zu bekommen.

Als Nächstes hätte ich mehr parallelisiert. Ich war in einem Einstellungsrausch, aber es kommt ein Zeitpunkt, an dem die Einstellung einen Punkt erreicht, an dem man eine Reihe von Interviews und potenzielle Kandidaten hat, aber der Fortschritt ins Stocken gerät. Ich war ziemlich vorsichtig und zögerte, in ein ausgelagertes Team zu investieren, um gleichzeitig an Projekten zu arbeiten. Mein Fokus lag ausschließlich darauf, die internen Positionen zu besetzen, was sich im Nachhinein als Fehltritt herausstellte. Hätte ich meine Denkweise geändert, hätte ich meine Operations- und Marketing-Teams vorübergehend mit einem ausgelagerten Engineering-Team besetzt und diese Arbeitsströme parallel laufen lassen, während ich an anspruchsvolleren Problemen arbeitete.

Rückblickend war die bedeutendste Auswirkung meiner Fehler ein Zeitverlust. Das ist etwas, das man nie zurückbekommt; für ein Startup ist Zeit oft eine knappe Ressource, wenn man versucht, mit anderen im Raum zu konkurrieren. Wir hätten schneller vorankommen können, wenn ich die Arbeitsströme für Operations, Marketing und HR parallel durch die Einstellung eines ausgelagerten Teams geführt hätte. Wir hätten auch mehr Daten gehabt, um sie in unsere App-Entwicklung einzubringen. Schließlich hätten wir für die VCs noch attraktiver sein können, indem wir diese Zeit zurückgewonnen hätten, und hätten früher Geld eingesammelt. Obwohl ich an einigen Fundraising-Runden teilgenommen habe, läuft keine so reibungslos oder schnell ab, wie man es erwartet.

Obwohl es einfach klingen mag, ist es eine der wichtigsten Lektionen, die ich gelernt habe. Tech ist nicht nur Ihr Kernprodukt. Die Anwendung von Technologie erstreckt sich über das Engineering hinaus auf verschiedene andere Abteilungen wie Operations, Marketing, HR und Finanzen. Neuere CTOs können diese Realität manchmal übersehen und nicht die notwendige Unterstützung für diese Funktionen so prompt wie erforderlich bereitstellen. Das war ich sicher, und im Nachhinein wäre mein erster Schritt gewesen, meinen Fokus über das Produkt hinaus zu erweitern.

Ein weiterer Anfängerfehler meinerseits war, die alleinige Verantwortung für alle Tech-Dinge zu übernehmen. Indem ich versuchte, die Tech den anderen Teams selbst zu liefern, bremste ich alle aus, einschließlich mich selbst. Hätte ich ein temporäres oder ausgelagertes Team mit einem guten Tech-Lead in diesen Funktionen platziert, hätte ich die Funktionsinhaber befähigen können, die Verantwortung zu übernehmen und Lösungen nach ihren Anforderungen zu entwickeln. Ihre Abhängigkeit von mir wäre auf bedeutende Angelegenheiten wie Architektur und Gesamtzusammenhalt beschränkt gewesen. Ich erkannte, dass ich durch den Versuch, alles zu kontrollieren, eine 2x-Denkweise und nicht eine 10x verwendete. Also geben Sie die Kontrolle auf, geben Sie Ihren Co-Führungskräften die Ressourcen und machen Sie ihnen Platz.

Das bringt uns direkt zurück zu dem Grund, warum ich Madison Technologies gegründet habe. Wir sind hier, um Ihnen zu helfen, Dinge schneller zu bewegen. Wir sind hier, um die Lücken zu schließen, während Sie Ihr Traumteam einstellen. Wir waren schon einmal dort, und wir werden das zusammen durchstehen.

Fühlen Sie sich frei, mich über mein LinkedIn für ein tieferes Gespräch zu kontaktieren. Lassen Sie uns in Verbindung treten!

Sheran Gunasekera ist Sicherheitsforscher und Softwareentwickler. Er ist Mitbegründer und Forschungsdirektor von Madison Technologies, einem Softwareentwicklungsunternehmen in Singapur, wo er das interne Engineering-Team sowohl in der Sicherheit von Personalcomputern als auch von Mobilgeräten berät. Sherans Einstieg in die mobile Sicherheit begann 2009, als er mit der BlackBerry-Sicherheitsforschung begann. Seitdem hatte er Führungsrollen sowohl im Engineering als auch in der Sicherheit bei mehreren Startups in Asien, einschließlich GOJEK, der On-Demand-Multi-Service-App, die jetzt öffentlich notiert ist.