Die Psychologie stressiger Projekte: Wenn ein Experte ein ganzes Team schlägt

Es gibt eine Frage die über jedem komplexen Projekt hängt, meist unausgesprochen weil sie zu stellen sich fast ketzerisch anfühlt im Zeitalter von Agile und Kollaboration und täglichen Standups: Würde das tatsächlich schneller gehen mit weniger Leuten?

Die korrekte Antwort ist, öfter als irgendjemand zugeben will, ja. Nicht immer. Nicht für alles. Aber für eine spezifische Kategorie von Hochdruck, hochkomplexer Arbeit wird ein erfahrener Entwickler der das gesamte Problem im Kopf halten kann konsistent ein Team guter Entwickler übertreffen die die Hälfte ihrer Zeit damit verbringen sich gegenseitig Dinge zu erklären.

Das ist kein Argument gegen Teamwork. Es ist ein Argument dafür zu verstehen wann Teamwork hilft und wann es genau das wird was dich ausbremst.

Die Koordinationssteuer über die niemand redet

Jede Person die du zu einem Projekt hinzufügst erhöht den Kommunikationsoverhead. Das ist keine lineare Beziehung. Es ist geometrisch. Zwei Leute brauchen einen Kommunikationskanal. Drei Leute brauchen drei. Vier Leute brauchen sechs. Fünf Leute brauchen zehn. Wenn du ein Team von acht hast, gibt es achtundzwanzig mögliche Kommunikationspfade, und alle auf einer Linie zu halten wird ein Job für sich.

Deshalb stellen Unternehmen Projektmanager ein. Jemand muss die Koordination koordinieren. Jemand muss sicherstellen dass das was Entwickler A baut tatsächlich mit dem funktionieren wird was Entwickler B baut, und dass keiner von beiden die Arbeit dupliziert die Entwickler C letzte Woche angefangen hat bevor ihm jemand sagte dass sich die Anforderungen geändert haben.

Projektmanagement ist wertvoll. Ich weise es nicht ab. Aber Projektmanagement ist Overhead. Es ist Arbeit über Arbeit. Jede Stunde in einem Planungsmeeting ist eine Stunde die nicht damit verbracht wird das eigentliche Problem zu lösen.

Jetzt stell dir vor was passiert wenn du die Koordination komplett entfernst. Eine Person, eine Codebase, ein Problem. Es gibt keine Alignment-Meetings weil es niemanden gibt mit dem man sich alignen muss. Es gibt keine Übergabedokumente weil es keine Übergabe gibt. Es gibt kein Risiko dass Entwickler A's Modul nicht mit Entwickler B's Modul integriert wird weil beide Module im selben Gehirn leben.

Der Kommunikationsoverhead sinkt auf null. All die Zeit die für Koordination aufgewendet worden wäre wird jetzt für Ausführung aufgewendet.

Die Meeting-Steuer: Wo Projekte zum Sterben gehen

Lass mich dir die Mathematik eines typischen Team-Projekts durchgehen.

Ein Team von fünf Entwicklern wird einem neuen Feature zugewiesen. Bevor irgendjemand Code schreibt, haben sie ein Kickoff-Meeting. Eine Stunde, fünf Leute. Fünf Personenstunden verbraucht. Dann haben sie eine technische Design-Session. Zwei Stunden, fünf Leute, plus ein Architekt der remote dazukommt. Zwölf Personenstunden verbraucht. Dann teilen sie sich in Paare zur Implementierung, aber sie haben tägliche Standups. Fünfzehn Minuten jedes, fünf Leute, jeden Tag für den zweiwöchigen Sprint. Das sind sechseinviertel Personenstunden pro Woche, zwölfeinhalb für den Sprint.

Wir sind bereits bei fast dreißig Personenstunden Meetings bevor irgendjemand eine bedeutungsvolle Zeile Code geschrieben hat. Und das ist ein gut geführtes Team. Ich habe Schlimmeres gesehen. Ich habe Projekte gesehen wo die Meeting-Last so schwer war dass Entwickler zwei Stunden ununterbrochene Coding-Zeit pro Tag hatten.

