Alex Akimov: Von Startups zu Giganten — API-Strategien und organisatorische Einblicke

Haftungsausschluss: Diese Transkription des Podcasts ist KI-generiert und kann Fehler oder Ungenauigkeiten enthalten.

Matt

Mein Name ist Matt, und ich werde mit Alex Akimov darüber sprechen, wie man die Dynamik von Unternehmensgründern und großen Organisationen in Einklang bringt. Hallo Alex. Guten Morgen. Wie geht's dir?

Alex Akimov

Hallo. Hallo. Mir geht es sehr gut. Wie geht's dir?

Matt

Mir geht es super. Mir geht es super. Ich freue mich auf die heutige Diskussion. Wir werden viel über die Fintechs sprechen, weil Sie arbeiten, früher bei Adyen, und jetzt arbeiten wir an Monite. Und ich denke du bist ich würde dich API Guy nennen, der Typ, der alles über die APIs weiß. Habe ich recht?

Alex Akimov

Ich danke dir. Danke vielmals. Ich würde natürlich sagen, dass es viel mehr Leute gibt, die viel mehr über APIs wissen als ich, aber APIs sind eine meiner Fachgebiete, meiner Leidenschaft. Also, ja, lass uns auch darüber sprechen.

Matt

Aber vielleicht können wir einen Schritt zurücktreten, bevor wir uns eingehender mit einer technischen Frage der API befassen. Du arbeitest bei Adyen. Das ist also, ich würde sagen, eines der wirklich bekannten und erfolgreichen europäischen Fintech-Unternehmen. Und Sie waren während des Übergangs von 250 auf 3.000 Personen dabei. Richtig?

Alex Akimov

Ja. Ja. Das ist richtig. Ich bin 2016 zu Adyen gekommen.

Und ich denke, zu dieser Zeit gab es natürlich viele Leute, die Adyen bereits kannten und daran glaubten, aber es war noch nicht an dem Ort, an dem es jetzt ist. Und es war eine unglaubliche Reise zu sehen, wie alles wächst, natürlich nicht nur aus geschäftlicher Sicht, sondern auch aus Unternehmenssicht, aus der Kultur, den Prozessen und der Technologie. Ich denke, es war wirklich, wirklich unglaublich.

Matt

Das ist also wirklich interessant. Also, ich baue selbst ein Unternehmen auf, also skaliere ich es von 3 Leuten auf 100. Und ich erinnere mich an all die Phasen, die für das Unternehmen wichtig waren, aber das ist wirklich ein kleiner Maßstab. Und ich gehe davon aus, dass sich bei einer Skalierung von 250 auf 3000 viele Dinge ändern, und jedes Jahr ist das Unternehmen ein völlig anderes Unternehmen. Könnten Sie die gewonnenen Erkenntnisse näher erläutern und erläutern, wie sich dies auf die technische Seite ausgewirkt hat, an der Sie gearbeitet haben?

Alex Akimov

Ja. Ich würde sagen, zuallererst, wenn wir über das Unternehmen und Imke und alles nachdenken, wie die Anzahl der Mitarbeiter, die Anzahl der Produkte und, ja, alle Geschäftsindikatoren, ist das wichtig, aber das ist nicht das Matt-Ziel. Du musst also nur dann skalieren, wenn es wirklich weh tut, nicht zu skalieren. Richtig? Das wäre also der und das haben wir bei Adyen beobachtet. Wir hatten ständig das Gefühl, dass wir mehr Leute brauchen, weil wir so viele Bereiche, so viele Dinge zu erledigen haben, so Matt tolle Projekte, so viele coole Kunden. Und gleichzeitig wollten wir wirklich sicherstellen, dass alle Leute, die zu uns kommen, einen sehr guten Klick haben.

Wir haben also etwas, das als Unternehmenskultur bezeichnet wird. Bei Adyen konzentrieren sie sich zum Beispiel sehr auf das, was sie das Hinzufügen von Prinzipien, das Hinzufügen von Formeln nennen. Sie können ganz einfach auf der Website nachschauen. Aber es gibt immer noch viele Videos von Gründern und von allen, die das erklären. Und ich denke, wenn ich zurückblicke, war das tatsächlich ein Schlüssel zum Erfolg für die Ideengeschichte. Denn wenn man so schnell und so stark skaliert, muss man wirklich sicherstellen, dass man auch das Mindset skalieren kann. Sie können den Ansatz zur Problemlösung skalieren, und Sie müssen keine Zeit mit verschiedenen Dingen verschwenden, die Sie verlangsamen würden.

