Modernes Staff Engineering in Startups

xguru · 2024-12-17T11:11:01+09:00

Vorstellung eines Praxisbeispiels dafür, wie sich die Konzepte DevOps, Staff Engineering und Platform Engineering in einem Startup-Umfeld wirksam anwenden lassen Der Sprecher Chad McElligott ist Senior Staff Engineer bei Smartrr, einem Unternehmen, das Shopify-basierte Abo- und Loyalty-Services anbietet Vorschlag einer Engineering-Methodik, die auf die besondere Kultur und die Anforderungen von Startups zugeschnitten ist [Schlüsselkonzepte] DevOps Die Definition von DevOps unterscheidet sich von Person zu Person; für manche ist es eine Stellenbezeichnung, für andere eine Arbeitsweise Das Konzept „DevOps as No Ops“ führt dazu, dass Software Engineers sämtliche Ops-bezogenen Aufgaben selbst übernehmen DevOps bedeutet, durch eine kollaborative Denkweise, die Automatisierung wiederkehrender und manueller Arbeit ( toil ) sowie den Einsatz moderner Tools schnell Mehrwert für Kund:innen zu liefern Entscheidend sind nicht nur technische Elemente wie Cloud-Nutzung, Infrastructure as Code und der Aufbau von CI/CD-Pipelines, sondern auch das Einreißen von Kommunikations- und Kollaborationsbarrieren, um bessere Ergebnisse zu erzielen Platform Engineering Platform Engineering ist ein technischer Ansatz zur Verringerung der kognitiven Belastung von Entwickler:innen Ziel ist es, zugleich die Geschwindigkeit der Produktentwicklung und die Stabilität von Systemen zu erhöhen, indem grundlegende Bausteine bereitgestellt werden, die die Arbeit von Entwickler:innen unterstützen Es gibt immer mehr Beispiele dafür, dass große Unternehmen Platform-Engineering-Teams aufbauen, um die Effizienz zu steigern und die Developer Experience zu verbessern Popularisiert wurde der Begriff durch das Buch Team Topologies von Manuel Pais und Matthew Skelton; Beispiele zur Stärkung von Engineering-Fähigkeiten finden sich in vielen verschiedenen Medien Staff Engineering Staff Engineering ist keine bestimmte Denkweise oder Technik, sondern eine Rolle, die Software Engineers innerhalb einer Organisation übernehmen Es ist eine Karrierestufe nach dem Senior Software Engineer und lässt sich auch als Servant Leadership im Software Engineering beschreiben Staff+-Engineers erweitern ihre Verantwortung über die eigene Arbeit hinaus auf die gesamte Organisation und arbeiten mit Managern oder VPs zusammen, um praktische Umsetzung und Perspektive einzubringen In Will Larsons Buch Staff Engineer wird die Staff-Rolle anhand von vier Archetypen beschrieben: Architect, Right Hand, Tech Lead und Fixer [Startup-Kultur] Venture-finanzierte Startups geben für Wachstum häufig mehr aus, als sie an Umsatz erzielen Das durch Investitionen beschaffte Kapital wird als „Runway“ genutzt, um schnelles Wachstum anzustreben; bevor die Runway aufgebraucht ist, müssen Wachstum und Profitabilität erreicht werden Dieses Umfeld schafft zwei zentrale kulturelle Eigenschaften Es gibt keine Zeit zu verschwenden Zeitverschwendung ist in Startups besonders fatal Entwicklungsteams müssen sich auf die strategischen Ziele der Organisation konzentrieren und innerhalb der verfügbaren Runway liefern Jedes Teammitglied sollte regelmäßig prüfen, ob die eigenen Aktivitäten mit den Zielen übereinstimmen, und sie bei Bedarf neu ausrichten Selbst wenn ein Experiment scheitert, ist es keine Verschwendung, solange es einen Rahmen für Lernen gibt und die gewünschten Erkenntnisse gewonnen wurden Alle übernehmen mehrere Rollen In kleinen Organisationen gibt es viel zu tun, aber zu wenige Menschen, die es erledigen können So kann etwa ein Frontend-Entwickler zugleich Produktdesigner, Technical Writer, Produktmanager, QA-Verantwortlicher oder Zuständiger für Third-Party-Integrationen sein Wenn eine neue Idee zur Verbesserung der Customer Experience entsteht, kann die Person, die sie vorgeschlagen hat, auch selbst die Verantwortung dafür übernehmen, einen Prototyp zu bauen oder sie umzusetzen Diese kulturellen Merkmale bestimmen, welche Fähigkeiten Produktentwicklungsgruppen und insbesondere Führungskräfte im Software Engineering brauchen Sie geben außerdem Hinweise darauf, wie sich DevOps, Platform Engineering und Staff Engineering an ein Startup-Umfeld anpassen müssen [Meine Engineering-Prinzipien (Tenets) auf die Startup-Kultur anwenden] DevOps in Startups In Startups ist es leicht, Prozesse zu verändern. Weil es nur wenige Personen gibt, bestehen kaum große Hürden, neue Verhaltensweisen einzuführen Die besten Ergebnisse erzielt man, wenn Prozesse an Tools angepasst werden Wenn starre Prozesse beibehalten werden, muss man Tools anpassen oder zusätzliche Software entwickeln, was Zeit verschwendet Custom-Tools sollten nach Möglichkeit vermieden werden Empfehlenswert ist der Einsatz von serverloser Infrastruktur, SaaS-Tools und Open-Source-Bibliotheken Man sollte sich am allgemeinen Fluss der Technologie orientieren und Technologien nicht anpassen, wenn sie keinen differenzierenden Wettbewerbsvorteil liefern Siehe dazu: Martin Fowlers Utility vs Strategic Dichotomy Man sollte sich für „langweilige Technologien“ entscheiden Das Team sollte keine großen Risiken auf Lösungen setzen, mit denen es nicht vertraut ist oder für die es kaum Community-Unterstützung gibt Bei Problemen sollte man Technologien wählen, für die sich online leicht Lösungen finden lassen Einen Vortrag, der diese Idee genauer erklärt, gibt es bei Dan McKinleys boringtechnology.club Platform Engineering in Startups Erwähnung aus Rebecca Murpheys Engineering Unblocked podcast: „Die Developer Experience eines Unternehmens ist ein Produkt, egal ob sie bewusst gestaltet wurde oder nicht“ Auch in der Größe eines Startups braucht man weiterhin Monitoring, Deployments, Error Tracking, Log-Einsicht und das Umschalten von Feature Flags Die wichtige Frage lautet: „Sind diese Aufgaben schmerzhaft?“ Platform Engineering ist in Startups eine Teilzeitrolle Anfangs kann eine integrierte Testumgebung nötig sein, später kann sie jedoch in der Priorität zurückfallen Die Platform-Engineering-Rolle wird nur dann wahrgenommen, wenn sie gebraucht wird Es gibt keinen Spielraum für langfristige Plattformprojekte Stattdessen müssen wertvolle Elemente in kleinen Arbeitseinheiten umgesetzt werden Wichtig ist, das große Bild und die Vision mit dem Team zu teilen und verständlich zu machen, wie die kleinen Teile zusammenhängen Plattformarbeit in Startups bedeutet, neue Produktivität und neue Herangehensweisen zu erschließen Meist geht es nicht um den Wechsel von bestehender Software zu modernen Tools, sondern darum, etwas völlig Neues aufzubauen, das vorher gar nicht existierte Wichtiger als die Frage, was möglich ist, ist die Frage, was getan werden sollte Man sollte sich auf Arbeit konzentrieren, die aktuelle Probleme der Organisation oder Probleme in naher Zukunft löst Welche Arbeit nötig ist, sollte über Praxiserfahrung, Gespräche mit Engineers, Feedback aus Retrospektiven und die Analyse von SDLC-Metriken (Software Development Life Cycle) ermittelt werden Manchmal ist es besser, Plattformarbeit zurückzustellen und sich auf andere Anforderungen zu konzentrieren Ein flexibler Ansatz ist entscheidend Staff Engineering in Startups Die Rolle des Staff Engineer passt gut in ein Startup-Umfeld Tiefe technische Expertise, der Wunsch nach breitem Einfluss und die Bereitschaft, dort einzuspringen, wo es nötig ist, um Geschäftsprobleme zu lösen, passen gut zu Startups In großen Organisationen sagt man oft: „Man weiß, wo der technische Schuldenberg vergraben ist“ Ein Staff Engineer findet die Menschen mit diesem Wissen, ordnet es und leitet daraus Entscheidungen für den weiteren Weg ab In Startups liegen technische Schulden und Probleme offen sichtbar zutage Ein Staff Engineer kann großen Einfluss haben, indem er dieses Chaos ordnet und Lösungen aufbaut, die der Organisation langfristig helfen In Startups kann ein Staff Engineer nicht bei nur einem Archetyp bleiben Weil die Organisation klein ist, muss er verschiedenste Aufgaben übernehmen, einschließlich direkter Umsetzung Neben Architekturdesign, Projektleitung und taktischer Arbeit muss er auch eigenständig Verbesserungsideen entwickeln und umsetzen Flexibilität und proaktive Verantwortungsübernahme sind für Staff+-Engineers in Startups unverzichtbare Eigenschaften Eine wichtige Aufgabe von Staff+-Engineers ist Mentoring und Sponsorship Das ist besonders wertvolle Unterstützung und Orientierung für Junior-Talente in Startups Staff Engineers fördern durch diese Unterstützung das Wachstum des Teams und stärken die Fähigkeiten der Organisation [Modernes Staff Engineering in Startups anwenden] Story 1 von 2 - "Improving DevEx by Removing a Merge Freeze" Problemsituation Bisheriger QA-Prozess: Vor einem Release wurde für 2–3 Tage ein "merge freeze" verhängt, während das QA-Team manuelle Regressionstests durchführte Gefundene Bugs wurden sofort behoben und in den main-Branch gemergt Entwickler erstellten neue Patches, mussten ihre Merge Requests aber bis nach dem Release zurückstellen Nachteile: Manuelle Regressionstests sind langsam und unvorhersehbar Durch Merge-Verzögerungen treten häufiger merge conflicts auf Produktivität und Zusammenarbeit der Entwickler werden beeinträchtigt Lösungsansatz Infrastruktur-Code in ein Monorepo integrieren Terraform-Projekte wurden in dasselbe Repository wie der Anwendungscode integriert An automatisierte Linting- und Dependency-Management-Tools angebunden, damit Entwickler einfacher mit der Infrastruktur arbeiten können Alle Umgebungen mit Terraform verwalten Nicht nur neue Umgebungen, sondern auch bestehende Staging- und Produktionsumgebungen werden mit Terraform verwaltet Konsistenz zwischen Umgebungen durch dieselben Infrastrukturdefinitionen mit unterschiedlichen Variablen CI/CD-Prozess vereinfachen Die bisherigen GitLab Auto DevOps Templates waren durch viele Anpassungen komplex geworden Auto DevOps entfernt und eine neue .gitlab-ci.yml klar definiert Die meisten Befehle in ein Makefile verschoben, sodass sie auch manuell ausgeführt werden können Secrets-Management verbessern Anwendungsecrets in den Google Cloud Secrets Manager verschoben, um die Kopplung an GitLab zu reduzieren Deployment-Skripte so angepasst, dass Kubernetes ConfigMaps automatisch aktualisiert werden Nicht im Umfang enthaltene Arbeiten Die Anwendung läuft als Monolith auf Kubernetes Daran wurde nichts geändert, da dies Verzögerungen und Risiken verursacht hätte Es wurde keine Terraform-Automatisierungspipeline aufgebaut Da Infrastrukturänderungen relativ selten sind, blieb der manuelle Prozess bestehen Ein Kubernetes-nativer Ansatz für den Zugriff auf Secrets wurde ebenfalls zurückgestellt Ergebnisse und Wirkung Eine neue Testumgebung wurde bereitgestellt, sodass das QA-Team Regressionstests eigenständig durchführen kann Durch die Abschaffung des merge freeze können Entwickler Änderungen frei in den main-Branch mergen Der Release-Prozess wurde vereinfacht und das Team insgesamt schneller Angewandte Prinzipien Staff-Engineering-Prinzipien Zusammenarbeit mit verschiedenen Teams und Leitung des Projekts Die Rolle des "Tech Lead" übernommen und das Projekt zum Abschluss geführt Durch Verbesserungen bei CI/CD und Infrastruktur das Verständnis und die Zugänglichkeit für das Team erhöht Platform-Engineering-Prinzipien Ein DevOps-Projekt zu einem Plattformprojekt erweitert Die gesamte Infrastruktur als Code verwaltet, um Konsistenz zwischen Umgebungen sicherzustellen Den Projektumfang durch realistische Trade-offs angepasst DevOps-Prinzipien Infrastruktur als Code verwaltet, um Cloud-Infrastruktur konsistent zu betreiben Den Release-Prozess verbessert und mit neuen Tools die Entwicklungsgeschwindigkeit erhöht Das RFC-Format (Request For Comment) eingeführt, um Entscheidungsprozesse inklusiver zu machen Fazit Das QA-Team kann nun automatisierte Tests in einer stabileren Umgebung ausführen Entwickler können ohne merge freeze kontinuierlich weiterentwickeln, was die Zusammenarbeit verbessert hat Bessere Tooling- und Prozessstrukturen haben die Produktivität der Organisation erhöht Künftig sollen zusätzliche Arbeiten wie der Aufbau von Preview-Umgebungen oder die Automatisierung von Regressionstests folgen Story 2 von 2 - "Iterating Towards a Productive Engineering Process" Problemsituation Bisheriger Prozess: Alle Teammitglieder arbeiteten in einem einzigen Board und teilten täglich ihren Fortschritt Viele waren nicht fokussiert und innerlich bereits "ausgecheckt", wenn sie nicht gerade an der Reihe waren Die Verantwortung für Feature-Entwicklung war verteilt, sodass oft der Product Manager die letzte Verantwortung trug Es fehlte zudem ein klares Verständnis der technischen Architektur Ziel: Verschiedene Experimente durchführen, um bessere Zusammenarbeit und einen besseren Softwareentwicklungsprozess aufzubauen Experiment 1: Kurzlebige Feature-Teams (Short-lived Feature Teams) Ziel: Engineers Verantwortung für den gesamten Lebenszyklus der Feature-Entwicklung geben Vorgehen: Für jedes Feature wurde ein Lead benannt und ein Team aus Backend, Frontend, QA usw. zusammengestellt Ergebnis: Das Verantwortungsgefühl der Teammitglieder verbesserte sich, aber nicht alle waren für die Lead-Rolle geeignet oder wollten sie übernehmen Danach erfolgte der Wechsel zu einem "Fixed Team Model" mit "Squads", in denen jedes Team Planung und Retrospektiven eigenständig durchführt Experiment 2: Epic Kickoff Documents Ziel: Anforderungen klarer machen und im Team Einigkeit über Projektumfang und Vorgehensweise herstellen Vorgehen: Mit der bereitgestellten Vorlage erstellten alle Teammitglieder das Dokument gemeinsam im Meeting Ergebnis: Die Teamkommunikation verbesserte sich, und die Zusammenarbeit begann schon früh im Projekt deutlich besser Die Teammitglieder bewerteten dieses Meeting als wertvoll investierte Zeit Experiment 3: Gruppen-Code-Review (Group Code Review) Ziel: Zeit für Code Reviews verkürzen, Codediskussionen fördern und technisches Wissen zwischen Engineers teilen Vorgehen: Zweimal pro Woche wurde in einem Slack Huddle eine einstündige Code-Review-Session durchgeführt Entwickler teilten ihren Bildschirm, erklärten ihre PRs und die Teilnehmenden gaben Feedback Ergebnis: Die Zeit für Code Reviews wurde deutlich reduziert, und Inbox 0 konnte beibehalten werden Durch Diskussionen über den Code entstand eine Kultur, in der Entwickler voneinander lernen und einander respektieren Neben Code Reviews wurden dem Team auch die Vorteile von Pair Programming nähergebracht Angewandte Prinzipien Staff-Engineering-Prinzipien Bei Abwesenheit eines Engineering Managers Verbesserungen am Prozess angeführt Eine Kultur kontinuierlicher Verbesserung eingeführt und durch agile Prozesse selbstorganisierte Zusammenarbeit gestärkt Das Team dabei unterstützt, festgefahrene Prozesse aufzubrechen und bessere Wege zu finden Platform-Engineering-Prinzipien Nicht nur Tools, sondern auch Prozesse als Teil der Plattform betrachtet Ineffiziente Prozesse beeinträchtigen die Produktivität des Teams, daher ist ihre Verbesserung wichtig Prozessänderungen zur Beseitigung von Verschwendung können ähnlich große Wirkung haben wie Tool-Verbesserungen DevOps-Prinzipien CALMS-Prinzipien: Collaboration, Automation, Lean, Measurement, Sharing Mit Lean-Prozessen Verschwendung beseitigt und Wert schneller geliefert Das Team darin geschult, sich durch agile Prozesse kontinuierlich zu verbessern Fazit Durch experimentelle Verbesserungen der Teamprozesse wurden Produktivität und Zusammenarbeit deutlich gesteigert Kostengünstige, hocheffiziente Verbesserungen haben die Developer Experience des gesamten Teams verbessert Es wird nachdrücklich empfohlen, die eigenen Prozesse kritisch zu prüfen und nach Verbesserungspotenzial zu suchen [Abschluss] Bei der Arbeit im Startup-Umfeld kann man sowohl Fachkompetenz als auch Leidenschaft voll einbringen, um verschiedenste Probleme zu lösen und Lösungen umzusetzen Da es zeitliche Einschränkungen gibt, ist es eine gute Gelegenheit, einen pragmatischen Ansatz zu entwickeln, und man kann in der frühen Unternehmensphase großen Einfluss ausüben Durch die Anwendung moderner Software-Engineering-Ansätze kann man die Grundlage für den Erfolg des Unternehmens schaffen Staff Engineering und Startups Für einen Staff Engineer ist Erfahrung mit sowohl Breite als auch Tiefe erforderlich Startups bieten Staff+-Ingenieuren die Möglichkeit, ihr technisches Wissen zu erweitern und neue Bereiche zu erkunden Beispiel: Ein Backend-Ingenieur kann Technologien wie React oder BigQuery lernen Platform Engineering und Startups Platform Engineering in Startups unterscheidet sich je nach Größe Durch 1:1-Kommunikation lassen sich die Pain Points der Entwickler erkennen, und mit kleinen Projekten kann die Developer Experience (DevEx) verbessert werden Es gilt, schnelle Feedback-Loops aufzubauen, um den Entwicklungsprozess zu verbessern und Entwicklern zu helfen, Probleme künftig selbst zu lösen Es ist wichtig, die Grundlagen des Software Development Lifecycle (SDLC) mit branchenüblichen Tools und Methoden abzudecken In Startups ist Platform Engineering keine dedizierte Aufgabe, sondern ein technischer Ansatz, der je nach Bedarf angewendet wird Man sollte im Hinterkopf behalten, dass die „Developer Experience eines Unternehmens ein Produkt ist“, und Zeit in deren Gestaltung investieren DevOps und Startups DevOps spielt auch in Startups eine sehr wichtige Rolle Im Kern geht es darum, durch Kultur, Prozesse und Tools Kunden schneller Mehrwert zu liefern und ein besseres Arbeitsumfeld zu schaffen Über DevOps die Effizienz des Unternehmens zu steigern und eine Kultur der Zusammenarbeit zu etablieren, ist ein sehr lohnender Prozess Ingenieure mit Leidenschaft für DevOps können in Startups mit ihren Fähigkeiten und Erfahrungen einen großen Beitrag leisten Das Startup-Umfeld ist voller neuer Herausforderungen und Lernmöglichkeiten; dadurch können Ingenieure weiter wachsen und bedeutungsvolle Ergebnisse erzielen

