Vom Marketingberater zum Entwickler: warum ich eine Grenze überschritten habe, die die meisten nicht überschreiten
Kurz gesagt: Nach mehr als einem Jahrzehnt, in dem ich Marken in Sachen Branding, Marketing und Kommunikation beraten habe, sowohl auf Agenturseite als auch unabhängig, stieß ich immer wieder auf dieselbe Wand: Entwickler, die fast alles bauen konnten, aber selten verstanden, warum eine Marketing- oder Designentscheidung überhaupt wichtig war. Die Übersetzung zwischen uns kostete immer wieder echte Zeit und echtes Geld, über verschiedene Teams und verschiedene Jahre hinweg. Irgendwann hörte ich auf, die Lücke mit neuen Mitarbeitern zu stopfen, und begann, sie selbst zu schließen.
Die Wand, gegen die ich immer wieder stieß
Über zwölf Jahre hinweg, in Branding, Marketing und Kommunikation, arbeitete ich auf beiden Seiten der Agenturwelt: innerhalb von Agenturen, die viele Marken gleichzeitig betreuten, und unabhängig, in direkter Beratung. Unterschiedliche Räume, unterschiedliche Kunden, dieselbe Wand.
Ich übergab eine Strategie, einen Gedanken aus dem Designprozess, einen Grund, warum eine Headline genau das sagen musste, was sie sagte, und sah dann, wie es auf der anderen Seite der Umsetzung ankam, verändert auf eine Weise, die etwas ausmachte. Nicht aus böser Absicht. Einfach verloren gegangen. Ein Entwickler vereinfachte etwas aus technischer Bequemlichkeit und merkte nicht, dass er dabei still und leise den eigentlichen Sinn entfernt hatte. Oder er baute exakt das, worum gebeten worden war, wörtlich, ohne das „Warum“ dahinter zu verstehen, und lieferte etwas ab, das technisch korrekt und strategisch falsch war. Oder wir beide verbrachten Tage damit, ein Stück Strategie in ein Briefing zu übersetzen, mit dem ein Entwicklungsteam arbeiten konnte, und trotzdem ging bei diesem Hin und Her etwas verloren. Oder die Arbeit war technisch exzellent und völlig gleichgültig gegenüber dem, was sie tatsächlich für die Konversion oder für die Marke bedeutete.
Keiner dieser Fälle war ein schlechter Entwickler oder ein schlechter Monat. Es war immer derselbe Fehler, nur in anderem Gewand, wieder und wieder, über verschiedene Teams und verschiedene Jahre hinweg. Jedes Mal kostete es Zeit, es kostete Geld, und schlimmer noch: Es kostete den Kunden eine Version der Arbeit, die still und leise schlechter war als die, die ursprünglich entworfen worden war.
Warum Einstellungen das Problem nie lösten
Die naheliegende Lösung sieht so aus: besser einstellen, gründlicher briefen oder „den richtigen Entwickler“ finden. Ich habe alle drei versucht, mehr als einmal. Sie helfen am Rande. Sie lösen nicht das strukturelle Problem: dass ein Briefing eine Übersetzung ist und jede Übersetzung etwas verliert. Die Person, die es empfängt, war nie in dem Raum, in dem die Entscheidung getroffen wurde, also füllt sie die Lücken mit einer eigenen, vernünftigen Vermutung, und vernünftige Vermutungen driften ab.
Das ist kein Einstellungsproblem. Es ist ein Distanzproblem. Die einzige Lösung, die es wirklich behebt, ist, die Distanz zu beseitigen: die Person, die versteht, warum eine Entscheidung getroffen wurde, auf denselben Platz zu setzen wie die Person, die sie baut.
Die Entscheidung
Also traf ich die Entscheidung, die die meisten Menschen in meiner Position nicht treffen. Ich hörte auf, die Umsetzung abzugeben, und lernte, sie selbst zu übernehmen.
Dahinter stand kein Bootcamp und kein Kurs. Ich brachte es mir direkt an echter Arbeit selbst bei, baute für echte Projekte, während ich lernte, statt zunächst an Wegwerfübungen zu üben und es später anzuwenden. Es war langsamer und unordentlicher, als ein strukturierter Kurs gewesen wäre, und es bedeutete, öffentlich zu lernen, an Arbeit, die zählte, ohne Sicherheitsnetz zwischen einem Fehler und dem Moment, in dem ein Kunde ihn sah. Es war auch der einzige Weg, der die Lücke tatsächlich schloss, denn jedes Projekt, das ich baute, war ein echter Test dafür, ob die Strategie die Umsetzung überlebt hatte, keine Simulation davon.
Was sich tatsächlich veränderte
Der Unterschied bestand nicht darin, dass mein Code besser wurde als der eines spezialisierten Entwicklers. Das war er selten, und ich habe nie etwas anderes behauptet. Der Unterschied war, dass nichts mehr verloren ging. Die Überlegung hinter einer Entscheidung musste keine Übergabe mehr überstehen, weil es keine Übergabe mehr gab. Die Person, die verstand, warum etwas wichtig war, war dieselbe Person, die es baute, sodass das „Warum“ nie mehr übersetzt werden musste und nie die Chance hatte, abzudriften.
Das ist die ganze Begründung dafür, die Grenze vom Berater zum Entwickler zu überschreiten. Nicht, dass eine einzelne Person einen Spezialisten beim Bauen übertreffen kann. Sondern dass eine Person, die beide Enden derselben Entscheidung in der Hand hält, aufhört, das zu verlieren, was bei einer Staffelübergabe immer verloren geht.
Häufig gestellte Fragen
Weil das Problem nicht die Qualität der Entwickler war, mit denen ich zusammenarbeitete. Es war die Distanz. Ein Briefing ist eine Übersetzung, und jede Übersetzung verliert etwas, unabhängig davon, wie kompetent die Person ist, die sie empfängt. Die einzige wirkliche Lösung war, den Übersetzungsschritt vollständig zu entfernen.
Mehrere Dinge, die sich überschnitten und die alle wiederholt auftraten: Design- und UX-Absichten wurden stillschweigend aus technischer Bequemlichkeit gestrichen, Arbeit wurde exakt so umgesetzt, wie sie wörtlich verlangt worden war, ohne zu verstehen, warum es wichtig war, dazu ein langsamer und teurer Hin-und-Her-Prozess, um Strategie in ein technisches Briefing zu übersetzen, sowie technisch solide Arbeit, die ignorierte, was sie tatsächlich für Konversion oder Marke bedeutete.
Nein. Ich habe es mir direkt an echten Projekten selbst beigebracht und für reale Kundenarbeit gebaut, während ich lernte, statt zuerst getrennt zu üben. Das war schwieriger, bedeutete aber, dass jede Fähigkeit, die ich mir aneignete, sofort an Arbeit geprüft wurde, die tatsächlich zählte.
Es ist nicht ohne Risiko, und stellenweise war es langsamer, als ein strukturierter Kurs es gewesen wäre. Aber es war auch der einzige Weg, wirklich zu prüfen, ob ein Stück Strategie die Umsetzung überstanden hatte, denn es gab kein Ersatzprojekt, das für das echte einspringen konnte.
Nein, und das war auch nie der Punkt. Die Behauptung war nie, dass ich einen Spezialisten im Bauen übertreffen könnte. Es ging darum, dass die gleichzeitige Verantwortung für Strategie und Umsetzung bedeutete, dass die Überlegung hinter einer Entscheidung nie eine Übergabe überstehen musste, weil es keine Übergabe gab, die sie hätte überstehen müssen.
Die Einzelheiten dazu behalte ich für mich, aber der Wechsel von einer etablierten Beraterkarriere zum praktischen Bauen ist kein üblicher Schritt, und man kann sagen, dass er für Stirnrunzeln sorgte. Entschieden haben letztlich die Ergebnisse.
Beides. Meine eigene Erfahrung war spezifisch für mich, aber das zugrunde liegende Problem, dass ein Briefing bei jeder Übergabe Informationen verliert, ist überhaupt nicht spezifisch für mich. Aus demselben Grund ist Thabrew Effect darauf aufgebaut, dass eine einzige Person Strategie, Design, Umsetzung und Wachstum zusammenhält.
Nein. Die Lehre daraus lautet nicht "alle sollten programmieren lernen". Sie lautet: Überall dort, wo eine Entscheidung eine Übergabe durchlaufen muss, besteht das Risiko, dass etwas verloren geht, und die Lösung besteht entweder darin, die Übergabe zu entfernen, oder dafür zu sorgen, dass die Überlegung dahinter bewusst mitgegeben wird. Für mich war es richtig, sie zu entfernen. Für alle anderen muss das nicht die richtige Entscheidung sein.