Betrieb im großen Maßstab: Dutzende Projekte mit einem kleinen Team betreuen

Beim Wachstum jedes kleinen Betriebs kommt der Punkt, an dem mehr Projekte aktiv sind, als sich im Arbeitsgedächtnis behalten lassen. Bestellungen auf mehreren Marktplätzen müssen überwacht werden. Die Infrastruktur braucht regelmäßige Wartung. Neue Funktionen sind in Entwicklung. Kunden fragen nach Sendungen, Compliance und Prognosen. Alles ist echte Arbeit, und die verfügbaren Stunden wachsen nicht mit der Zahl der Projekte.

Die meisten Ratschläge für diese Situation setzen voraus, dass Sie mehr Mitarbeiter einstellen. Oft ist das richtig, aber nicht immer. Das gilt besonders bei vielfältigen Projekten mit unterschiedlichen Technologie-Stacks, Fachgebieten und betrieblichen Rhythmen, wenn der zusätzliche Umsatz eines einzelnen Projekts keine eigene Stelle rechtfertigt. Kleine Teams mit Dutzenden Projekten brauchen Systeme, nicht nur mehr Menschen.

Dieser Beitrag beschreibt unseren Ansatz: die Werkzeugentscheidungen, die sich über die Zeit bewährt haben, die Betriebsprinzipien, die den Koordinationsaufwand verringern, und den Zielkonflikt zwischen Neuentwicklung und der Pflege dessen, was bereits funktioniert.

Der zentrale Zielkonflikt

Bei kleinen Teams mit vielen Projekten konkurrieren zwei Aufgaben um dieselbe Ressource: Aufmerksamkeit. Neues zu entwickeln erfordert ununterbrochene Aufmerksamkeit zum Erkunden. Bestehende Systeme zu pflegen erfordert Aufmerksamkeit für Reaktionen auf aktuelle Anforderungen. Diese Arbeitsweisen sind nicht miteinander vereinbar, und der Wechsel zwischen ihnen verursacht Kosten, die in keinem Projektmanagementwerkzeug auftauchen.

Die meisten betrieblichen Probleme entstehen jedoch nicht, weil man sich für den falschen Modus entscheidet, sondern weil man sich gar nicht entscheidet. Die Grenze zwischen Wartung und Entwicklung verschwimmt, bis beides nicht mehr richtig erledigt wird. Der Wartungsrückstand wächst, weil Entwicklung ihn verdrängt. Die Entwicklung stockt, weil sich wartungsbedingte Unterbrechungen häufen. Beides leidet.

Unsere Disziplin besteht darin, Zeit bewusst statt beiläufig zuzuteilen. Ein festgelegter Anteil jeder Woche ist für Wartung reserviert: Infrastrukturprüfungen, Aktualisierung von Abhängigkeiten, Monitoring-Kontrollen und Kundenberichte. Diese Zeit steht nicht für Entwicklung zur Verfügung, unabhängig davon, was gerade spannend ist. Entwicklungszeit ist vor Wartungsunterbrechungen geschützt, außer bei echten Störungen. Die Aufteilung ist nicht minutengenau starr, aber verbindlich genug, um nicht stillschweigend von anderen Prioritäten aufgezehrt zu werden.

Die Wahl der Werkzeuge

Unser Prinzip bei Werkzeugen lautet: innerhalb eines Stacks konsequent standardisieren und die Zahl der Stacks minimieren. Jedes zusätzliche Werkzeug ist eine weitere mögliche Fehlerquelle, etwas Neues zu lernen und eine potenzielle Abhängigkeit, deren Probleme auch andere Arbeiten aufhalten können. Die Kosten eines Werkzeugs sind nicht seine Lizenzgebühren, sondern der laufende Aufmerksamkeitsbedarf aller damit verbundenen Aufgaben.