(chadxz.dev)

47 Punkte von xguru 2024-12-17 | 3 Kommentare | Auf WhatsApp teilen

Vorstellung eines Praxisbeispiels dafür, wie sich die Konzepte DevOps, Staff Engineering und Platform Engineering in einem Startup-Umfeld wirksam anwenden lassen
Der Sprecher Chad McElligott ist Senior Staff Engineer bei Smartrr, einem Unternehmen, das Shopify-basierte Abo- und Loyalty-Services anbietet
Vorschlag einer Engineering-Methodik, die auf die besondere Kultur und die Anforderungen von Startups zugeschnitten ist

[Schlüsselkonzepte]

DevOps

Die Definition von DevOps unterscheidet sich von Person zu Person; für manche ist es eine Stellenbezeichnung, für andere eine Arbeitsweise
Das Konzept „DevOps as No Ops“ führt dazu, dass Software Engineers sämtliche Ops-bezogenen Aufgaben selbst übernehmen
DevOps bedeutet, durch eine kollaborative Denkweise, die Automatisierung wiederkehrender und manueller Arbeit ( toil ) sowie den Einsatz moderner Tools schnell Mehrwert für Kund:innen zu liefern
Entscheidend sind nicht nur technische Elemente wie Cloud-Nutzung, Infrastructure as Code und der Aufbau von CI/CD-Pipelines, sondern auch das Einreißen von Kommunikations- und Kollaborationsbarrieren, um bessere Ergebnisse zu erzielen

