Interview: Verschwende niemals eine gute Krise – Low Code, Agile und Kreativität

Der Informatiker Jurgen Appelo erzählt im Interview von Sterbehilfe für dysfunktionale Unternehmen und wieso er zugleich Programmieren und Low Code liebt.

In Pocket speichern vorlesen Druckansicht 4 Kommentare lesen

(Bild: Alones/Shutterstock.com)

Lesezeit: 24 Min.
Von
  • Silke Hahn
Inhaltsverzeichnis

IT-Fachleute hätten ihren Teamleitungen sicher öfter mal ein Wörtchen mitzuteilen zu gelungener oder missglückter Projektführung – wenn diese ihnen denn zuhörten. Doch greifen die meisten Softwareentwickler nicht gleich zur Feder, und in den wenigsten Fällen würde wohl ein Bestseller daraus, den Führungskräfte auch lesen. heise Developer hat im Vorfeld der Fachkonferenz inside agile den niederländischen Informatiker Jurgen Appelo zum Gespräch eingeladen, der nicht nur technisch versiert ist, sondern auch Sachbücher zu Führungsthemen geschrieben hat, die Resonanz finden.

Was ihn zum Schreiben anspornte, sein Verhältnis zu den "agilen Gurus" und zum Agilen Manifest, aber auch seine Vorlieben beim Programmieren sowie Low Code und Bloggen sind Teil des Gesprächs, das im Original auf Englisch stattfand.

heise Developer: Jurgen, du hast schon viele Rollen eingenommen im Berufsleben: Autor, Sprecher, Unternehmer, aber auch Softwareingenieur und CIO großer Entwicklerteams. Was genau machst du heute beruflich, und welcher Weg führte dich dorthin?

Interviewgast Jurgen Appelo

Jurgen Appelo ist ein niederländischer Serienunternehmer, Autor und Redner sowie Informatiker. Er gilt als Experte für agile Leadership-Themen und bezeichnet sich selbst als kreativen Netzwerker. Neben seinem Blog schreibt er Bücher, unter anderem "Management 3.0", "Startup, Scaleup, Screwup" und "Kreativ Denken, beherzt Machen, erfolgreich Skalieren – 42 Werkzeuge für Führungskräfte, die sich und ihre Organisation verbessern möchten".

Jurgen Appelo: Ursprünglich bin ich Softwareingenieur. Ich habe an der Technischen Universität in Delft studiert, Softwaretechnik und Informatik. Ein echter Nerd oder Geek war ich aber nie. Ich programmiere für mein Leben gern, doch meine Interessen waren zu breit gefächert. Ich mag auch Buchhaltung, Marketing und Führung, das Erstellen von Inhalten. Bei so vielen Interessen kann man nicht mit allem Schritt halten, was in der Technologie passiert. Seit zwölf Jahren habe ich keine einzige Zeile Code mehr geschrieben. Vielleicht werde ich eines Tages, wenn ich alt bin, als Hobby zum Programmieren zurückkehren.

heise Developer: Was war deine erste Programmiersprache als Einstieg ins Coden?

Appelo: Basic, auf meinem Commodore 64. Meinen C64 kannte ich in- und auswendig, den liebe ich innig. Darauf habe ich auch ein bisschen Maschinensprache gemacht, an der Universität bin ich zu Turbo Pascal übergegangen. Danach habe ich andere Sprachen gelernt, C++ und sogar ein bisschen COBOL.

heise Developer: COBOL ist doch neuerdings wieder gefragt wegen Legacycode. Mit einem zwinkernden Auge: Wie wäre es damit für den Ruhestand später?

Appelo: Nein, danke. Das war 1987 und mir war damals schon klar, COBOL ist schrecklich. Ich habe mich auf Turbo Pascal konzentriert und bin dann zu Microsoft .NET übergegangen, danach habe ich aufgehört. Ich wurde Manager, war Chief Information Officer und leitete bis zu 100 Leute in mehreren Softwareteams – auch Projekt- und Produktmanager war ich. Als 2010 mein Buch "Management 3.0" erschien, habe ich meinen Job gekündigt und mich selbstständig gemacht. Das hat mein Leben verändert. Seither bin ich selbstständig als Redner, Autor, Unternehmer. Ich habe alle möglichen Dinge ausprobiert. Manches funktioniert, manches nicht – so ist das eben.

