Die Rolle technischer Projektleiter und deren Bedeutung erlebte ich das erste mal, als ich für ein Partnerunternehmen tätig war. Dort gab es diesen einen Menschen, der mir als Entwickler stets zur Seite stand: Wie ist meine IDE einzurichten, welche infrastrukturellen Eigenheiten gibt es und wen muss ich ansprechen, wenn ich Fragen zu einer Technologie habe. Mirco war sein Name und ich war nicht nur fasziniert von seiner Kompetenz, sondern auch von der Verantwortung die er ausstrahlt. Er traf technische Entscheidung und war der erste Ansprechpartner bei Problemen. Er hatte immer ein offenes Ohr und war nie so autoritär, dass man das Gefühl hatte übergangen zu werden.

Ab da an begann ich mich mit der Rolle des technischen Projektleiters auseinanderzusetzen. Was sind dessen Aufgaben und warum gibt es eine solche Person? Was sind die Qualitäten und wann braucht es eine solche Rolle im Unternehmen? Diese Fragen versuche ich in diesem Post zu beantworten und lasse dabei meine persönliche Erfahrungen einfließen.

Warum es einen technischen Projektleiter braucht

Mein Chef fragte mich einmal:

Warum ist ein Entwickler auf einem Projekt alleine effizienter als zehn Entwickler?

Ab einer gewissen Projektgröße werden Anwendungen so komplex, dass diese durch einen einzelnen Entwickler nicht mehr zu stemmen sind: Mehrstufige Caching-Mechanismen, Anbindungen an externe Systeme, diverse große Libraries oder die Nutzung einer SearchEngine wie SolR sind nur einige Fachbereiche in einem CMS-Projekt. All diese Fachbereiche brauchen unterschiedliche Experten. Ab diesen Punkt müssen Teams gebildet werden und plötzlich entstehen ganz neuen Herausforderungen.

Sobald Entwickler mit anderen Entwicklern zusammenarbeiten, ist Abstimmung notwendig. Je besser der Wissenstransfer, je eingespielter das Know-How und je klarer die Koordination der Aufgaben ist, desto besser arbeiten unterschiedliche Entwickler zusammen. Einem Projektleiter ohne technisches Hintergrundwissen fällt es mit steigender Komplexität schwerer Aufwände abzuschätzen und einen soliden Projektplan zu entwickeln. Hinter augenscheinlich kleinen Dingen können sich aus technischer Sicht oft große Aufwände verbergen. Um dies zu erkennen ist tieferes technischen Verständnis von Vorteil.

Entwickler haben unterschiedliche Präferenzen und Bedürfnisse. Ein Entwickler der überwiegend allein gearbeitet hat, kann unter Umständen den Teamflow stören. Ein anderer Entwickler ist es gewohnt gewisse Zuarbeiten zu bekommen, bevor er mit seiner Tätigkeit beginnt. Ein dritter Entwickler verstrickt sich in die Abstraktion eines Features und sucht nach Lösungsansätzen, die ein klassischer Projektleiter nicht liefern kann. Es ist wichtig die daraus entstehenden Stärken und Schwächen der Teammitglieder zu verstehen und im Projekt richtig einzusetzen.

Klassische Projektleiter werden im Scope von Teams meist nicht als wirkliche Teammitglieder angesehen, insbesondere wenn diese nur Aufschlagen, wenn es darum geht wann etwas fertig zu sein hat oder sich überwiegend um die Bedürfnisse von Kunden als um die des eigene Teams kümmern. Vertrauen in Entscheidungen, Motivation oder gar Leidenschaft für eine Sache aufzubauen ist meist ein schwieriges Unterfangen.