Für die Infrastruktur betreiben wir Docker bei einem einzigen Anbieter. Kein Kubernetes, keine Multi-Cloud-Architektur, kein Service Mesh. Docker Compose auf einem ausreichend dimensionierten VPS bewältigt die Last aller derzeit von uns betriebenen Systeme. Klare Dokumentation erleichtert die Wiederherstellung nach Ausfällen. Eine anspruchsvollere Infrastruktur würde durch ihre betriebliche Komplexität mehr Wartungsaufmerksamkeit kosten, als sie an anderer Stelle einspart.

Bei der Anwendungsentwicklung standardisieren wir auf wenige Technologien: TypeScript für Web-Frontends, Python für Backend-Dienste und Datenpipelines, PostgreSQL (oft TimescaleDB) für dauerhafte Speicherung sowie Redis für Warteschlangen und Caching. Neue Projekte verwenden diesen Stack, sofern kein überzeugender Grund für eine Abweichung besteht. Dieser Grund muss ausdrücklich benannt und gegen die langfristigen Wartungskosten eines abweichenden Stacks abgewogen werden.

Für Projekt- und Aufgabenmanagement verwenden wir ein System, das einfach genug ist, damit das Werkzeug selbst nicht zum Projekt wird. Die Pflege eines komplexen Projektmanagementsystems verursacht häufig mehr Aufwand als die Projekte, die es koordinieren soll. Entscheidend ist diese Struktur: Jedes Projekt hat einen klar definierten aktuellen Stand, einen nächsten Schritt und eine verantwortliche Person. Alles andere ist optionale Detailtiefe.

Die Disziplin besteht hier darin, dem Druck zu widerstehen, neue Werkzeuge für Probleme einzuführen, die Sie noch gar nicht haben. Eine neue Observability-Plattform, eine neue Deployment-Pipeline, ein neues Teamkommunikationswerkzeug – alles wird als Lösung präsentiert. Die Einführungskosten sind aber real und sofort fällig, während der Nutzen ungewiss ist und später eintritt. Wir prüfen neue Werkzeuge anhand der Frage: Welches konkrete bestehende Problem lösen sie, und rechtfertigt die Lösung den Einführungs- und Wartungsaufwand?

Asynchrone Zusammenarbeit als Standard

Synchrone Kommunikation – Anrufe, Besprechungen und Echtzeit-Chat – verursacht pro Interaktion einen festen Aufwand, unabhängig von der Komplexität des Themas. Hinzu kommt die Terminabstimmung, die oft mehr kostet als die Interaktion selbst. Bei kleinen Teams mit vielfältigen Projektportfolios kann synchrone Koordination einen unverhältnismäßig großen Teil der verfügbaren Arbeitszeit beanspruchen.

Wir arbeiten nach dem Prinzip „asynchron zuerst“: Schriftliche Kommunikation und Dokumentation sind der Standard. Synchrone Abstimmung bleibt Situationen vorbehalten, in denen schriftliche Kommunikation tatsächlich nicht ausreicht. Eine Frage, die durch Lesen der Dokumentation beantwortet werden kann, sollte so beantwortet werden. Fehlt die Dokumentation, besteht die Antwort darin, sie zu schreiben – statt in einem Anruf, der nur diesen einen Fall klärt und den nächsten offenlässt.

In der Praxis bedeutet das: Entscheidungen werden schriftlich getroffen. Bei einer wesentlichen technischen oder betrieblichen Entscheidung – etwa zur Datenbankwahl, zu einem geänderten Deployment-Prozess oder einem Kundenworkflow – dokumentieren wir die Begründung, erwogene Alternativen und das erwartete Ergebnis. Diese Dokumentation ist nicht für die Nachwelt gedacht, sondern für das nächste Mal, wenn dieselbe Frage aufkommt. Bei vielen Projekten in einem kleinen Team geschieht das öfter als erwartet.