Natürlich ist es immer noch eine Herausforderung, weil Adyen ursprünglich ein niederländisches Unternehmen mit Hauptsitz hier in Amsterdam ist. Aber sie hatten ungefähr mehr als 20 Büros auf der ganzen Welt. Und selbst in Amsterdam, ich weiß nicht, Menschen aus mehr als 80 Ländern und Nationalitäten. Man bringt also all diese Leute von verschiedenen Orten, mit unterschiedlichem Hintergrund, die auch verschiedene Dinge in der Organisation tun, und man sucht nach etwas, das sowohl für Sie als auch für Ihre Kollegen und Ihre Kollegen wichtig ist. Also, und das war ziemlich interessant. Ich würde sagen, dass wir keine Fehler gemacht haben. Und wenn man so schnell wächst, möchte man natürlich experimentieren und viele Dinge ausprobieren.

Adyen versucht immer schlank zu bleiben und so präzise wie ein Start-up. Und irgendwann ist das zum Beispiel meine persönliche Meinung, als ich feststellte, dass, wenn wir ein Unternehmen mit mehreren tausend Mitarbeitern sind, es nicht immer funktioniert, wenn man versucht, Dinge so zu machen, wie wir es in einem Startup tun würden. Aber das ist auch eine bewusste Entscheidung. Also, okay. Möchten Sie Zeit damit verbringen, dieses Problem für den Kunden zu lösen, diesen Prozess einzurichten oder etwas einzuführen?

Matt

Das ist alles, Imke, es interessiert mich immer, weil das das Gaspedal für ein Autojahr ist. Ich meine, skalieren Sie quasi das Wesen, während das Unternehmen so schnell und so groß skalierte. Sie haben also einen der Nachteile erwähnt, aber sehen Sie welche, haben Sie da einige Lektionen, zum Beispiel, was Sie in einem ähnlichen Setup anders machen würden, etwa in einer ähnlichen Skalierungsgeschwindigkeit, mit dem nächsten Unternehmen, etwa, wenn Sie eine solche Möglichkeit haben?

Alex Akimov

Ja. Das ist sehr interessant, Gaus, wenn du einmal Teil dieser Erfolgsgeschichte bist, kannst du immer sagen, okay. Jetzt kenne ich das perfekte Rezept. Richtig? Und wie man alles macht. Und das ist teilweise auch meine Geschichte, denn nach 6 Jahren bei Tadeum entschied ich, okay. Jetzt bin ich als kleines Start-up zu Monite gekommen und wir haben eine API-Plattform entwickelt, die perfekt ist.

Etwas, das ich gerne mache. Und ich habe gute Ideen im Kopf, wie man Dinge baut, auch unternehmensweit und technologisch. Und gleichzeitig sinkt man quasi mehrere Stufen tiefer, was den Reifegrad der Wissensprozesse von allem angeht, was man hat. Und dann siehst du, dass manche Dinge quasi nicht richtig funktionieren und du es eigentlich anders machen solltest, oder du verstehst, warum es einige Entscheidungen gab, die bei deinen Leuten wahrscheinlich anders getroffen wurden. Nochmals, das sind nur etwa 22 verschiedene Erfahrungen, die Sie gemacht haben. Meiner Meinung nach ist es hier wichtig, nicht nur auf deine Erfahrungen zu schauen und mit mehr Menschen zu sprechen. Sprechen Sie mit unseren Leuten, denen es gelungen ist.

Sprechen Sie mit unseren Mitarbeitern, die scheitern, und lernen Sie von ihnen. Und deshalb finde ich es großartig, dass wir diesen Podcast im Allgemeinen haben. Am Ende gibt es so viele Leute, die bereit sind, ihren Fonds zu teilen. Im Allgemeinen, wenn ich die Arbeit in einer großen Organisation wie Adyen im Moment mit einem Startup wie Cognite vergleiche. Ich denke, man muss immer verstehen, was anwendbar ist und was nicht. Und ich habe ein separates Gespräch darüber. Wenn du willst, kannst du nach oben schauen.