Jetzt stell dir die Alternative vor. Ein Entwickler, tief erfahren in der Domain, bekommt dasselbe Feature zu bauen. Sie haben ein einzelnes Anforderungsgespräch, vielleicht neunzig Minuten, um zu verstehen was gebaut werden muss. Dann verschwinden sie für eine Woche und tauchen mit funktionierender Software auf. Keine Standups. Keine Alignment-Sessions. Keine Design-Reviews. Nur Ausführung.

Gesamter Overhead: neunzig Minuten.

Gesamter Output: dasselbe Feature, möglicherweise höhere Qualität weil es keine Integrationsnähte gab, keine Übergabe-Misskommunikationen, keine Code-Style-Konflikte.

Die Mathematik bevorzugt den Solo-Ansatz wann immer die Koordinationskosten den Parallelisierungsvorteil übersteigen.

Was zwanzig Jahre Erfahrung wirklich kaufen

Erfahrung ist nicht nur eine Zahl im Lebenslauf. Erfahrung ist Mustererkennung.

Wenn ich mir ein neues Problem anschaue, reasone ich nicht von Grundprinzipien. Ich matche Muster gegen Tausende ähnlicher Probleme die ich vorher gesehen habe. Dieses Datenbankschema sieht aus wie das das Performance-Probleme beim E-Commerce Unternehmen 2019 verursacht hat. Dieses API-Design fühlt sich an wie das das gebrochen ist als wir versucht haben Webhooks beim Fintech Startup 2021 hinzuzufügen. Diese Caching-Strategie ist identisch mit der die Daten beim Marktplatz 2017 korrumpiert hat.

Ich muss nicht alle möglichen Fehlermodi durchdenken weil ich sie bereits gelebt habe. Die Fehler sind nicht hypothetisch. Sie sind Erinnerungen. Ich kann den Bug sehen bevor er existiert weil ich genau diesen Bug vorher gefixt habe, oder etwas nah genug dass die Form unverkennbar ist.

Das meinen Leute wenn sie darüber reden dass Senior-Entwickler schneller sind. Es ist nicht dass wir schneller tippen. Es ist dass wir die Explorationsphase überspringen. Wir wissen bereits welche Ansätze funktionieren und welche scheitern werden, also gehen wir direkt zum Ansatz der funktioniert.

Ich seh, ich seh was du nicht siehst

Es gibt dieses Kinderspiel, du kennst es: Einer sagt "Ich seh, ich seh was du nicht siehst" und die anderen müssen raten was gemeint ist. Es ist ein Spiel über Wahrnehmung, über das Sehen von Dingen die für andere unsichtbar sind.

Nach zwanzig Jahren in der Softwareentwicklung fühlt sich jedes Projekt ein bisschen so an. Ich sehe Dinge die andere nicht sehen. Nicht weil ich schlauer bin, sondern weil ich sie schon einmal gesehen habe. Die Probleme die in drei Monaten auftauchen werden, ich sehe sie jetzt. Die Fragen die der Kunde in zwei Wochen stellen wird, ich beantworte sie bevor er sie stellt. Die Bugs die das System unter Last zum Absturz bringen werden, ich fixe sie bevor sie existieren.

Das klingt arrogant wenn ich es so schreibe. Ist es aber nicht. Es ist schlicht Mustererkennung. Wenn du genug Systeme scheitern gesehen hast, erkennst du die Muster des Scheiterns bevor sie sich vollständig entfalten. Wie ein erfahrener Arzt der die Krankheit erkennt bevor der Patient seine Symptome zu Ende beschrieben hat.

