Die überraschenden Lektionen, die ich als technischer Leiter gelernt habe

Hallo zusammen! Nach einer Zeit der Schreibpause bin ich wieder da und versuche, wieder in Schwung zu kommen. Ich möchte betonen, dass die hier geteilten Erfahrungen auf meinen akademischen und beruflichen Erfahrungen basieren. Daher ist es wichtig, sich daran zu erinnern, dass das, was hier beschrieben wird, möglicherweise nur einen Bruchteil der Realität darstellt und nicht als endgültige Formel für bestimmte Prozesse, Verfahren oder Dienste interpretiert werden sollte.

Ich freue mich derzeit sehr auf diesen neuen Abschnitt meiner Karriere. Ich habe viel gelernt und möchte etwas von dieser Reise mit der Community teilen. Ich hoffe, dass die hier präsentierten Informationen für die Leser von großem Wert sind.

Der Mensch steht im Mittelpunkt - Die Bedeutung von Soft Skills

Als ich vor einigen Jahren an meinem ersten Auswahlverfahren teilnahm, erinnere ich mich noch genau an die fast langweiligen Schritte, die ich durchlief: Vorstellungsgespräch mit der Personalabteilung, praktischer Test, Vorstellungsgespräch mit dem technischen Leiter und schließlich Vorstellungsgespräch mit dem Manager. Während meiner Karriere als Entwickler habe ich an mehreren Vorstellungsgesprächen mit unterschiedlichen Modellen teilgenommen. Damals fühlte ich mich bei Vorstellungsgesprächen mit Personalern immer unwohl. Ich verstand nicht ganz, warum und dachte: „Wenn ich das, was im technischen Test verlangt wird, schaffe, zeige ich bereits genügend Kompetenz für die Stelle.“

Als ich meine Rolle als Leiter der technischen Entwicklung übernahm, bestand eine meiner Aufgaben darin, gemeinsam mit der Personalabteilung (ja, denselben Leuten, bei denen ich nicht verstand, warum ich am Auswahlverfahren teilnahm) einen technischen Test vorzubereiten und das Interviewformat für zwei Kandidaten zu definieren, die im Backend-Bereich anfingen. Ich dachte, ich wüsste bereits, was ein Anfängerentwickler im Backend-Bereich liefern sollte und was im Test als Unterscheidungsmerkmal gelten würde. Womit ich jedoch nicht gerechnet hatte, war, dass trotz der Bedeutung des Codes noch weitere Anforderungen über die Projektabwicklung hinaus aufkamen: Wie bewertet man Kandidaten in Bezug auf die Kommunikation? Welches Interesse haben sie an der Stelle? Und wie kann der Kontext, den sie präsentieren, ihre Eignung für die vorgeschlagene Stelle beeinflussen? Diese und andere Fragen erwiesen sich als ebenso relevant wie der von beiden Kandidaten präsentierte Code, etwas, das ich in meinen frühen Jahren als Entwickler zuvor nicht bedacht hatte.

Ich erinnere mich, wie ich am Besprechungstisch saß, um die endgültige Entscheidung zu treffen, und ein wenig überrascht war, wie wenig über die technischen Fähigkeiten der einzelnen Kandidaten gesprochen wurde. Dies lag zum Teil daran, dass es sich um Kandidaten auf Einstiegsniveau handelte, sodass zu erwarten war, dass ihre technischen Fähigkeiten nicht so ausgeprägt waren, und dies war nicht der Hauptschwerpunkt der Diskussion.

Aber auch bei anspruchsvolleren Stellen, insbesondere bei Positionen auf höherer Ebene, ist es wichtig, Fähigkeiten wie Kommunikation, Dokumentation, Anpassungsfähigkeit, Proaktivität und andere oft genannte Fähigkeiten zu berücksichtigen. Diese Soft Skills sind grundlegend und können neben technischen Fähigkeiten entscheidend für den Erfolg in der Rolle sein. Das ist eigentlich mein nächster Punkt.

Die Grenze zwischen Junior und Senior (nein, nicht mittleres Niveau).

Ich weiß, dass es viele Diskussionen über die Bedeutung und Klassifizierung von Begriffen im Zusammenhang mit Erfahrungsstufen wie „Senior“ gibt. Einige sagen, dass „Senior durch Jahre an Erfahrung definiert wird“, andere behaupten, dass „man in manchen Unternehmen nach einem Jahr Senior-Erfahrung erlangt“. Es gibt auch diejenigen, die sagen, dass „es keine klare Unterscheidung zwischen Junior und Senior gibt“ oder dass „Senioren nur Code-Reviews durchführen und PRs genehmigen“. Einige dieser Aussagen sind komisch, andere enthalten ein Körnchen Wahrheit. Tatsache ist, dass der Begriff „Senior“ sehr vielfältig ist und es nicht meine Aufgabe ist, einen universellen Standard zu definieren, aber ich kann einige Hinweise geben, um diese Klassifizierung auf individuellere Weise zu verstehen.

