7. Mai 2026
Direkte Verantwortung beim Engineer: Warum weniger Handoffs schneller liefern
3 MIN. LESEZEIT
Die meisten Softwareprojekte scheitern nicht an schlechtem Code. Sie scheitern an schlechter Kommunikation.
Wenn Sie jemals eine klassische Softwareagentur beauftragt haben, um ein Legacy-ERP zu integrieren oder eine individuelle Shopify-App zu bauen, kennen Sie wahrscheinlich das stille Post-Spiel der modernen Webentwicklung. Sie erklären Ihren operativen Engpass einem Sales Executive. Diese Person fasst es für einen Account Manager zusammen. Der Account Manager schreibt ein Briefing für eine Solutions-Architektin oder einen Solutions-Architekten. Daraus entsteht ein Diagramm, das an einen Projektmanager geht, der am Ende Jira-Tickets für einen Junior-Entwickler erstellt.
Bei jeder Übergabe geht entscheidender fachlicher Kontext verloren. Wenn der Code schließlich geschrieben wird, weiß der Entwickler oft nicht mehr, warum das System auf eine bestimmte Weise funktionieren muss. Er arbeitet nur noch ein Ticket ab. Taucht dann eine unerwartete Eigenheit in Ihrer Legacy-Datenbank auf, steht die Entwicklung still, während die Frage wieder die gesamte Kette nach oben wandert.
Ich arbeite bewusst nach dem gegenteiligen Modell: Direkte Engineer-Verantwortung.
Direkte Verantwortung bedeutet: Dieselbe Person, die die Architektur entwirft, implementiert auch die Lösung und übernimmt Produktionsprobleme. Ohne diese Übersetzungsebenen bleibt die Entscheidungsfindung dort, wo sie hingehört: nah am Code.
So sieht dieses Modell in der Praxis aus.
1. Kickoff: Technische Realität statt Sales-Folien
Agenturen lieben die Discovery-Phase: mehrere Wochen Aufwand, hohe Kosten, am Ende ein farbiges Deck und eine grobe Schätzung.
Ich verkaufe keine Folien. Unser Kickoff ist ein einziges, hochfokussiertes technisches Gespräch. Sie bringen Ihre Randbedingungen, Ihre API-Dokumentation und den operativen Engpass mit. Wir mappen die Datenstrukturen, identifizieren die Grenzen Ihres aktuellen ERP und definieren das exakt messbare Ergebnis, das die Integration liefern muss.
Kein Sales-Overhead. Wir klären sofort die technische Realität und legen einen klaren Weg fest.
2. Umsetzung: Das Ende der Handoffs
In klassischen Teams ist der größte Engpass nicht das Tippen von Code, sondern das Warten. Warten auf Reviews, Warten auf QA, Warten darauf, dass ein Projektmanager ein Ticket entblockt.
Wenn eine Person Architektur, Entwicklung, Tests und Rollout verantwortet, fallen diese Wartezeiten weg. Wenn ich zum Beispiel eine B2B-Preislogik-App baue und feststelle, dass Ihr Legacy-System Staffelpreise anders formatiert als erwartet, muss ich kein Meeting mit einer Solutions-Architektin oder einem Solutions-Architekten ansetzen, um eine Modelländerung freizugeben. Ich passe die Architektur an, überarbeite den Go-Parser und arbeite weiter.
Geschwindigkeit in der Softwareentwicklung entsteht nicht durch schnelleres Tippen. Sie entsteht durch weniger Wartezustände und vollständigen Kontext über das gesamte System.
3. Reporting: Hohes Signal, wenig Rauschen
Viele agile Routinen sind zu Ritualen ohne Mehrwert geworden. Sie haben keine Zeit für tägliche Standups, Backlog-Grooming oder wöchentliche Retrospektiven darüber, wie sich ein Team fühlt.
Sie müssen wissen, ob das Projekt auf Kurs ist.
Mein Reporting ist strikt asynchron und auf ein hohes Signal-Rausch-Verhältnis ausgelegt. Sie erhalten wöchentlich ein strukturiertes Delta mit genau drei Punkten:
- Abgeschlossene Arbeit: Was in dieser Woche tatsächlich ausgeliefert oder getestet wurde.
- Aktuelles Risiko: Welche technischen Unbekannten oder API-Grenzen den Zeitplan gefährden und wie ich sie abfedere.
- Nächster Schritt: Was ich als Nächstes konkret umsetze.
4. Eskalation: Direkt zur implementierenden Person
Wenn ein kritisches System ausfällt, etwa wenn der Lagerabgleich während eines großen Black-Friday-Peaks stoppt, kostet jede Minute Geld.
Im Agenturmodell eröffnen Sie ein Support-Ticket. Ein Account Manager priorisiert es und weist es einem verfügbaren Maintenance-Entwickler zu, der Ihre Codebasis noch nie gesehen hat. Vier Stunden vergehen oft allein dafür, die Architektur zu verstehen, bevor die eigentliche Fehlerbehebung beginnt.
Bei direkter Verantwortung gehen Incidents direkt an die implementierende Person. Wenn Sie mich wegen eines Problems kontaktieren, sprechen Sie mit der Person, die das System von Grund auf gebaut hat. Ich kenne Datenflüsse, Logs und API-Verhalten bereits. Der Kontext ist schon da, und die mittlere Lösungszeit sinkt deutlich.
Was Sie mit direkter Verantwortung gewinnen
Wenn Sie die aufgeblähten Agentur-Ebenen weglassen und mit einem unabhängigen Infrastruktur-Spezialisten arbeiten, sind die geschäftlichen Vorteile unmittelbar:
1. Schnellere Reaktionsschleifen
Weil kein Projektmanager als Zwischeninstanz agiert, können Änderungen an Geschäftsanforderungen sofort in die Codebasis einfließen. Wenn sich Ihre Strategie ändert, ändert sich die Software mit, ohne auf das nächste Sprint-Planning zu warten.
2. Weniger Koordinationsaufwand
Sie bezahlen ausschließlich für Engineering-Zeit und Problemlösung. Sie finanzieren keinen Agentur-Overhead für Scrum Master, Büroflächen oder Account Management. Jeder investierte Euro geht direkt in schnellere und stabilere Shopify-Infrastruktur.
3. Klare Verantwortung für technische Ergebnisse
Es gibt kein Fingerpointing. Ich kann nicht das Frontend-Team verantwortlich machen und auch nicht die Systemarchitektur. Ich habe es gebaut. Wenn es funktioniert, dann weil es sauber umgesetzt wurde. Wenn es ausfällt, liegt die Behebung bei mir.
Wenn Sie Handoffs eliminieren, eliminieren Sie Ausreden. Sie bekommen funktionierende Software.