Ich schaue sechs Monate zurück und kann mich kaum noch erinnern, wie wir vor einem Jahr gearbeitet haben. Nicht aus Nostalgie, sondern aus purer Verwunderung. Wie wenn man in ein Haus zurückkehrt, in dem man einmal gelebt hat, und die Räume nicht wiedererkennt.
Es begann als Experiment ohne Namen. Heute hat es immer noch keinen, aber es hat eine erkennbare Form. Bei Dcycle trägt das gesamte Unternehmen zur Codebasis des Produkts bei. Nicht nur die Ingenieure. Customer Success stellt Automatisierungen bereit. Marketing baut eigene Datenflüsse. Ops erstellt Dashboards, die früher drei Meetings und ein Ticket erforderten. Niemand muss sie ausdrücklich darum bitten. Die Werkzeuge erlauben es einfach, und die Neugier erledigt den Rest.
Was während dieses Experiments passierte, ist, dass Geschwindigkeit die Kultur veränderte. Nicht umgekehrt. Es war nicht so, dass wir zuerst ein Autonomie-Manifest entwarfen und die Leute dann anfingen zu bauen. Es war, dass jemand aus dem CS-Team es leid war, zwei Zyklen zu warten, um ein Problem zu lösen, das er gut kannte, Claude Code öffnete und es behob. Als das Team das Ergebnis sah, fragte niemand, ob das "seine Rolle" war. Sie fragten, wie man es macht.
Wir hatten das Autonomie-Gen bereits in uns, aber die Werkzeuge haben es zum Explodieren gebracht.
Was eine bewusste Entscheidung ist, ist es aufrechtzuerhalten. Ich hoffe, dass jede Person in diesem Team den Reflex hat, zu lösen, bevor sie delegiert. Wenn du ein Problem siehst und es beheben kannst, behebe es. Du hast bereits die Erlaubnis. Wenn du es nicht kannst, lerne genug, um es beim nächsten Mal zu können. Suche einen Weg zu lernen; wenn du keinen findest, bitte um Hilfe. Du wirst immer eine helfende Hand in der Nähe finden.
Dein Titel beschreibt nicht mehr, was du tust
Es gibt etwas, das nicht oft genug gesagt wird darüber, was passiert, wenn jeder Lösungen bauen kann: dein Titel hört auf, ausschließlich zu beschreiben, was du tust.
Marina ist immer noch im Customer Success. Aber letzte Woche hat sie einen Bot bereitgestellt, der Nutzungsdaten mit Churn-Signalen verknüpft und Slack-Warnungen mit Handlungsvorschlägen generiert. Juan ist immer noch im Finance, aber er hat ein Finanzabstimmungssystem gebaut, das uns früher zwei Tage kostete und jetzt zehn Minuten dauert. Sie haben nicht aufgehört, ihre Arbeit zu machen. Ihre Arbeit umfasst jetzt auch das Entwerfen der Maschinen, die einen Teil ihrer Arbeit erledigen.
Ich weiß, das kann wie ein LinkedIn-Unternehmer klingen. Aber es zu leben hat einen ganz anderen Geschmack als es zu lesen. Es zu leben fühlt sich eher wie eine produktive Desorientierung an: das Gefühl, dass das, was man konnte, nicht mehr ausreicht, aber das, was man tun kann, mehr ist als je zuvor. Das kann ich bestätigen.
Manager von einem und vielen
Wir nennen es "Manager von einem und vielen", und ich weiß, es klingt seltsam. Aber es erfasst etwas Reales.
Jede Person bei Dcycle managt ihre eigene Arbeit. Das ist das "von einem". Sie haben die Autonomie zu entscheiden, was sie bauen, wie sie etwas lösen oder wann sie iterieren. Sie warten nicht auf Genehmigungen, um etwas zu verbessern. Die Tendenz geht zum Handeln.
Und jede Person orchestriert außerdem Agenten. Das ist das "von vielen". Nicht im Science-Fiction-Sinne. Im praktischen Sinne: Sie entwerfen Prompts, definieren Abläufe, machen Dinge kaputt und reparieren sie, überwachen Outputs, korrigieren Fehler. Sie haben ein Team von Agenten, das ihre Kapazität verstärkt. Wir sind von "Tun" zu "Entwerfen, wie es gemacht wird" übergegangen und überprüfen dann, ob es gut gemacht wurde.
Der "Agent Manager" ist kein neuer Jobtitel (wenn ihr ihn irgendwo seht, seid misstrauisch, es ist der neue 'Director of Innovation'). Es ist eine neue Kompetenzschicht, die unter allem anderen liegt. Es spielt keine Rolle, ob du im CS, Produkt oder Vertrieb bist. Wenn du nicht weißt, wie man Agenten orchestriert, nutzt du zwanzig Prozent deiner Kapazität und erreichst zehn Prozent dessen, was du könntest.
Das ist nicht optional. Ich erwarte, dass alle Zeit investieren, um zu lernen, wie man mit Agenten arbeitet. Es ist der Unterschied zwischen jemandem, der Aufgaben erledigt, und jemandem, der Systeme entwirft. Und hier, jetzt, suchen wir Letzteres.
Silos sind vorbei
Und hier ist die Konsequenz, die ich am wenigsten kommen sah: funktionale Silos sind vorbei. Nicht weil wir einen Workshop für bereichsübergreifende Zusammenarbeit durchführen. Nicht weil wir ein gemeinsames OKR haben. Sie lösen sich auf, weil man, wenn man mehr Dinge tun kann, unweigerlich mehr Bereiche berührt.
Die Abhängigkeit zwischen Teams war der Klebstoff, der die Silos an ihrem Platz hielt. Durch die Beseitigung der Abhängigkeit verlieren Silos ihre Daseinsberechtigung. Was bleibt, sind Menschen, die immer mehr über alles wissen und sich zwischen Problemen bewegen, statt zwischen Abteilungen.
Es gibt kein Innovationskomitee. Es gibt kein Labor, das vom Rest getrennt ist. Was es gibt, ist ein Schneeball, den jede Person in eine andere Richtung schiebt, und das Ergebnis ist etwas, das keiner von uns allein hätte entwerfen können. Die Grenze wird nicht geplant. Sie wird entdeckt, jeden Tag, wenn jemand eine Grenze überschreitet, von der niemand ihm gesagt hat, dass er sie überschreiten darf.
Lies diesen Satz noch einmal
Letzte Woche hat unser Talent Manager einen Bug in der Produktion behoben. Er hat nicht den falschen Beruf gewählt. Er sah etwas Kaputtes, lernte genug, um es zu verstehen, und behob es. Bald wird sich ein Entwickler hinsetzen und Aufnahmen von Prospecting-Calls anhören, aus einer Prospecting-Kadenz, die ein SDR von Anfang bis Ende entworfen hat, aber nicht allein ausführt. Der SDR entwirft die Strategie, die Agenten führen sie aus, und der Entwickler will immer noch verstehen, was die Kunden sagen, um das zu verbessern, was er gerade baut.
Ein SDR, der entwirft, aber nicht ausführt. Ein Entwickler, der Vertriebsgespräche anhört. Ein Talent Manager, der Code pusht. Wenn man es aus der Logik des Organigramms betrachtet, ist es ein Desaster. Wenn man es aus der Logik der Ergebnisse betrachtet, sind wir so effizient wie noch nie.
Das passiert, wenn man aufhört, die Grenzen zwischen Rollen zu schützen, und anfängt, die Neugier zu schützen. Der Schneeball wächst in alle Richtungen. Und die Grenze ist nicht vorne. Sie ist überall.
Die Spannungen
Ich möchte das nicht als Eden darstellen. Es hat seine Spannungen.
Die offensichtlichste: Wenn jeder bauen kann, wer entscheidet, was gebaut wird? Autonomie ohne Ausrichtung ist Chaos. Die Antwort ist nicht weniger Autonomie, sondern mehr Sichtbarkeit. Deshalb erwarte ich etwas sehr Konkretes: Teile mit, was du baust, bevor du es baust. Denke laut. Veröffentliche, bevor du perfektionierst. Transparenz ist kein Nice-to-have. Sie ist das, was Autonomie funktionieren lässt und sie nicht zur Anarchie werden lässt.
Es gibt eine stille Falle in der Baufähigkeit: Es ist sehr leicht, Output mit Outcome zu verwechseln. Etwas zu bauen, das funktioniert, ist nicht dasselbe wie etwas zu lösen, das wichtig ist.
Bevor du Claude Code öffnest, bevor du den Flow entwirfst, gibt es eine Frage, von der ich hoffe, dass sich jeder sie stellt: Was muss anders sein, wenn das fertig ist? Nicht was werde ich bauen, sondern was muss sich verändert haben. Der Output ist das Mittel; der Outcome ist der Punkt.
Das bremst das Handeln nicht: Es orientiert es. Ein Builder, der genau weiß, was er zu verändern versucht, baut schneller, nicht langsamer, weil jede Entscheidung einen klaren Norden hat.
Die zweite Spannung: die berufliche Identität. Wenn du nicht mehr "nur Marketing" oder "nur Ops" bist, was bist du? Das erzeugt Unbehagen. Es gibt Menschen, die Sicherheit in der Spezialisierung fanden und die jetzt spüren, dass der Boden sich bewegt. Ich verstehe das. Aber ich hoffe, dass ihr dieses Unbehagen annehmt, anstatt davor zu fliehen. Denn was du bist, ist ein Builder, der viel über Marketing weiß. Ein Learner, der Ops beherrscht. Deine Expertise verschwindet nicht. Sie wird zu deiner Perspektive, nicht zu deinem Perimeter. Den Perimeter zu erweitern ist ein Zeichen einer guten Richtung.
60 Menschen, 100x mehr Kapazität
Wir sind dieselben sechzig Menschen. Aber der Output dieses Unternehmens wird im Vergleich zu vor einem Jahr nicht wiederzuerkennen sein. Nicht weil wir mehr Stunden arbeiten. Wir arbeiten und werden die gleichen Stunden arbeiten. Es ist so, dass jede Person mit einem Team von Agenten hinter sich, das alles verstärkt, was sie tut, ihren Wirkungsradius um das 100-fache multipliziert. Was früher zwei Personen und eine Woche erforderte, kann jetzt eine Person an einem Nachmittag lösen. Nicht immer. Aber immer häufiger.
Das hat enorme Auswirkungen darauf, wie wir über Wachstum nachdenken. Die Frage lautet nicht mehr "wie viele Menschen müssen wir einstellen", sondern "wie sehr können wir die Kapazität derer verstärken, die wir bereits haben". Es ist kein Argument gegen Einstellungen. Es ist ein Argument dafür, anders einzustellen: Menschen, die orchestrieren können, die schnell lernen, die sich in der Ambiguität einer Rolle wohlfühlen, die sich jedes Quartal ändert. Und ich erwarte dasselbe von denen, die bereits hier sind: dass ihr jeden Monat in der Lage seid, mehr zu tun als im Monat davor. Nicht mehr Stunden. Mehr Kapazität.
Builders und Learners
So beschreiben wir, was wir suchen und wie wir an die Arbeit herangehen.
Builder, weil du baust. Du denkst nicht nur, du planst nicht nur, du machst nicht nur Strategien (und schon gar keine PowerPoints). Du bringst Dinge in die Welt. Code, Automatisierungen, Dokumente, Systeme. Dinge, die funktionieren, die einen Output haben, die jemand morgen nutzen kann. Ich erwarte, dass jede Woche jede Person in diesem Team etwas in die Welt gebracht hat, das am Montag noch nicht existierte.
Learner, weil das, was du heute weißt, für morgen nicht ausreicht. Vor sechs Monaten wusste niemand in diesem Team, wie man Agenten orchestriert. Vor drei Monaten taten es einige mit Mühe. Heute wird es zum Standard. Die Geschwindigkeit, mit der sich Werkzeuge ändern, die Schwelle des Möglichen, erfordert eine gleichwertige Lerngeschwindigkeit. Warte nicht, dass jemand kommt, um dich zu unterrichten. Geh und lerne. Es ist einfacher als je zuvor. Wer aufhört zu lernen, hört auf. Ich erwarte unermüdliche Neugier. Ich erwarte, dass ihr Dinge durch Ausprobieren kaputt macht. Ich erwarte Fragen vor Gewissheiten. Wenn du etwas Neues gelernt hast, teile es, innerhalb und außerhalb von Dcycle.
Es sind nicht zwei verschiedene Dinge. Es ist dasselbe: Du baust, um zu lernen, und du lernst, um zu bauen.
Mein Teil
Alles oben ist, was ich von euch erwarte. Jetzt mein Teil.
Wenn ich euch bitte zu bauen, verpflichte ich mich, Hindernisse aus dem Weg zu räumen. Jeder Prozess, der nichts beiträgt, jede Genehmigung, die nur aus Trägheit existiert, jedes Meeting, das eine Nachricht sein könnte: Es ist meine Verantwortung, es zu eliminieren. Weist darauf hin, wenn ihr es seht. Eure Energie soll ins Bauen fließen, nicht in das Navigieren von Bürokratie.
Wenn ich euch bitte, Dinge durch Ausprobieren kaputt zu machen, verpflichte ich mich, dass Dinge kaputt machen keine Konsequenzen hat. Fehler in gutem Glauben werden hier nicht bestraft. Sie werden analysiert, man lernt daraus, und es geht weiter. Der einzige unverzeihliche Fehler ist, es nicht zu versuchen. Wenn ihr jemals das Gefühl habt, dass ein Fehler politische Kosten hat, sagt es mir. Denn das wird bedeuten, dass etwas in der Kultur zerbrochen ist, und es zu reparieren wird meine oberste Priorität sein.
Und wenn ich euch bitte, ständig zu lernen, verpflichte ich mich, mit euch zu lernen. Nicht aus einem Büro heraus. Aus denselben Schützengräben. Wenn ich aufhöre zu bauen, Dinge kaputt zu machen, unbequeme Fragen zu stellen, habt ihr das Recht, mich darauf aufmerksam zu machen. Dieser Pakt funktioniert in beide Richtungen oder er funktioniert nicht.
Das Transformativste von allem
Ich weiß nicht, ob wir in einem Jahr noch genau so arbeiten werden. Wahrscheinlich nicht. Wahrscheinlich werden wir Probleme entdeckt haben, die wir jetzt nicht sehen, und Lösungen erfunden haben, die wir uns jetzt nicht vorstellen können.
Und das, glaube ich, ist das Transformativste von allem. Nicht die Technologie. Nicht die Agenten. Nicht der Code. Es ist die Denkweise von jemandem, der aufhört zu warten und anfängt zu lösen. Von jemandem, der ein Problem sieht und, anstatt zu eskalieren, baut. Das erwarte ich von jeder Person in diesem Unternehmen. Nicht mehr, nicht weniger.
So arbeiten wir bei Dcycle. Builders. Learners. Manager von einem und vielen. Und der Weg entsteht weiterhin beim Gehen.
J.