Es geht um Ihre API-Strategie für Unternehmen im Vergleich zu Startups. Also hat API letztes Jahr Dokumente erstellt, sodass ich sie etwas später teilen kann. Aber im Grunde identifizieren Sie verschiedene Muster und Sie sehen, wie diese Muster in Ihre Organisation und in das Produkt, das Sie haben, und zu den Menschen passen. Und manchmal treffen Sie Entscheidungen mehr über die Geschwindigkeit, manchmal mehr über die Qualität. Manchmal konzentriert man sich mehr auf die Kunden. Manchmal tut man das einfach nicht und macht weiter, weil

Matt

und du bist schon eine ganze Weile in den Niederlanden, und ich frage mich immer, und das ist immer interessant von dir. Sie sind beide Ausländer und arbeiten in einem vorinternationalen Umfeld. Und sehen Sie etwas Spezifisches an der niederländischen Kultur, das Ihre Arbeitsweise beeinflusst, die Arbeitsweise der Technik? Ist Ihnen so etwas aufgefallen?

Alex Akimov

Ja. Auf jeden Fall. Ich finde die niederländische Kultur großartig, um gemeinsam Dinge zu erreichen.

Es ist also sehr kooperativ. Es wird meiner Meinung nach auch als egalitär bezeichnet, wenn man zu verschiedenen Themen einen Konsens erzielen muss, um als Gruppe voranzukommen. Und das ist perfekt, wenn Sie einige komplexe Herausforderungen vor Augen haben, für die Sie selbst keine perfekte Lösung haben. Sie müssen also mit anderen Menschen sprechen, bevor Sie sich etwas einfallen lassen, das verbessert werden kann. Adiyan ist ein perfektes Beispiel auch für niederländische Kultur. Eines der Prinzipien ist, dass Sie Ihre Ideen immer gemeinsam mit anderen gestalten. Selbst wenn Sie denken, dass Sie der Klügste sind, wenn Sie alles über APIs wissen, ist es immer gut, mehr Leute im Raum zu haben, um ihre Sichtweisen kennenzulernen.

Und das haben wir zum Beispiel mit API-Konsolen gemacht. Wir haben angefangen, mehr Leute einzuladen, wie technischen Support, Implementierungsmanager, Kundenbetreuer, Backend-Entwickler und andere Leute. Nicht nur das Engineering, nicht nur das Produkt, sondern auch mehrere Personen. Und jedes Mal, wenn wir die Diskussion hatten, konnten wir die Suchmaschine verbessern. Ja. Niederländer sind auch dafür bekannt, direkt zu sprechen. Sie behaupten immer, dass sie zu den aufrichtigsten Menschen auf diesem Planeten gehören. Wahrscheinlich, ja.

Wahrscheinlich nicht für mich. Ich denke, da ich auch einen westeuropäischen Hintergrund habe, ist das ganz okay. Ja. Ich denke, ehrlich zu sein ist hilfreich, besonders wenn man mit Technik zu tun hat und manchmal keine Zeit hat, herauszufinden, wie das funktioniert. Du musst Matt bewegen. Du sagst einfach Gaus, du siehst es, und dann stimmst du zu oder nicht, und wir werden uns zusammenschließen. Es ist wichtiger, dass Sie gemeinsame Werte und Ziele haben.

Sie möchten Kunden helfen. Sie wollen etwas erreichen. Matt, vielleicht nur ein paar Erkenntnisse, aber wenn man auf dem Land lebt, trifft man natürlich auf viele andere Umstände. Matt, außerdem stellst du fest, dass alle Menschen unterschiedlich sind, was ganz normal ist. Meine Nachbarn, von der einen Seite und von der anderen Seite, sie sind sehr unterschiedlich und sie sterben alle. Das heißt also auch, dass wir wirklich auf dieser Route unterwegs sind.

Matt

Und lassen Sie uns über die API sprechen. Sie haben also APIs für Millionen von Benutzern erstellt. Ich frage mich also, ob Sie einige Erkenntnisse daraus teilen könnten. Zum Beispiel, wenn es einige Unternehmen gibt, die skalieren, dann sind sie auf Unternehmensebene und sie wollen etwas entwickeln, das so vielen Benutzern gewachsen ist. Zum Beispiel, was haben Sie daraus gelernt? Wie würden Sie die Erstellung der API angehen?

Alex Akimov

