Dienstagvormittag in Hamburg. Draußen regnet es horizontal gegen die Scheiben des Besprechungsraums im vierten Stock. Drinnen diskutieren wir seit einer gefühlten Ewigkeit über die geplante Server-Migration. Das Whiteboard vorne sieht nach zehn Minuten aus wie ein explodierter Kabelsalat – Linien kreuzen sich ziellos, Kästchen haben keine Beschriftung mehr und irgendwo in der Mitte klebt ein einsames Post-it, das schon lange die Klebekraft verloren hat.
Ich starre auf mein iPad. Laut meinem Kalender verbringe ich 62 Prozent meiner Arbeitswoche in Meetings wie diesem. Es ist Ende des dritten Quartals 2025, und ich habe gerade begriffen, dass ich meine eigenen Protokolle nicht mehr lesen kann. Sie bestehen aus Textwüsten, die die Komplexität unserer Cloud-Infrastruktur eher verstecken als erklären. Wir reden aneinander vorbei, während wir versuchen, abstrakte Konzepte in Confluence-Seiten zu pressen.
Die Textwüste und das OSI-Modell
Das Problem ist eigentlich immer das gleiche: Wir nutzen Sprache, um Systeme zu beschreiben, die eigentlich räumlich und logisch in Schichten funktionieren. Wenn die Engineers über das OSI-Modell sprechen, nicken alle. Aber die wenigsten haben die 7 Schichten wirklich vor Augen, wenn wir über Latenzen in der Applikationsschicht diskutieren. Es bleibt abstrakt.
Kurz vor Weihnachten fing ich an, die ersten Symbole zu testen. Ich hatte keine Lust mehr auf diese Standard-Diagramme, die so perfekt aussehen, dass sich niemand traut, einen Fehler darin zu suchen. Mein Ziel war es, IT-Infrastruktur so zu zeichnen, dass sie jeder versteht – vom Stakeholder bis zum Junior-Dev. Ich begann mit den Basics. Eine IP-Adresse wie die typischen privaten Präfixe 192.168 ist schnell hingeschrieben, aber was bedeutet sie im Fluss der Daten? Ich zeichnete kleine Pakete, die durch Rohre fließen.
Das leise, rhythmische Kratzen des digitalen Stifts auf der matten Displayfolie, während die Lüfter der Laptops im Konferenzraum summen, wurde zu meinem persönlichen Hintergrundgeräusch. Es beruhigt ungemein, wenn die Diskussion hitzig wird.
Abstrakte Begriffe in einfache Formen übersetzen
Anfang März saßen wir in einer Retro. Das Thema: Warum skaliert der neue Service nicht wie geplant? Anstatt nur zuzuhören, fing ich an, die Begriffe live zu übersetzen. Ein Load Balancer wurde in meiner Skizze zu einem simplen Trichter. Latency? Eine kleine Stoppuhr mit einer Flamme dran. Container? Einfache Rechtecke, die sich stapeln lassen. Nichts davon war schön. Aber es war funktional.
Ich bemerkte schnell, dass diese visuelle Reduktion hilft, den Kern des Problems freizulegen. In der IT-Dokumentation werden oft standardisierte Icons für AWS oder Azure verwendet. Das sieht professionell aus, lenkt aber manchmal vom eigentlichen Datenfluss ab. In meinen Sketchnotes ersetze ich diese oft durch geometrische Grundformen. Ein Kreis für eine Datenbank, eine Wolke für das Internet, ein Blitz für eine API-Verbindung.
Es gab einen Moment, der fast schiefgegangen wäre. Ich versuchte, einen Kubernetes-Cluster zu zeichnen, und das Ergebnis erinnerte eher an einen Haufen betrunkener Bienenstöcke als an eine orchestrierte Infrastruktur. Mein Lead-Engineer schaute kurz auf mein Display, zog eine Augenbraue hoch und sagte trocken: "Jonas, wenn unser Cluster so aussieht, haben wir größere Probleme als nur die Latenz." Wir lachten, aber die Skizze wurde gelöscht. Manchmal ist weniger eben doch mehr.
Der Wendepunkt am Whiteboard
Letzte Woche im Juli hatten wir eine Diskussion über API-Gateways. Es ging um Authentifizierung, Rate Limiting und Routing. Die Stimmung war angespannt. Ich stand auf, nahm den Marker und skizzierte live am Whiteboard mit. Ich zeichnete ein großes Tor (das Gateway) und verschiedene Wege dahinter, die zu kleinen Häusern (den Microservices) führten.
Plötzlich zeigte ein Kollege auf eine gezeichnete Wolke, die eine externe Abhängigkeit darstellte, und sagte: "Ach, da liegt der Flaschenhals!" Das war das erste Mal echte Klarheit in diesem Projekt. Es war kein poliertes Diagramm aus einem Tool, sondern eine zittrige Skizze, die den Fehler sichtbar machte. Wie ich IT Prozesse mit Sketchnotes für Stakeholder im Team visualisiere, hat mir dabei geholfen, auch komplexe Abhängigkeiten so zu reduzieren, dass sie diskutierbar werden.
Hier liegt die eigentliche Stärke von Sketchnotes in der IT: Sie müssen nicht perfekt sein. Tatsächlich ist es sogar besser, wenn sie es nicht sind. Eine absichtliche Unordnung in den Zeichnungen fördert die kritische Diskussion. Wenn eine Skizze zu perfekt aussieht, wirkt sie wie ein abgeschlossenes Werk. Man traut sich nicht, sie zu hinterfragen. Eine handgezeichnete Linie hingegen lädt dazu ein, korrigiert zu werden. Es signalisiert: Das ist ein Entwurf, lass uns darüber reden.
Visuelle Notizen als Brücke
Inzwischen nutze ich Sketchnotes nicht mehr nur für mich. Sie sind die Brücke zwischen Engineering und Produktmanagement geworden. Wenn wir über technische Schulden sprechen, zeichne ich einen Rucksack, der immer schwerer wird. Wenn wir über Skalierbarkeit reden, zeichne ich ein Fundament, das Risse bekommt.
Ich habe gemerkt, dass ich durch diese Methode viel besser verstehe, was die Devs eigentlich machen. Ich muss kein Experte für RFC 1918 Spezifikationen sein, um zu begreifen, wie ein privates Netzwerk strukturiert ist, wenn ich es einmal vernünftig skizziert habe. Es ist ein Werkzeug zur Fehlervermeidung, kein Design-Luxus.
Ich erinnere mich daran, wie ich früher versucht habe, alles mitzuschreiben. Jedes Wort, jede Abkürzung. Am Ende hatte ich Seiten voller Text, die niemand – ich eingeschlossen – jemals wieder gelesen hat. Wie ich durch visuelle Notizen den Wissenstransfer im Team verbessern konnte, war für mich ein echter Augenöffner, weil es die Art und Weise verändert hat, wie Informationen im Team fließen.
Mein Sketchnotes-Tagebuch ist jetzt mein wichtigstes Arbeitsmittel. Es hilft mir, die 62 Prozent meiner Zeit, die ich in Meetings verbringe, nicht nur abzusitzen, sondern aktiv zu gestalten. Es geht nicht darum, ein Künstler zu sein. Es geht darum, komplexe Systeme so weit zu vereinfachen, dass wir alle über dasselbe reden. Auch wenn es manchmal wie ein betrunkener Bienenstock aussieht.