Platform Engineering

Platform Engineering ist ein technischer Ansatz zur Verringerung der kognitiven Belastung von Entwickler:innen
Ziel ist es, zugleich die Geschwindigkeit der Produktentwicklung und die Stabilität von Systemen zu erhöhen, indem grundlegende Bausteine bereitgestellt werden, die die Arbeit von Entwickler:innen unterstützen
Es gibt immer mehr Beispiele dafür, dass große Unternehmen Platform-Engineering-Teams aufbauen, um die Effizienz zu steigern und die Developer Experience zu verbessern
Popularisiert wurde der Begriff durch das Buch Team Topologies von Manuel Pais und Matthew Skelton; Beispiele zur Stärkung von Engineering-Fähigkeiten finden sich in vielen verschiedenen Medien

Staff Engineering

Staff Engineering ist keine bestimmte Denkweise oder Technik, sondern eine Rolle, die Software Engineers innerhalb einer Organisation übernehmen
Es ist eine Karrierestufe nach dem Senior Software Engineer und lässt sich auch als Servant Leadership im Software Engineering beschreiben
Staff+-Engineers erweitern ihre Verantwortung über die eigene Arbeit hinaus auf die gesamte Organisation und arbeiten mit Managern oder VPs zusammen, um praktische Umsetzung und Perspektive einzubringen
In Will Larsons Buch Staff Engineer wird die Staff-Rolle anhand von vier Archetypen beschrieben: Architect, Right Hand, Tech Lead und Fixer