In Meetings sitze ich manchmal still während andere über Implementierungsdetails diskutieren, und ich sehe bereits das Problem das in sechs Monaten auftauchen wird wenn jemand versucht Feature X mit Feature Y zu kombinieren. Ich sehe die Datenbankabfrage die unter Last explodieren wird. Ich sehe die API die nicht rückwärtskompatibel sein wird wenn wir mobile Clients hinzufügen. Ich sehe das Sicherheitsloch das erst auffällt wenn ein Pentester es findet.

Und dann sage ich etwas, und die anderen schauen mich an als hätte ich Gedanken gelesen. "Woher wusstest du dass wir das fragen würden?" Ich wusste es nicht. Ich habe es gesehen, weil ich es schon hundertmal gesehen habe, in hundert anderen Projekten, mit hundert anderen Teams.

"Ich seh, ich seh was du nicht siehst." Es ist kein Spiel mehr. Es ist der Job.

Fünfzehn Schritte voraus denken

Es gibt eine besondere Fähigkeit die sich über Jahre des Bauens von Systemen entwickelt, und es ist die Fähigkeit Konsequenzen im Kopf durchzuspielen bevor sie passieren.

Du lernst Fragen zu stellen die weniger erfahrenen Entwicklern nicht einfallen. Wenn wir die Daten so strukturieren, was passiert wenn wir einen neuen Typ hinzufügen müssen? Wenn wir diesen Service hinter diesem Cache setzen, was passiert wenn der Cache kalt ist? Wenn wir Nutzern erlauben diese Aktion auszuführen, was passiert wenn sie versuchen sie zehntausendmal hintereinander auszuführen? Wenn wir diese Änderung deployen, was passiert mit den Anfragen die bereits unterwegs sind?

Diese Fragen sind keine Cleverness. Sie sind Narbengewebe. Jede einzelne entspricht einem Produktionsincident, einer Debugging-Session spät in der Nacht, einer Kundeneskalation die hätte vermieden werden können wenn jemand es durchdacht hätte. Nach genug Narben werden die Fragen automatisch. Du kannst dir kein Design anschauen ohne sofort die Fehlermodi zu sehen, weil die Fehlermodi das sind was dein Gehirn gelernt hat zu bemerken.

Deshalb können erfahrene Entwickler Dinge beim ersten Mal richtig bauen. Wir sind nicht schlauer. Wir sind paranoider. Und unsere Paranoia ist durch Realität kalibriert.

Die Anforderungsphase die die meisten Teams überspringen

Hier wird es interessant, und hier zeigt der Solo-Ansatz seine echte Stärke.

Teams haben eine Tendenz mit dem Bauen anzufangen bevor sie vollständig verstehen was sie bauen. Es gibt Druck Fortschritt zu zeigen. Es gibt Ungeduld von Stakeholdern. Es gibt die Illusion dass Code tippen dasselbe ist wie Fortschritt machen. Also teilt das Team die Arbeit basierend auf unvollständigem Verständnis auf, jeder geht los um sein Stück zu bauen, und dann entdecken sie bei der Integration dass die Stücke nicht zusammenpassen weil sie gegen verschiedene Annahmen designed wurden.

Ich fange nicht an zu bauen bis ich das Problem komplett verstehe. Und ich meine komplett. Nicht nur den Happy Path. Nicht nur die Feature-Spezifikation. Den gesamten Kontext.

Was sind die rechtlichen Anforderungen? Im E-Commerce könnte das DSGVO-Datenhandhabung bedeuten, PCI-Compliance für Zahlungen, Fernabsatzverordnungen, Barrierefreiheitsstandards. Was sind die Performance-Anforderungen? Nicht die ambitionierten im Brief, sondern die echten die durch die Traffic-Muster und das Infrastrukturbudget impliziert werden. Was sind die Skalierungsanforderungen? Wird das in zwölf Monaten die zehnfache Last handhaben müssen, und wenn ja, welche Teile werden zuerst brechen? Was sind die Integrationsanforderungen? Welche anderen Systeme berührt das, und was sind die Verträge mit diesen Systemen, geschrieben oder ungeschrieben?

