Ein dediziertes TypeScript Team Schritt für Schritt aufbauen

Was dediziert im Alltag bedeutet

Dediziert heißt, dass eine Person in den vereinbarten Stunden ausschließlich für Sie arbeitet. Sie ist nicht nebenbei in drei anderen Projekten eingeplant, sie bleibt über die Zeit dieselbe, und sie nimmt an Ihren Ritualen teil, vom Daily bis zur Retrospektive. Das Gegenteil ist ein Pool wechselnder Leute, die Tickets abarbeiten und nach zwei Wochen weiterziehen.

Ein dediziertes TypeScript Team ist dann die Summe solcher Personen, die gemeinsam an Ihrem Produkt arbeiten, mit Ihren Zielen und nach Ihren Regeln. Formal sind sie bei uns angestellt, fachlich gehören sie zu Ihrem Team.

Eine Randnotiz zur Schreibweise. In Suchanfragen taucht oft der dezidierte TypeScript Entwickler auf. Gemeint ist in aller Regel der dedizierte, also jemand, der einem Kunden fest zugeordnet ist. Dezidiert heißt eigentlich entschieden, was einer guten Entwicklerin natürlich auch nicht schadet.

Mit einer Person anfangen, nicht mit fünf

Der häufigste Fehler beim Aufbau ist Ungeduld. Die Roadmap ist voll, also sollen gleich vier oder fünf Leute starten. Auf dem Papier bringt das Tempo, in der Praxis bremst es fast immer. Jede neue Person braucht Zugänge, Einarbeitung und Antworten auf Fragen, und die kommen von Ihrem internen Team, das ohnehin schon ausgelastet ist.

Fred Brooks hat dieses Phänomen schon 1975 beschrieben. Mehr Leute in ein verspätetes Softwareprojekt zu stecken, macht es noch später. Das gilt bis heute, auch wenn die Werkzeuge deutlich besser geworden sind.

Bewährt hat sich ein anderer Weg. Zuerst startet eine erfahrene Person als Anker. Sie lernt die Codebasis kennen, findet die Engstellen, schreibt die fehlenden Konventionen auf und baut ein kleines Onboarding für alle, die nachkommen. Nach vier bis acht Wochen wisst Sie, welches Profil als Nächstes am meisten bewirkt, und die zweite Person startet in eine vorbereitete Umgebung statt ins Chaos.

Welche Rollen ein kleines TypeScript Team braucht

Ein kleines Team braucht keine Organigramme, aber klare Schwerpunkte. Für die meisten Produkte mit TypeScript reichen vier Rollen, die nicht alle sofort besetzt sein müssen.

• Senior mit Schwerpunkt TypeScript. Verantwortet Architektur, Reviews und die technischen Standards und ist in vielen Fällen die erste Person im Team. Mehr dazu auf der Seite Senior TypeScript Entwickler mieten.
• Frontend. Baut Oberflächen mit React, Vue oder Angular und kümmert sich um Barrierefreiheit, Performance und das Designsystem.
• Backend. Entwickelt APIs mit Node.js oder NestJS und verantwortet Datenmodelle, Schnittstellen und Hintergrundjobs.
• DevOps nach Bedarf. Pipelines, Deployments und Monitoring, oft nur mit einigen Stunden im Monat. Details stehen auf der Seite für DevOps Engineers.

Eine Rolle bleibt immer bei Ihnen, nämlich die Produktverantwortung. Was gebaut wird und in welcher Reihenfolge, entscheidet jemand aus Ihrem Unternehmen. Ein externes Team kann beraten und Alternativen aufzeigen, aber es sollte nicht über Ihre Roadmap bestimmen.

Eine typische Reihenfolge ist Senior, dann Frontend, dann Backend oder DevOps in Teilzeit. Bei Produkten mit schwerem Backend dreht sich die Reihenfolge einfach um.

Wie die zweite und dritte Person gut ankommen

Sobald der Anker steht, wird Onboarding zur Routine. Die erfahrene Person übernimmt dabei einen großen Teil der Einarbeitung und entlastet Sie internes Team. Ein Ablauf für die ersten vier Wochen kann so aussehen.

Das Onboarding selbst wird dabei jedes Mal ein Stück besser. Was beim ersten Mal gefehlt hat, landet in der Anleitung für das nächste Mal.

Wie Wissen bei Ihnen bleibt, auch wenn das Team extern ist

Die größte Sorge bei externen Teams ist berechtigt. Was passiert, wenn die Leute eines Tages gehen? Die Antwort liegt in ein paar einfachen Gewohnheiten, die von Anfang an gelten sollten.