Ja. Danke für die Frage. Ich denke, es gibt bereits viele Playbooks im Internet, wie man eine API erstellt, wie man eine API verfügbar macht. Meiner Meinung nach ist es wichtig, zunächst zu verstehen, wer die Benutzer sind, für welche Zielgruppe Sie den CPI erstellen. Und ist es etwas, das du einfach von Grund auf neu aufbaust? Wenn Sie beispielsweise ein Startup oder eine kleine Organisation sind, hatten Sie nie eine öffentliche API, und tatsächlich ist Ihr gesamtes Produkt eine API, im Fall von Imke. Richtig? Das ist ein Ansatz.

Ein anderer Ansatz wäre, wenn Sie zum Beispiel für eine große traditionelle Bank arbeiten und nie eine öffentliche API hatten, aber Sie haben Tausende von internen APIs, Microservices, was auch immer. Und jetzt müssen Sie, ich weiß nicht, PSD 2 einhalten, oft Bankgeschäfte, Gausa-Standards und Sie auch Ihre API oder Sie erstellen eine API für Partner. Diese Partner werden, wie Sie wissen, nur nicht mehr als 10 Organisationen sein, die Ihnen im Entwicklungsteam sehr bekannt sind. Und wenn Sie diese Benutzer wirklich kennen, die sich mit der API verbinden werden, können Sie damit beginnen, zu experimentieren, ihnen die Dokumentationsbeispiele mitzuteilen und Ihre API nur an ihre spezifischen Bedürfnisse anzupassen. Aber wenn Sie eine API für Millionen von Benutzern erstellen, ist das eine andere Geschichte, denn Sie werden niemals in der Lage sein, mit allen zu sprechen. Sie werden sozusagen nur Annahmen treffen. Und das bedeutet, dass Sie wirklich agil bleiben müssen.

Sie müssen wirklich verstehen, dass Sie Ihre API ändern werden. Du wirst es kaputt machen. Und das bedeutet, dass Sie einen guten Vertrag haben müssen, der versteht, was eine bahnbrechende Änderung ist, was keine bahnbrechende Änderung ist, was in der Branche auch nicht gegeben ist. Darüber gibt es immer noch viele verschiedene Debatten. Sie benötigen Ihre API-Versionen. Wie versioniert man es? Wie verstehen Ihre Kunden die Version, die sie verwenden?

Veröffentlichen Sie eine Version pro Jahr oder haben Sie etwa 100 Versionen pro Jahr? All das klingt ziemlich einfach, aber wenn Sie mit der Implementierung beginnen, ist es ziemlich komplex. Und am Ende des Tages, was immer noch wichtig ist, und viele Leute, vor allem in der Technik, neigen dazu, Matt zu vergessen. Natürlich ist es ein technisches Produkt, und natürlich ist es ein anderer Entwickler, der Einfluss darauf hat. Aber am Ende des Tages geht es nicht um JSON im Vergleich zu, ich weiß nicht, REST GraphQL. Es geht nicht nur darum, wie Sie dieses Feld benennen. Es geht natürlich um Sicherheit. Es geht um Leistung.

Es geht um Skalierbarkeit. Aber am Ende des Tages geht es um den Wert, den die Endbenutzer in dieser API sehen werden. Und deshalb müssen Sie wirklich immer verstehen, wie das Endprodukt aussieht, was nicht einfach ist.

Warum nicht einfach eine API? Also musst du visualisieren. Sie müssen verstehen, welche Art von Benutzeroberflächen es sein kann. Und das bedeutet, dass du dich in einem ständigen Lernprozess befinden musst, um zu sehen, okay. Das sind die Beispiele, mit Kunden zu sprechen, mit jemandem zu sprechen, der es versteht. Das ist nicht einfach. Aber wenn Sie das erreichen, dann erreichen Sie eine qualitativ hochwertige API Imke Stripe, wie Adyen, wie Twilio, wie

Matt

Und der größte Fehler, den du gesehen hast, der vielleicht nicht langsam ist, ist offensichtlich. Hast du etwa einige der größten Fehler, die du beim Erstellen der API siehst?

Alex Akimov