Für Führungskräfte und Product Owner: Fachkonferenz inside agile

Jurgen Appelo ist Keynoter bei der agilen Konferenz "inside agile" am 3. und 4. Mai 2022 (Online).

Kaum ein Unternehmen kommt heute noch ohne agile Arbeitsweisen aus, viele Teams haben mittlerweile agile Methoden im Einsatz. Häufig müssen sie jedoch feststellen, dass sie damit nicht automatisch schneller, beweglicher und effizienter werden. Die inside-agile-Konferenz greift das Problem auf und zeigt, welche Lösungen sich in der Praxis bewährt haben.

Die Themen der beiden Online-Tage lassen sich dem Programm entnehmen. Im Fokus stehen folgende Fragen:

  • Welcher Führungsstil passt zu mir und wie kann ich mich als Leader weiterentwickeln?
  • Wie verbessere ich die Arbeit selbstorganisierter Teams und deren Zusammenarbeit?
  • Welche Methoden und Ideen helfen mir, das gesamte Unternehmen agiler zu gestalten?

Die Konferenz richtet sich an Führungskräfte aller Ebenen, Produktverantwortliche sowie Menschen in agilen Rollen wie Scrum Master, Product Owner oder Agile Coaches. Tickets sind zum Preis von 449 Euro (zzgl. MwSt.) auf der Website verfügbar und gewähren Zugang zu beiden Konferenztagen.

heise Developer: Was hat dich dazu bewogen, dieses Buch zu schreiben?

Appelo: Eigentlich wollte ich ein Buch über Komplexitätsforschung schreiben, weil ich mich Ende der 90er, Anfang der 2000er Jahre für Chaostheorie und Komplexität interessiert habe. 2001 kam Agile auf, und ich interessierte mich aus beruflichen Gründen dafür. In den nächsten zehn Jahren führte ich in meinem Job als CIO Scrum in meiner Organisation ein und lernte, wie man als Manager in einem agilen Kontext arbeitet. Und mir ist aufgefallen, dass dieses Thema von keinem der "Gurus" damals wirklich angesprochen wurde. In den ersten Jahren konzentrierten die sich hauptsächlich auf die Teamebene.

heise Developer: Wen meinst du mit Gurus?

Appelo: Die Autoren des Agilen Manifests, Jim Highsmith, Ken Schwaber, Kent Beck, Martin Fowler… die hatten alle einen technischem Schwerpunkt. Damals habe ich alle Bücher zum Thema verschlungen. Aber man kann nicht mal eben die Arbeitsweise von Softwareteams ändern ohne den Rest der Organisation, damit hatte ich als Leiter mehrerer Teams zu kämpfen. Es gab fast nichts zu dem Thema. Irgendwann bin ich voll eingestiegen, der Perspektivwechsel half: Wie agieren Management und Führungskräfte in der agilen Welt? Hier war ein Problem, das gelöst werden musste, und das Thema war noch unbesetzt.

Durch meine Beschäftigung mit Komplexitätsforschung und Systemdenken verfügte ich über einen soliden Hintergrund für das Buch. Die Kombination hat gut funktioniert: Systemdenken und Agile passen hervorragend zusammen. Ich konnte die Managementaspekte erklären, da ich mich von der Verwaltung komplexer Systeme inspirieren ließ. Ich bin immer noch stolz auf das Buch, es hat mich einige Jahre gekostet. Dass es so ein Renner würde, hätte ich allerdings nicht erwartet. Es war das erste Buch, das ich veröffentlicht habe. Ein paar Jahre zuvor hatte ich mich an einem Roman versucht, was aber in die Hose ging.

heise Developer: Was war dein Antrieb, es mit einem Sachbuch erneut zu probieren?

