Der Weg zum VP of Engineering
(honeycomb.io)- Der erste VP of Engineering von Honeycomb wurde im Februar 2020 vom Director of Engineering befördert; dieser Weg war weniger eine geplante Executive-Karriere als vielmehr ein Hineinwachsen in Lücken, die durch das Wachstum des Unternehmens entstanden
- In der frühen Phase von Honeycomb managte Mitgründerin Charity Majors fast alle; zwei Personen mit ähnlicher Philosophie, aber unterschiedlichem Hintergrund und Stil teilten sich zunehmend die Managementverantwortung für R&D
- Die Beförderung war kein einzelner großer Übergang, sondern die Summe kleiner Erweiterungen des Verantwortungsbereichs; das Schaffen neuer Prozesse und Verantwortlichkeiten in einem Startup wurde zum zentralen Weg
- Zur Vorbereitung auf die Rolle gehörten Denken auf Unternehmensebene, eine Generalist:innen-Neigung, die Fähigkeit, zwischen verschiedenen Abstraktionsebenen zu wechseln, Verantwortungsbewusstsein, Systemdenken, Unterstützung beim Wachstum von Teammitgliedern und ein breites Beziehungsnetz
- Was einen guten VP of Engineering ausmacht, hängt weniger von einer Standardschablone ab als von den aktuellen Problemen des Unternehmens, der vorhandenen Zusammensetzung aus Leadership und ICs, den technischen Herausforderungen und der Wachstumsphase
Ein Ausgangspunkt, der keine geplante Executive-Karriere war
- Der erste VP of Engineering von Honeycomb wurde im Februar 2020 vom Director of Engineering befördert
- Das ursprüngliche Ziel beim Einstieg bei Honeycomb war, als Engineer zu arbeiten, mit dem Verständnis, bei Bedarf wieder in eine Managementrolle zurückkehren zu können
- Zum Zeitpunkt des Einstiegs war die Person etwa die zwölfte Mitarbeiterin; in einem frühen Startup war klar, dass man mit wachsendem Erfolg des Unternehmens in verschiedenen Phasen unterschiedliche Aufgaben übernehmen würde
- Ein starkes Festhalten an einer bestimmten Rolle wurde eher als hinderlich denn als hilfreich für die Person und das Unternehmen gesehen
- Die Entscheidung für Honeycomb fiel, weil das Team klug und freundlich wirkte, es viel zu lernen zu geben schien und das Produkt wie etwas aussah, das man sich beim vorherigen Arbeitgeber gewünscht, dort aber nicht gefunden hatte
- Wer schnell in eine bestimmte Rolle hineinwachsen möchte, ist mit einem Einstieg in ein Startup nach Series B möglicherweise effizienter unterwegs; bei Honeycomb erfolgte der Einstieg jedoch in der Series-A-Phase
Wie sich Managementverantwortung verlagerte
- Anfangs managte Charity Majors, Mitgründerin und damalige CEO, fast alle – von Executives bis zu einzelnen Engineers
- Die beiden passten in ihrer Managementphilosophie im Großen und Ganzen gut zusammen, hatten aber unterschiedliche Hintergründe und Stärken
- Charity Majors hatte tiefgehende Erfahrung in Infrastruktur, Operations, Datenbanken und Backend Engineering
- Die beförderte Person kam aus Design, Frontend und Product Engineering und arbeitete gern mit Product Management und UX Design zusammen
- Erfahrung mit Metriken und Monitoring-Technologie hatten beide, aber ihre Haltung dazu war unterschiedlich
- Charity Majors mochte diesen Bereich eher nicht
- Die beförderte Person hatte eine starke Zuneigung dazu
- Auch die Arbeitsstile unterschieden sich deutlich
- Die beförderte Person legt Wert auf Regeln und Prozesse und plant auch im Arbeitsalltag und bei Hobbys viel, inklusive Risikomanagement
- Charity Majors hat einen intuitiven und spontanen Stil, glänzt besonders in Krisensituationen, mag keine Checklisten und erkennt schnell, wenn Regeln oder Prozesse nicht hilfreich sind
- Als Honeycomb wuchs, nahm die R&D-Managementarbeit zu, und die Verantwortung wurde zunehmend entlang der Bereiche aufgeteilt, die besser zum jeweiligen Hintergrund passten
Beförderung als Summe kleiner Erweiterungen des Verantwortungsbereichs
- Auf dem Weg zum VP gab es weniger einen klaren einzelnen Meilenstein als viele kleine Schritte
- Zwischenzeitliche Titeländerungen waren im Rückblick nützliche Marker für Fortschritt, signalisierten aber meist keine große Veränderung des Aufgabenbereichs – abgesehen davon, dass oft neue Meetings hinzukamen
- In einem wachsenden Startup entstehen ständig Lücken bei Prozessen und Verantwortlichkeiten; Probleme, die zunächst wie kleine Lecks wirken, können zu Themen werden, die viel Zeit und Aufmerksamkeit verschlingen
- Es gibt immer Gelegenheiten, durch die Übernahme neuer Probleme das eigene Level zu erhöhen; ob das Unternehmen dies mit einem neuen Titel und einer neuen Rolle anerkennt, ist jedoch eine andere Frage
- Die beiden Honeycomb-Mitgründer unterstützten nicht nur bei dieser Person, sondern auch bei anderen Mitarbeitenden aktiv interne Beförderungen und die Anerkennung von Einfluss
- Bei der Suche nach einem künftigen Startup würde man nach Executives oder Gründerteams Ausschau halten, die nachweislich High Performer intern befördert haben und Personen schnell anerkennen und belohnen, die bereits über ihren formalen Rollenbereich hinaus Wirkung erzielen
Der Übergang vom Management von ICs zum Management von Manager:innen
- Der interessanteste Übergang auf der gesamten Reise war der Moment, in dem die Person nicht mehr nur ICs managte, sondern auch Manager:innen
- Wer diesen Übergang anstrebt, sollte ihn eher in einem Unternehmen versuchen, dessen Team, Technologie und Geschäftsprobleme man bereits kennt, statt in einem neuen Unternehmen
- Viele bestehende Line-Management-Fähigkeiten ließen sich übertragen, aber es dauerte, bis man lernte, die gesamte Organisation durch eine zusätzliche Managementebene hindurch effektiv zu „sehen“
- Besonders schwierig war es, die Stellen in der Organisation zu erkennen, an denen Reibung entstand oder mehr Unterstützung nötig war
- Die direkte Erfahrung mit den Menschen und Problemen der Engineering-Organisation half dabei, durchzuhalten, bis gemeinsam mit den Manager:innen Praktiken und Fähigkeiten zur Einschätzung der Teamsituation aufgebaut waren
Suche nach externen VP-Kandidat:innen und interne Beförderung
- In einer Phase, in der der Kurs des Unternehmens etwas ins Schwanken geriet, wurde auch erwogen, extern einen VP of Engineering einzustellen
- Charity Majors teilte dies offen mit und bezog die Person in den Prozess ein, geeignete Kandidat:innen zu finden und auszuwählen
- Es gab Gespräche mit mehreren herausragenden Engineering Leaders, aber einige passten damals nicht zu Honeycomb, und andere entschieden sich nicht dafür, Honeycomb als nächsten Schritt zu wählen
- Danach entstanden im Unternehmen neue Probleme, und frühere Probleme, die unlösbar gewirkt hatten, wurden leichter handhabbar
- Die Beförderung erfolgte zu diesem Zeitpunkt nicht sofort, aber die externe Suche wurde eingestellt
- Beförderungen in Leadership-Rollen ab einer gewissen Ebene sollten sich nicht an der Einzelperson, sondern daran orientieren, was das Unternehmen braucht; hilfreich war der gemeinsame Prozess, sich vorzustellen, wie ein passender VP of Engineering für Honeycomb aussehen sollte
Eigenschaften, die halfen, zur passenden Person für die Rolle zu werden
- Ganzheitliches Denken erwies sich als wichtige Eigenschaft
- Der Fokus lag ganz natürlich nicht nur auf dem Team, sondern darauf, Honeycomb als Unternehmen insgesamt erfolgreicher zu machen
- In einer Umgebung, in der Handeln zugunsten des gesamten Unternehmens statt zugunsten einer Abteilung, eines Teams oder einer Einzelperson belohnt wird, ließ sich gut arbeiten
- Auch eine Generalist:innen-Neigung half
- Fast alle Geschäftsprobleme und Domänen innerhalb eines Softwareunternehmens waren interessant
- Es machte Freude zu sehen, wie in einem Startup alle Teile ineinandergreifen
- Bei Bedarf bestand keine Scheu davor, auch unscheinbare, wenig glamouröse Arbeit zu übernehmen
- Die Person konnte auf mehreren Abstraktionsebenen arbeiten
- Auch ohne die unteren Ebenen vollständig zu verstehen, ließen sich Konzepte auf höheren Ebenen schnell erfassen
- Wenn nötig, machte es auch Spaß, bis in die Details einzusteigen
- Ein starkes Verantwortungsgefühl ist in Startups hilfreich, braucht aber auch Grenzen
- Es ist nützlich in Startups, in denen wichtige Aufgaben in funktionsübergreifende Lücken fallen
- Gleichzeitig ist kontinuierliche Anstrengung nötig, Dinge abzuschließen oder an andere zu übergeben, damit sich Arbeit nicht stapelt oder das Wachstum des Teams behindert
- Systemdenken mit Interesse sowohl an Menschen als auch an technischen Systemen gehörte ebenfalls zu den wichtigen Punkten
- Ebenso wichtig war die echte Freude daran, wenn Teammitglieder wachsen
- Energie entstand daraus, Menschen, die bereit für die nächste Stufe waren, mit wichtigen Problemen zu verbinden, die an der Grenze ihrer Fähigkeiten lagen
- Gute Beziehungen im gesamten Unternehmen waren ebenfalls nötig
- Menschen innerhalb und außerhalb des Unternehmens mussten sich mehr darauf freuen, dass diese Person die Rolle übernimmt, als darauf, auf eine externe Kandidatur zu setzen
Hilfreiche Berufserfahrung
- Erfahrung in Startups verschiedener Phasen und Größen, insbesondere in B2B-SaaS-Startups, war hilfreich
- B2C- und B2B-Startups behandeln relativ unterschiedliche Problemkategorien und haben jeweils eigene Problemlösungsmethoden entwickelt
- Es ist gut, beide Bereiche zu kennen, aber auch wertvoll, Expertise in entweder B2B oder B2C aufzubauen
- Go-to-Market-Ansätze, Organisationsstrukturen, Engineering-Probleme und Skalierungsherausforderungen können sich zwischen B2B und B2C unterscheiden
- Auch Erfahrung über den gesamten Stack hinweg half
- Die tiefste Engineering-Erfahrung lag im Bereich Frontend-Technologien
- Frühe Erfahrungen entstanden in mehreren Organisationen, in denen Pair Programming praktiziert und ein DevOps-Mindset angewandt wurde
- Durch das Lernen von Backend-, Infrastruktur-, Plattform- und Operations-Engineers entstand Verständnis dafür, wie sie denken und welche Probleme sie für wichtig halten
- Man muss nicht in allen Engineering-Bereichen Expert:in sein, aber Empathie für verschiedene Teams und ein hohes Domänenverständnis auf übergeordneter Ebene sind sehr hilfreich
- Erfahrung im Bereich Developer Tools und Monitoring passte ebenfalls zur Rolle
- Die Person arbeitete nacheinander bei drei Developer-Tools-Unternehmen
- Sie mochte das Honeycomb-Produkt aufrichtig und hatte auch für mehrere Produkte in den Bereichen Observability, Monitoring und Developer Tools große Sympathie
- Domänenwissen und Begeisterung für die Tools helfen Kolleg:innen und können in entmutigenden Situationen Energie geben
Passung durch Glück und Teamzusammensetzung
- Dass die Person zur Rolle passte, hatte auch viel mit Glück zu tun
- Es reichte nicht, komplementäre Fähigkeiten und Erfahrungen zu Charity Majors zu haben; wichtig war auch, dass die frühen Senior ICs die zentralen Engineering-Herausforderungen gut bearbeiteten
- Ein VP of Engineering mit Frontend-Hintergrund ist vergleichsweise selten, weil die dringendsten technischen Herausforderungen in Startups meist bei Skalierung, Zuverlässigkeit und Backend-Architektur liegen
- Hätten anhaltende Ausfälle, Skalierungsprobleme und große Architekturprobleme bei Query- und Storage-Engines dominiert, wäre wahrscheinlich eher jemand mit tieferer Backend- und Operations-Erfahrung gewählt worden
- Dank Ben Hartshorne, Ian Wilkes, weiteren hervorragenden ICs und soliden Designentscheidungen des Gründerteams gab es technischen Spielraum; die wichtigsten Prioritäten der damaligen Leadership lagen bei der Umsetzung der Produktstrategie und der Verbesserung der User Experience
- Im Executive Team gab es bereits extern eingestellte Führungskräfte mit viel Erfahrung in Go-to-Market-Funktionen
- Auch Christine und Charity, die als intern gewachsene Leaders gesehen werden können, hatten in früheren Unternehmen Gründer- oder Leadership-Erfahrung, und Charity war schon vor der Gründung von Honeycomb als hervorragende Managerin bekannt
- Wenn das Executive Team stärker aus neuen Executives oder intern beförderten Personen bestanden hätte, hätte es möglicherweise keinen Spielraum gegeben, noch eine weitere Führungskraft heranwachsen zu lassen
VP of Engineering hängt vom Unternehmenskontext ab
- Die wichtigste Erkenntnis ist, dass das Bild eines guten VP of Engineering kontextabhängig ist
- Früher schien es möglich, Standardmerkmale aufzulisten, die einen hervorragenden VP of Engineering ausmachen; die Annahme, dass die Grundschablone in jedem Unternehmen fast gleich sei, erwies sich jedoch als weniger zutreffend
- Die grundlegenden Aufgaben sind in den meisten Softwareunternehmen ähnlich, aber die Art von Executive, die sie führen sollte, hängt stark von den aktuellen Problemen der Organisation und von der vorhandenen Zusammensetzung aus Executives, Manager:innen und ICs ab
- Auch nach dem Einstieg in die Rolle bleiben die Anforderungen nicht fix
- In einem wachsenden Unternehmen kann sich die Rolle des VP of Engineering, wie andere Startup-Rollen auch, im Lauf der Zeit verändern
1 Kommentare
Hacker-News-Kommentare
Dieser Punkt war interessant: „Charity hat einen intuitiveren und spontaneren Stil, glänzt am meisten in Krisen und hasst Checklisten“ wirkte fast wie ein beiläufiges Eingeständnis.
Anders gesagt heißt das, dass Gründer nicht die Qualifikationen oder Eigenschaften haben, die Untergebene für nötig halten, um eine Führungsposition zu bekleiden.
Wenn man ein Unternehmen gründet, wird man automatisch CEO, CTO usw., und das galt genauso für die Gründer von Firmen, die heute Großkonzerne sind.
Gründer brauchen keine bestimmten Qualifikationen, um ihren Titel zu rechtfertigen, werden erst einmal selbst zu Führungskräften und wählen dann ihre Freunde als erste Mitarbeiter aus.
Dass Einstellungen formalisiert werden, passiert viel später, und so sehr man auch glauben möchte, eine Hierarchie sei meritokratisch, ihr Anfang war ganz eindeutig Chaos.
Hierarchisches und gehorsamsorientiertes Denken hat sich für mich immer seltsam angefühlt, und ich habe nie gedacht, dass frühere Vorgesetzte „besser“ waren als ich.
Das Erklimmen der Karriereleiter im Unternehmen ist im Kern eher Politik, und auch die endlosen Texte à la „Was ist ein Senior Engineer?“ wirken, als kämen sie aus einem korporatisierten Denken, das Hierarchien rechtfertigen will.
Mit der Zeit muss man diese Positionen aber rechtfertigen, indem man das Unternehmen nicht zugrunde richtet und erfolgreich macht.
Das ist oft eine viel ehrlichere und härtere Methode zur Leistungsmessung als jede andere Beurteilung.
Ein Großunternehmen wie Google geht nicht pleite, nur weil ein VP unfähig und faul ist, daher braucht es Bewertungssysteme.
Vergleichenswert: https://gwern.net/backstop
Ich selbst bin vollständig ausführungsorientiert, aber ich habe früh gelernt, dass die idealen Eigenschaften eines Mitgründers das Gegenteil von meinen sind, und genau dieser Unterschied zeigt sich auch hier.
Die beschriebene Person ist eine typische untypische Führungspersönlichkeit: spontan, springt von einem Thema zum nächsten und kann zerstreut sein, ist zugleich aber ein herausragender Innovator und jemand, der andere motivieren kann.
Erfolgreiche Startups brauchen sowohl untypische Persönlichkeiten als auch umsetzungsstarke Menschen.
Empfehlung: Rocket Fuel: https://www.amazon.com/Rocket-Fuel-Essential-Combination-Bus...
Er wirkte auf mich wie ein ehrliches und freundliches Eingeständnis, dass es zwei verschiedene Stile gibt, und solche Unterschiede anzuerkennen ist gesund, kein impliziter Appell an Hierarchie.
Im Gegenteil: Durch Begriffe wie „Untergebene“ und „Vorgesetzte“ sowie die Gleichsetzung von Unternehmensgründung mit der Errichtung von Hierarchie verstärkt der ganze Kommentar eher Hierarchie, obwohl er behauptet, sie infrage zu stellen.
In der Wissensindustrie sind Manager keine Leader, sondern Support-Personal.
Die besten Software-Manager und Führungskräfte wissen, dass ihre Rolle darin besteht, es den tatsächlichen Leadern und Experten, also den individuellen Contributors, leicht zu machen, ihre Arbeit zu tun.
Eine der Support-Funktionen des Managements besteht darin, solche Erwartungen durch das eigene Verhalten vorzuleben.
Wenn ein Startup an einen Großkonzern verkauft wird und sich herausstellt, dass niemand aus dem Startup-Team nach den HR-Standards dieses Konzerns eingestellt worden wäre, ist das ziemlich amüsant.
Und dann werden diese Startup-Leute plötzlich noch vor den von HR abgesegneten, hochqualifizierten Mitarbeitern des Großunternehmens befördert.
Viele Menschen sind von der amerikanischen Befehlskette in Unternehmen indoktriniert und nehmen viel zu oft an, dass jemand mit einem bestimmten Titel auch tatsächlich die passende Qualifikation dafür hat.
Titelinflation gibt es überall, und meinem Eindruck nach dienen Titel oft nicht der Anerkennung von Kompetenz, sondern eher als Mittel für Gehaltserhöhungen und als Anerkennung von Betriebszugehörigkeit.
Ich wollte das übrigens nicht nur auf die USA beschränken.
Meiner Erfahrung nach ist es sehr selten, dass man gezielt nach Fällen interner Beförderung schaut.
In den meisten Startups ist die Standardeinstellung bei einer neuen Hierarchiestufe oder wenn durch den Weggang einer Person eine Stelle frei wird, externe Einstellung.
Die Logik scheint zu sein, dass man besser nichts anrührt, solange alle ihre nötige Arbeit gut machen, aber ehrlich gesagt ist das extrem demotivierend.
Es ist viel frustrierender, als wenn ein Kollege befördert wird und ich übergangen werde, weil man bei einer Kultur von Beförderung und Wachstum wenigstens glauben kann, dass man beim nächsten Mal eine faire Chance hat.
Wenn aber immer extern eingestellt wird, bleibt meine Karriere in dieser Firma genau auf der Stufe stehen, auf der ich eingetreten bin.
Die Logik scheint eher darin zu bestehen, kluge Menschen, die mehr leisten können als ihr Titel vermuten lässt, so günstig wie möglich zu halten.
Ein Jobwechsel hat auf Mitarbeiterseite reale Kosten, und je schlechter die Konjunktur, desto höher sind sie.
Trotzdem gehen manche, manche machen stillschweigend nur noch das Nötigste, und manche halten einfach durch.
Meiner Erfahrung nach weigern sie sich oft, sich anzupassen, und gehen dann entweder selbst oder werden entlassen.
Nur weil man ein Team von 10 Leuten führen kann, heißt das nicht, dass man auch eine Organisation mit 100 oder gar 1000 Leuten führen kann.
Ich sage nicht, dass das hier zwingend der Fall ist, aber in manchen Fällen ist es ein legitimer Grund, das Peter-Prinzip zu vermeiden.
Denn befördert werden dann Menschen, die diese Defizite ertragen haben oder sie gar nicht erst bemerkt haben.
Wenn dann doch einmal jemand extern eingestellt wird, der genug Erfahrung hat, um solche Defizite zu erkennen, dürfte diese Person es ziemlich schwer haben.
Der Großteil der obersten Führungsebene ist intern aufgestiegen, manchmal sogar vom Individual Contributor bis zum VP, und man merkt den Effekt davon.
Wenn jemand dazukommt, der diese Größenordnung schon in mehreren Organisationen erlebt hat, wäre das für die Organisation sicherlich hilfreich.
Es war schwer zu erkennen, was die Person tatsächlich gemacht hat und was sie jetzt in der VP-Rolle macht.
Es gibt viele wohlklingende Aussagen, aber wofür der Großteil des Tages aktuell draufgeht, bleibt unklar.
Auch die Formulierung „aus Design, Frontend und Product Engineering kommend“ liefert nicht viele Informationen.
Ich bin genau so jemand, der alles von Skizzen über Figma-Layouts bis zum SvelteKit-Frontend und der Middleware sowie dem Aufbau von FastAPI-APIs macht, aber ich verstehe nicht, was diese Person so gut konnte, dass sie VP wurde, und was sie jetzt fern der praktischen Arbeit macht oder am meisten vermisst.
Der Text ist enorm lang, aber ich verstehe nicht recht, was er sagen will.
Wer sehen will, welche Rolle heute in kleineren Firmen als FAANG erwartet wird und wie der Pfad aussieht, auf dem Engineers in die Management-Laufbahn aufsteigen, sollte sich „The Manager's Path“ ansehen.
Je weiter man in Richtung Executive Leadership geht, desto strategischer wird die Arbeit und desto seltener setzt man selbst direkt um — das dachte ich jedenfalls. Im Text werden aber viele taktische Erfahrungen und Eigenschaften aufgezählt, die die Person angeblich zu einem guten VP machen.
Als armer Mensch am Rand der Tech-Welt habe ich viele Fälle gesehen, in denen Leute im Unternehmen gezwungen wurden, irgendetwas zu schreiben, und es sah immer genau so aus.
Für Campus-Recruiting werden Leute in der Firma dazu gebracht, ein oder zwei solche Texte zu schreiben, damit in den Suchergebnissen aktuelle Beiträge erscheinen.
So erfüllt der Text gleichzeitig zwei Zwecke: angemessenes Einschmeicheln und potenzielle Bewerber aufwerten.
https://www.honeycomb.io/blog/becoming-vp-of-engineering-pt2
Dieser Text ist im Grunde ein Beispiel für Survivorship Bias und dessen Rationalisierung.
Was fehlt, ist die statistische Perspektive auf interne Wechsel in eine VP-Position versus externe Einstellungen.
Ob Startup oder Großkonzern: Ich halte es für extrem schwer, intern in eine VP-Rolle zu kommen.
Ein Startup muss erfolgreich sein, und in einem Großunternehmen muss man jahrelang durchhalten und gute politische Beziehungen aufbauen.
Der einfachste Weg ist, nicht zu glauben, man beginne ganz unten, sondern früh im Leben auf hohe Rollen zu zielen und konsequent in diese Richtung zu gehen.
Wenn man es im bestehenden Unternehmen nicht an die Spitze schafft, kann man die Spitze auch selbst aufbauen.
Wer ganz unten anfängt, bleibt dort, weil diese Fähigkeiten in den obersten Führungsrollen keinen Wert haben.
Er hat es versucht, aber letztlich ist nichts daraus geworden, und eine Wertung gab es auch nicht.
Es sieht eher so aus, als hätte man keinen großartigen Kandidaten gefunden und die Autorin oder den Autor dann am Ende befördert.
Auch in meinem vorherigen Startup hat man nach einem VP gesucht und am Ende intern befördert; statistisch gesehen passiert so etwas offensichtlich zumindest manchmal.
Die Autorin oder der Autor würde dem letzten Satz „Wer ganz unten anfängt, bleibt dort“ vermutlich nicht zustimmen.
Es heißt dort, dass die Firmeninfrastruktur auch während der Skalierung stabil blieb, weil die „Leute ganz unten“ ihre Arbeit gut gemacht haben, und dass dadurch Raum entstand, mehr über Strategie nachzudenken.
Es scheint weniger um oben und unten zu gehen als darum, welche Art von Problemen man gut löst.
Wenn man Planung, Management und Strategie mag, sollte man Rollen anstreben, in denen man diese Fähigkeiten einsetzen kann — ganz oben, in der Mitte oder unten.
Wenn man zum Beispiel wirklich herausragen will, darf man es sich nicht auf einem JavaScript-Posten bequem machen, sondern muss sich selbst in wettbewerbsintensivere Bereiche drängen; und wenn man ein wirklich guter Programmierer werden will, muss man in OCaml verfluchten Code schreiben.
Aus der Sicht eines CTO eines venture-finanzierten Startups gilt: Leute in hohen Positionen sind meistens klug, und ich zähle Verschlagenheit zur gleichen Kategorie.
Es gibt aber viele ebenso kluge Menschen, die keine hohen Positionen haben, weil ihnen die Gelegenheit gefehlt hat.
Wenn man selbst ein Unternehmen gründet, verbessern sich die Chancen; niemand gründet zwar, um VP in einem anderen Unternehmen zu werden, aber es ist ein guter alternativer Weg.
Oder man braucht Networking mit den richtigen Leuten, was meistens mit dem eben genannten Gründungsweg einhergeht.
Man kann auch bei einer bekannten Firma wie Google arbeiten und dann zu einem kleineren Unternehmen wechseln, um dort der große Fisch zu sein.
Oder man muss dem eigenen Chef und dessen Chef auffallen, damit man der nächste Kandidat ist, wenn die direkte Führungskraft zurücktritt.
Eine Sache, die ich gelernt habe: Wenn man sieht, dass ein Unternehmen Führungskräfte aus anderen Gründen als Kompetenz befördert oder einstellt, dann ist es Zeit, sich nach einem neuen Job umzusehen.
Im Vorstellungsgespräch wusste ich es nicht, aber in meinem früheren Unternehmen waren die Positionen ab VP aufwärts fast vollständig von Leuten besetzt, die Verbindungen zum CEO hatten, unabhängig von ihrer Qualifikation.
Es gab zwar ein paar Menschen, die aufgrund ihrer Leistung befördert worden waren oder im Zuge einer Übernahme ganz natürlich aufgestiegen waren, aber mit der Zeit wurden sie konsequent ersetzt oder herabgestuft, um Platz für Freunde und sogar Familienmitglieder der C-Level-Führungskräfte zu machen.
Eine C-Level-Führungskraft, mit der die Zusammenarbeit angenehm war, wurde zum VP degradiert, und ein langjähriger Freund des CEO bekam die C-Level-Position.
Die herabgestufte Führungskraft hatte jahrelang Karriere bei den besten Unternehmen der Branche gemacht und war für diese Rolle sogar mit der Familie quer durchs Land umgezogen, aber der Nachfolger hatte überhaupt keine Erfahrung in dieser Branche.
Dieser VP wurde gebeten zu bleiben, damit der langjährige Freund des CEO die Arbeit lernen und übernehmen konnte, und man „erlaubte“ ihm, seine Aktienoptionen zu behalten.
Das hat mir die Augen dafür geöffnet, wie Nepotismus und Loyalität in manchen Unternehmen funktionieren.
Dieses Zitat ist mir besonders ins Auge gefallen
Die Stelle, dass VPs of Engineering mit Frontend-Hintergrund vergleichsweise selten sind, weil die dringendsten technischen Probleme in Startups meist bei Skalierbarkeit, Zuverlässigkeit und Backend-Architektur liegen
Ich habe früher in Unternehmen gearbeitet, in denen Frontend geringgeschätzt wurde, weil die Führungskräfte alle aus dem Backend- oder Infrastruktur-Bereich kamen, und ich habe Fälle gesehen, in denen die Codequalität dieser Backend-Entwickler ziemlich katastrophal war
Ich frage mich, ob es eine negative Korrelation zwischen Repräsentation in Führungspositionen und Engineering-Talent gibt
Ich bin jemand, der vom Frontend Engineer zum Tech Lead geworden ist, und ich denke, Entwickler setzen je nach persönlicher Veranlagung und den Werten, die ihnen wichtig sind, unterschiedliche Schwerpunkte
Menschen, die sich für Frontend entscheiden, und Backend-Entwickler haben meist unterschiedliche Neigungen
Was ist katastrophaler Code
Ist das Format inkonsistent oder nicht hübsch, sind Variablennamen nicht aussagekräftig, ist der Code nicht schön aufgeteilt oder strukturiert
Ich habe das Gefühl, dass Frontend-Entwickler Code eher nach oberflächlichen Werten beurteilen
Gerade in stark engineeringgetriebenen Organisationen bekommt man Anerkennung, indem man Probleme löst
Viele Teams funktionieren auch ohne eine zentrale Frontend-Person noch gut genug, aber ohne einen starken Infrastruktur- oder Backend-Engineer, oder erst recht mehrere davon, geraten sie oft ins Wanken
Das ist die Realität
Frontend-Entwicklung wird oft weiblich codiert und als weniger wichtig angesehen
Zum Beispiel: https://thoughtbot.com/blog/tailwind-and-the-femininity-of-c...
In der Tech-Branche gibt es auch die Tendenz, Führung mit männlich codierten Eigenschaften zu verknüpfen
Deshalb ist es überhaupt nicht überraschend, dass Führung und ein Frontend-Hintergrund als irgendwie unpassend wahrgenommen werden
Dieselben Gender-Dynamiken spielen auch beim Code eine Rolle
Für mich gehört zu gutem Code auch Code, der für andere gut ist und gute Zusammenarbeit ermöglicht
Aber wenn man sich machohaft wie ein Alpha-Nerd-Techbro geben will, kann man allein Cowboy-Coding betreiben und dabei seine Genialität zur Schau stellen
Dann ist das Ziel nicht, eng als Team zusammenzuarbeiten und gemeinsam etwas zu bauen, sondern vor dem Management als erstaunlicher individueller Top-Beitragender aufzufallen
VP of Engineering ist keine Rolle, die man unternehmensübergreifend standardisiert vergleichen könnte
In meinem jetzigen Unternehmen verantworten Directors oft Organisationen mit bis zu 500 Personen, und VPs normalerweise 1000 oder mehr, manchmal 3000 bis 5000
Einen Startup-VP mit einer 50-köpfigen Organisation mit einem FAANG-VP für eine Organisation mit über 1000 Leuten gleichzusetzen, ergibt keinen Sinn
Es geht nicht darum, dass eines besser wäre, sondern darum, dass die benötigten Fähigkeiten klar unterschiedlich sind
Ich habe tatsächlich erlebt, dass Leute, die in kleinen Unternehmen den VP-Titel bekommen hatten, diesen Unterschied nicht verstanden, sich bei FAANG bewarben und dann schockiert waren, als ihnen eine Manager- oder Senior-Manager-Rolle angeboten wurde
Das ergab überhaupt keinen Sinn
Meiner Erfahrung nach hatte dieser VP, gemessen an großen Organisationen, Erfahrung auf Praktikanten-Niveau, war aber eben früh eingestiegen
Der Director war noch schlimmer, und die zwei Leute, die an sie berichteten, waren kompetent
Ich wünschte, die Leute bei Honeycomb würden statt Blogposts zu schreiben etwas Zeit darauf verwenden, das Produkt sichtbar zu verbessern
Ich hatte das Pech, Honeycomb in einem Unternehmen benutzen zu müssen, und in Systemen, die mit mehr als ein paar Services interagieren, war es einfach nicht nutzbar
Ich verstehe nicht, warum dieses Unternehmen so überzogene Erwartungen auf sich zieht
Ich lese diesen Beitrag mit dem Bewusstsein, dass ein VP bei Honeycomb eher einem Senior Manager in einem großen Tech-Unternehmen entspricht
Nach Maßstäben großer Unternehmen entspricht das einem Director
Meiner Erfahrung nach bauen Individual Contributors Produkte, Manager bauen Menschen auf, Directors bauen Prozesse, und VPs schaffen Richtlinien
Alle darüber sind nur noch eine Station zur Genehmigung von Budgetanträgen
Falls man Richtlinien und Strategie nicht als dasselbe ansieht
Wenn das ein subtiler Witz darüber sein soll, dass niemand Strategie macht, dann ist es ein guter Witz