Ich würde natürlich sagen, dass es keine API-Versionierung gibt. Ich habe das auch gesehen, und es ist erstaunlich, dass selbst die Art und Weise, wie sehr große Unternehmen Organisationen aufgebaut haben, manchmal einfach etwas kaputt machen oder einem sagen, okay. In 10 Tagen werden wir das entfernen und Sie müssen Ihre Integration anpassen. Natürlich gibt es eine alternative Strategiebewertung, wenn Sie keine Version installiert haben oder einfach ständig Dinge hinzufügen, was auch in Ordnung ist, aber es bedeutet immer noch, dass Sie intern eine Menge technischer Schulden anhäufen. Sie benötigen also eine Strategie zum Aufräumen, was manchmal noch komplizierter ist. Das ist und dann der zweitgrößte Fehler, ich würde sagen, nein, wahrscheinlich die Implementierung der API-Authentifizierung. Denn wenn Sie sich die letzten zehn Sicherheitsprobleme ansehen, denke ich, dass Matt der Probleme immer mit der blinden Sicherheit passiert ist. Es gibt also eine sehr gute Ressource auf der Internet-API Leszek University, wo es kostenlose Kurse und viele Erklärungen gibt.

Und vor Kurzem haben wir auch mit ihnen gesprochen. Ihren Angaben zufolge ist es immer ein Problem mit der Authentifizierung. Wahrscheinlich nicht. Natürlich wird es noch andere Hauptprobleme geben, aber das dritte Problem ist, sich nicht um Ihre Endbenutzer zu kümmern. Da es sich bei der API um ein technisches Produkt handelt, kümmern Sie sich immer um Ihre aktuellen Benutzer, die Entwickler sind. Daher ist eine großartige Entwicklungserfahrung sehr wichtig. Aber wenn Sie sich nicht um Ihre Endbenutzer kümmern, werden Sie zu dem Unternehmen werden, das sie wirklich wollen.

Matt

Sie haben in Ihren Organisationen gearbeitet, also haben Sie viel aus der technischen Perspektive gesehen. Und vor Kurzem hatte ich ein interessantes Gespräch mit einem meiner Gäste, und wir sprachen über die Überkonstruktion in Europa und den USA beim Bauen, Sie wissen schon, das Produkt, während wir an der technischen Seite arbeiteten. Und wir haben darüber gesprochen, dass in den USA sogar die Ingenieure wirklich geschäftsorientiert sind, also diese Vermutung, Gaus. Und, ich weiß nicht, vielleicht sind wir in Europa nicht so geschäftsorientiert, aber wir sind wirklich gute Ingenieure, also konzentrieren wir uns so sehr auf das Engineering. Und manchmal überkonstruieren wir die Dinge und denken zu viel darüber nach. Hast du das in deiner Karriere erlebt?

Alex Akimov

Ich denke ja. Das ist teilweise das, was ich auch oft beobachtet habe. Natürlich vermischt sich jetzt, zum Glück, mit Imkes Arbeit und allem, auch die Ingenieurskultur. Also entweder ich, sozusagen, Ingenieur aus der ganzen Welt und arbeite für kleine Unternehmen mit Sitz in den USA, die einen anderen Ansatz verfolgen, um Werte zu erzielen. Ich denke, das ist es, was wir jetzt auch mehr in europäischen Unternehmen beobachten können, und in meiner Organisation habe ich auch Ingenieure aus Europa, den USA, aus Großbritannien, aus einer anderen Region. Es geht also nur um Matt darum, wie Sie Dinge bauen, auch von der Produktseite aus, wie das Produkt ist und von Ihrem Ingenieur erwartet wird, dass es geliefert wird. Haben Sie Produktteams in Ihrer Organisation?

Wie formatiert man? Wie arbeitet ihr zusammen? Wie beziehen Sie Ihre Ingenieure in Kundengespräche ein? Und vielleicht kann einer der Gründe übrigens die Sprachbarriere sein. Denn wenn Sie Englisch sprechen, können Sie Alex gehen und mit Ihren Kunden sprechen. Matt ist wahrscheinlich auch englischsprachig oder international. Richtig? Aber wenn Sie sich beim Sprechen nicht wohl fühlen und trotzdem ein sehr guter Ingenieur sind, werden Sie Ihren Platz in der Organisation finden, aber Sie werden quasi von jeder Fähigkeit ausgeschlossen, oder auch Sie selbst, nicht weil jemand Sie bearbeitet, sondern Sie selbst.

Du fühlst dich nicht wohl dabei, zu reden und herauszufinden, und du konzentrierst dich mehr auf technische Dinge von Matt. Das kann auch der Fall sein. Ja. Ich und vielleicht ein letztes Beispiel hier. Es tut mir leid. Jetzt erinnere ich mich. Wenn Sie sogar an die Richtlinien denken, internationale Richtlinien, die beispielsweise von den USA oder der Europäischen Union entwickelt wurden, wenn Sie darüber nachdenken, wie komplex die DSGVO ist oder wie PSD 2 oder so, denke ich, sollte Matt Teil des, ich weiß nicht, natürlichen nationalen Charakters sein, der versucht