Appelo: Als Manager versuchte ich herauszufinden, wie ich meiner Organisation zum Erfolg verhelfen kann, und mir stand nicht viel an Literatur zur Verfügung – abgesehen von allgemeinen Management- oder Führungsbüchern. Die hatten keinen technischen Blickwinkel. 2008 begann ich mit einem Blog, noop.nl, und ein paar Jahre lang habe ich nur Blogeinträge geschrieben. Kurze Textstücke, zu denen ich Feedback bekam. Das lässt sich als ein agiles Prinzip außerhalb der Softwareentwicklung erklären: Wenn du ein Buch schreibst, beginne mit einem Blog! Während des Schreibens kann man herausfinden, was die Leute am interessantesten finden. Worauf bekommt man das beste Feedback? Und wozu erhält man Korrekturen und neue Erkenntnisse?

Zu dieser Zeit gab es noch nicht einmal Social Media, damals hat jeder Blogs veröffentlicht. Der kurze Feedbackzyklus ist etwas, was ich von den agilen Gurus gelernt hatte. Aber sie haben es vor allem auf die technische Seite der Dinge angewandt, um schnelles Feedback zur Programmierung zu bekommen: ob Funktionen funktionieren oder nicht, ob sie von den Benutzern genutzt werden oder nicht. Das gleiche Prinzip habe ich auf Management und Führung angewandt: Wie bekommt man schnelles Feedback von der Teamleitung? Das Prinzip blieb dasselbe, die Praxis war völlig anders. Als ich meine Stelle antrat, lag die Fluktuation in der Firma bei 15 Prozent, Ingenieure und andere haben oft gekündigt. Ich habe es geschafft, sie wieder auf Null zu senken.

heise Developer: Wie habt ihr das bewerkstelligt?

Appelo: Niemand wollte mehr kündigen. Dass wir Scrum einführten, trug dazu bei, dass sich die Teams selbst organisieren, ihre eigene Planung, Stand-up-Meetings und Retrospektiven machten. Es war neu und aufregend, Teil dieses Wandels zu sein. Lustig war, dass wir damals einen großen offenen Büroraum hatten, in einem berühmten Gebäude in Rotterdam, das zu einem Büroraum umgestaltet worden war. Der Rest des Unternehmens sah die Technik-Abteilung bei Stand-up-Meetings und ähnlichen Aktionen. Ein großer offener Raum, wo alle einander sehen können. Ich mag diese Art von Umgebung, aber nicht jeder fühlt sich damit wohl. Irgendwann haben die Vertriebs- und die Marketingabteilung auch Stand-up-Meetings abgehalten, weil sie uns dabei auf der anderen Seite des Raums gesehen hatten. Das war ziemlich cool.

Plötzlich sah ich sie auf der anderen Seite des Büros Stand-ups machen und fragte mich, was zum Teufel da los ist. Über die Raucher hatte es sich wohl herumgesprochen, die kamen abteilungsübergreifend außerhalb des Gebäudes zusammen.

heise Developer: Zwei entscheidende Elemente treten hervor – Architektur kann hilfreich sein, und Raucherpausen waren es offenbar auch: Siehst du eine Verbindung zwischen solchen Pausen und Kreativität?

Appelo: Das sind unbeabsichtigte, aber nützliche Nebeneffekte von eigentlich schädlichen Dingen. Großraumbüros sind auch nicht so gut für die Gesundheit, wie man inzwischen weiß – haben aber auch ein paar Vorteile: Man kann buchstäblich sehen, was auf der anderen Seite des Unternehmens vor sich geht.

heise Developer: Die Pandemie hat uns in die Vereinzelung geschickt. Wie war diese Zeit für dich?

Appelo: Seit 2011 arbeite ich remote. Ich habe mein Zuhause und ich reise viel, habe auf Konferenzen und Veranstaltungen auf der ganzen Welt gesprochen und Workshops gegeben. Ich hatte auch einige Unternehmen ins Leben gerufen, Lizenzen rund um meine Kursunterlagen, was recht gut lief. Im Jahr 2019 war ich an etwa 250 Tagen auf Reisen, ein Wahnsinn. Ich hatte viele verschiedene Kunden und Auftraggeber, war von niemandem abhängig. Als Unternehmer will man nicht von einem einzigen Großkunden abhängig sein, das wäre riskant. Damals dachte ich, ich hätte alles im Griff. Mir war nicht bewusst, dass ich eine Achillesferse hatte, nämlich das Reisen.

