Was ist ein technischer Projektmanager?

Was ist ein Technischer Projektmanager (TPM)? Die Antwort hängt davon ab, wen Sie fragen, sagt Andi Blackwell, ein erfahrener IT-Berater und Experte für Geschäftsabläufe. Als Toptals leitender Direktor für Projekt- und Produktmanagement leitet Blackwell das Team, das dafür verantwortlich ist, hochqualifizierte Projektmanager in Toptals freiberuflichem Netzwerk mit Organisationen zusammenzubringen, die Spitzentalente für bestimmte Initiativen suchen. In den letzten Jahren hat sie einen Anstieg der Nachfrage nach TPMs erlebt.

„In der Technologiebranche gibt es definitiv einige Debatten darüber, was dieser Begriff eigentlich bedeutet“, sagt Blackwell. „Es gibt viele Leute, die sich Technische Projektmanager nennen, weil sie sehr eng mit einem Engineering-Team zusammengearbeitet oder ein technisches Team aus Projektmanagement-Perspektive geleitet haben, aber das ist nicht das, wonach wir suchen.“

Die Definition von Toptal ist spezifischer. Alle Projektmanager im Netzwerk von Toptal sind Experten für traditionelle Projektmanagementfähigkeiten wie Scoping, Budgetierung und Verwaltung von Zeitplänen sowie agile Softwareentwicklungspraktiken im Zusammenhang mit iterativer Bereitstellung und kontinuierlicher Verbesserung. Sie haben ausnahmslos eng mit Ingenieuren zusammengearbeitet und konnten bei Bedarf ein Scrum-Team coachen und leiten.

Um sich als TPMs zu qualifizieren, müssen sie jedoch über die Verwaltung agiler Prozesse und die Zusammenarbeit mit Entwicklern hinaus über eine zusätzliche Erfahrungsebene verfügen: Sie müssen selbst Entwickler gewesen sein.

Eine wertvolle Kombination

Große und kleine Organisationen interessieren sich zunehmend für diese besondere Kombination von Fähigkeiten. „Die meisten Startups können keine Person einstellen, die nur eine Sache kann“, sagt Blackwell, und größere Unternehmen möchten „Entwickler“ oder „Architekt“ im Profil eines Kandidaten sehen, wenn sie für ein Ingenieurprojekt einstellen.

Auch in Fällen, in denen ein Kunde nicht ausdrücklich einen Projektleiter mit technischem Hintergrund benötigt, ist das Setzen eines Häkchens bei „Entwickler“ ein wichtiges Verkaufsargument. Jemand, der ein Softwareprojekt planen und durchführen, agile Prozesse implementieren und optimieren und programmieren kann? Das ist ein großer Segen.

In Wirklichkeit wird von TPMs jedoch nicht erwartet, dass sie codieren – viele haben seit Jahren nicht mehr codiert. Warum also Programmiererfahrung?

TPMs sind erforderlich, um technische Entscheidungen zu treffen, sagt Blackwell: „Wenn Sie nicht zumindest einige relativ aktuelle praktische Erfahrungen mit einem modernen Tech-Stack, einem SDK (Software Development Kit), einer Architektur oder einer Testautomatisierungsplattform haben, dann müssen Sie Sie werden möglicherweise nicht die richtigen Entscheidungen treffen. Sie werden beim Kunden keine Glaubwürdigkeit haben, weil Sie diese Dinge noch nie benutzt haben.“

Arbeiten mit Teams

Glaubwürdigkeit gegenüber einem potenziellen Kunden zu demonstrieren, ist ein wichtiger Faktor bei der Sicherung von Engagements, aber es ist nur die erste Hürde. Einmal einem Projekt zugewiesen, muss ein TPM schnell das Vertrauen und den Respekt eines technischen Teams gewinnen.

Michael Poythress begann als Teenager mit dem Programmieren. Mit 16 baute er eine kommerzielle Website für ein Immobilien-Werbeunternehmen, das er mit seinem Vater gründete. Seitdem ist er CEO und Gründer mehrerer Startups. 2018 trat er als TPM dem Toptal-Netzwerk bei und arbeitet nun eng mit Ingenieurteams zusammen. „Wenn ich keine Erfahrung mit dem Programmieren hätte, würden die Programmierer das aufgreifen“, sagt er. „Sie würden nicht direkt mit mir schießen. Aber wenn ich sie herausfordere und mit ihnen auf Augenhöhe spreche, gibt es Respekt und eine Beziehung.“