• Alles liegt in Ihren Systemen, also Code in Ihrem Repository, Tickets in Ihrem Tracker und Dokumentation in Ihrem Wiki.
• Wichtige Entscheidungen werden als kurze Notiz im Repository festgehalten, mit Kontext, Optionen und Begründung. Solche Architecture Decision Records sind in einer Viertelstunde geschrieben und sparen später Tage.
• Code Reviews laufen in beide Richtungen. Ihre Leute reviewen den Code des externen Teams und umgekehrt.
• Pairing ist eingeplant und nicht nur erlaubt. Eine Stunde pro Woche zu zweit an einem Ticket verteilt Wissen schneller als jedes Handbuch.
• Das Übergabedokument wird monatlich aktualisiert und nicht erst in der letzten Woche.

Rechtlich ist die Frage ebenfalls geklärt. Wir arbeiten unter Ihrem Namen, und alle Rechte am Code liegen bei Ihnen.

Führen, ohne ins Mikromanagement zu rutschen

Ein dediziertes Team steuert Sie über Ziele und Ergebnisse, nicht über Stundenzettel. Die Stunden sind trotzdem jederzeit nachvollziehbar, aber sie sind nicht das, worauf es ankommt.

Für den monatlichen Blick reichen wenige Fragen.

• Wie viele der geplanten Tickets wurden fertig?
• Wie lange dauert es von der Idee bis zur Produktion?
• Wie viele Pull Requests warten länger als zwei Tage auf ein Review?
• Wie viele Fehler tauchen nach einem Release auf?

Für vertragliche Themen haben Sie bei uns eine feste Ansprechperson. Im Tagesgeschäft sprecht Sie direkt mit den Entwicklern, ohne Umweg über einen Projektmanager. Wie das in der Praxis aussieht, beschreiben wir unter Wie wir arbeiten.

Ein Team, nicht zwei

Technik ist selten das Problem. Schwieriger ist es, wenn sich im Alltag ein „wir“ und ein „die“ bildet. Die Externen sitzen dann in eigenen Kanälen, erfahren Entscheidungen als Letzte und werden zu Dienstleistern für Tickets, statt mitzudenken.

Dagegen helfen kleine Dinge. Nehmt die Leute in dieselben Kanäle auf wie Sie internes Team, ladet sie zu Retrospektiven und Produktdemos ein und nennt sie in Ihrer Teamübersicht mit Namen und Rolle. Wenn es passt, gehört auch ein gemeinsamer Termin vor Ort dazu, etwa zum Kickoff eines großen Vorhabens.

Der Effekt ist messbar, wenn auch nicht in einer Kennzahl. Leute, die sich als Teil des Teams fühlen, melden Probleme früher, schlagen Verbesserungen vor und übernehmen Verantwortung für Dinge, die in keinem Ticket stehen.

Fünf Fehler, die beim Teamaufbau immer wieder passieren

Die folgenden Fehler begegnen uns in unterschiedlichen Varianten, und fast alle lassen sich mit wenig Aufwand vermeiden.

1. Niemand darf entscheiden. Das Team hat Fragen, aber die Person mit Entscheidungsbefugnis ist nie erreichbar. Die Folge sind Annahmen, die später tIhr korrigiert werden.
2. Die Zugänge kommen zu spät. Die ersten Tage vergehen mit Tickets an die interne IT. Legt alles an, bevor jemand startet.
3. Tickets ohne Kontext. Wer nur liest, was zu tun ist, aber nicht warum, trifft schlechtere Entscheidungen. Nehmt das Team mit in Gespräche über Kunden und Ziele.
4. Zu viele auf einmal. Lieber zwei Personen gut einarbeiten als fünf schlecht.
5. Die Übergabe kommt zuletzt. Wer erst in der letzten Woche dokumentiert, dokumentiert gern das Falsche. Übergabe ist eine laufende Aufgabe.

Wann das Team wieder kleiner werden sollte

Ein guter Teamaufbau plant auch den Rückbau. Nach einem Launch oder am Ende einer großen Migration sinkt der Bedarf oft deutlich. Dann ist es sinnvoll, das Team zu verkleinern, statt Arbeit zu erfinden.

Bewährt hat sich, die Person mit dem meisten Wissen über das System zu halten, zum Beispiel über einen Stundenpool ab 80 Stunden, und die übrigen Rollen auslaufen zu lassen. So bleibt jemand verfügbar, der Fehler schnell findet und neue Anforderungen einschätzen kann. Die Modelle dazu stehen in der Preisübersicht.

Wächst der Bedarf wieder, startet die nächste Person nicht bei null, sondern mit einer dokumentierten Codebasis und jemandem, der sie einarbeitet.