Durch Reisen habe ich Geld verdient, und plötzlich hörte das im März 2020 auf. Alle Termine waren innerhalb weniger Wochen gestrichen. Mein gesamtes Einkommen für das Jahr hat sich in Luft aufgelöst, von einem Moment auf den anderen. Das hatte enorme Auswirkungen auf mich und mein Geschäft. Zum Glück hatte ich noch andere Dinge am Laufen, die Lizenzeinnahmen aus meinen Workshops, Tantiemen aus Büchern. Aber das Wichtigste waren die Veranstaltungen gewesen, die zu verlieren war schmerzhaft. Aber verschwende niemals eine gute Krise. Das war der Moment, um etwas Neues auszuprobieren. Ich war zwei Jahre lang hauptsächlich zu Hause und habe andere Möglichkeiten getestet, Einnahmen zu erzielen. Heute bin ich besser aufgestellt – weniger abhängig vom Reisen.

Eine Sache habe ich gelernt: Wahrscheinlich gibt es immer eine Achillesferse, egal, was man tut, und man sollte sich dessen bewusst sein. Wer hätte gedacht, dass die Reisetätigkeit plötzlich so stark zurückgehen würde, weltweit und global. Damit hätte ich nie gerechnet. Aber ich profitierte von meiner Erfahrung mit der agilen Praxis: Innerhalb von zwei, drei Wochen hatte ich den Prototyp eines neuen Geschäfts am Laufen, und seitdem habe ich nachjustiert.

Es gibt diese berühmte Metapher vom Frosch im kochenden Wasser. Das Wasser wird heißer und heißer, aber er merkt es nicht und springt nicht heraus. Und dann kocht der Frosch. Man muss aus dem Wasser springen, bevor man gekocht wird. Es kam mir sehr gelegen, dass ich so viele Anfragen für Veranstaltungen und Konferenzen hatte. Ich musste die meisten davon ablehnen, weil es einfach überwältigend war. Es war toll, es war cool, und ich hatte Spaß, aber dann ist es einfach, nicht zu sehen, was um einen herum passiert, dass das Wasser langsam kocht. Da ist diese Pandemie, die auf uns zukommt. Vielleicht bemerkt man die Anzeichen nicht, und irgendwann ist das Wasser zu heiß.

Es fühlt sich gut an, eine neue Fähigkeit zu entwickeln. Ich bin davon ausgegangen, dass meine Finger nur zum Tippen auf Tastaturen da sind und für nichts anderes. Jetzt stellt sich heraus, dass ich gut bin im Malen. Inzwischen habe ich viele Wände und Räume gestrichen und freue mich schon auf das nächste Malerprojekt. Dank Corona habe ich mich in einem Bereich weiterentwickelt, der mir gar nicht bewusst war. Das ist ein Denkanstoß für andere: Vielleicht hast du verborgene Fähigkeiten oder Dinge, von denen du denkst, dass du sie nicht magst, aber eigentlich könntest du anfangen, sie zu mögen, wenn du sie einfach ausprobierst. Vielleicht braucht es eine Krise, um sie auszuprobieren.

heise Developer: Jetzt haben wir über die Krise als Motor für Veränderung gesprochen, aber Krisen sind ja nur eine Möglichkeit, um Kreativität anzustoßen, und sie sind eher chaotisch. Gibt es ein Werkzeug aus der Praxis, das du besonders nützlich findest?

Appelo: Interessante Frage, denn das Agile Manifest stellt Menschen und Interaktionen über Prozesse und Werkzeuge. Es geht um die Menschen, aber die müssen miteinander kommunizieren, und dafür sind Werkzeuge erforderlich. Ohne sie sind wir nicht in der Lage, miteinander zu kommunizieren. Wir benutzen jetzt die englische Sprache als Werkzeug. Tools müssen die individuellen Interaktionen unterstützen, versteht sich. Nicht umgekehrt.