[Startup-Kultur]

Venture-finanzierte Startups geben für Wachstum häufig mehr aus, als sie an Umsatz erzielen
Das durch Investitionen beschaffte Kapital wird als „Runway“ genutzt, um schnelles Wachstum anzustreben; bevor die Runway aufgebraucht ist, müssen Wachstum und Profitabilität erreicht werden
Dieses Umfeld schafft zwei zentrale kulturelle Eigenschaften
- Es gibt keine Zeit zu verschwenden
  - Zeitverschwendung ist in Startups besonders fatal
  - Entwicklungsteams müssen sich auf die strategischen Ziele der Organisation konzentrieren und innerhalb der verfügbaren Runway liefern
  - Jedes Teammitglied sollte regelmäßig prüfen, ob die eigenen Aktivitäten mit den Zielen übereinstimmen, und sie bei Bedarf neu ausrichten
  - Selbst wenn ein Experiment scheitert, ist es keine Verschwendung, solange es einen Rahmen für Lernen gibt und die gewünschten Erkenntnisse gewonnen wurden
- Alle übernehmen mehrere Rollen
  - In kleinen Organisationen gibt es viel zu tun, aber zu wenige Menschen, die es erledigen können
  - So kann etwa ein Frontend-Entwickler zugleich Produktdesigner, Technical Writer, Produktmanager, QA-Verantwortlicher oder Zuständiger für Third-Party-Integrationen sein
  - Wenn eine neue Idee zur Verbesserung der Customer Experience entsteht, kann die Person, die sie vorgeschlagen hat, auch selbst die Verantwortung dafür übernehmen, einen Prototyp zu bauen oder sie umzusetzen