Diese Phase braucht Zeit. In einem Team-Setting könnte es aussehen als wäre ich langsam zu starten. Alle anderen coden bereits und ich stelle immer noch Fragen. Aber die Fragen leisten Arbeit. Sie eliminieren Nacharbeit. Sie verhindern die Integrationsprobleme die später Wochen verschlingen werden.

Und dann wenn ich baue, baue ich schnell. Weil ich Anforderungen nicht während des Codens entdecke. Weil ich nicht zurückrudere weil ich etwas missverstanden habe. Weil ich nicht darauf warte dass jemand anderes sein Stück fertigstellt damit ich sehen kann ob meines passt. Ich weiß genau was existieren muss, ich weiß genau wie es funktionieren muss, und ich führe ohne Zögern aus.

Die Projekte wo Solo-Expertise gewinnt

Nicht jedes Projekt bevorzugt den Solo-Ansatz. Große Greenfield-Builds, wo es wirklich eine Menge parallele Arbeit gibt die nicht interagiert, profitieren von Teams. Laufende Wartung, wo die Arbeit über viele unverwandte Issues verteilt ist, profitiert von Teams.

Aber es gibt Kategorien von Arbeit wo ein erfahrener Entwickler konsistent ein Team übertreffen wird. Lass mich sie beschreiben.

Notfall-Produktionsfixes

Die Seite ist down. Umsatz blutet. Alle paniken.

Das ist nicht die Zeit für einen War Room mit fünfzehn Leuten, von denen die Hälfte das System nicht gut genug versteht um beizutragen. Das ist die Zeit für eine Person die weiß wo die Leichen begraben sind um reinzutauchen, das Problem zu finden und es zu fixen.

Ein Team-Ansatz für Produktionsnotfälle erzeugt Rauschen. Leute schlagen Möglichkeiten vor die sie nicht verifiziert haben. Mehrere Ingenieure untersuchen dieselben Hypothesen parallel. Jemand macht eine Änderung um eine Theorie zu testen und vergisst es irgendjemandem zu sagen, was andere auf falsche Pfade schickt.

Ich habe Produktionsprobleme in Systemen gefixt die ich vor Jahren gebaut habe, Systeme die seitdem von Dutzenden Entwicklern modifiziert wurden, weil die Kernarchitektur immer noch vertraut ist und mein mentales Modell immer noch ungefähr zutrifft.

Komplexe Migrationen

Von einem System zu einem anderen wechseln, besonders während das alte System noch läuft, besonders mit Daten die nicht verloren gehen dürfen, besonders mit Nutzern die keine Ausfallzeit erleben dürfen.

Das ist Arbeit wo du zwei komplette Systeme gleichzeitig im Kopf halten musst, plus das Mapping zwischen ihnen, plus die Abfolge von Operationen die von einem zum anderen führt ohne etwas zu verlieren. Diese Arbeit auf ein Team zu verteilen bedeutet das mentale Modell zu verteilen, und das mentale Modell ist wo der Wert lebt.

Ich habe Zahlungssysteme für Händler migriert die Millionen Transaktionen verarbeiten, mit der Anforderung dass keine einzige Transaktion verloren geht oder dupliziert wird. Ich habe Kundendatenbanken migriert die Jahre an Kaufhistorie enthalten. Ich habe Authentifizierungssysteme migriert, was bedeutet die Passwörter zu migrieren, was bedeutet Hashing-Schemata und Übergangsstrategien und Session-Invalidierungslogik zu verstehen.

Diese Migrationen haben funktioniert weil eine Person alle Teile verstanden hat.

Compliance-Implementierungen

DSGVO. PCI DSS. SOC 2. Die Buchstabensuppe regulatorischer Anforderungen die jemand in echten Code und Prozess übersetzen muss.