Matt

einen Konsens erzielen. Denn wenn Sie versuchen, einen Konsens zwischen so vielen Ländern und Parteien zu erzielen, haben Sie es mit etwas sehr Komplexes zu tun. Und das ist nur ein Teil des Prozesses, wie man Dinge erreicht. In den USA dreht sich alles um Geschwindigkeit, Lieferung und Wert, weil es entweder heißt, groß oder nach Hause zu gehen. Richtig? Es geht also immer darum, und du tust alles, um es schneller zu machen. Ja. Die DSGVO ist ein perfektes Beispiel für den Vergleich der Kulturen. Richtig? Also ich liebe es absolut.

Es ist ein perfekter Vergleich. Und Alex, ich spreche wirklich gerne über die schwierigen und schwierigen Dinge während der Gaus, die du während deiner Karriere erlebt hast. Normalerweise lernen wir in diesen Zeiten am meisten. Richtig? Sie sind herausfordernd. Sie sind schwierig, aber wir haben Dinge, die unsere Herangehensweise an das, was wir in Zukunft tun, einmal, einmal im Leben ändern. Ich frage mich nur, können Sie mir eine Zeit beschreiben, in der Sie vielleicht an einer umstrittenen Entscheidung beteiligt waren, einer Führungsentscheidung in der technischen Abteilung?

Was war das und was hast du vielleicht daraus gelernt?

Alex Akimov

Oh, ja. Offensichtlich gab es in meiner Karriere mehrere Dinge, von denen ich dachte, oh, das ist sehr umstritten. Und einigen von ihnen kann ich jetzt zustimmen, bei einigen würde ich wahrscheinlich immer noch nicht zustimmen. Und auf der Seite der Menschen geht es ziemlich oft, ich weiß nicht, um Reorganisation. Sehr oft geht es darum, Teams und Menschen und ihre Ambitionen zu verändern. Oder noch schlimmer, es geht darum, einige der Produkte aufzugeben, an denen Ihr Team ein Jahr lang gearbeitet hat, sogar länger. Das hat uns immer schwer getroffen, weil wir kreative Menschen sind.

Wir machen gerne etwas, von dem wir glauben, dass es uns wert ist. Und außerdem fühlen sich die meisten von uns, weil wir eine Organisation sind, an Menschen gebunden, mit denen wir zusammenarbeiten. Wir sind gerne zusammen, und deshalb sind all die Veränderungen normalerweise ziemlich schwierig. Ich habe es auf die harte Tour gelernt, aber ich verstehe auch, dass es notwendig ist. Und manchmal fordert Matt uns auf, sogar die Organisation zu wechseln, um an einen anderen Ort zu gehen. Das habe ich zum Beispiel vor fast 2 Jahren mit Adient gemacht. Ja. Vielleicht ist es Gaus nicht einfach, aber es ist unvermeidlich.

Eine andere Sache, die wirklich umstritten war, ist die Frage, ich weiß es nicht. Was die technische Seite angeht, kann ich meine zahlreichen Beispiele haben. Bauen wir zum Beispiel einen Monolithen oder verwenden wir Microservices? Oder, okay, was bekommen wir jetzt aus einem verteilten Monolith mit vielen Microservices? Wie pflegen wir ihn? Wie viel haben wir hier. Ist Matt für dieses Modul eine gute Lösung für diese Organisationsgröße?

Ist es nicht? Also diese Art von architektonischen Entscheidungen fällt Matt auch ziemlich schwer und ist auch ziemlich schwer wiedergutzumachen. Und dann klingt das natürlich wie, okay. Wir müssen diese Funktionalität jetzt implementieren, wie API-Pufferung, aber es gibt kein gutes Framework.

Aber was machen wir jetzt? Wollen wir einen solchen Brauch aufbauen und darin investieren, oder wollen wir als Arbeiter etwas aufbauen und uns für immer damit auseinandersetzen? Dies ist auch eine der schwierigeren Entscheidungen, die wir alle als Ingenieurgruppe getroffen haben, und ich würde sagen, wir könnten es besser machen. Ich möchte hier generell keine weiteren Gaus herausgeben. Und das ist etwas, das mir auffällt. Und vielleicht der letzte Punkt, den ich im Laufe meiner Karriere wirklich gelernt habe, ist, dass es sich um eine Fähigkeit handelt, die oft als Gaus-Delegation bezeichnet wird, aber ich habe kürzlich eine sehr gute Definition davon von einem meiner CTO-Kollegen gehört, der sagte, okay. Du solltest immer so optimieren, dass du nicht anwesend bist, was im Grunde bedeutet, dass du alles, was du tust und jeden Prozess, den du einrichtest und wie du Menschen befähigst, immer für einen Moment optimierst, wenn du aus irgendeinem Grund nicht verfügbar bist.

