Wie Sie ein leistungsfähiges Team aufbauen, das gut zusammenarbeitet, klar kommuniziert und Ergebnisse liefert.
Im Laufe der Jahre habe ich gesehen, wie brillante Ideen scheiterten, weil das Entwicklungsteam nicht für den Erfolg gerüstet war.
Das eigentliche Problem ist, dass sich viele Unternehmen zu sehr auf Tools und Methoden konzentrieren und dabei die Grundlagen außer Acht lassen.
Sie stellen reaktiv ein, verlassen sich auf ein unsicheres Berichtswesen und erwarten, dass die Leute es schon irgendwie „herausfinden“, wenn das Projekt an Umfang und Größe zunimmt. Und dann sind sie überrascht, wenn sich kleine Probleme zu großen Verzögerungen auswachsen.
Leistungsstarke Entwicklungsteams entstehen nicht durch Zufall.
Sie entstehen durch klare Strukturen, ehrliche Kommunikation und Prozesse, die Ihre Mitarbeiter unterstützen, anstatt sie auszubremsen.
In diesem Artikel stelle ich Ihnen die 7 Lektionen vor, die uns geholfen haben, DECODE dorthin zu bringen, wo wir heute stehen.
Ich werde darauf eingehen, wie man die richtigen Leute einstellt, sein Team strukturiert, anpassungsfähig bleibt, wenn das Unternehmen wächst, und vieles mehr.
Lassen Sie uns eintauchen!
Table of Contents
Halten Sie Ihren Einstellungsprozess einfach
Ich habe gelernt, dass die Einstellung von Mitarbeitern am besten funktioniert, wenn der Prozess einfach und ehrlich ist. Deshalb halten wir unseren Prozess bei DECODE einfach.
Keine Tests, Rätsel oder endlose Gesprächsrunden. Nur zwei Gespräche, die uns ein klares Bild davon vermitteln, wie jemand denkt und ob er oder sie zu uns passt oder nicht.
Das erste Gespräch ist ein Gespräch über echte Erfahrungen. Wir sprechen über vergangene Projekte, über die Entscheidungen, die sie getroffen haben, und darüber, wie sie an knifflige Aufgaben herangegangen sind.
Sie werden mit unseren Technologieexperten sprechen.
Es istabsichtlich entspannt. Menschen arbeiten am besten, wenn sie nicht das Gefühl haben, dass sie getestet werden.
Wenn ein Kandidat die Prüfung besteht, gehen wir zum zweiten Gespräch über. Dieses Gespräch geht tiefer.
Wir sprechen darüber, wie sie Probleme lösen, wie sie kommunizieren, wenn die Dinge unklar sind, und ob unsere Werte übereinstimmen.
Diekulturelle Übereinstimmung ist wichtig, denn sie bestimmt, wie das Team tagtäglich arbeitet. Und keine noch so guten technischen Fähigkeiten können eine giftige Persönlichkeit ausgleichen.
Das sollten Sie tun:
2 klare Interviews – Konzentrieren Sie sich auf reale Projekte und die Denkweise der Person.
Beurteilen Sie die kulturelle Eignung – Suchen Sie nach Personen, die auf natürliche Weise so arbeiten wie Sie und Ihre Werte teilen.
Ein entspanntes Umfeld – Die Bewerber sollten sich wohl genug fühlen, um ihr wahres Ich zu zeigen.
Keine Tricks – Vermeiden Sie komplizierte LeetCode-Aufgaben, die nichts über die wirklichen Fähigkeiten der Bewerber aussagen.
Konsistente Struktur – Jeder durchläuft die gleichen Schritte, was die Entscheidungen fair hält.
Klare Zuständigkeiten – Für jedes Interview sollte ein Verantwortlicher bestimmt werden, damit der Prozess bei der Skalierung vorhersehbar bleibt.
Wenn Sie den Prozess so schlank halten, wird die Einstellung fair und vorhersehbar. Die Bewerber wissen genau, was sie zu erwarten haben, und das Team weiß, auf welche Signale es achten muss.
Außerdem ist es gut skalierbar. Als wir wuchsen, behielten wir den gleichen Ablauf mit zwei Vorstellungsgesprächen bei und fügten mehr Struktur hinzu, um zu bestimmen, wer die einzelnen Phasen leitet, damit die Entscheidungen konsistent bleiben.
Ich habe gelernt, dass man keine Struktur von einem anderen Unternehmen kopieren kann. Man muss sie nach den eigenen Zielen ausrichten.
Bevor Sie sich für ein Teammuster entscheiden, sollten Sie einige Dinge beachten.
Erstens: Wie komplex ist die Arbeit? Tiefgreifende technische Herausforderungen erfordern Spezialisten, die das Problem in- und auswendig kennen. Generalisten haben Schwierigkeiten, wenn die Arbeit zu komplex wird.
Und wie stabil ist der Aufgabenbereich? Spezialistenteams funktionieren gut bei klaren Anforderungen. Schnell wechselnde Projekte eignen sich für Generalisten oder hybride Teams, die schnell die Richtung wechseln können.
Und wo befinden Sie sich im Produktlebenszyklus? Frühe MVP-Projekte erfordern Generalisten, die den gesamten Stack aufbauen können. Die Skalierung erfordert in der Regel Spezialisten. Die Wartung funktioniert am besten mit kleinen Hybrid-Teams, die das System gut kennen.
Die meiste Zeit wird Ihr Team in eines der 3 Muster fallen:
Technologie-(Spezialisten)-Teams – Diese Teams sind technisch versiert und konzentrieren sich auf Bereiche wie Backend, Mobile, QA oder DevOps. Sie sind ideal, wenn Sie Tiefe, Vorhersagbarkeit und ein hohes Maß an technischer Konsistenz benötigen.
Produktteams (funktionsübergreifend) – Kleine, autonome Teams, die Technik, Design und QA umfassen. Sie betreuen einen Produktbereich von Anfang bis Ende. Sie sind schnell, flexibel und perfekt, wenn Sie eine schnelle Lieferung und weniger Übergaben wünschen.
Matrix-Teams – Eine Mischung aus beidem. Die Ingenieure unterstehen einem spezialisierten Leiter, arbeiten aber in funktionsübergreifenden Gruppen. So erhalten Sie Tiefe und Flexibilität zugleich. Sie eignet sich gut für große Projekte, bei denen eine Struktur allein nicht allen Anforderungen gerecht werden kann.
Um die Dinge einfach zu halten, sollten Sie sich an ein paar Grundprinzipien halten:
Halten Sie die Teams klein – 2 bis 7 Personen sind der optimale Wert.
Machen Sie die Verantwortlichkeiten klar – Jeder sollte genau wissen, was er zu tun hat.
Bleiben Sie, wann immer möglich, funktionsübergreifend – Das sorgt für nahtlose Übergaben und beschleunigt die Umsetzung.
Überprüfen Sie Ihre Struktur regelmäßig: Was für ein kleines Team funktioniert, ist für ein großes Team nicht geeignet.
Betrachten Sie die Teamstruktur nicht als feststehend. Sie sollte sich ändern, wenn Ihr Unternehmen wächst.
Ihre Aufgabe ist es, dafür zu sorgen, dass die Teamstruktur immer zur Arbeit passt, nicht umgekehrt.
Legen Sie die wichtigsten Prozesse von Anfang an fest und dokumentieren Sie sie
Wenn Sie ein kleines Team haben, ist es leicht zu glauben, dass Sie keine Dokumentation brauchen.
Dann kommen mehr Leute hinzu oder der Aufgabenbereich wächst, und plötzlich stellt jeder die gleichen Fragen. Ich habe gelernt, dass es einfacher ist, die Grundlagen frühzeitig zu schaffen, als später das Chaos zu entwirren.
Beginnen Sie mit den Arbeitsabläufen, die den Code von der Idee zur Produktion bringen. Sie sollten die Grundlagen von Anfang an richtig machen.
Wir dokumentieren Verzweigungsregeln, Überprüfungsschritte, Testerwartungen und die Funktionsweise von Bereitstellungen. Ein neuer Ingenieur sollte in der Lage sein, den Abläufen ohne Rätselraten zu folgen, sobald er einsteigt.
Wie man Ingenieurteams aufbaut und skaliert. Aufgedeckt von Experten.
Genauso wichtig sind Kodierungsstandards. Benennung, Dateistruktur, Art der Kommentierung, Formatierung des Codes.
Die gleiche Klarheit braucht auch Ihr Projektmanagementansatz.
Egal, ob es sich um Scrum, Kanban oder eine Mischform handelt, das Team muss wissen, wie die Arbeit geplant, nach Prioritäten geordnet und nachverfolgt wird. Sie müssen auch festlegen, wer was genehmigt, wie Entscheidungen getroffen werden und wo Probleme eskaliert werden.
Hier sind die Grundlagen, die ich Ihnen empfehle, frühzeitig zu dokumentieren:
Zentrale Entwicklungsabläufe und CI/CD-Pipelines – Wie der Code vom Konzept zur Produktion gelangt.
Regeln für Verzweigungen und Überprüfungen – Wer überprüft was und wann.
Erwartungen an das Testen – Wann wird die Qualitätssicherung einbezogen und was wird zuerst getestet.
Bereitstellungsschritte – Wer löst die Freigaben aus und wie wir sie überprüfen.
Kodierungsstandards – Benennung, Struktur und Konventionen, die für Konsistenz sorgen.
Wie wir die Arbeit planen – Sprint-Routinen, Planungsregeln und Prioritätensetzung.
Entscheidungsfindung – Wer hat in jedem Bereich das letzte Wort.
Wir überprüfen und aktualisieren die Dokumentation regelmäßig, wenn sich etwas ändert.
Und eine wichtige Regel sollten Sie befolgen: Dokumentieren Sie nur Prozesse, die ein echtes Problem lösen. Wenn ich nicht erklären kann, warum ein Prozess existiert, behalten wir ihn nicht bei.
Schaffen Sie ein ehrliches Berichtswesen
Bei einer guten Berichterstattung geht es nicht darum, die Dinge perfekt aussehen zu lassen. Es geht darum, so nah wie möglich an der Realität zu bleiben.
Ich habe schon zu viele Projekte in Schwierigkeiten geraten sehen, weil frühe Berichte abgeschwächt oder Risiken aufgeschoben wurden. Dieser Optimismus in der „Flitterwochen-Phase“ fühlt sich zunächst harmlos an, aber er verdeckt die wirklichen Probleme, bis alle einfachen Lösungen nicht mehr funktionieren.
Beginnen Sie damit, zu definieren, was „auf dem richtigen Weg“,„gefährdet“ und „nicht auf dem richtigen Weg“ tatsächlich bedeutet. Ohne klare Regeln werden die Leute die Lücken mit Vermutungen füllen.
Bei DECODE untermauern wir jeden Status mit Fakten. Verwendete Stunden, Prozentsatz der geleisteten Arbeit und die verbleibende Zeit. Wenn 80 % der Zeit verstrichen sind und nur 40 % der Arbeit erledigt ist, ist das Projekt nicht im grünen Bereich, egal wie zuversichtlich sich jemand fühlt.
Ich achte auch auf kleine Signale. Eine Verschiebung des Umfangs, ein Mitarbeiter, der sich schwer tut, eine unerwartete Änderung des Kunden.
Diese sind oft wichtiger als große Probleme, weil sie früher auftauchen. Mit der Frage „Ist der Plan noch realistisch?“ kann man Problemen zuvorkommen, anstatt erst zu reagieren, wenn es schon zu spät ist.
So sieht ein ehrliches Berichtswesen für mich aus:
Klare Definitionen – Jeder weiß, was grün, gelb und rot bedeutet.
Daten hinter jedem Status – Kein Bauchgefühl, nur tatsächliche Zahlen.
Frühzeitige Risikoberichterstattung – Risiken sind Gelegenheiten, Dinge zu korrigieren, solange unsere Optionen noch offen sind.
Regelmäßige Check-Ins – Kurze, gezielte Aktualisierungen, um zu bestätigen, dass der ursprüngliche Plan immer noch Sinn macht.
Unterstützung des Boten – Wenn jemand ein Risiko meldet, danke ich ihm und gebe ihm nicht die Schuld.
Transparenz im gesamten Team – Alle sehen dieselben Daten, nicht nur das Management.
Ich habe gelernt, dass die Menschen nicht mehr die Wahrheit sagen, wenn die Berichterstattung zu einer angstgetriebenen Aktivität wird. Und wenn das passiert, verliert man die Kontrolle über das Projekt.
Ehrliche Berichterstattung beseitigt keine Probleme. Sie macht sie frühzeitig sichtbar, wenn sie noch klein und behebbar sind.
Und das ist es, was Ihnen die Kontrolle sichert.
Ermutigen Sie zu offener und ehrlicher Kommunikation
Wenn die Mitarbeiter sich nicht trauen, ihre Meinung zu sagen, wachsen die Probleme schneller, als man sie lösen kann.
Ich habe Leute erlebt, die geschwiegen haben, weil sie nicht negativ klingen oder alle anderen aufhalten wollten. Aber das ist es, was ein echtes Risiko darstellt.
Ich versuche also klarzustellen, dass es normal ist, Bedenken zu äußern.
Bei DECODE betrachten wir frühe Probleme als ein Zeichen dafür, dass das System funktioniert und nicht versagt. Wenn jemand auf ein Risiko hinweist, lautet unsere Reaktion: „Danke, dass Sie darauf aufmerksam gemacht haben. Wir sollten es uns gemeinsam ansehen“, nicht mit Schuldzuweisungen oder Druck.
Eine klare Kommunikation sorgt auch für eine reibungslose Zusammenarbeit zwischen verschiedenen Teams oder Abteilungen. Design, Produkt und Technik werden immer unterschiedliche Standpunkte haben, daher ist es wichtig, dass sie diese offen diskutieren.
Missverständnisse beruhen in der Regel auf falschen Annahmen, nicht auf mangelnden Fähigkeiten. Eine strukturierte Kommunikation verringert diese Reibung und sorgt dafür, dass alle Beteiligten auf derselben Seite stehen.
Im Folgenden erfahren Sie, worauf wir achten, um eine ehrliche und gesunde Kommunikation zu gewährleisten:
Aufbau einer Kultur, in der Ehrlichkeit sicher ist – Die Mitarbeiter sollten keine Angst davor haben, zu sagen, dass ein Projekt gefährdet ist. Wenn Ehrlichkeit bestraft wird, tauchen Probleme zu spät auf, um sie kostengünstig zu beheben.
Führen Sie offene Einzelgespräche – Ich stelle Fragen wie „Was macht es schwer, sich zu äußern?“ oder „Wo bricht die Kommunikation zusammen?“ Dann gehe ich auf die Muster ein, nicht auf die einzelnen Personen.
Schaffen Sie eine gemeinsame Sprache – Wir verwenden eine einfache, einheitliche Terminologie in Design und Technik. Dies ist einer der wichtigsten Faktoren, um Verwirrung zwischen den Teams zu vermeiden.
Fördern Sie die funktionsübergreifende Kommunikation – Kleine, funktionsübergreifende Teams arbeiten schneller, weil Designer, Ingenieure und QA von Anfang an in Kontakt sind.
Verwenden Sie ein Buddy-System für neue Mitarbeiter – Es gibt ihnen einen sicheren Ort, an dem sie „offensichtliche“ Fragen stellen können, und senkt die Hemmschwelle, sich zu Wort zu melden, wenn sie an komplexen Projekten teilnehmen.
Gute Kommunikation ist nicht nur ein Soft Skill.
Sie wirkt sich direkt auf die Leistung, die Mitarbeiterbindung und darauf aus, wie schnell das Team Probleme erkennen und beheben kann. Wenn Menschen ohne Angst ihre Meinung sagen können, wird alles andere einfacher.
Optimieren Sie Übergaben zwischen Teams
Übergaben sind einer der einfachsten Punkte, an denen Projekte ihren Schwung verlieren können.
Ich habe das schon oft zwischen Design und Technik erlebt.
Die meisten Probleme waren nicht technischer Natur. Sie waren auf unklare Erwartungen und Annahmen auf beiden Seiten zurückzuführen.
Aus diesem Grund legen wir vor Projektbeginn fest, wie die Übergabe funktionieren soll. Jeder weiß, was übertragen wird, in welchem Format und wer für die Weitergabe verantwortlich ist.
Dadurch wird viel Verwirrung gestiftet und die Teams müssen nicht mehr raten, was die „andere Seite“ gemeint hat.
Dokumentation ist der Schlüssel zu einer guten Übergabe. Halten Sie Entscheidungen, offene Fragen, blockierte Arbeiten und den Kontext in denselben Tools fest, die Ihr Team bereits verwendet.
Hier sind einige der wichtigsten Tipps zur Vermeidung von„Übergabekriegen„:
Legen Sie klare Übergabeanforderungen fest – Definieren Sie genau, was eine Übergabe beinhalten muss, z. B. Benutzerabläufe, Randfälle und bekannte Risiken und Einschränkungen.
Verwenden Sie eine einzige Quelle der Wahrheit – Speichern Sie alle endgültigen Entwürfe, Spezifikationen und Entscheidungen an einem gemeinsamen Ort, um Verwirrung zu vermeiden und neuen Teammitgliedern den Einstieg zu erleichtern.
Stellen Sie sicher, dass verschiedene Teams die Arbeit gemeinsam überprüfen – Verbinden Sie die Dokumentation mit einer strukturierten Demo, damit sich alle über Abläufe, Entscheidungen und Risiken abstimmen können.
Verdeutlichen Sie die Verantwortlichkeiten – Machen Sie auf jeder Seite eine Person dafür verantwortlich, dass die Übergabe vollständig ist und nichts unklar ist oder fehlt.
Reduzieren Sie Annahmen – Eine gemeinsame Terminologie zwischen Design und Technik beseitigt viele Reibungsverluste, bevor sie sich auf Ihr Projekt auswirken können.
Gute Übergaben geben dem nächsten Team das, was es braucht, damit es sich sofort an die Arbeit machen kann, ohne Zeit damit zu verbringen, zu raten, was das vorherige Team gemeint hat.
Das ist eine der einfachsten Möglichkeiten, Verzögerungen zu vermeiden und das Team bei der Stange zu halten.
Seien Sie nicht dogmatisch
Dies ist der wichtigste Tipp, den ich Ihnen beim Aufbau eines Entwicklungsteams geben kann: Seien Sie nicht dogmatisch.
Starre Prozesse zerbrechen in dem Moment, in dem die Dinge unübersichtlich werden. Wenn Teams blind einem Rahmen folgen, hören sie auf zu denken, und der Prozess wird zum Ziel und nicht das Ergebnis.
Und das ist der Punkt, an dem Projekte ins Stocken geraten.
Bei DECODE verwenden wir das, was für das Projekt funktioniert, und nicht das, was in einem Buch steht, dass es funktionieren soll. Unsere Prozesse sind leichtgewichtig und anpassungsfähig. Ich stelle mir das folgendermaßen vor:
Betrachten Sie Frameworks als Werkzeuge – Verwenden Sie sie, wenn sie hilfreich sind, und lassen Sie sie fallen, wenn sie es nicht sind.
Experimentieren Sie in kleinen Zyklen – Setzen Sie Versuche in Timeboxen, damit das Team ohne Unterbrechung lernen kann.
Vermeiden Sie Cargo Culting – Kopieren Sie nicht, was große Unternehmen wie Google oder Meta tun, es sei denn, es passt tatsächlich zu Ihrer Situation.
Anpassung auf der Grundlage von Erkenntnissen – Nehmen Sie Änderungen vor, weil das Team sie braucht, und nicht, weil eine Methode es vorschreibt.
Überprüfen Sie Prozesse häufig – Prozesse sollten sich mit dem Produkt und dem Team weiterentwickeln.
Bleiben Sie ergebnisorientiert – Wenn es die Lieferung, Qualität oder Kommunikation verbessert, behalten Sie es bei. Wenn nicht, entfernen Sie sie.
Wir passen unsere Prozesse für verschiedene Projekte an, wenn sich der Umfang ändert oder wenn unser derzeitiger Ansatz keine Ergebnisse mehr liefert.
Ich möchte Sie ermutigen, zu experimentieren. Probieren Sie für ein paar Wochen einen neuen Planungsrhythmus aus. Passen Sie Standups an. Ändern Sie die Art und Weise, wie Sie Tickets schreiben.
Und wie immer gilt: Hören Sie auf Ihr Team.
Beschweren sie sich darüber, dass die täglichen Standups zu lang sind? Kürzen Sie sie. Oder wird in den Sprint-Reviews und Retrospektiven immer wieder dasselbe Thema behandelt? Lassen Sie sie weg.
Ihr Ziel sollte es nie sein, Scrum, Kanban oder eine andere Methodik perfekt zu befolgen. Sie müssen flexibel sein und einen Rhythmus finden, der Ihrem Team hilft, schneller zu liefern.
Halten Sie Ihre Kernprozesse konstant und passen Sie die Details an, wenn sich Ihre Anforderungen ändern. Nehmen Sie nicht plötzlich große Änderungen vor, wenn sie nicht absolut notwendig sind.
Und wenn Sie sie doch vornehmen müssen, nehmen Sie sich die Zeit, sie zu planen, bevor Sie loslegen. Denken Sie daran: Langsam ist sanft, sanft ist schnell.
Wie Sie ein leistungsfähiges Entwicklungsteam aufbauen: FAQs
Team structure should support the work, not slow it down. When the structure stops matching reality, you’ll see the signs long before the team says anything outright.
Look for things like:
Slow decisions because no one knows who owns what
People waiting on each other or stepping on each other’s toes
The same questions resurfacing in every sprint
Constant bottlenecks around one person or skillset
Those signals usually mean the structure isn’t keeping up with the scope, the team size or the product lifecycle.
Don’t wait for a crisis to fix it. Review the structure every few months, even if everything feels “fine.” Small adjustments early are easier than big reorganizations later.
I look at meetings the same way I look at features. If they don’t add value, remove it.
Keep meetings short and define the purpose upfront. A meeting should help you make a decision, remove a blocker or adjust the plan. If it doesn’t do one of those three things, cut it.
Also, try to shift as much as we can to async updates.
Most status checks, planning notes and small questions work better in writing. It lets people respond when it makes sense for them and keeps the team focused on actual work instead of jumping between calls all day.
If you want to keep meetings relevant, ask two simple questions:
Does this need a conversation?
Does it need to happen now?
If the answer is “no” to either, either send a quick message or drop it.
Honest communication always starts with leadership. People won’t speak up if they think honesty is risky, so try to show it’s safe by going first.
When I admit mistakes or raise risks early, the team follows.
Also, you need to react well when someone brings up a problem. A simple “Thanks for flagging it” goes a long way.
You set the tone. If you’re open, direct and calm about problems, the team will be too.
Suchen Sie einen zuverlässigen Softwareentwicklungspartner?
Der Aufbau eines leistungsstarken Teams erfordert mehr als nur gute Ingenieure. Es braucht eine klare Struktur, ehrliche Kommunikation und Prozesse, die den Mitarbeitern helfen, ihre beste Arbeit zu leisten, ohne sie zu bremsen.
Genau so haben wir unser Team bei DECODE aufgebaut.
Wir haben mehr als ein Jahrzehnt damit verbracht, Unternehmen in der Finanzbranche, im Gesundheitswesen, in der Telekommunikation und in anderen Branchen dabei zu helfen, Produkte zu entwickeln, die von starken, zuverlässigen Ingenieurteams abhängen.
Und wir haben gelernt, wie man diese Teams so aufstellt, dass sie vom ersten Tag an schnell, abgestimmt und fokussiert arbeiten.
Unsere Ingenieure, Designer und technischen PMs wissen, wie man komplexe Ideen in funktionierende Software umsetzt. Und wir sorgen dafür, dass sich der gesamte Prozess klar und überschaubar anfühlt.
Wenn Sie ein Projekt planen und Hilfe von einem hochkarätigen Team benötigen, das weiß, wie man es umsetzt, lassen Sie uns darüber sprechen. Wir vereinbaren einen kurzen Gesprächstermin, um zu erfahren, was Sie vorhaben, und um zu sehen, wie wir Ihnen bei der Verwirklichung helfen können.
Mario sorgt dafür, dass jedes Projekt reibungslos läuft. Als überzeugter Verfechter der Ansicht, dass die Menschen bei DECODE die wichtigste Ressource sind, wuchs er ganz natürlich in seine frühere Rolle als People Operations Manager hinein. Heute ermöglicht ihm sein enzyklopädisches Wissen über die Rolle jedes DECODErs und seine Expertise in allen technischen Belangen, die technische Vision von DECODE als CTO zu leiten und sicherzustellen, dass wir stets einen Schritt voraus sind.
Teil Ingenieur und scheinbar auch Teil Therapeut, bleibt Mario immer ruhig unter Druck, was hilft, die stressfreie Atmosphäre im Büro aufrechtzuerhalten. Tatsächlich ist Sitzen und Nachdenken sein Haupt Hobby. Was könnte Zen-artiger sein als das?