Und es ist die technologische Erfahrung, die mehr zählt als der Titel, sagt Allen Takatsuka, ein Toptal TPM aus Orange County, Kalifornien: „Nach allem, was ich gesehen habe, hat das „T“ in TPM für Ingenieure nicht wirklich Bedeutung. Sie denken, dass es nur ein weiterer Projektmanager ist, der ihre Meetings arrangiert und sie bittet, Tabellenkalkulationen auszufüllen.“

Sobald jedoch Gemeinsamkeiten hergestellt sind, „ist der Geschmack der Interaktion sehr unterschiedlich. Es ist eher eine Partnerschaft mit der Technik“, sagt er.

Takatsuka hat zu Beginn seines Berufslebens Jahrzehnte damit verbracht, Ingenieurteams zu leiten. Er schreibt dieser Erfahrung zu, dass er seine Soft Skills verbessert hat. „Es ist eine etwas andere Empathiefähigkeit“, sagt er. „Man muss zeigen, dass man die Sprache beherrscht. Sie können sagen: ‚Ich verstehe, warum Sie diese Herausforderungen haben, basierend auf den technischen Dingen, die vor sich gehen.'“

Dan Allen, ein Technologieberater aus Vienna, Virginia, beschreibt seinen beruflichen Werdegang als „Guy-in-the-Cubicle-Programmierer zum technischen Leiter zum Architekten, Direktor, VP, CTO, CIO“. Seit er 2019 als TPM dem Toptal-Netzwerk beigetreten ist, war er beschäftigt und hat an 14 Kundenaufträgen gearbeitet.

„Ich lese selten Code. Ich schreibe fast nie Code“, sagt er. „Aber es gab Situationen, in denen ein Entwickler feststeckte. Sie können mich durch die Architektur führen und ich kann genau sehen, was sie zu tun versuchen, und die Logik.“

Er findet die Dynamik nicht nur in Grenzfällen nützlich, sondern im weiteren Sinne. „Ihr Team weiß, dass es zu Ihnen kommen und reden kann, und Sie verstehen wirklich, was es sagt“, sagt er. „Sie können ihnen helfen, alle Komplexitäten zu berücksichtigen, falls sie etwas übersehen haben. Sie können ein Resonanzboden sein und Feedback geben.“

Der Multiplikatoreffekt

Diese Art von Feedback und Erkenntnissen ist nicht nur für den Aufbau von Beziehungen wichtig. TPMs bieten einem Unternehmen ein anderes Wertversprechen. Sie dienen weniger als Informationskanäle als vielmehr als Wissensquellen. Ja, sie planen, koordinieren und kommunizieren, aber sie helfen Kunden und Teams auch dabei, komplexe Technologieentscheidungen zu treffen.

„Du hast die Fähigkeit, technisch rechthaberisch zu sein“, sagt Takatsuka. „Und das ist ein Mehrwert für die Organisation, denn jetzt haben Sie eher einen Multiplikatoreffekt als nur die Organisation und Zusammenarbeit.“

Takatsuka merkt an, dass TPMs durch weniger Hürden springen müssen, um Probleme zu lösen. Insbesondere in größeren Organisationen kann ein nicht technischer Programm- oder Projektmanager eine technische Herausforderung angehen, indem er die relevanten Akteure und Interessengruppen identifiziert, Kontext anbietet, Informationen zusammenfasst und dann die Ergebnisse durchgeht, um eine Entscheidung zu treffen. TPMs können ihr eigenes Wissen einbringen.

„Sie können Risiken viel effizienter angehen“, sagt Oana Ciherean, TPM mit Sitz in Tokio. „Und diese Risiken können von so vielen Orten kommen. Sie können von falschen Schätzungen des Teams herrühren. Sie können also sagen: „Okay, ich bin mir sicher, dass es keine Woche dauern wird, bis dieses Stück Code geschrieben ist“, weil es in Wirklichkeit zwei Tage sind. Sie können also tatsächlich Personen entsperren. Weil Sie herausgefunden haben, dass sie feststecken, und deshalb brauchen sie dafür fünf Tage. Du weißt das, weil du dort warst und selbst festgefahren bist.“

Das Gleichgewicht finden