Du kannst in den Urlaub fahren oder es kann ein weiterer Anruf sein oder du kannst das tun und das habe ich selbst auf die harte Tour gelernt Gaus, wenn du etwas tust und gut darin bist, du versuchst immer, das zu tun und du tust das immer weniger, wenn sich die Leute auf dich verlassen, und dann wirst du natürlich ein Bot

Matt

also ich habe noch 2 2 Fragen, die ich dir stellen wollte. 1 liegt daran, dass du von einem API-Leiter herangewachsen bist. Sie waren VP of Technology und jetzt sind Sie CTO, für etwa ein paar, ein paar Monate. Und es ist eine neue Rolle, und ich frage mich nur, was Ihre aktuellen Herausforderungen sind, was sind Ihre aktuellen Dinge, die Sie lernen, was haben Sie dieses Jahr zu lösen, wissen Sie, zu lösen?

Alex Akimov

Ja. Ich glaube, eine der größten Herausforderungen ist eine ähnliche wie die, die ich zuvor hatte, aber sie ist immer noch ziemlich neu, weil es viel um Menschen geht, und es geht viel mehr um Menschen als um Technologie, zumindest an dieser Stelle der Organisation und zumindest gemäß meiner Sichtweise und meiner Strategie. Also wo finde ich, dass Matt das richtige Talent ist? Also, weil wir zuerst remote arbeiten, können wir von überall Leute einstellen. Wer sind diese Leute? Wie erweitern wir unsere Teams? Wie unterstützen wir Menschen, die bereits an Bord sind?

Wie helfen wir ihnen? Und was sind die richtigen Herausforderungen? Dann besteht die zweite Herausforderung natürlich darin, wie wir alles für das Unternehmen bereitstellen können? Denn wenn Sie sich auf den technischen Teil konzentrieren, ist er bereits gegeben, okay, wir müssen ihn erreichen. Wie stimmen wir Geschäftsziele ab, auf die ich jetzt mehr Einfluss haben kann, und das Budget und die Kundenerwartungen und alles andere mit dem, was mein Team leisten kann und was noch wichtiger ist, dem, was mein Team liefern möchte? Dieser Gaus ist also auch eine Art Herausforderung. Ja. Und dann natürlich all die technischen Herausforderungen, wie Skalierbarkeit, Leistung, Sicherheit, was ich erwähnt habe.

Es ist sehr interessant, wenn man ein Startup gründet und wenn man eine sehr große technologische Matt-Plattform aufbaut. Aber es ist auch toll, wenn man erst am Anfang steht. Es ist also nicht so, dass man nicht viel ändern kann, aber auch jede Entscheidung ist

Matt

Und die letzte Frage, die ich habe, wenn Sie ein Buch nennen könnten, das Ihre Karriere als technische Führungskraft wirklich beeinflusst hat, erinnern Sie sich an den Titel des Buches, das Sie empfehlen könnten?

Alex Akimov

Ich denke, das grundlegendste Buch für mich war sehr früh in meiner Karriere. Es war Kybernetik von Norbert Wiener. Es ist ein sehr altes Buch, aber ich weiß nicht, ob dieses Buch heutzutage jemand liest. Im Allgemeinen denke ich, dass Team-Topologien gut sind. Matt, viele Leute empfehlen es.

Und außerdem ein elegantes Puzzle. Es ist eines der neuesten. Ich sage, ich habe es tatsächlich irgendwo. Ja. Von Will Larson.

Von Will Larson.

Matt

Oh, okay. Ja. Ja, es ist Imke. Es ist genial. Vielen Dank, Alex, für das tolle Gespräch heute. Danke.

Alex Akimov

Hab einen schönen Tag. Danke, dass du mich eingeladen hast. Tschüss. Tschüss.

Matt

Folgen Sie Matt auf LinkedIn und abonnieren Sie den Better Tech Leadership-Newsletter.

‍