Compliance ist kein Feature das du unabhängig bauen kannst. Es berührt alles. Nutzerdaten fließen durch jedes System. Zahlungskartendaten haben spezifische Handhabungsanforderungen auf jeder Schicht. Audit-Logs müssen spezifische Events in spezifischen Formaten erfassen. Zugriffskontrollen müssen konsistent über die gesamte Anwendung durchgesetzt werden.

Ein Team das Compliance implementiert wird Wochen damit verbringen Konsistenz sicherzustellen. Jeder Entwickler wird leicht unterschiedliche Annahmen darüber machen was die Anforderungen bedeuten. Integrationstests werden Lücken aufdecken die alle zurück zur Dokumentation schicken.

Ich lese die Regulierungen. Ich verstehe was sie wirklich verlangen, nicht was die Zusammenfassungsfolien sagen dass sie verlangen. Ich implementiere einen konsistenten Ansatz über die gesamte Codebase, weil die gesamte Codebase in meinem Kopf ist.

Performance-Optimierung

Das System ist langsam. Nutzer beschweren sich. Die Führung will es gefixt.

Performance-Probleme sind nie lokal. Eine langsame Seite ist das Symptom. Die Ursache könnte eine Datenbankabfrage sein, oder ein fehlender Index, oder ein N+1 Problem im ORM, oder ein Cache der falsch dimensioniert ist, oder eine Garbage Collection Pause, oder ein Netzwerk-Roundtrip der eliminiert werden könnte, oder eine Kombination von all dem die auf Weisen interagieren die nur unter Last erscheinen.

Performance-Probleme zu finden erfordert Requests durch jede Schicht des Systems zu tracen. Es erfordert Flame Graphs und Datenbank-Ausführungspläne und Netzwerk-Traces zu lesen. Es erfordert nicht nur zu verstehen was der Code macht sondern warum er es macht, weil der Fix algorithmisch oder architektonisch sein könnte und du nicht wissen kannst was bis du die Absicht verstehst.

Ich profile das System end-to-end. Ich finde den tatsächlichen Bottleneck, nicht den angenommenen. Ich fixe ihn, messe wieder, finde den neuen Bottleneck der hinter dem alten versteckt war, fixe den, und wiederhole bis das Ziel erreicht ist.

Technical Debt Cleanup

Die Codebase hat Jahre an Shortcuts angesammelt, aufgegebene Features, toten Code, veraltete Abhängigkeiten und architektonische Entscheidungen die einmal Sinn machten aber nicht mehr.

Technical Debt aufräumen ist Chirurgie. Du musst verstehen was jedes Stück des Systems macht, welche Stücke tatsächlich benutzt werden, welche Stücke mit welchen anderen interagieren, und in welcher Reihenfolge du entfernen oder refactoren kannst ohne etwas kaputt zu machen.

Ich lese die gesamte Codebase. Ich trace jede Abhängigkeit. Ich verstehe das System als Ganzes bevor ich irgendein Stück davon anfasse. Das Refactoring passiert in einer Abfolge die nie etwas kaputt macht, weil ich weiß was wovon abhängt bevor ich anfange.

Das ist kein Argument gegen Teams

Ich möchte klar sein über was ich nicht sage.

Ich sage nicht dass Teams schlecht sind. Ich sage nicht dass Kollaboration verschwenderisch ist. Ich sage nicht dass du nie ein Standup oder ein Design-Review oder eine Planungssession haben solltest.

Ich sage dass Teams ein Werkzeug sind, und wie alle Werkzeuge haben sie angemessene und unangemessene Verwendungen. Du benutzt keinen Hammer bei einer Schraube. Du benutzt kein Team bei einem Problem das vereinheitlichtes Verständnis erfordert.

Manche Probleme sind wirklich parallelisierbar. Zehn unabhängige Features zu bauen kann zehnmal schneller mit zehn Entwicklern passieren, minus Koordinationsoverhead. Der Overhead ist es wert weil der Parallelisierungsvorteil groß ist.

