Vertrauen ist eine wichtige Grundlage für Zusammenarbeit. Es ersetzt aber weder einen geklärten Produktumfang noch Entscheidungsrechte, Ressourcen und eine faire Verteilung von Chancen und Risiken.
Was bedeutet technische Gesamtverantwortung?
Bezeichnungen wie CTO, Technical Lead oder technischer Partner können sehr unterschiedliche Aufgaben meinen. Vor einer Zusage muss deshalb sichtbar werden, welche Verantwortung tatsächlich erwartet wird.
Zur technischen Gesamtverantwortung können unter anderem gehören:
- Produkt- und Systemarchitektur
- Entwicklung von App, Webanwendung und Backend
- Datenschutz, Informationssicherheit und Verfügbarkeit
- Auswahl, Steuerung und Finanzierung weiterer Entwickler
- Veröffentlichung, Betrieb, Wartung und Support
- technische Skalierung und langfristige Weiterentwicklung
Damit ist die Rolle nicht nur eine Entwicklungsleistung. Sie kann zugleich operative Verantwortung, unternehmerisches Risiko und eine Investition aus Zeit, Infrastruktur und Reputation enthalten.
Grundsatz
Je größer die erwartete Verantwortung, desto klarer müssen Entscheidungsrechte, Ressourcen und wirtschaftliche Beteiligung geregelt sein.
Sieben Prüffragen vor einer Zusage
1. Welches Problem ist bereits belegt?
Eine klare Vision ist noch kein Nachweis für ein relevantes Problem. Wichtig sind Gespräche mit der Zielgruppe, beobachtbares Verhalten, bestehende Ersatzlösungen und erste Hinweise auf Zahlungsbereitschaft.
2. Was gehört wirklich zum ersten Produkt?
Ein MVP ist kein vollständiges Wunschbild mit weniger Zeit. Es braucht eine begrenzte Kernfrage, klare Nutzergruppen und eine Liste dessen, was ausdrücklich noch nicht umgesetzt wird.
3. Wer entscheidet bei Zielkonflikten?
Technische Verantwortung ohne Einfluss auf Umfang, Qualität, Zeitplan und Ressourcen ist nicht belastbar. Es muss geregelt sein, wer Prioritäten setzt und wer ein technisch nicht vertretbares Vorgehen stoppen kann.
4. Welche Mittel stehen tatsächlich zur Verfügung?
Entwicklung benötigt Zeit, Werkzeuge, Infrastruktur und oft weitere Fachleute. Ein Plan ist nur dann realistisch, wenn auch geklärt ist, wer diese Mittel finanziert und verfügbar macht.
5. Wie werden geistiges Eigentum und Vorleistungen behandelt?
Quellcode, wiederverwendbare Bausteine, projektspezifische Ergebnisse und bestehendes Wissen sollten voneinander unterschieden werden. Rechteübergänge brauchen einen klaren Zeitpunkt und eine nachvollziehbare Gegenleistung.
6. Passen Risiko und wirtschaftliche Chance zusammen?
Wer ohne gesicherte Vergütung Zeit und Betriebsmittel einbringt, investiert unternehmerisch. Das wirtschaftliche Modell sollte deshalb nicht nur den möglichen Erfolg, sondern auch Vorleistung, Haftung, Bindungsdauer und Ausstieg berücksichtigen.
7. Was passiert, wenn Annahmen nicht bestätigt werden?
Eine verantwortliche Partnerschaft definiert nicht nur den Erfolgsfall. Sie regelt auch, wann ein Pilot angepasst oder beendet wird, wie eine Trennung abläuft und wie mit Code, Daten, Zugängen und laufenden Kosten umgegangen wird.
Ein einfacher Verantwortungscheck
Die folgenden vier Felder sollten gemeinsam betrachtet werden. Ein Ungleichgewicht in einem Feld wirkt meist auf alle anderen.
Warnsignale in frühen Gesprächen
Ein einzelnes Warnsignal muss eine Zusammenarbeit nicht ausschließen. Mehrere gleichzeitig sollten jedoch zu einer langsameren und gründlicheren Prüfung führen.
- Ein fester Veröffentlichungstermin steht vor dem geklärten Umfang.
- Verantwortung wird vollständig übertragen, Entscheidungen bleiben jedoch an anderer Stelle.
- Budget und Team sollen sich erst nach einer verbindlichen Zusage klären.
- Alle technischen Ergebnisse sollen früh übergehen, während die Gegenleistung unbestimmt bleibt.
- Rückfragen zur Tragfähigkeit werden als fehlendes Vertrauen statt als Teil der Verantwortung behandelt.
Entscheidungsregel
Eine Zusage sollte erst erfolgen, wenn Aufgabe, Befugnisse, Ressourcen und wirtschaftliches Modell dieselbe Verantwortung beschreiben.
Häufige Fragen
Ist eine Umsatzbeteiligung grundsätzlich ungeeignet?
Nein. Sie kann sinnvoll sein, wenn Berechnungsgrundlage, Dauer, Informationsrechte, Kostenverteilung und Ausstieg klar geregelt sind und zur tatsächlichen Vorleistung passen.
Braucht jede technische Partnerschaft eine Beteiligung am Unternehmen?
Nein. Festvergütung, Meilensteinzahlungen, Umsatzbeteiligung und Unternehmensanteile können jeweils passen. Entscheidend ist das Gesamtverhältnis von Risiko, Einfluss und Gegenleistung.
Warum sollte die Produktvalidierung vor der Architektur beginnen?
Architekturentscheidungen hängen von Nutzerzahl, Daten, Abläufen, Sicherheitsbedarf und Geschäftsmodell ab. Ungeprüfte Annahmen werden sonst früh und teuer in Technik übersetzt.
Der Beitrag beschreibt eine allgemeine Arbeits- und Prüfmethode und ersetzt keine rechtliche oder steuerliche Beratung.