Statusmeldungen werden schriftlich und zu festgelegten Zeiten erstellt, statt mündlich auf Nachfrage. Für jedes Projekt gibt es einen kurzen wöchentlichen Bericht mit aktuellem Stand, jüngsten Änderungen, anstehenden Arbeiten und Hindernissen. Er wird geschrieben statt in einer Besprechung vorgetragen. Das Schreiben deckt oft Probleme auf, die in einem mündlichen Austausch verborgen geblieben wären, weil es die nötige Genauigkeit erzwingt, um Probleme sichtbar zu machen.

Selbst entwickeln oder kaufen

Jedes Werkzeug, das Sie entwickeln, ist ein Projekt, dessen dauerhafte Wartung Sie übernehmen. Bei der Entscheidung vergisst man das leicht: In diesem Moment sieht man die Entwicklungskosten und den Nutzen der neuen Fähigkeit. Die laufenden Wartungskosten werden erst später sichtbar, sind aber real und summieren sich.

Wir wenden drei Kriterien auf die Entscheidung zwischen Eigenentwicklung und Kauf an. Erstens: Gibt es das Werkzeug in einer Form, die das Problem ausreichend löst? Ausreichend heißt nicht perfekt. Ein kommerzielles Werkzeug, das neunzig Prozent des Problems gut löst, ist fast immer einer Eigenentwicklung vorzuziehen, die hundert Prozent abdeckt, dafür aber dauerhaft gewartet werden muss. Die verbleibenden zehn Prozent wiegen meist weniger schwer als die laufende Wartung der Eigenentwicklung.

Zweitens: Erfordert das Problem Kenntnisse unserer konkreten Daten oder Systeme, die kein externes Werkzeug haben kann? Datenpipelines, Geschäftslogik und Integrationen zwischen Systemen unter unserer Kontrolle kommen für Eigenentwicklung infrage. Allgemeine Funktionen wie E-Mail-Versand, Zahlungsabwicklung, Authentifizierung und Monitoring-Dashboards kommen für den Zukauf infrage, sofern kommerzielle Angebote nicht tatsächlich ungeeignet sind.

Drittens: Sind wir bereit, die betroffenen Daten mit einem Drittanbieterdienst zu teilen? Manche Betriebsdaten – Bestelldetails, Kundeninformationen und Finanzunterlagen – sollten nicht durch kommerzielle Dienste laufen, die sie protokollieren, analysieren oder für eigene Zwecke verwenden. Selbst betriebene Lösungen sind hier aus Datenschutzgründen gerechtfertigt, auch wenn kommerzielle Alternativen technisch überlegen sind. Deshalb betreiben wir unsere Datenanalyse, unser Supabase-Backend und unseren Monitoring-Stack selbst.

Unsere teuersten Eigenentwicklungen wirkten zum Entscheidungszeitpunkt allerdings nicht offensichtlich falsch. Sie erschienen als vernünftige individuelle Werkzeuge für konkrete Anforderungen. Die Kosten wurden achtzehn Monate später sichtbar: als das Werkzeug wegen einer geänderten Abhängigkeit aktualisiert werden musste, ein neues Teammitglied eine Codebasis ohne externe Dokumentation verstehen sollte oder ein Fehler eine Kundenlieferung blockierte und kein Supportkanal zur Eskalation verfügbar war. Die Lehre lautet nicht, niemals selbst zu entwickeln, sondern die Kosten über die gesamte Lebensdauer ehrlich zu betrachten, statt nur die Erstellungskosten.

Der Blick auf das Portfolio

Dutzende Projekte gleichzeitig zu betreuen wird einfacher, wenn jedes als Teil eines Portfolios statt als einzelne Verpflichtung verstanden wird. Manche Projekte eines Portfolios erzielen bei relativ geringem laufendem Einsatz mit der Zeit wachsende Erträge; andere stagnieren oder verlieren an Wert. Die Frage der Ressourcenverteilung ist für beide unterschiedlich.

