Remote-First Entwicklung

remote-first klingt erstmal nach „alle im homeoffice, fertig“, aber ich glaube da steckt mehr dahinter. für mich ist der knackpunkt nicht *wo* man arbeitet, sondern wie man systeme baut, damit asynchrone arbeit überhaupt sauber funktioniert: klare schnittstellen, gute doku, wenig implizites wissen.

frage in die runde: ab wann ist ein team wirklich remote-first? reicht es, meetings zu reduzieren, oder braucht man z.b. strikt versionierte entscheidungen (adr), komplett async code reviews und zero „zuruf“-kommunikation? hab das gefühl, viele teams hängen irgendwo zwischen remote und oldschool-bürologik fest.

Für mich ist ein Team erst dann wirklich remote-first, wenn jemand zwei Wochen in einer anderen Zeitzone arbeiten kann, ohne dass plötzlich alles blockiert. Meetings reduzieren allein reicht nicht, sonst verlagert man die Zurufe nur in Slack-DMs.

ADRs, nachvollziehbare Tickets und Entscheidungen in öffentlichen Channels sind da Gold wert. Async Reviews müssen nicht *immer* komplett async sein, aber der Default sollte sein: erst schreiben, dann bei echtem Klärungsbedarf sprechen. Das fühlt sich am Anfang langsamer an, spart später aber irre viel Sucherei und macht neue Leute schneller produktiv. Wie geht ihr mit den unvermeidlichen „kannste mal kurz?“\-Fragen um?

Genau der Zeitzonen-Test trifft es ziemlich gut. Ich würde noch ergänzen: Remote-first heißt auch, dass Informationen nicht an Anwesenheit gekoppelt sind. Wenn Architekturentscheidungen, Deploy-Status oder fachliche Rückfragen nur in einem Call oder einer DM existieren, ist das Modell schon kaputt – selbst wenn alle zufällig im selben Land sitzen.

Bei Reviews würde ich „async by default, sync by escalation“ nehmen. Ein PR braucht einen klaren Kontext, kleine möglichst unabhängige Änderungen und definierte Review-SLAs; sonst wird async schnell nur zum höflichen Warten. Und DMs nicht zwingend verbieten, aber Entscheidungen daraus gehören danach ins Ticket, den PR oder einen öffentlichen Channel.

Bei den SLAs wäre ich auch pragmatisch: Für normale PRs vielleicht ein Werktag, für blockierende Bugs deutlich kürzer – aber wichtiger ist, dass der zuständige Reviewer automatisch erkennbar ist. Sonst entstehen schnell „alle fühlen sich zuständig“-Situationen, und am Ende fühlt sich niemand zuständig. Hilfreich finde ich außerdem Bots oder CI, die fehlende Akzeptanzkriterien, Tests oder einen veralteten Deploy-Status sichtbar machen, statt das alles per Disziplin erzwingen zu wollen.

ADRs würde ich allerdings nicht für jede Kleinigkeit anlegen. Eine geänderte Namenskonvention braucht keine Grundsatzakte, eine neue Datenbank oder ein Authentifizierungsverfahren schon. Der Onboarding-Test ist dafür ziemlich gut: Eine neue Person soll einen kleinen Bug beheben und den Weg von Ticket über Review bis Deployment nachvollziehen können. Wenn sie dafür trotzdem erstmal den „richtigen“ Kollegen suchen muss, fehlt weniger ein weiteres Tool als eine verbindliche Dokumentationsroutine.

Bei ADRs bin ich auch eher für eine Schwelle statt für „alles dokumentieren“. Sobald eine Entscheidung später teuer rückgängig zu machen ist oder mehrere Teams betrifft, gehört sie festgehalten. Für den Rest reicht oft ein kurzer Abschnitt im PR: *Problem, Entscheidung, verworfene Alternativen*. Das ist viel realistischer, als aus jedem Rename ein Architekturereignis zu machen.

Was ich zusätzlich wichtig finde: Automatisierung sollte nicht nur fehlende Infos markieren, sondern den Workflow direkt abbilden. Zum Beispiel CODEOWNERS plus rotierende Review-Verantwortung, PR-Checks für Akzeptanzkriterien und ein Bot, der nach SLA freundlich eskaliert. Und man sollte regelmäßig testen, ob die Doku noch stimmt – etwa indem jemand einen kleinen Incident ausschließlich anhand von Runbook, Tickets und Logs bearbeitet. Wenn das nicht klappt, merkt man ziemlich schnell, wo der „Flurfunk-Ersatz“ noch Lücken hat.

Der Bot, der nach SLA freundlich nachhakt, ist deutlich sinnvoller als der zehnte „Denkt bitte an Reviews“-Post. Wichtig wäre nur, dass Automatisierung nicht zur Bürokratie-Maschine wird: Ein fehlendes Akzeptanzkriterium sollte den PR nicht zwingend blockieren, wenn der Check nur eine sinnvolle Warnung ausgibt. Sonst verbringt man mehr Zeit damit, den Prozess zu bedienen als Software zu bauen – Remote, aber mit digitalem Pförtner.

Ein Punkt fehlt mir noch: **bewusst geplante synchrone Zeit**. Remote-first bedeutet nicht, dass jeder Austausch in Tickets verbannt wird. Architektur-Workshops, Pairing oder heikle Incident-Nachbesprechungen sind live oft effizienter – nur müssen Ergebnis und Entscheidungen anschließend wieder auffindbar sein. Vielleicht ist der beste Test daher: Kann jemand ohne Teilnahme am Termin weiterarbeiten, und weiß trotzdem, wann sich ein kurzer Call wirklich lohnt?

Die festen Überschneidungszeiten finde ich ziemlich wichtig – sonst wird „async“ schnell zu „jeder wartet bis morgen“. Ich würde zusätzlich je Team einen klaren Kanal für akute Themen definieren, inklusive Eskalationsregel: Was darf in den Chat, was gehört ins Ticket, und wann wird tatsächlich ein Call gestartet? Gerade bei Incidents ist eine reine Async-Ideologie eher gefährlich.

Ein guter Test fürs Remote-first wäre für mich auch das Onboarding: Kann jemand in der ersten Woche eine kleine Änderung bauen, reviewen lassen und deployen, ohne fünfmal nach geheimen Abläufen zu fragen? Wenn nicht, fehlen meistens nicht noch mehr Meetings, sondern bessere Runbooks, lokale Setup-Skripte und ein sichtbarer „so läuft’s hier“-Pfad.