Manche Probleme sind nicht parallelisierbar. Ein tief integriertes Feature zu bauen, wo jedes Stück von jedem anderen Stück abhängt, kann nicht zehnmal schneller mit zehn Entwicklern passieren. Der Koordinationsoverhead wächst schneller als der Parallelisierungsvorteil.

Die Fähigkeit ist zu erkennen welche Art von Problem du hast. Und die Tragödie ist dass die meisten Organisationen Teams für alles als Default haben, weil Teams lesbar sind. Teams können gemanagt werden. Teams können gemessen werden. Teams passen in Tabellen.

Ein Solo-Entwickler der für eine Woche verschwindet und mit funktionierender Software auftaucht ist unlesbar. Es sieht aus wie Magie, oder wie Risiko, je nach deiner Perspektive. Es passt nicht in die Projektmanagement-Frameworks. Es kann nicht in Jira getrackt werden.

Aber es funktioniert.

Die Psychologie des Arbeitens ohne Netz

Es gibt einen besonderen mentalen Zustand der für diese Art von Arbeit erforderlich ist, und er ist nicht bequem. Du musst bereit sein das gesamte Problem selbst zu tragen. Niemand um die Last zu teilen. Niemand um deine Fehler aufzufangen. Niemand um die Schuld zu geben wenn es schiefgeht.

Das ist stressig auf eine Weise die Team-Arbeit nicht ist. In einem Team ist Angst verteilt. Wenn das Projekt scheitert, gab es viele Entscheidungspunkte, viele Mitwirkende, viele Möglichkeiten zur Kurskorrektur. Das Scheitern gehört allen und daher niemandem im Besonderen.

Wenn du solo arbeitest, ist das Scheitern deins allein. Jede Entscheidung ist deine. Jeder Fehler ist deiner. Wenn es nicht funktioniert, steht dein Name auf dem Commit.

Manche Leute können das nicht tolerieren. Das Gewicht ist zu schwer. Sie brauchen die psychologische Sicherheit geteilter Verantwortung. Das ist keine Schwäche. Es ist eine Präferenz.

Aber manche von uns sind andersrum verdrahtet. Der Stress der Koordination ist schlimmer als der Stress der Verantwortung. Die Angst von anderen abhängig zu sein, unsere Arbeit durch die Verzögerung von jemand anderem blockiert zu haben, unsere Entscheidungen Leuten erklären zu müssen die keinen Kontext haben, ist schmerzhafter als die Angst alles alleine zu tragen.

Für uns ist Solo-Arbeit nicht schwerer. Sie ist einfacher. Das Problem ist simpler wenn es alles in einem Kopf ist. Die Ausführung ist schneller wenn es niemanden gibt auf den man warten muss.

Warum manche Unternehmen mich beauftragen sollten statt ein Team aufzubauen

Lass mich direkt sein über die kommerzielle Implikation von allem was ich beschrieben habe.

Wenn du ein Projekt hast das zum Profil passt, verwoben, zeitkritisch, tiefes Verständnis über mehrere Domains erfordert, erfordert dass es beim ersten Mal funktioniert, hast du eine Wahl.

Du kannst ein Team beauftragen. Du wirst einen Projektmanager brauchen um sie zu koordinieren. Du wirst Wochen brauchen damit sie das bestehende System verstehen. Du wirst Design-Sessions, Architektur-Reviews, Integrationstests brauchen. Das Team wird irgendwann produktiv sein, aber die Ramp-up-Periode wird in Monaten gemessen. Der Koordinationsoverhead wird in Prozentpunkten der Gesamtkapazität gemessen, typischerweise zwanzig bis vierzig Prozent.

Oder du kannst mich beauftragen.