Um noch einmal die Brücke zur Malerei zu schlagen: Mir ist aufgefallen, dass es gar nicht so wichtig ist, den perfekten Pinsel oder die perfekte Farbrolle zu finden, denn der Großteil der Technik liegt in der Hand des Malers. Entscheidend ist, wer malt – welche Art von Techniken und Verfahren dieser Mensch lernt und anwendet. Dann sind die meisten Pinsel und Farbroller in Ordnung. Leute verbringen manchmal zu viel Zeit damit, nach dem besten Werkzeug zu fragen. Ein guter Koch kann in jeder Küche ein großartiges Gericht zaubern, ohne die besten Messer und die besten Töpfe und Pfannen zu haben.

Dennoch habe ich in den letzten zwei Jahren einige Dinge entdeckt, die mir sehr geholfen haben. Ich bin ein Fan von No-Coding- beziehungsweise Low-Code-Plattformen geworden. Eine meiner Lieblingsplattformen ist Airtable, eine andere Integromat.

Warum dies meine Lieblingstools sind: Mit ein paar schnellen Klicks kann ich einen Prototyp einer Idee für eine neue Anwendung erstellen, Dinge verbinden und etwas Grundlegendes zum Laufen bringen, ohne eine Zeile Code einzugeben. Das ist das Versprechen von Low-Code- und No-Code-Plattformen. Der Code ist auf eine niedrigere Ebene verlagert, und dann wird jeder zum Programmierer. Wie bereits gesagt, hatte ich innerhalb kurzer Zeit den Prototyp für eine Idee zum Laufen gebracht. Ich habe sogar ein Video davon gemacht und auf YouTube gestellt. Zwei, drei Wochen später hatte ich ihn mit Airtable und mehreren dieser No-Code-Plattformen auf den Markt gebracht. Die Leute geben Feedback zur Idee, zum Prototyp, zum Minimum Viable Product, und ich habe keine einzige Zeile Code geschrieben!

heise Developer: Du hast als professioneller Softwareentwickler angefangen, der das Programmieren mag und genießt. Wie passt das zusammen mit einer Vorliebe für Low Code? Empfiehlst du gestandenen Entwicklern etwa, das auszuprobieren?

Appelo: Ja, auf jeden Fall. Weil man schneller Ergebnisse erzielen kann als mit Sprachen der dritten oder vierten Generation. Wir wollen schnelles Feedback zu unseren Ideen, denn neun von zehn Ideen funktionieren nicht und man muss sie verwerfen. Eine große Verschwendung, wenn man viel Zeit mit dem Programmieren verbringt. Oft wollen wir den selbst geschriebenen Code nicht wegwerfen, weil wir an ihm hängen, Zeit und Energie darauf verwendet haben. Dann fühlen wir uns schlecht, wenn wir ihn wegwerfen.

Warum zählt man nur dann als Programmierer, wenn man Zeilen von Code schreibt? Ich bin jetzt ein erfahrener Benutzer von Airtable. Ich verwende Ansichten, Abfragen, Filter und Sortierung. Auch denke ich, dass ich bei der Verwendung von Airtable viel von meinem ursprünglichen Talent, Datenbanken zu verstehen und Abfragezeichenfolgen zu verstehen, einsetze. Heißt das jetzt, dass ich kein Programmierer mehr bin? Ich wage zu behaupten, dass ich ein Programmierer bin, allerdings auf einer höheren Ebene.

heise Developer: Low-Code-Plattformen siehst du also mehr als Werkzeuge zum Automatisieren der Abläufe beim Programmieren?

Appelo: Genau. Man sieht visuell, wie die Daten von einem Ort zum anderen fließen, dann werden sie aufgeteilt, man erstellt Filter, und das ist so cool. Hier kommt eine E-Mail an, dort wird ein Datensatz erstellt, und dort wird ein Tweet versendet – all das lässt sich durch visuelles Ziehen miteinander verbinden. Das ist auch Programmieren, denke ich.

Als ich von 1987 bis 1994 an der Universität Delft arbeitete und studierte, stand ein Versprechen im Raum. Damals haben wir visuell programmiert und hatten Kurse darin. So langweilig! Man hatte Flussdiagramme, die man miteinander verbinden musste, sehr klobig und umständlich. "Warum nicht einfach Pascal benutzen?", dachte ich bei mir. "Viel einfacher und schneller..." Erst dreißig Jahre später wurde das Wirklichkeit. In den 80er Jahren haben wir es versucht, Katastrophe. Eine Zeit lang hörte man nichts mehr vom Visuellen Programmieren. Aber jetzt mache ich das in Integromat, und es funktioniert wunderbar.