Ciherean begann ihre Karriere als Entwicklerin, wechselte aber bald ins Projektmanagement aus dem Wunsch heraus, am großen Ganzen beteiligt zu sein. In diesen Rollen stellte sie jedoch fest, dass sie das Programmieren vermisste. Sie sagt, dass das technische Projektmanagement das Beste aus beiden Welten bietet: „Es ermöglicht mir, wirklich praktisch in der Technologie zu sein, aber auch das Geschäft und die Kunden auf hohem Niveau zu verstehen und zu verstehen, was sie von Funktionen erwarten.“

Auch Poythress hat das Gefühl, seinen Sweet Spot gefunden zu haben. „Ich bin ein Übersetzer oder eine Verbindung zwischen den Visionären, die eine Idee haben, und dem technischen Talent, das weiß, wie man sie baut und umsetzt“, sagt er. „Ich spreche beide Sprachen fließend. Ich spreche ‚normale Person‘ und ich spreche ‚technisches Essisch‘.“

Der Mini-CTO

TPMs, die für Startups und kleine Unternehmen arbeiten, nehmen einen besonders guten Platz an der Schnittstelle zwischen Wirtschaft und Technologie ein. Bei diesen Engagements ist ein TPM oft der erste Mitarbeiter, der zu Beginn eines Projekts an Bord kommt. Er oder sie ist dann dafür verantwortlich, die Lebensfähigkeit des Produkts zu bewerten, den technischen Umfang und die Anforderungen zu definieren und dem Kunden (manchmal einem einzelnen Gründer mit einem Keimling einer Idee) zu helfen, einen Tech-Stack auszuwählen, Anbieter für die Servicebereitstellung zu bewerten, Best Practices für DevOps zu implementieren, und das richtige Team zusammenstellen.

Takatsuka betrachtet diese Engagements als „Mini-CTO“-Rollen, in denen der TPM die geschäftlichen und technischen Bereiche überbrückt, um Dinge auf den Weg zu bringen. Manche Kunden hätten so gut wie keine Ahnung von Softwareentwicklung, sagt er: „Wie richte ich einen Shop ein? Ich habe über Agilität gelesen. Wie mache ich das?"

Poythress sieht die beiden Rollen als überlappend, in bestimmten Fällen sogar als nicht voneinander zu unterscheiden. „Es gibt viel gegenseitige Befruchtung“, sagt er. „Ein CTO für eine kleinere Organisation könnte sehr leicht in eine leitende technische PM-Rolle in einer größeren Organisation wechseln und sich sofort wie zu Hause fühlen.“

Agilität ermöglichen

Während die Mechanik von Agile im Steuerhaus praktisch jedes Projektmanagers mit Erfahrung in der Softwareentwicklung steckt, kann jemand mit technischer Begabung eine differenziertere Perspektive auf das Management von Prozessen einbringen.

Ciherean stellt fest, dass agile Methoden niemals streng nach dem Buch implementiert werden; Sie müssen individuell angepasst, gemischt und an die spezifischen Bedürfnisse eines Teams und Projekts angepasst werden.

„Sie müssen sicherstellen, dass das, was Sie als Prozess entwerfen, die Arbeit der Entwickler nicht beeinträchtigt und sie tatsächlich effizienter oder produktiver macht“, sagt sie. „Manchmal bedeutet das, tief in den GitHub-Workflow einzutauchen, um beispielsweise zu sehen, wie sie ihre Commits durchführen, zu sehen, wie sie Verzweigungen für ihren Code erstellen und zu sehen, ob Ihr Prozess in ihren Workflow passt. Und dann korrigierst du entweder deinen Prozess oder korrigierst ihren Workflow.“

Das Fachwissen eines TPM kann auch Informationen zu spezifischen Agile-Artefakten und -Praktiken wie dem Product Backlog und relativen Größenschätzungen liefern.

„Wenn Sie das Technische verstehen, kennen Sie die grobe Komplexität der Dinge in einem Backlog“, sagt Takatsuka. „Andernfalls haben Sie nur diese Liste und es wäre schwer für Sie zu wissen, ob Nummer eins ein T-Shirt in Größe Large im Vergleich zu Nummer zwei ist. Sie haben vielleicht eine Vorstellung davon, dass einer schwieriger ist, aber Sie wissen nicht wirklich, was sich hinter den Kulissen verbirgt. Ein „extremer“ TPM, sagt er, „könnte die Dinge selbst bestimmen, mit der Einschränkung, dass das Team, wenn es an Bord kommt, seine eigene Geschwindigkeit haben wird.“