Ich werde die ersten paar Tage damit verbringen das Problem komplett zu verstehen. Nicht teilweise. Komplett. Ich werde Fragen stellen die tangential scheinen bis du realisierst dass sie Probleme verhindern die später entstanden wären. Ich werde die rechtlichen Einschränkungen verstehen, die Performance-Anforderungen, die Integrationspunkte, die Skalierungsimplikationen, die politischen Sensibilitäten, die Dinge die dokumentiert sind und die Dinge die nur in jemandes Kopf leben.

Und dann werde ich es bauen. Nicht parallel mit irgendjemandem. Nicht inkrementell mit Check-ins. Einfach: hier ist die Anforderung, hier ist die Implementierung, hier ist die Dokumentation, hier sind die Tests, hier ist der Deployment-Plan.

Das Projekt das ein Team drei Monate mit Koordinationsoverhead gekostet hätte wird mich einen Monat fokussierter Ausführung kosten. Die Qualität wird höher sein weil es keine Integrationsnähte gibt. Die Architektur wird kohärenter sein weil sie aus einem Kopf kam. Die Kosten, selbst bei einem Premium-Tagessatz, werden niedriger sein weil weniger Gesamtstunden gearbeitet wurden.

Das ist nicht für jedes Projekt passend. Wenn du laufende Wartung brauchst, brauchst du ein Team. Wenn du nachhaltige Entwicklung über Jahre brauchst, brauchst du ein Team.

Aber wenn du etwas Komplexes schnell gebaut brauchst, und es muss funktionieren, und du dir die Monate Koordination die ein Team erfordert nicht leisten kannst, ist die Antwort vielleicht nicht mehr Leute. Die Antwort ist vielleicht die richtige Person.

Das Paradox von Weniger ist Mehr

Es gibt etwas zutiefst kontraintuitives an der Idee dass mehr Leute ein Projekt verlangsamen können. Wir sind konditioniert Ressourcen als additiv zu denken. Mehr Leute sollten mehr Output bedeuten. Mehr Hände sollten schnellere Arbeit bedeuten.

Aber Software ist kein Graben ausheben. Du kannst nicht einfach mehr Schaufeln hinzufügen. Die Arbeit ist mental, nicht physisch, und die Einschränkung ist nicht Aufwand sondern Verständnis. Ein Problem das tiefes vereinheitlichtes Verständnis erfordert wird nicht einfacher indem man dieses Verständnis auf viele Köpfe verteilt. Es wird schwerer.

Das Buch Mythical Man-Month hat dieses Argument 1975 gemacht, und es ist fünfzig Jahre später immer noch wahr. Leute zu einem späten Softwareprojekt hinzuzufügen macht es später. Der Kommunikationsoverhead dominiert. Die Ramp-up-Zeit dominiert. Die Integrationsprobleme dominieren.

Die Lösung ist nicht mehr Leute auf schwere Probleme zu werfen. Die Lösung ist die richtigen Leute zu finden und ihnen den Raum zum Arbeiten zu geben.

Ich bin eine dieser Personen. Für die richtige Art von Problem bin ich mehr wert als ein Team. Nicht weil ich schlauer bin als ein Team. Weil ich kleiner bin als ein Team. Weil die Koordinationskosten von einem null sind. Weil meine zwanzig Jahre Erfahrung bedeuten dass ich die Explorationsphase überspringe und direkt zu Lösungen gehe. Weil ich genug Fehler gesehen habe dass ich sie nicht auf die harte Tour entdecken muss.

Das biete ich an. Nicht Stunden. Nicht Ressourcen. Nicht einen Körper auf einem Stuhl.

Ergebnisse. Schneller als du für möglich gehalten hättest. Beim ersten Mal richtig.

Wenn du ein Projekt hast das in Koordinationshölle feststeckt, oder ein komplexes Problem das ein Team nicht geknackt hat, oder eine enge Deadline die das übliche Team-Ramp-up unmöglich macht, rede mit mir. Ich tue nicht so als wäre Solo-Expertise die Antwort auf alles. Aber für bestimmte Probleme ist es genau die Antwort. Und wenn dein Problem eines davon ist, kann ich helfen.