Zudem ist es wichtig bei technischen Lösungen über den Tellerrand einzelner Projekte zu sehen und Innovationen, Entwicklungen und Erkenntnisse übergreifend mitzunehmen. Der Grundstein einer solchen strategischen Entwicklung ist die Evaluation von wiederkehrenden Anforderungen. Die Schwierigkeit dabei ist, die konkrete Entwicklung über Projekte hinweg zu überschauen und zu planen, z.B. für Modularisierung. Anforderungen technische zu Abstrahieren, deren Aufwände wirtschaftlich sinnvoll zu gestalten und diese in der laufenden Entwicklung richtig einzuordnen gelingt nur mit gewissen Verständnis für Systemarchitektur (meiner Erfahrung nach).

Für diese und weitere Herausforderungen ist die Rolle des technischen Projektleiters prädestiniert.

• Er stellt das Bindeglied zwischen Management und Entwicklung dar
• Er kennt die Stärken und Schwächen der einzelnen Entwickler/des Teams und kann diese unterstützen
• Er hat tieferes technisches Verständnis um Aufwände zu verifizieren
• Er kennt die Architektur und kann strategische Entwicklung koordinieren

Daily drive eines technischen Projektleiters

Prinzip-bedingt kommen technische Projektleiter oftmals aus der Position eines Entwicklers. Meist ist der Übergang von der Rolle des Entwicklers zum technischen Projektleiter fließend. Ich persönlich habe an folgenden Aufgaben/Herausforderungen erkannt, dass ich diese Rolle bereits intern einnehme:

• Ansprechpartner bei technischen Entscheidungen für Entwickler
• Ansprechpartner für die Projektplanung und den -Verlauf bei Projektleitern
• Schulungen zu Systemen und Lösungen durchführen
• Stetig wachsender Kundenkontakt
• Übernahme von Verantwortung von technischen Entwicklungen und deren Koordination

Doch erst mit der offiziellen Erhebung als Projektleiter haben sich in meinem täglichen Aufgaben wirklich Änderungen und Probleme ergeben.

Das Wandeln zwischen den Welten eines Entwicklers und eines Projektleiters hat auch eine Kehrseite der Medaille: Aus Perspektive der Projektleitung wird man als Entwickler und aus Perspektive der Entwickler als Projektleiter eingeordnet. Die resultierenden Aufgaben können sich schnell aufsummieren:

• Die Projektleitung übergeht dich bei technisch wichtigen Entscheidungen und plant deine Zeit und Aufgaben wie für einen Entwickler (du schreibst definitiv nicht mehr soviel LoC wie als Entwickler).
• Für Entwickler bist du Entscheidungsträger und Ansprechpartner, wodurch sich der Kommunikations- und Organisationsaufwand erhöht.

Die tägliche Herausforderung besteht also darin den Kollegen bewusst zu machen, dass man weniger Zeit für die aktive Entwicklung hat, dafür gleichzeitig aktiver die Projektleitung und das Team unterstützen kann.

Fazit und persönlichen Leitsätze

Als Entwickler habe ich erst durch einen guten technischen Projektleiter erfahren, was es bedeutet eine solche Person im Team zu haben. Eine Person mit der ich bei einem kühlen Erfrischungsgetränk über technische Themen reden kann, der zu jeder Zeit ein offenes Ohr für Probleme hat und Verantwortung übernimmt, wenn es hart auf hart kommt.

Damit ich selbst ein solcher technischer Projektleitern sein kann, verinnerliche ich mir persönliche Leitsätze, die ich mir im Alltag immer wieder ins Gedächtnis rufe:

• lovely neglection: Dem Team Freiheiten geben und beratend zur Seite stehen
• True & fast feedback: Direktes, schnelles und ehrliches Feedback (aber kein Verhaltensfeedback)
• Solution-oriented: Orientiere dich an Lösungen und dem Soll-Zustand (nicht an Problemen)
• Change yourself, not them: Die einzige Person die man ändern kann, ist man selbst
• To listen is more than listen: Fokussiere dich auf den Dialog und nehme auf, was gesagt wird
• Get things done: Packe an wo es nur geht und rede nicht nur darüber

Weiterführende Lektüre

Karriereweg IT-Management: https://www.oreilly.de/buecher/13124/9783960090649-karriereweg-it-management.html (Leseprobe)