Projekte mit wachsenden Erträgen verdienen Wartungsinvestitionen, um das Funktionierende zu schützen, benötigen aber selten umfangreiche Neuentwicklung. Ein E-Commerce-Betrieb mit stabilen organischen Rankings, einem guten Bewertungsprofil und zuverlässiger Logistik hat sich seinen Ertrag erarbeitet. Die Aufgabe ist nicht, ihn zu verbessern, sondern ihn nicht zu beschädigen. Das ist eine grundlegend andere Haltung als bei einem Projekt im Aufbau. Sie benötigt weniger Aufmerksamkeit und schafft Kapazität für Projekte, die noch keine wachsenden Erträge liefern.

Projekte ohne wachsende Erträge brauchen eine klare Einschätzung: Wird sich ihre Entwicklung durch weitere Investitionen voraussichtlich verbessern, oder ist es Zeit, das Ergebnis zu akzeptieren und Ressourcen neu zu verteilen? Kleine Teams mit vielen Projekten sind besonders anfällig für den Fehlschluss versunkener Kosten: Sie investieren weiter in erfolglose Projekte, weil bereits viel Arbeit hineingeflossen ist. Der Portfolioblick macht dieses Fehlermuster sichtbarer, weil er zum Vergleich zwingt. Aufmerksamkeit für ein stagnierendes Projekt fehlt bei Projekten, deren Erträge wachsen könnten.

Der eigentliche Engpass

Die übliche Sicht auf die Wachstumsgrenzen kleiner Teams konzentriert sich auf Geld und Zeit. Mehr Projekte brauchen mehr Geld zur Finanzierung und mehr Zeit zur Umsetzung. Das stimmt, ist aber unvollständig.

Der entscheidende Engpass eines kleinen Teams, das vielfältige Projekte in mehreren Fachgebieten betreut, ist Aufmerksamkeit – genauer: die Qualität der Aufmerksamkeit für Entscheidungen, die Kontextwissen erfordern. Routineaufgaben lassen sich systematisieren, delegieren oder automatisieren. Entscheidungen darüber, was als Nächstes entwickelt wird, wie auf eine Marktveränderung zu reagieren ist, ob ein neuer Marktplatz erschlossen werden soll oder ob ein technischer Ansatz tragfähig ist, verlangen fundiertes Urteilsvermögen von jemandem mit vollständigem Kontext. Diese Aufmerksamkeit wächst nicht linear mit der Teamgröße und lässt sich nicht durch Systematisierung ersetzen.

Daraus folgt: Der wichtigste Hebel im Betrieb kleiner Teams ist nicht Effizienz, also dieselben Dinge schneller zu erledigen, sondern Auswahl – überhaupt zu entscheiden, welche Dinge getan werden. Ein Projekt, das ständige Aufmerksamkeit braucht, um tragfähig zu bleiben, ist auch bei geringen direkten Kosten kein günstiges Projekt. Ein Projekt, das mit minimalen Eingriffen zuverlässig läuft, ist für das Portfolio wertvoller, als sein Umsatz vermuten lässt. Es verbraucht nicht die Aufmerksamkeit, die Arbeiten mit höherem Urteilsbedarf verlangen.

Wir berücksichtigen das ausdrücklich bei der Projektauswahl. Bevor wir eine neue Initiative beginnen, schätzen wir nicht nur den Entwicklungsaufwand, sondern auch den dauerhaften Aufmerksamkeitsbedarf: Wie viele Stunden pro Woche wird der Betrieb nach der Fertigstellung benötigen? Projekte mit hohem laufendem Aufmerksamkeitsbedarf im Verhältnis zum Ertrag sind weniger attraktiv, als sie bei alleiniger Betrachtung der Erstellungskosten und des möglichen Nutzens wirken. Das Aufmerksamkeitsbudget ist endlich, und anders als bei Geld oder Zeit können Sie nicht mehr davon kaufen.