Es ist spät an einem Dienstagabend im Hamburger Büro. Ich starre auf ein Jira-Board, das sich anfühlt wie eine digitale Schüssel Spaghetti. Wir stehen kurz vor dem Release-Fenster und ich merke, dass wir es krachend verfehlen werden. Warum? Weil der Kritische Pfad unter fünf Ebenen textlastiger Sub-Tasks begraben liegt.
Hinweis: In diesem Text sind Affiliate-Links enthalten. Wenn du darüber einen Kurs buchst, bekomme ich eine kleine Provision – ohne dass es für dich teurer wird. Ich empfehle hier nur Dinge wie den Sketchnotes Kurs, den ich selbst über Monate im Hamburger PM-Wahnsinn getestet habe, um meine eigene Handschrift und Struktur zu retten.
Das Grab der Bullet Points
Ich erinnere mich an die Verzweiflung Ende 2025. Mein Kalender sagt mir, dass ich 62 Prozent meiner Arbeitswoche in Meetings verbringe. Meine Protokolle waren damals ein unleserlicher Friedhof aus Bullet Points. Wenn ich drei Tage später reinschaute, wusste ich oft selbst nicht mehr, was ich mit 'API-Sync beachten' eigentlich gemeint hatte.
Besonders schlimm war es im Q3 2025. Ich saß beim CTO im Büro und sollte den Status der Service-Migration erklären. Ich blickte auf meine Notizen und spürte diesen echten Knoten im Magen. Ich konnte meine eigenen Action Items nicht entziffern. Peinlich ist gar kein Ausdruck dafür – es war professionelle Kapitulation.
Irgendwann in diesem Herbst fing ich an, Dinge zu zeichnen. Nicht weil ich plötzlich zum Künstler wurde – ich kann immer noch kein gerades Haus malen –, sondern weil ich überleben musste. Unser Gehirn verarbeitet Bilder etwa 60.000 Mal schneller als Text. In einer Welt, in der Stakeholder nur fünf Minuten Aufmerksamkeit haben, ist das kein Bonus. Es ist eine Notwendigkeit.
Vom Text-Chaos zur funktionalen Logik
Mein erster Versuch, technische Abhängigkeiten visuell darzustellen, war kein Meisterwerk. Es war ein Experiment, basierend auf den ersten Lektionen aus dem Sketchnotes Kurs. Statt zu schreiben 'Service A ist abhängig von API B, die wiederum auf die Datenbank-Migration in Sprint 4 wartet', zeichnete ich zwei Container.
Dazwischen ein dicker, gezackter Pfeil. Ein Blitz-Symbol für das Risiko. Keine Kunst. Nur funktionale Logik, um die Abhängigkeiten zu kartieren. Es ging nicht um Ästhetik. Es ging darum, den Engpass zu sehen, bevor er uns im Sprint um die Ohren fliegt. Wer mehr Wert auf das digitale Setup legt, könnte auch einen Blick auf den Digital Lettering Kurs werfen, aber für den Anfang reicht ein simpler Fineliner.
Ich nutze oft einfache Layouts, um komplexe Themen zu entwirren. Wer ähnliche Herausforderungen hat, findet hier gute Ansätze: Sketchnotes Layout Vorlagen für komplexe IT Projekte im SaaS Bereich. Es hilft ungemein, wenn man nicht jedes Mal bei Null anfangen muss, wenn die Release-Planung ansteht.
Der Moment, in dem es klick macht
Der Wendepunkt kam während eines hitzigen Stakeholder-Meetings an einem regnerischen Dienstagnachmittag im September. Die Diskussion drehte sich seit zwanzig Minuten im Kreis. Es ging um die Deployment-Reihenfolge. Drei verschiedene Meinungen, fünf verschiedene Interpretationen der technischen Dokumentation.
Ich teilte ein einfaches, handgezeichnetes Diagramm auf dem digitalen Whiteboard. Das spezifische Quietschen meines digitalen Stifts auf dem Glas während der kurzen Stille im Zoom-Call ist mir heute noch im Ohr. Dann passierte es: Drei Leute schalteten gleichzeitig ihr Mikrofon stummfrei, um zuzustimmen. 'Ah, jetzt sehe ich es', sagte der Lead Dev. Es war das erste Mal seit Langem, dass ich mich wieder wie ein PM fühlte und nicht wie ein Stenograf.
Diese visuelle Klarheit hilft auch in anderen Bereichen, etwa wenn man Technical Debt visualisieren will, um dem Management klarzumachen, warum wir gerade keine neuen Features bauen können. Es geht um die Theorie des Dual Coding – die Kombination aus Wort und Bild bleibt einfach besser hängen.
Die Illusion der perfekten Planung
Hier kommt der Punkt, den viele falsch verstehen: Die detaillierte Visualisierung technischer Abhängigkeiten führt oft zu einer gefährlichen Planungs-Illusion. Man denkt, weil die Zeichnung sauber aussieht, ist auch der Plan sicher. Das ist Quatsch. Eine zu starre visuelle Map kann die agile Reaktionsfähigkeit sogar lähmen.
Ich habe gelernt, dass meine Sketchnotes 'lebendig' bleiben müssen. Sie sind kein in Stein gemeißeltes Dokument, sondern ein Werkzeug zum Denken. Wenn ich versuche, jede kleinste Sub-Dependency darzustellen, verliere ich den Fokus. Ein gescheitertes Symbol – ich wollte mal eine Cloud-Infrastruktur zeichnen, die am Ende aussah wie ein Haufen zerknitterter Wäsche – hat mir gezeigt, dass Einfachheit alles ist.
Es geht darum, die Kommunikation zu steuern. Wer das beherrscht, kann auch schwierige Stakeholder Erwartungen visuell managen. Man zeigt das große Ganze, lässt aber genug Raum für die Unwägbarkeiten der Software-Entwicklung.
Ein Jahr visuelle Notizen: Ein Fazit ohne Fazit
Mein öffentliches Tagebuch zeigt den Weg von den chaotischen Kritzeleien Ende 2025 bis zu den heutigen Dependency Maps. Ich habe keinen Design-Hintergrund. Ich habe nur aufgehört, mich auf reine Textprotokolle zu verlassen, die ich nach zwei Tagen nicht mehr verstehe. Es ist ein Handwerk, das man lernt, weil der Schmerz des Nicht-Verstanden-Werdens zu groß wird.
Falls du auch 60 Prozent deiner Zeit in Meetings verbringst und dich fragst, wo die ganze Information eigentlich hinfließt: Probier es aus. Fang nicht mit Kunst an. Fang mit einem Container und einem Pfeil an. Der Sketchnotes Kurs ist ein solider Startpunkt, wenn du Struktur suchst, ohne gleich Kalligrafie-Meister werden zu wollen. Die aktuelle Kursgebühr und alle Details findest du direkt beim Anbieter – das ändert sich ja gelegentlich.
Am Ende des Tages geht es darum, dass wir Software pünktlich ausliefern. Und wenn ein kleiner, hässlicher Pfeil auf einem digitalen Whiteboard dabei hilft, eine 20-minütige Debatte zu beenden, dann hat er seinen Job gemacht. Ich tippe das hier gerade in der Pause zwischen zwei Sprints. Der nächste Stakeholder-Call wartet schon. Mein Stift liegt bereit.