Diese kulturellen Merkmale bestimmen, welche Fähigkeiten Produktentwicklungsgruppen und insbesondere Führungskräfte im Software Engineering brauchen
Sie geben außerdem Hinweise darauf, wie sich DevOps, Platform Engineering und Staff Engineering an ein Startup-Umfeld anpassen müssen

[Meine Engineering-Prinzipien (Tenets) auf die Startup-Kultur anwenden]

DevOps in Startups

In Startups ist es leicht, Prozesse zu verändern.
- Weil es nur wenige Personen gibt, bestehen kaum große Hürden, neue Verhaltensweisen einzuführen
- Die besten Ergebnisse erzielt man, wenn Prozesse an Tools angepasst werden
- Wenn starre Prozesse beibehalten werden, muss man Tools anpassen oder zusätzliche Software entwickeln, was Zeit verschwendet
Custom-Tools sollten nach Möglichkeit vermieden werden
- Empfehlenswert ist der Einsatz von serverloser Infrastruktur, SaaS-Tools und Open-Source-Bibliotheken
- Man sollte sich am allgemeinen Fluss der Technologie orientieren und Technologien nicht anpassen, wenn sie keinen differenzierenden Wettbewerbsvorteil liefern
- Siehe dazu: Martin Fowlers Utility vs Strategic Dichotomy
Man sollte sich für „langweilige Technologien“ entscheiden
- Das Team sollte keine großen Risiken auf Lösungen setzen, mit denen es nicht vertraut ist oder für die es kaum Community-Unterstützung gibt
- Bei Problemen sollte man Technologien wählen, für die sich online leicht Lösungen finden lassen
- Einen Vortrag, der diese Idee genauer erklärt, gibt es bei Dan McKinleys boringtechnology.club