Poythress nutzt sein Verständnis der Größenschätzung als Maßstab, um die technischen Leiter und Ingenieure zu bewerten, die er für ein Projekt in Betracht zieht. Wenn er erwartet, dass etwas eine kleine Aufgabe ist, aber jemand anderes es für riesig hält, ist das ein Warnsignal: „Ich werde sie anhören, um zu sehen, ob es Komplexitäten gibt, von denen ich nichts weiß, aber wenn das nicht stichhaltig ist, Ich sage: 'Okay, nun, das passt nicht gut.' Wir brauchen jemanden, der das wirklich gut versteht und sich nicht einschüchtern lässt von einem eigentlich einfachen Feature.“

TPMs helfen auch dabei, Kunden über nicht-funktionale Anforderungen aufzuklären. Wie gehen Sie mit Hochverfügbarkeit um? Wie gehen Sie mit Disaster Recovery um? „Ohne das technische Verständnis weiß ich nicht, wie Sie diese Diskussion führen“, sagt Takatsuka. „Sie werden wahrscheinlich auf der Ebene der Scrum-Anforderungen aufhören und Schluss machen, bis die Techniker kommen. Nun, dann hast du diese riesige Kluft.“

Aktuell bleiben

Obwohl ihre Zeit an einer Tastatur eine grundlegende Rolle in dem spielt, was sie heute tun, können sich TPMs nicht auf vergangene Erfahrungen verlassen, um relevant zu bleiben. Angesichts der Geschwindigkeit, mit der sich die Technologie ändert und entwickelt, ist es leicht, ins Hintertreffen zu geraten.

Poythress lernte dies auf die harte Tour, während eines fünfjährigen Zeitfensters, bevor er zu Toptal kam, als er sich ausschließlich auf die Führung seines eigenen Unternehmens konzentrierte. „Ich bin definitiv stagniert“, sagt er. „Viele verschiedene Sprachen kamen hinzu und lösten in dieser Zeit Probleme, von denen ich nichts wusste, weil wir unseren Tech-Stack hatten und das war alles, was wir brauchten.“

Heute verbringt er bis zu 10 Prozent seiner Zeit damit, Dokumentationen zu lesen, YouTube anzusehen und Sandboxing zu betreiben, „um etwas über die neuesten und besten Dinge zu erfahren“.

„Ich experimentiere fast immer nebenbei mit einer neuen Sprache oder Technologie, nur damit ich auf dem Laufenden bleibe“, sagt er. „Denn wenn ich es nicht tue, wird die Branche weitermachen. Mir ist das schon mal passiert. Und es ist viel schwerer zu pauken, als auf dem Laufenden zu bleiben.“

Auch Takatsuka füllt proaktiv seine Wissenslücken: „Google ist heutzutage großartig. YouTube ist großartig. Du musst deine Hausaufgaben machen. Aber diese Arbeit baut auf sich selbst auf.“

Er stützt sich auch auf ein breites Netzwerk von Beraterkollegen für Unterstützung und Wissensaustausch. „Ich war schon in Situationen, in denen der Kunde Google verwenden wollte, aber zufällig kenne ich die AWS-Plattform besser“, sagt er. „Ich kann Freunde anrufen und sagen: ‚Hey, wir werden Firebase verwenden. Hatten Sie Kunden, die dies tun? Was ist mit der Skalierbarkeit?'“

Auch nach mehr als 30 Jahren im Geschäft und mehreren Positionen auf Führungsebene hat Dan Allen keine Angst davor, sich die Hände schmutzig zu machen. In den letzten drei Jahren hat er sich selbst beigebracht, wie man im Alleingang Amazon und Google Cloud bereitstellt. „Ich habe es getan, damit ich es verstehen und einem Toptal-Kunden helfen kann“, sagt er. „Sie hatten kein Technologieteam. Alles, was sie hatten, war ich. Also bin ich zur YouTube University gegangen und habe es geschafft.“

Seit Allen 1985 als Entwickler anfing, hat sich so viel verändert. Aber er genießt die Herausforderungen, die mit jeder neuen Gelegenheit einhergehen. „Das ist ein Teil dessen, was ich an diesem Job liebe“, sagt er. „Es gibt immer etwas, was du noch nicht getan hast, etwas Neues. Und Sie gehen immer mit einer zusätzlichen Feder in Ihrer Kappe davon, die Sie bei der nächsten Verlobung nutzen können.“