Wie ich als Staff Engineer Probleme finde, die es wert sind, gelöst zu werden
How I Find Problems to Solve as a Staff Engineer
Ein Staff Engineer erklärt, wie er wichtige Probleme entdeckt, indem er wie ein Schwamm den täglichen Lärm absorbiert und Probleme im Hinterkopf reifen lässt. Er rät davon ab, Zeit für strategisches Denken zu blockieren, sondern schlägt vor, zuzuhören, Probleme sich ansammeln zu lassen und nach gemeinsamen Mustern zu suchen. Anhand von Beispielen wie Perfetto zeigt er, wie aus vielen kleinen Anfragen eine große Lösung entstehen kann, und betont, dass man Ideen vor dem Bauen testen sollte. Der Ansatz basiert auf Erfahrungen in Infrastruktur- und Developer-Tools-Teams in großen Unternehmen.
Wenn eine Verbindung endlich klickt, ist das eines der besten Gefühle im Job: Mehrere unbeholfene Anfragen kollabieren zu einer einzigen Idee, und es eröffnen sich Möglichkeiten, die keine von ihnen allein angedeutet hat.
- stevepotter
Ich rate jungen Leuten, sich nach kleinen Unternehmen umzusehen, idealerweise nach solchen, die gerade den Product-Market-Fit durchlaufen. Also, sie haben kürzlich etwas entwickelt, das sie verkaufen können, und haben begonnen, es zu verkaufen. Begrenzte Ressourcen, gutes Wachstum, nicht super explosiv. Es gibt viele solcher Unternehmen. In diesem Umfeld lernt man schnell, wie man mit weniger mehr erreicht, die echten Probleme identifiziert, schnell liefert, direkt mit Kunden arbeitet und wie man gute Produkte baut. Danach kannst du gerne für ein großes Unternehmen arbeiten, wenn du willst, und du wirst erstaunt sein, wie gut du dich schlägst.
- wpasc
Der Autor merkt an:
> Eine Einschränkung: Meine Erfahrung stammt hauptsächlich aus der Arbeit an Infrastruktur- und Entwicklertools in großen Unternehmen, in Teams, in denen Ingenieure viel Bottom-up-Autonomie haben, um ihre Roadmaps zu beeinflussen. In einem eher Top-down-Umfeld gibt es möglicherweise einfach weniger Raum, auf diese Weise zu arbeiten.
Ich frage mich, ob der allgemeine Trend in der Tech-Branche dahin geht, dass Ingenieure weniger Bottom-up-Autonomie und mehr Top-down-kontrollierte Umgebungen erleben. Ich wäre neugierig zu sehen, wie viele Tech-Unternehmen (oder die durchschnittliche Erfahrung von Ingenieuren) sich von technikgetrieben, wo Ingenieure Autonomie haben, zu eher produktmanagementgetrieben verändert haben. Meine Vermutung ohne Belege ist, dass die allgemeine Ingenieursautonomie im Laufe der Jahre abgenommen hat, da sich die Tech-Kultur (meiner Meinung nach) von einem Technikfokus zu mehr Geschäfts-, Management- und Produktfokus verschoben hat, wobei Ingenieure nur noch die Rädchen sind, die damit beauftragt sind, die Ziele von Geschäft, Management und Produkt zu erfüllen.
Alles Hypothesen, nur anekdotische Daten.
- 9dev
Komisch, dass Leute dieses Problem haben. Ich habe den Großteil meiner Karriere im Startup-Bereich verbracht, und meine Erfahrung war durchweg, dass die Menge an Problemen, die es zu lösen gilt, weitaus größer ist, als ich in meinen Wachstunden vernünftigerweise bewältigen kann.
Also finde ich keine Probleme zum Lösen, sondern ich versuche einzuschätzen, welche Probleme am dringendsten sind oder welche Lösung mehrere gleichzeitig löst. Zu lernen, diese Priorisierung richtig hinzubekommen, um alle Teams und Kunden zufrieden und produktiv zu halten, ist etwas, worauf ich in meiner Karriere sehr stolz bin.
- CSMastermind
Das ist alles sehr guter Rat, aber ich würde jeden warnen, der die Frage am Anfang des Essays stellt, dass er wahrscheinlich kein Staff Eng sein sollte. Es sei denn, du bist bei einem Unternehmen, wo dieser Titel nur eine Sprosse auf der Karriereleiter ist, die keine differenzierten Verantwortlichkeiten hat (es gibt viele davon da draußen).
Jede Person, mit der ich zusammengearbeitet habe und die als Staff+ Engineer erfolgreich war, deren Beförderung war normalerweise eher eine Formalität, da sie bereits offensichtlich die Arbeit machten. Jede Person, die ich gesehen habe, wie sie 'auf ihr Inkompetenzniveau aufstieg', strebte nach dem Titel/der Gehaltserhöhung und versuchte, 'das Spiel zu spielen', um dorthin zu gelangen.
Wenn deine Motivation, die Probleme der Leute zu lösen, darin besteht, dass es dir eine Beförderung einbringt, anstatt dass du gerne Probleme löst, dann ist es wahrscheinlich nicht der richtige Job für dich.
- rr808
Ich wünschte, unsere höchsten Staff-Eng/Architekten würden tatsächlich an nützlichen Dingen arbeiten. Sie lieben es, mit neuer Technologie herumzuspielen, die nichts mit unserer aktuellen Plattform oder unserer Richtung zu tun hat. Manchmal versuchen sie, etwas zu reparieren, das der letzte Architekt begonnen hat, bevor auch er zu einem anderen Job wechselt.
- ronnier
Ich denke, fast die gesamte Tech-Branche ist aufgebläht, und massive Entlassungen würden die meisten Unternehmen kaum beeinträchtigen (obwohl es für die Menschen schädlich wäre, also scheint es grausam, das zu tun). Weniger Leute pro Team bedeutet weniger Kontextwechsel, und Entwickler besitzen mehr. Sie müssen nicht nach Arbeit suchen, sie wird vor ihrer Nase liegen. In so vielen dieser großen Tech-Unternehmen, in denen ich gearbeitet habe, habe ich zu viele gesehen, die nicht genug zu tun hatten. Sie schaffen Meetings und andere verschwenderische Dinge (Dokumentenschreiben), um ihre Zeit zu füllen. Manager und Direktoren scheinen große aufgeblähte Teams zu wollen, je größer ihre Mitarbeiterzahl, desto mehr können sie fordern und auf eine Beförderung drängen.
- intoXbox
Der Teil, den ich in der Dämmerung zwischen Senior und Staff herausfordernd finde, ist, dass tiefes technisches Wissen bedeutet, dass ich kurzfristige Probleme, nur als Anfragen, schnell und effektiv lösen kann.
Der Autor erwähnt, dass man Zeit damit verbringen sollte, die Frustrationen anderer Teams zu verstehen, aber das nimmt viel Zeit in Anspruch, und ich mag es nicht, die Person zu sein, die redet und redet, aber keinen Code pusht und Features ausliefert. Ich würde gerne hören, wie andere das erlebt haben.
- napo
Ich habe eine Weile auf Staff-Ebene gearbeitet; ich denke, der Schlüssel ist, an einen Direktor zu berichten, der Manager verwaltet. Jedes Mal, wenn ich das tat, hatte ich eine gute Zeit, Projekte waren leicht zu definieren und Leute waren leicht zu überzeugen. Ich hatte die gleiche Ebene mit ein paar Managern, die andere ICs verwalteten, und das hat nie funktioniert. Andere ICs versuchen, bei Aufgaben zu konkurrieren, Leute kommen nicht mit ihren Bedürfnissen zu dir, du erfährst von verschiedenen Projekten oft zu spät, andere Teams sind territorial und wollen nicht wirklich, dass du eingreifst.