Platform Engineering in Startups

Erwähnung aus Rebecca Murpheys Engineering Unblocked podcast:
- „Die Developer Experience eines Unternehmens ist ein Produkt, egal ob sie bewusst gestaltet wurde oder nicht“
- Auch in der Größe eines Startups braucht man weiterhin Monitoring, Deployments, Error Tracking, Log-Einsicht und das Umschalten von Feature Flags
- Die wichtige Frage lautet: „Sind diese Aufgaben schmerzhaft?“
Platform Engineering ist in Startups eine Teilzeitrolle
- Anfangs kann eine integrierte Testumgebung nötig sein, später kann sie jedoch in der Priorität zurückfallen
- Die Platform-Engineering-Rolle wird nur dann wahrgenommen, wenn sie gebraucht wird
Es gibt keinen Spielraum für langfristige Plattformprojekte
- Stattdessen müssen wertvolle Elemente in kleinen Arbeitseinheiten umgesetzt werden
- Wichtig ist, das große Bild und die Vision mit dem Team zu teilen und verständlich zu machen, wie die kleinen Teile zusammenhängen
Plattformarbeit in Startups bedeutet, neue Produktivität und neue Herangehensweisen zu erschließen
- Meist geht es nicht um den Wechsel von bestehender Software zu modernen Tools, sondern darum, etwas völlig Neues aufzubauen, das vorher gar nicht existierte
- Wichtiger als die Frage, was möglich ist, ist die Frage, was getan werden sollte
Man sollte sich auf Arbeit konzentrieren, die aktuelle Probleme der Organisation oder Probleme in naher Zukunft löst
- Welche Arbeit nötig ist, sollte über Praxiserfahrung, Gespräche mit Engineers, Feedback aus Retrospektiven und die Analyse von SDLC-Metriken (Software Development Life Cycle) ermittelt werden
- Manchmal ist es besser, Plattformarbeit zurückzustellen und sich auf andere Anforderungen zu konzentrieren
- Ein flexibler Ansatz ist entscheidend