Ein Senior zu sein bedeutet nicht nur technisches Wissen, obwohl dies zweifellos sehr wichtig ist. Ein echter Senior oder zumindest ein guter Senior ist jemand, der in der Lage ist, komplexe Probleme sowohl in Bezug auf Code als auch Systemarchitektur zu lösen. Die Aufrechterhaltung der Codequalität, die Einhaltung guter Entwicklungspraktiken und Kenntnisse im Projektmanagement sind entscheidende Aspekte.

Der Hauptunterschied besteht darin, dass ein Senior in der Lage sein muss, all dies autonom auszuführen und, was noch wichtiger ist, mit Teams aus verschiedenen Ebenen und Bereichen zusammenzuarbeiten, um das bestmögliche Projekt abzuliefern. Darüber hinaus leitet und führt ein echter Senior (oder zumindest die besten) nicht nur das Team, sondern entwickelt und bereitet auch andere Entwickler auf neue Positionen und Verantwortungen vor.

Meine erste Erfahrung als Projektleiterin

Als ich mein erstes Projekt übernahm, wusste mein Chef, dass ich vorher noch kein anderes Projekt geleitet hatte. Ich nahm lediglich an der Entwicklung teil und arbeitete einige Dinge aus, die die Entwicklung in Bezug auf die Kommunikation mit dem Management erleichtern würden. Die erste Frage, die er mir stellte, war: „Wie viele Leute und welche Art von Mitarbeitern werden ausreichen, um das Projekt zu ergänzen?“ Ich wusste die Antwort nicht sofort, es war eine sehr komplexe Frage. Da das Projekt erst in der Entwurfsphase war, hatten wir keine Vorstellung vom Stack, wie viel Zeit es dauern würde, jede Aufgabe zu erledigen und von anderen Kennzahlen, die für die Leute vor uns von Interesse waren. Ich führte eine umfassende Studie zu mehreren Projektmanagementmethoden durch, um sie am nächsten Tag abliefern zu können: Pert, Planning Poker. Wir wählten gemeinsam die Methode aus, die am besten geeignet war, und die Herausforderung begann. Für jedes Teammitglied war klar, was die beste Entwicklungsplattform war, welcher Stack am besten zu verwenden war, wie die Systemarchitektur funktionieren würde, wir studierten andere Lösungen auf dem Markt, überwachten das Niveau jedes Entwicklers, es gab Meetings, Meetings und noch mehr Meetings mit dem Management .

Wenn ich es am wenigsten bemerkte, entfernte ich mich immer mehr vom Code. Meine Rolle bestand nun darin, Verbesserungen vorzuschlagen und einige kritische Fehler zu beheben, damit das Projekt funktionieren konnte, oder zumindest eine solide Grundlage für den Start der Entwickler zu schaffen. Der Rest der Arbeit bestand aus der Kommunikation mit den Entwicklern, der Aufgabenaufteilung, der Überwachung von Messdaten und im Grunde genommen einem Auge auf Asana (um die Projektlieferzeit abzuschätzen) und einem anderen auf Meet, um sicherzustellen, dass mein Mikrofon nicht eingeschaltet war und nichts Unerwünschtes „aus Versehen“ durchrutschte.

Fazit und ein Blick in die Vergangenheit - dem Meister mit Zuneigung

Ich begann meine Karriere als Entwicklungspraktikant und hatte interessanterweise – und das finden Sie vielleicht ein wenig widersprüchlich – keine konkreten Erfahrungen (zumindest nicht formal in meinem Arbeitszeugnis festgehalten), die mich als Junior-, Vollzeit- oder Senior-Entwickler einstufen würden. Viele meiner Erfahrungen habe ich durch persönliche Projekte und Forschung an der Hochschule gesammelt. Es war ein schleichender Prozess, bis mir klar wurde, dass sich meine Fähigkeiten seit diesen frühen Tagen weiterentwickelt hatten.

Aber ja, ich habe intensiv als Entwickler auf verschiedenen Ebenen gearbeitet und hatte im Laufe meiner Karriere die Möglichkeit, unterschiedliche Typen von erfahrenen Fachkräften kennenzulernen:

1. Der sehr kompetente und effektive, aber unkommunikative Vorgesetzte, der Probleme löste, ohne Erklärungen zu seiner Vorgehensweise abzugeben.
2. Der Senior verfügt über hervorragende Kommunikations- und Lehrfähigkeiten, ist jedoch häufig mit dringenden Aufgaben überlastet und hat keine Zeit zum Unterrichten.
3. Der Senior, der sich für Over-Engineering und Zentralisierung der Technologie begeisterte, aber Termine einhielt und lieferte, was er versprach.

Das Wichtigste ist, dass all diese Fachleute trotz ihrer berechtigten Mängel (obwohl es möglich ist, ist es sehr schwierig, die Anforderungen auszugleichen) etwas Wertvolles zu vermitteln hatten. Diese Erfahrungen haben meine Karriere geprägt und mir einen klaren Blick darauf gegeben, was in der Systementwicklung funktioniert und was nicht.