heise Developer: Inzwischen gibt es KI-gestützte Möglichkeiten wie Codex und GitHub Copilot, und bald werden Programme noch besser in der Lage sein, Anweisungen in natürlicher Sprache in Code zu übersetzen. Dagegen sieht Low Code doch alt aus. Wie siehst du diese Entwicklung? Ist das ein brauchbarer Weg dafür, dass Menschen ihre Kreativität besser nutzen können?

Appelo: Gewiss. Wenn man mehr Schichten auf den Stapel legt, ist irgendwann jeder ein Programmierer. Mein Cousin ist ein Programmierer, wenn er versucht, tägliche Routinen mit Google Home oder Alexa zu erstellen. Wenn er das Haus betritt, sollen alle Lichter angehen, das ist Programmieren. Und gleichzeitig ist er kein Programmierer. Wir bekommen Werkzeuge, um das mit der Denkweise eines Programmierers zu tun, so dass wir immer mehr Menschen zu Programmierern machen. Ingenieure können wählen, womit sie sich am wohlsten fühlen.

Ich fühle mich wohl, wenn ich in der Hierarchie aufsteige und keine Codezeilen mehr schreibe. Aber andere Ingenieure schätzen diese Art von Dingen. Es gibt Leute, denen Maschinensprache taugt. Manche lieben C++ oder eine andere Sprache, und das ist auch gut so, denn wir brauchen das weiterhin. Es gibt immer noch Chips, die hergestellt werden müssen. Es gibt immer noch Programmierung.

heise Developer: Du hast einmal kritisiert, dass einige Consultinganbieter "alten Wein in neuen Schläuchen" verkaufen. Sind das Ausreißer, oder gibt es in der agilen Szene ein grundlegenderes Problem mit Etikettenschwindel?

Appelo: Ich bin ein Optimist. Das ist eine Nebenwirkung, die sich daraus ergibt, dass Unternehmen oft gezwungen sind, agil zu sein und geschäftliche Agilität erreichen müssen. Man kann nicht mehr nicht agil sein – sonst stirbt man als Organisation. Die Unternehmen bemühen sich, agiler zu werden, und einige stellen die falschen Leute ein, die ihnen alten Wein in neuen Schläuchen verkaufen. Das ist schade für sie, lässt sich aber mit guter Recherche vermeiden. Der größere Kontext ist ja: Die Geschäftswelt wandelt sich, und einige werden auf der Strecke bleiben. Das ist nicht unbedingt schlecht. Warum sollten schlechte Organisationen weiterbestehen? Einer meiner Freunde sagte: "Ich hoffe, dass sie aussterben. Ich möchte ihnen dabei helfen, ersetzt zu werden." Die Mitarbeiter kündigen ab einem gewissen Punkt und gehen zu anderen Organisationen, die besser funktionieren. Kein Problem. Einen Hinweis ist es aber wert: Es gibt agiles Theater, es gibt Fake Agile und Fake Scrum. Wie bei den Fake News – wann immer etwas populär ist, sind Fälschungen zu finden. Manche Leute versuchen, auf der Welle zu reiten, ohne sich anzustrengen.

heise Developer: Du hast auch etwas Neues im Gepäck. Was steckt hinter UnFix?

Appelo: In den letzten paar Jahren sind ein paar Dinge aufgetaucht, die wirklich gut waren: Team Typologies und Dynamic Re-Teaming. Das beschreibt, wie sich Teams kontinuierlich reformieren können und wie das der gesamten Organisation zugute kommt. Darüber hatte ich dann Einsichten, wie eine Organisation aussehen könnte. Das UnFix-Modell ist ähnlich wie Legosteine, die man auf unterschiedliche Weise kombinieren kann, um ein eigenes Organisationsdesign zu schaffen. Darin unterscheidet es sich von SAFe, denn SAFe kommt mit einem fertigen Bild daher, das sagt: "So sollte Ihre Organisation aussehen". Stattdessen versuche ich, viele verschiedene Bilder anzubieten, die die gleichen Bausteine verwenden. Der Ansatz scheint den Menschen zu gefallen. Darauf werde ich mich in den nächsten Jahren konzentrieren.