Staff Engineering in Startups

Die Rolle des Staff Engineer passt gut in ein Startup-Umfeld
- Tiefe technische Expertise, der Wunsch nach breitem Einfluss und die Bereitschaft, dort einzuspringen, wo es nötig ist, um Geschäftsprobleme zu lösen, passen gut zu Startups
In großen Organisationen sagt man oft: „Man weiß, wo der technische Schuldenberg vergraben ist“
- Ein Staff Engineer findet die Menschen mit diesem Wissen, ordnet es und leitet daraus Entscheidungen für den weiteren Weg ab
- In Startups liegen technische Schulden und Probleme offen sichtbar zutage
- Ein Staff Engineer kann großen Einfluss haben, indem er dieses Chaos ordnet und Lösungen aufbaut, die der Organisation langfristig helfen
In Startups kann ein Staff Engineer nicht bei nur einem Archetyp bleiben
- Weil die Organisation klein ist, muss er verschiedenste Aufgaben übernehmen, einschließlich direkter Umsetzung
- Neben Architekturdesign, Projektleitung und taktischer Arbeit muss er auch eigenständig Verbesserungsideen entwickeln und umsetzen
- Flexibilität und proaktive Verantwortungsübernahme sind für Staff+-Engineers in Startups unverzichtbare Eigenschaften
Eine wichtige Aufgabe von Staff+-Engineers ist Mentoring und Sponsorship
- Das ist besonders wertvolle Unterstützung und Orientierung für Junior-Talente in Startups
- Staff Engineers fördern durch diese Unterstützung das Wachstum des Teams und stärken die Fähigkeiten der Organisation