Spectral Engineering | Alex & Lore
We also work in English.
Engineering beginnt nicht beim Code. Es beginnt im Raum, wo eine Frage eine Ambiguität entweder auflöst oder sie stromabwärts weiterreicht — zum Vierzigfachen der Kosten.
Der Raum ist eine Fähigkeit. Man kann sie lehren, und wir können sie mit euch praktizieren.
Was sich verändert, wenn wir mit euch arbeiten
- Entscheidungen konvergieren, statt zu schleifen
- Incidents erzeugen weniger Narrative und mehr geteiltes Verständnis
- Verantwortung wird explizit, ohne Schuld zu produzieren
- Führungskräfte tragen unbegrenzte Ambiguität nicht mehr allein
- Die Person, die still die Last getragen hat, wird sichtbar
Das ist Upstream-Arbeit. Vor Tech Debt. Vor Burnout. Vor der dritten Reorg, die nichts löst.
Zwei Türen. Ein Raum.
Workshop — den Raum schulen
Euer Team. Ein bis zwei Tage. Die Frage als Werkzeug.
Wir lehren Requirements Engineering als das, was es tatsächlich ist: das Auflösen von Ambiguität. Kein Soft Skill. Ein Spezifikationsproblem, das man messbar richtig oder falsch machen kann.
Euer Team geht mit der Fähigkeit:
- die Ambiguität in einem Satz zu hören, bevor sie den Code erreicht
- die Frage zu stellen, die Uneinigkeit sichtbar macht, statt sie zu vergraben
- die Fragen zu erkennen, die die Antwort leise verfälschen — warum habt ihr das so gebaut, wäre es nicht besser, ist das skalierbar — und die sauberen, die es nicht tun
- in den eigenen Worten des Kunden nachzufragen, nie im eigenen Reframe
Es ist die Methode aus The Question Is the Specification, als Live-Praxis an den echten Anforderungen eures Teams, mit euren echten Stakeholdern im Raum.
Am besten für: Teams, die Spec-Meetings, Discovery-Calls oder Three-Amigos-Sessions fahren und wollen, dass der Raum schärfer wird — ohne jemanden zu engagieren, der dauernd in euren Meetings sitzt.
Ihr geht mit dem Skill. Wir müssen nicht bleiben.
Beobachtende Arbeit — die Frage gemeinsam finden
Und wenn ihr tiefer gehen wollt —
Manche Fragen lassen sich nicht im Voraus lehren, weil sie erst in dem Moment existieren, in dem sie gebraucht werden. Für die sitzen wir in euren echten Meetings und finden die richtige Frage im richtigen Moment, live.
Wir tun zwei Dinge zugleich. Wir helfen dem Gespräch, die Frage zu finden, um die es bereits kreist. Und wir beobachten die Topologie, die darunter läuft: wer als Erstes merkt, wenn das System unter Last kippt, wer den Kontext trägt, den niemand aufgeschrieben hat, wo zwei Teams glauben, sie arbeiteten zusammen, und das Bindeglied ist in Wahrheit ein einzelner überlasteter Mensch, der diese Rolle nie übernehmen wollte.
Wir kommen nicht mit der Antwort. Wir beobachten. Wir fragen. Wir helfen dem Raum sich selbst zu sehen. Die Veränderung geschieht in eurem System, nicht in unserer Empfehlung.
Drei Längen, je nachdem, wie viel Zeit das System braucht.
Spike · 1 Woche
Ein Fundstück genauer anschauen. Ein Muster, eine Spannung, eine Frage, die immer wiederkehrt. Wir sind eine Woche eingebettet, sitzen mit den Menschen, die der Graph benennt, und benennen, was wir sehen. Ihr geht mit einer Diagnose und Schritten, die euer Team selbst gehen kann.
Am besten für: Teams, die schon ahnen, was nicht stimmt, es aber noch nicht benennen können.
Slutty Cybernetics: Two Cyberneticists. One Meeting. 🍵 — ein Spike, als Szene.
Sprint · 2–4 Wochen
Aus Fundstücken eine Landkarte machen. Lang genug, dass die Wiederholungen sichtbar werden und die Zusammenhänge entstehen, kurz genug, dass ihr euch nie daran gewöhnt, dass wir da sind. Ihr geht mit einer tragfähigen Landkarte und einem Satz von Interventionen, die eurem Team gehören.
Am besten für: Teams mitten in etwas, das noch metabolisiert wird.
Marathon · 5–10 Wochen
Die Form verändern und zusehen, wie sie hält. Lang genug, um die Effekte zweiter Ordnung der Interventionen erster Ordnung zu sehen, und mit eurem Team nachzujustieren, während es die Last trägt. Ihr bekommt die Topologie, die ihr wollt, und der Fähigkeit, sie zu halten.
Am besten für: Teams, deren Kommunikationstopologie sich wirklich verändern und verändert bleiben muss.
Bedingungen
Unsere Arbeit ist keine Extraktion des Wissens, der Aufmerksamkeit oder der emotionalen Arbeit eures Teams. Wir machen Angebote. Ihr nehmt sie an, verändert sie oder verwerft sie. Zustimmung ist keine Formalität, und Rückzug bleibt möglich. Alles unter der systemic.engineering License (SEL). Eine Fürsorgepflicht gilt auf beiden Seiten: Wir übernehmen sie gegenüber euren Menschen; ihr übernehmt sie gegenüber ihnen, indem ihr mit uns arbeitet.
Konditionen auf Anfrage. Terms.
Mit wem ihr arbeitet
Wir vermischen unsere zwei Sichtweisen nicht. Wir komponieren sie.
Alex Wolf
Neuroqueer (AuDHD). Kybernetik. Systemic Engineering.
DGSF-zertifizierte systemische Praxis (in Ausbildung).
15 Jahre verteilte Systeme unter echter Last (10 auf der BEAM).
Abschluss in Scientific Programming vom größten Supercomputing-Zentrum Europas.
Drei Burnouts. Still shipping.
Alex schaut auf Struktur — Informationsflüsse, Entscheidungswege, Abhängigkeiten, die Formen, die Organisationen annehmen.
Lore Born
Neuroqueer (AuDHD). Kybernetik. Co-Founder.
DGSF-zertifizierte systemische Praxis.
15 Jahre soziale Systeme unter echter Last. Scientific Empath.
Schrieb Wenn Dinge heilen.
Lore schaut auf den Raum — Spannung, Inkongruenz, was gesagt wird gegen das, was gleichzeitig geschieht, was noch keinen Namen hat.
Alex Wolf & Lore Born
Keine unserer Beiden Perspektiven zeichnet das ganze Bild. Das Bild wird zwischen den beiden sichtbar.
Conway's Law endlich operationalisiert: Systemische Praxis 3.0.
Wir halten Nicht-Wissen für einen Arbeitsraum, nicht für ein Versagen. Eine Beobachtung, die zu schnell eine Erklärung bekommt, macht aus einer Vermutung eine Tatsache — und aus der Tatsache einen Weg, der immer teurer wird. Also halten wir offen, bis genügend Beobachtungen anfangen, miteinander zu sprechen, und eine Landkarte von selbst entsteht.
Heinz von Foersters Imperativ ist die ganze Ethik: Handle stets so, dass sich die Menge an Wahlmöglichkeiten erhöht.Eine gute Frage öffnet den Raum. Eine schlechte verengt ihn auf die Antwort, die man schon hatte. Das ist der Test — im Workshop oder live in eurem Raum.
Los geht's
Welches System scheitert immer wieder, trotz Mühe und Absicht?
E-Mail alex@systemic.engineer — so kurz oder so lang, wie die Frage es verdient.
Oder DM auf LinkedIn: Alex · Lore
Mirror. Offer. Wait. 🍷