heise Developer: Was kommt als Nächstes bei dir, wirst du wieder mehr reisen?

Appelo: Einige Veranstaltungen werde ich machen, aber nicht so viele wie 2019, habe ich mir vorgenommen. Ein bisschen entspannter will ich es angehen.

heise Developer: Also planst du nicht, wieder an 250 Tagen unterwegs sein?

Appelo: Gott bewahre, nein! Das sollte eine schöne Sache sein – nicht etwas, was man tun muss, um zu überleben. Und das hat sich dank der Pandemie so ergeben, sonst würde ich immer noch Management-3.0-Vorträge halten. Aber Corona hat mich in die Lage versetzt, mich neu zu erfinden, und eine neue Methode zu entwickeln, wie Menschen ihre Unternehmen organisieren können.

heise Developer: Unsere Art, zu arbeiten, hat sich ja insgesamt stark verändert seither. Hast du abschließend noch einen Tipp für uns auf Lager für besseres Arbeiten?

Appelo: Das Pendeln ist für viele Menschen der meistgehasste Teil des Tages. Die Fahrt ins Büro und die Rückkehr nach Hause – das mögen die Wenigsten. Aber es erfüllt einen Zweck, es dient dem Grenzübergang. Man wechselt von einer Identität zur anderen. Man wird von einem Vater oder einer Mutter zum Kundenbetreuer und so weiter. Für die Menschen ist wichtig, dass sie diese Übergänge zwischen einer Rolle und der anderen haben. Problematisch wird es, wenn sich die verschiedenen Rollen ineinander verheddern und man versucht, alles gleichzeitig zu machen. Dann verschwimmen die Dinge und das führt zu Burn-out und anderen negativen Begleiterscheinungen. Unterteilung ist wichtig.

Wir müssen unseren Tag in Abschnitte unterteilen, in denen wir uns auf eine Aufgabe konzentrieren können, und dann einen Übergang zu einer der anderen Aufgaben schaffen. Eine Tasse Kaffee kochen, eine Zigarette rauchen oder von einem Zimmer ins andere gehen. Man bringt seinem Gehirn bei, von einer Rolle in die andere zu wechseln. Aus meiner Sicht ist das der Schlüssel, den wir als Mensch begreifen müssen, denn die Welt ist komplex, und wir werden von so vielen Dingen angegriffen, von all diesen Signalen, die unsere Aufmerksamkeit erregen wollen. Wir müssen uns selbst beibringen, uns auf den Moment zu konzentrieren.

Von Neun bis Fünf zu arbeiten war eine altmodische Art, unsere Rollen und diese Grenzen zu verwalten. Das brauchen wir nicht mehr. Aber wir haben die Verantwortung, unsere Grenzübergänge bewusst zu gestalten und zu verstehen, dass wir verschiedene Rollen innehaben. Manchmal bin ich ein Freund, manchmal bin ich der Partner meiner Frau, ein anderes Mal bin ich Schriftsteller, Redner oder Workshop-Leiter: Dann muss ich in dem Moment da sein, nur das tun und darf mich nicht von den drei, vier, fünf, sechs anderen Rollen ablenken lassen, sonst wird man verrückt. So funktioniert es.

heise Developer: Also sind Menschen, die scheinbar mit Multitasking gut klarkommen, einfach gut im Einteilen ihrer Aufgaben?

Appelo: Ja, Slow-Motion-Multitasking. Wir sind Multitasking-Wesen, aber wir teilen die Projekte, an denen wir arbeiten, auf. Für uns Menschen ist es vorteilhaft, an mehreren Projekten beteiligt zu sein, weil sich die Ideen dann gegenseitig befruchten. Nur, wenn wir verschiedene Dinge verfolgen, können wir innovativ sein. Aber wir sollten nicht versuchen, alles gleichzeitig zu tun. Darin ist das menschliche Gehirn nicht gut. Das ist meine Botschaft zum Mitnehmen.

heise Developer: Jurgen, danke für das inspirierende Gespräch!

Das Interview führte Silke Hahn, Redakteurin von heise Developer.

(sih)