Letztes Mal, als ich beim Dynamite Circle in Bangkok war. Abends, bevor ich schlafen gegangen bin, habe ich ein paar Mails geschrieben. Ein Webseiten Projekt, was in der Endphase war mit Problemen, die gelöst werden mussten. Eine Mail an unser Team in Deutschland, eine an einen Entwickler in Indien.
Ich wachte auf. Sechs Stunden später hatte der Entwickler in Indien bereits geantwortet. Die fehlende Funktionalität war implementiert, getestet. Zwei Stunden später — mittlerweile war es Morgen in Deutschland — kamen die Feedback-Comments vom deutschen Team zu den Änderungen.
Bis ich am nächsten Abend wieder in meine Mails schaute, war das Website-Projekt einen Riesenschritt weiter. Die kritischen Probleme waren gelöst.
Das ist nicht Remote-Planung. Das ist nicht strukturiertes Async-Management. Das ist: Ich schreibe nachts auf, und während ich schlafe, arbeitet die Welt an meinen Problemen.
Das funktioniert. Und es hat nichts mit den Best-Practice-Frameworks zu tun, die ich in Business-Büchern lese.
Warum Zeitzonen eigentlich ein Feature sind
Die meisten Teams kämpfen gegen Zeitzonen. „Wir brauchen Core Hours”, „Wir müssen alle online sein”, „Remote ist schwierig weil die Zeitzonen”.
Richtig. Zeitzonen sind schwierig — wenn du denkst, dass dein ganzes Team gleichzeitig arbeiten muss.
Aber was, wenn du das Gegenteil machst?
Bei punktbar haben wir einen Entwickler in Indien, ein Team in Deutschland, ich bin ständig unterwegs (Bangkok, Essen). Wir haben keine „Core Hours”. Wir haben keine strukturierten Async-Prozesse wie in den Management-Büchern.
Was wir haben: Wir schreiben auf, was getan werden muss. Und während einer schläft, arbeiten die anderen. Das ist es.
Wie es praktisch läuft
Es ist ehrlich gesagt ziemlich simpel.
Wenn ich arbeiten muss und gerade in einer anderen Zeitzone bin: Ich schreibe auf, was zu tun ist. Konkret, klar, im bestmöglichen Format. Ein GitHub Issue. Eine Slack Message mit Code-Snippet. Ein Google Doc mit Spezifikation. Was auch immer der Job braucht.
Dann geht das Los:
Der Entwickler in Indien — während ich schlafe — liest das. Versteht das Problem. Schreibt Code, testet lokal, pushed. Die Änderungen sind live auf staging. Wenn er Fragen hat, schreibt er sie auf. Hinterlässt sie für mich oder das deutsche Team.
Das deutsche Team — morgens, während Indien gerade zu Bett geht — checkt die Website auf staging. Testet die neuen Features. Gibt Feedback im GitHub Issue. Der nächste Punkt wird angegangen.
Und so geht das. Ich schreibe nachts auf. Und während ich schlafe, passiert die Arbeit. Es ist nicht geplant. Es ist nicht „strukturiert”. Es ist nur: Wir alle verstehen, dass wir nicht zur gleichen Zeit arbeiten, also arbeiten wir nacheinander.
Das Ergebnis: Was bei klassischen Teams ein 2-3 Tage Problem ist, ist bei uns ein Over-Night-Problem. Wir arbeiten 24 Stunden an Dingen, weil die Welt nicht schläft.
Warum das funktioniert
Das funktioniert, weil es auf Vertrauen basiert, nicht auf Kontrolle.
Ich schreibe auf, was zu tun ist. Ich vertraue dem Team, dass es es tun wird — ohne dass ich zuschaue. Ohne dass ich frage „Bist du fertig?”. Ohne dass ich ein Meeting brauche, um den Status zu klären.
Das Gegenteil von klassischen Remote-Teams, wo der Manager ständig checkt „Sind alle online?”, „Antwortet jemand?”, „Warum dauert das so lange?”.
Wir machen das nicht. Wir schreiben auf. Der andere macht. Punkt.
Das funktioniert 20 Jahre lang mit Saltatio — verschiedene Zeitzone, keine Kontrolle, nur Vertrauen. Und es funktioniert jetzt mit punktbar — weil wir alle verstehen, dass das die einzige Weise ist, wie es funktioniert.
Der einzige Haken: Vertrauen braucht Klarheit
Das funktioniert nur, wenn die Aufgabe crystal-clear ist.
Wenn ich schreibe: „Bitte mach was mit dem Bug”, passiert nichts. Weil zu viele Fragen offen sind.
Wenn ich schreibe: „Der User kann auf Seite X nicht auf Button Y klicken. Es triggert einen JS-Error auf Line 142 in component.js. Hier ist der Fehler [Stack trace]. Bitte fix den Error so dass Button Y wieder clickbar ist. Akzeptanzkriterium: Button klickbar, keine Fehler in Console” — dann passiert was.
Die Klarheit ist das Einzige, das zwischen „Zeitzonen sind cool” und „Zeitzonen sind ein Alptraum” unterscheidet.
Die Realität
Das ist kein Framework, keine Best Practice, keine „Agilität” oder „Scrum”.
Das ist einfach: Ich schreibe auf, der andere macht, ich schlafe. Und während ich schlafe, arbeitet die Welt an meinen Problemen.
Das funktioniert nicht, weil ich ein Genie bin. Es funktioniert, weil mein Team verdammt gut ist. Weil sie verstehen, was getan werden muss. Weil Vertrauen höher ist als Kontrolle.
Nach 20 Jahren mit Saltatio Mortis — wo wir die gleiche Kraft haben — kann ich sagen: Das ist das einzige Remote-Modell, das wirklich funktioniert.
Nicht die „Core Hours”. Nicht die „Async Frameworks”. Nicht die „Dokumentation Prozesse”.
Nur: Klare Aufgabe. Vertrauen. Die Welt arbeitet 24 Stunden für dich.