Warum wir keine Titel und Positionen mehr haben

Wir kommen aus der PHP-Community und sind inzwischen in der agilen Community und der JavaScript-Community angekommen. Deshalb bekommen wir es mit, wenn gute Leute nach einer neuen Herausforderung, sprich: nach einem Arbeitgeber, der besser in ihr Leben passt als der bisherige, schauen.

Die Nachricht finden wir erst mal immer super, weil wir die Leute kennen und wissen was sie können. Bei den meisten könnte ich aus dem Stand eine halbstündige Eloge über ihre Fähigkeiten und Talente halten.

Und dann kommt die Irritation. Denn sie wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen.

Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben.
Denn die existieren bei uns nicht mehr.

„Matrix“-Organisation

Warum machen wir „agil“? Weil unsere Arbeit weniger planbar und verlässlich geworden ist, und wir uns jeweils den aktuellen Anforderungen und Erkenntnissen anpassen müssen.

Scrum macht jeden Sprint eine Retrospektive, um die Prozesse und Organisationsform kontinuierlich zu adaptieren. Kanban schleppt ein ganzes Sammelsurium von Messinstrumenten mit, um überhaupt feststellen zu können, wie es im Projekt aussieht und was gerade gebraucht wird. Agil fordert cross-funktionale Teams, bei DevOps wird die Brücke in den Betrieb geschlagen. Das Team ist eigenverantwortlich. Es trägt die Verantwortung selbst. Nicht der Projektleiter, nicht der Teamleiter, nicht der Senior Architect und nicht der Technical Lead.

Und wenn alles angepasst werden kann, und alle Entscheidungen vom Team ausgehen, bilden Positionen und Titel da eine Ausnahme?

Alles darf angepasst werden, nur die Titel und Positionen nicht? Das Team darf entscheiden und ist verantwortlich, ausser da ist ein Technical Lead, ein Architect oder ein Team Lead?

In der Praxis kippen solche Environments dann in die Matrix, die formelle und die reale Welt laufen auseinander.

Red Pill Blue Pill

Red Pill Blue Pill Matrix

Ich nehme die blaue Pille – und lebe in der Matrix weiter

Wir haben formelle Positionen. Ich habe die Verantwortung, die sich aus meiner Position ergibt, und meine Stellung ist über sie definiert. Die Positionen und Titel der Kollegen verhalten sich zu meiner. Wenn jemand Junior ist, und ich der Senior, dann hat mein Wort ganz offensichtlich mehr Gewicht. Und natürlich trägt der Teamleiter die Verantwortung. Er ist weisungsbefugt gegenüber den Kollegen und leitet das Team an. Wenn das Projekt scheitert war er schuld, ausser das Team ist seinen Anweisungen nicht gefolgt.

In der Matrix kann ich Karriere machen. Ich kreide den Projekterfolg meiner individuellen, und nicht der Teamleistung an. Ich melde bei meinem formellen Vorgesetzten, dass ich mit diesem Erfolg jetzt mal mehr Position oder Gehalt bekommen soll. Oder, wenn kein Projekterfolg auf meine Kappe geht – dann melde ich mich bei meinem Vorgesetzten, er solle sich mal endlich um meine Weiterentwicklung kümmern.

Und der macht dann einen Plan mit Fortbildung, alles abgestimmt auf meine Wünsche und Fähigkeiten, und nach X Zeit wächst Titel, Position und hoffentlich auch Einkommen um eins. Und ich bekomme einen Posten mit meinem neuen Level im Team, und die haben sich danach zu richten.

Die meisten Unternehmen die ich kenne funktionieren so, auch wenn sie Scrum oder Kanban machen. Und stehen dabei im harten Widerspruch zu den Grundfesten agiler Arbeit.

Und was passiert dementsprechend im Hintergrund, wenn die Kollegen trotz dieser Strukturen zurechtkommen müssen?

Man arrangiert sich, findet Kompromisse und toleriert die Differenz der realen zur formellen Welt. Jeder von uns kennt Juniors, die dem Senior Dinge erklären, Architekten, bei denen man dankbar ist, dass die Developer etwas anderes implementierten als sie planten, und Teamleiter, die sich Aufgaben ausserhalb des Teams suchen, um dessen agile Arbeit nicht zu stören.

Ich nehme die rote Pille – und erkenne die Matrix

Das Team findet in den Sprints heraus, welche Aufgaben wir haben und wer es machen sollte. Wir wollen dabei alles machen, was das Projekt braucht, und eignen uns die nötigen Kompetenzen bei Bedarf an.

Es ergeben sich Rollen, die sich bei bestimmten Personen zuhause fühlen und gut funktionieren: Kollege A hat ein gutes Gefühl für die Welt der Anwender, und die Ansprechpartner vertrauen ihm zu 100%. Deshalb entscheidet das Team dass er die PO-Rolle ausfüllen soll, weil das den maximalen Benefit für alle bringt. Kollege B trägt schon immer seine soziale Ader mit sich herum, ist aufgeräumt und organisiert, und ein aktives Mitglied in der agilen COP der Firma und oft auf agilen Konferenzen: er nimmt die Rolle des Scrum-Masters ein.

Die DevOps-Themen fallen meist sowieso zur Kollegin mit der Admin-Vergangenheit, die auch schon bei Ubuntu comittete.

Und natürlich wechseln die Rollen. Wenn die PO-Arbeit überhand nimmt unterstützt ein Kollege und übernimmt einen Teil der Aufgaben. Eine andere Kollegen möchte ebenfalls Scrum-Master-Fähigkeiten erwerben. Also arbeitet sie in Ihrer Slacktime gezielt daran. Und nach einer Weile bringt sie das in der Retrospektive auf, und das Team entscheidet dass sie für den nächsten Monat zunächst den bestehenden Scrum-Master unterstützen soll, in den folgenden Sprints dann die Rolle mal zur Probe ganz übernehmen soll.

In der Zwischenzeit wird kein DevOps-Knowhow mehr gebraucht, also landen vermehrt Datenbankthemen bei der Kollegin mit Admin-Vergangenheit.

Diese Welt ist keinesfalls unreguliert. Sie hat klare, einfache Regeln, die nur das dokumentieren sollen was die Wirklichkeit vorlebt.

  • es gibt keine Positionen mehr, nur noch Talente und temporäre Rollen
  • die Rollen bestimmt das Team gemeinsam, und sie ergeben sich aus den realen Anforderungen und den Talenten
  • die Zuordnung eines Kollegen zu einer Rolle ist Sache des Teams – sie treffen im Kontext die optimale Zuordnung
  • die Weiterentwicklung ist ein Abfallprodukt aus diesen Erfahrungen und Engagement im Unternehmenskontext (Slacktime und Konferenzen)
  • Macht und Verantwortung liegt beim Team, nicht beim Titel oder bei der Position
  • das Team kann Macht und Verantwortung temporär delegieren

Das ist, im Gegensatz zur Welt in der Matrix, völlig synchron und kompatibel zu agilen Methoden.

Und wie mache ich jetzt Karriere?

Das liegt nicht mehr bei Dir und Deinem Vorgesetzten, sondern bei Deinem Team und Deinen Peers, denn die sehen jeden Tag Deine Arbeit und sind kompetent, wenn es um Deine Fähigkeiten geht. Wenn die Leute, die auf Deine Arbeitskraft und Unterstützung angewiesen sind sagen „Diese Aufgabe solltest genau Du machen„, dann kannst Du davon ausgehen, dass sie an Deine Kompetenz glauben.

Wenn der aktuelle Scrum-Master und das Team in Deine Erfahrung als Scrum-Master investieren, dann glauben Sie, dass sich dieses Investment in rentieren wird. Und dann habe ich nicht nur die Fähigkeit, die meinen Interessen und einem echten Bedarf entspricht, ich habe sie auch gleich real ausprobiert. Ich finde heraus ob ich es nicht nur will, sondern auch kann.

Und was noch viel wichtiger sind: ich habe Leute, die tatsächlich wollen, dass ich das mache. Wenn ich eine Referenz oder ein Statement zu meiner Fähigkeit haben möchte muss ich die einfach nur fragen. Sie werden mich unterstützen, denn sie haben auch schon dafür abgestimmt, dass ich diese Rolle einnehmen soll.

Und damit habe ich eine neue Form von Karriere: die Position wird ersetzt durch echte Fähigkeiten, an die nicht nur ich und mein Vorgesetzter, sondern alle Kollegen glauben. Damit habe ich wieder eine Position und Verantwortung, denn das Team delegiert sie mit der Rolle temporär an mich. Weil sie es für in der Situation und fachlich für optimal halten, wenn ich das mache. Nicht, weil die formelle Position und Macht es erzwingt.

Und damit habe ich wieder eine Karriere, die im Einklang mit der täglichen Arbeit lebt, und nicht nur – wie bei der blauen Pille – in der formellen Hierarchiewelt stattfindet.

Aber auf meiner Visitenkarte ist Platz für einen Titel!
Hervorragend! Und wir können uns jetzt sogar aussuchen, was wir damit machen wollen. Für Position & Macht brauchen wir ihn nicht mehr, denn die Macht liegt in der agilen Welt bei den Stakeholdern und dem Team. Für die Karrierestufe brauchen wir ihn auch nicht mehr, denn da gibt es viel mehr und echteres Feedback von den Kollegen.
Also kann ich den Platz dazu nutzen, meinen Gesprächspartner mitzuteilen woran sie bei mir wirklich sind.

Der eine ist der Chief Puppeteer, weil das den Kern seiner Rollen am besten trifft. Mein Titel ist Chief Tailwind Officer, weil ich meine Rolle als Verpflichtung zum Rückenwind für Kollegen & Kunden sehe.

Und auf einmal gibt es Titel, die passend und glaubwürdig sind und neugierig machen. Und dann gibt es Werkzeugschmiede, die den Entwicklern ein besseres Handwerk erlauben wollen, Unruhestifter, Feelgoodmanager, DevOps Ninjas und Moneypennys.

Und warum sollte jemand dann bei Euch anfangen?

Offensichtlich nicht, um eine formelle Karriere zu machen. Aber vielleicht möchte man aus seiner eigenen Matrix heraus und genau das machen, von dem die Kollegen denken, dass man es machen sollte.
Oder man legt Wert auf ernstgemeinte Teamarbeit.
Es arbeiten bei uns viele gute & schlaue Leute in guten & schlauen Teams. Die vielen Konferenzvorträge, Bücher und Zeitungsartikel sind ein Nebenprodukt dieser Zusammenarbeit guter Leute.
Nicht weil es Principal Architects, Rockstars oder Project Heros gibt. Sondern gute Kooperation von Talenten.

Für neue Blogupdates anmelden:


57 Gedanken zu “Warum wir keine Titel und Positionen mehr haben

  1. Spannendes Konzept! Im Artikel ist immer wieder von Vorgesetzten die Rede. So ganz ohne Hierarchie geht es also (noch) nicht. Wo ist da die Grenze?

    Und zweite Frage: An was macht ihr Gehalt und Gehaltserhöhung fest?

    Gruß Joscha

    • Ja, im Gegenbeispiel ist jeweils von Vorgesetzten die Rede :-) .

      Aber tatsächlich: wir haben 3 Geschäftsführer/Gesellschafter die als Stakeholder andere Rechte und Pflichten geniessen/wahrnehmen müssen. Das bedeutet aber nicht per se disziplinarische Veranwortung, sondern vor allem eine aktive Stakeholderrolle, analog zu Kunden & Kollegen.

      Gehalt:
      Wir haben eine Gehaltsmatrix, die die verschiedenen Aspekte des Gehaltes transparent macht.
      – Marktpreise für Branche, Fähigkeiten & Standort, meist auf Basis von Robert Half-Daten
      – persönliche Weiterentwicklung nach Einschätzung der Teamkollegen
      – Beitrag zum Teamerfolg nach Einschätzung der Teamkollegen
      – Progression anhand von marktüblicher Progression
      – individuelle Gehaltsentwicklung im Verhältnis zur Marktentwicklung

      Dazu kommen transparente Rahmenbedingungen:
      – wieviel Geld wir pro Jahr in Fortbildung pro Kollege investiert haben
      – wieviel Gehaltsprogression wir im Jahr für alle im Jahr etwa anstreben (etwas mehr als marktüblich, aber eben nicht zu viel mehr :-) )
      – wieviel Geld da überhaupt zum Verteilen übrigbleibt.

      Vielleicht noch eine Anmerkung:
      Das ist bei uns alles Work in Progress, in Diskussion und Bewegung. Und wir haben bestimmt keine goldene und richtige Lösung, es ist nur die richtigste, die wir im Moment für uns zu fassen bekommen.
      Ich könnte noch seitenweise darüber erzählen, wie man sich darum kümmern muss, das die Kollegen gute & echte Referenzen für zukünftige Stellenangebot bekommen. Dass man Weiterentwicklung & Leistung im Team und in der Firma transparent macht.
      Dass man mit dem Lake-Wobegon-Effekt bei der Gehaltsverteilung umgeht (80% glauben sie wären überdurchschnittlich). Und vieles mehr.

      • Hi Johann-Peter,

        schöner Beitrag mit interessanter Diskussion.

        Magst du noch ein paar Details zum Thema Gehaltsmatrix geben? Klingt ja fast nach einer Formel ähnlich der von Buffer. Wie transparent ist diese und das Gehalt? Wie habt ihr die Transition von alten Gehältern in die neue Formel gemacht? Was habt ihr mit Ausreissern nach oben/unten gemacht? Wie ist es bei den Mitarbeitern angekommen? Habt ihr die Formel veröffentlicht?

        Danke dir schonmal vorab:)

        Gruß Leif

  2. Es gibt die Dimension des Mitarbeiters innerhalb eurer Firma, aber auch die Dimension, in der eure Firma nur einer von mehreren Meilensteinen innerhalb der Karriere des Mitarbeiters ist. In der ersten Dimension mag euer Modell sehr sinnvoll sein, für die Karriere des Mitarbeiters in der zweiten Dimension reicht es meiner Meinung nach nicht aus.

    Ich bevorzuge ein Modell, in der beide Dimensionen parallel existieren, sozusagen als Paralleluniversen:

    Einerseits gibt es die althergebrachte Struktur mit Junior Backend Developers etc., klassische Teamstrukturen mit z. B. Head Of Frontend Development, Director Engineering etc., aber das wird nur gebraucht für den administrativen Teil des ganzen, für Scrum-Team-übergreifende Kommunikation, Eskalation und so weiter. Ich finde es gut, dass jeder Mitarbeiter genau einen disziplinarischen Vorgesetzten hat, zu dem eine besondere Vertrauensstellung aufgebaut werden kann.

    Andererseits können operativ genau die Mechanismen der Crossfunktionalität benutzt werden, wie Du sie beschrieben hast – es sind aber eben firmeninterne und -spezielle Mechanismen, die eine Dimension höher liegen als die zugrundeliegende “offizielle” Teamstruktur.

    • Ja, es gibt einen Grund, warum wir diese Paralleluniversen nicht wollen, bzw. von transaktionalem Management und Hierarchien dort, wo wir können, verzichten. Wir haben das ja wie alle anderen über Jahre so gemacht. Management by Exception verlegt die Entscheidung in komplexen Welten an eine weniger kompetente Stelle. Team-übergreifende Kommunikation funktioniert bei uns wie bei vielen anderen mit verschiedene Querschnittsforen, wie DevOps-Gruppe, Scrum-Cop etc. Dazu kommt ein montäglicher Jour Fixe, bei dem _jeder_ teilnehmen und Themen über Teamgrenzen hinweg ansprechen kann.
      Wie kann ich eine Vertrauensstellung zu einem „Vorgesetzten“ aufbauen, der mir durch fremde Hand vorgesetzt wird? Das ist imho durch freie Wahl der Ansprechpartner für 1:1 besser gelöst.
      Wenn es Dich interessiert: schau Dir mal die Konzepte aus Organisation für Komplexität von Niels Pflaeging bzw. Denkwerkzeuge für Höchstleister von Gerhard Wohland an, insbesondere Niels erklärt die Vorteile einer Netzwerkstruktur gegenüber der intuitiven Hierarchie gut.

  3. Super interessanter Bericht. Ich finde die Artikel zu diesem Thema sehr spannend und habe mich schon öfter gefragt, wie sich die Konzepte agiler Arbeitsweise mit formellen Punkten wie „Positionen“ vertragen. Positionen erlauben es nicht, sich wirklich zu entfalten. Auf der Karte steht dann zum Beispiel „Senior Entwickler“ aber die Aussagekraft ist gleich null und schränkt einen Mitarbeiter in seiner Entfaltung ein. Wenn sich der Gedanke „Ich bin ja nur Entwickler aber eigentlich möchte ich auch mal Projektmanagement machen, vielleicht bewerbe ich mich ja bei einer anderen Firma“ mal verfestigt hat, ist es dann oftmals zu spät.

    Wenn der Arbeitgeber das richtige Klima schafft, und agile Arbeitsweise und der Verzicht auf Positionen sind imho mehr als eine gute Basis, so dürfte die langfristige Mitarbeitermotivation auch gegeben sein.

    Der heutiger Arbeitnehmer ist nicht mehr Teil einer Abteilung oder eine Nummer innerhalb einer Linien- oder Matrixorganisation sondern strebt immer mehr nach Selbstverwirklichung und das heißt eben auch, dass man öfter mal was neues ausprobieren möchte.

  4. Vielen Dank für den spannenden Artikel. Das klingt alles nach einem hohen Reifegrat im Blick auf agile Organisation. Ich kann auch vieles davon nachvollziehen – gerade in Sachen „Junior/Senior“. Was mir noch schwer fällt nachzuvollziehen und was sich für mich aktuell noch recht riskant anhört (und ein sehr reifes Team und ebenso reife Mitarbeiter voraussetzt) ist der Umgang mit der individuellen Weiterentwicklung der Mitarbeiter. Diese Weiterentwicklung in die Hände von Teams zu legen, die sich maßgeblich um die Entwicklung von Produkten/Projekten kümmern, kann ich mir noch nicht gut vorstellen.

    Wie stellt ihr sicher, dass Entwicklungswünsche introvertierter Mitarbeiter berücksichtigt werden, oder was macht ihr, wenn die individuellen Entwicklungswünsche nicht zu den Schwerpunkten innerhalb des Entwicklungsteams passen? Ich glaube, dass „servant leader“ oder „host als leader“ zu sein nochmal ganz andere Fähigkeiten erfordern, die nicht jeder mitbringt und auch nicht jeder mitbringen will. Was macht ihr, wenn die Anforderungen in einem Projekt oder bei einem Produkt in eine Richtung entwickeln, die das Team selbst gar nicht mitgehen möchte?

    • Heja, offensichtlich muss ich da noch eine Reihe Blogartikel schreiben, bis das im Kontext verständlich wird :-)
      Das Team ist nur ein Bestandteil. Es gibt mit Google-Time, Cops etc auch die Möglichkeit an Kollegen zu wenden und hier für das eigene Anliegen zu pitchen.
      Wenn es im Team nicht geht wird das Knowhow aufgebaut und auf eine „Gelegenheit gewartet“, das Wissen in Praxis einzubringen. Das führt meist zu einem Teamwechsel.
      Wenn es bei uns im Unternehmen keine Stelle gibt wo das eigene Interesse gebraucht wird ist man vermutlich in der falschen Firma :-)

      Für Servant Leader gilt das gleiche: die Rolle landet da wo die anderen sie vermuten. Wenn jemand die Kompetenzen nicht hat wird er die Rolle auch nicht bekommen.
      Die letzte Frage verstehe ich nicht. Eigenverantwortliche Teams erkenne ich doch genau daran, dass sie in Verantwortung für das Projekt gehen und auch die unternehmerischen Interessen berücksichtigen. Und wenn dort herauskommt, dass das trotz der Konsequenzen für das Unternehmen nicht mit Ihrem Gewissen vereinbar ist, oder es bessere Alternativen gibt, dann werden sie schon einen plausiblen Grund haben.
      Aber im Ernst: ich stehe gerne mal für einen Hangout / Skype zur Verfügung, um die Wirkweisen im Detail zu besprechen. Das Titel & Positionsthema gibt es bei uns seit drei Jahren, da stecken viele gute und viele fehlgeschlagene Erfahrungen drin.

  5. Danke für den tollen Artikel! Hilfreich wäre evtl. noch, wenn du ergänzt, wie lange ihr auf diesen Zustand hingearbeitet habt. Denn manch spontane Ablehnung oder Relativierung mag aus der Vorstellung resultieren, man könne das von heute auf morgen in der eigenen Firma einführen.

  6. Soviel ich weiß verwendet Ihr doch auch diverse agile Management Praktiken aus Management 3.0 (Moving Motivators, etc.) um die Entwicklung der Mitarbeiter zu fördern.
    Dieses Thema ist ja hier noch gar nicht beleuchtet worden.
    Ich sehe das „agile Management“ als Grundvoraussetzung an damit so etwas in Unternehmen funktionieren kann. Das „agile Management“ ist verantwortlich dafür die Mitarbeiter glücklich und erfolgreich zu machen.
    Wieder mal ein toller Artikel. Danke dafür. :-)

  7. Halleluja! – Endlich ein Unternehmen das mal wagt, das zu versuchen, was längst überfällig ist:

    Die nachhaltige Beerdigung des „Konzepts der Karriere“: https://ilwyc.wordpress.com/2014/08/02/das-konzept-der-karriere-in-unternehmen/

    Wem das noch nicht reicht, hier noch mehr vom gleichen „Stoff“: https://ilwyc.wordpress.com/2014/11/15/neue-energie-fur-unsere-unternehmen-frei-von-den-ruckstanden-und-schadstoffen-des-ehrgeiz/

    Danke Mayflower, dass Ihr diesen mutigen Weg wagt! :-))

    • Klar, das gehört ja quasi dazu :-).
      Wie das Team damit umgeht hängt vor allem von der Reife des Teams ab.
      Bei reifen, guten Teams sind die Formtiefs normalerweise ohnehin bekannt und man geht mit ihnen um. Wenn die Ursachen für das Formtief in der Arbeit liegen – oder eben genau im Team selbst – dann wird an ihnen gedreht. Bei privaten Gründen wird es oft vom Team toleriert, wenn man davon ausgeht, dass es sich wieder einrenkt. Es kommt im Kontext von Retrospektiven aber immer zur Sprache.
      Junge Teams – und damit meine ich alles was in den letzten 12 Monaten seine Struktur nennenswert geändert hat – tragen sich oft noch nicht selbst, da springt dann die Scrum-Master-Rolle ein und kümmert sich darum.
      Das klappt natürlich nicht immer, aber oft. Manchmal beobachtet man auch wie ein anderes Team sich rührt, wenn es die Probleme mitbekommt, und es in die allgemeine Diskussion trägt.
      Die Five Dysfunctions of a Team gehören bei uns zum Repertoir, und es gibt eine ganze Reihe von Leuten mit Coaching-Fähigkeiten, die man ansprechen kann.
      Freerider-Effekte / Social Loafing, bei denen sich Kollegen auf Kosten der anderen „ausruhen“, finden meiner Erfahrung nach in eigenverantwortlichen Teams praktisch nicht statt.

    • Wir haben verschiedene Möglichkeiten, um Teams hier zu unterstützen. Das reicht von der Eigenkreativität (mal gepflegt gemeinsam einen über den Durst trinken und die Themen „inoffiziell-freundschaftlich“ besprechen) bis hin zu Team- oder Einzelcoachings durch externe Coaches, oder gar Team-Mediierungen. Oder Tausch mit einem Crewmember aus einem anderen Team.

      Das ist übrigens eines von mehreren Dingen, bei denen ich nach wie vor der Ansicht bin, dass es eine „Backbone-Struktur“ mit Personalverantwortung (AKA sowas wie einen „Teamleiter“, auch wenn das Wort bei uns leider ein wenig verbrannt ist) benötigt, sich um solche und andere Dinge zu kümmern.

      Ein Wegfall dieser Struktur führt hingegen dazu, dass solche Aufgaben bei uns Geschäftsführern landen – kann man machen, ich denke aber diese Aufgabe sollte nicht 100% bei uns verortet sein. Und nicht jeder Scrum Master sieht dies als seine Aufgabe und/oder ist dem gewachsen, zumal ja ein Scrum Master genau nicht die disziplinarische Verantwortung haben sollte.

      Wie Johann schon schrieb, ist das bei uns alles im Fluß (und IMHO hängt es stark von vielen Faktoren wie zB Kunden-/Projektumfeld, Reife des Teams usw. ab) und wird auch hier unterschiedliche Ausprägungen haben.

      HTH
      Björn

      • Boris Gloger beschreibt Björns Punkt noch mal von einer anderen Seite betrachtet, anlässlich Zappos:
        http://borisgloger.com/2015/05/18/organisier-dich-oder-geh/

        Das deckt sich zu weiten Teilen mit unseren Erfahrungen: Selbstorganisation hat auch seine endothermen Momente, sprich: es muss von aussen Energie zugefügt werden damit es weitergeht. Die meisten unserer Teams kommen aus einer klassischen Teamleiter + Rollen-Struktur. Im Verlauf der Jahre hat sich das durch die agile Arbeit erledigt, und in den reifen Teams sind die Rollen nicht mehr fix. Dann greift natürliche Führung – sprich: wenn Organisation und / oder Führung gebraucht wird fällt diese Rolle dahin wo es am meisten Sinn ergibt. Das kann natürlich auch der ursprüngliche Teamleiter sein (wenn das Team ihn als dafür geeignet ansieht), faktisch wechselt es aber. Es gibt auch Teams die von Vorneherein ohne solche Strukturen entstanden sind.

  8. Danke für eure Antworten oben. – Noch eine andere Frage: Habt ihr auch keine Vorgesetzten sowie keine Titel und Positionen bei den querschnittlichen Funktionen/Aufgaben (z. B. im internen und externen Rechnungswesen)?

    • Hallo!
      Also: wir haben Titel, nur sind die selbstgewählt, und entsprechen dem Selbstverständnis, nicht der Arbeitsposition.
      Und klar gibt es Aufgaben, die man zentral besser erledigen kann als in den Team – zB Rechnungswesen oder Lohnbuchhaltung. Bei uns gibt es ein Team „Hoth“, das sich um diese Themen (und Dinge wie Feelgood/Flow) kümmert, und dort werden die Aufgaben und Rollen ebenfalls fliessend nach Kompetenz & Zeit verteilt. Das gleiche gilt für den zentralen Rechnerbetrieb, und da gibt es jeweils fliessende Grenzen zwischen den Teams und den zentralen Funktionen – eine Aufgabe wird dort erledigt, wo es am meisten Sinn ergibt. Die zentralen DevOps/Admins unterstützen auch in den Teams, die Teams unterstützen auch bei den zentralen Dingen. Wenn die Theorie dahinter interessiert:
      Einflüsse sind dabei Niels Pflaegings Organisation für Komplexität, Gerhard Wohlands Denkwerkzeuge für Höchstleister und die Wertbildungsrechnung von dm.

  9. Als bekennender Dropout, aus dem agilen Scrum Wonderland, wünsche ich viel Erfolg mit diesem
    Ansatz. Früher war zwar nicht alles besser, aber da nannte man diese Vorgehensweise,
    gesunden Menschenverstand.

    Letztendlich steht die Problemlösung für den Kunden im Zentrum aller Aktionen, denn dieser bezahlt
    das Gehalt und diesem sind Titel und Vorgehensweise in der Regel auch ziemlich egal.

    Wie stabil das Ganze bleibt wird sich erst zeigen wenn die Aufträge wegbrechen und es richtig eng
    wird. Dann werden wahrscheinlich alte Strukturen und Befehlsketten wieder die Oberhand gewinnen.

    Ich hoffe das bleibt ihnen erspart !

    • Wir segeln seit 1997 unter dem Namen Mayflower und hatten dementsprechend die Chance auch mal schlechte Zeiten mitzumachen. Und durchaus auch den daraus resultierenden Versuch auf klassische Modelle zurückzugreifen. Und da ist bei uns das passiert was von der Empirie zu Softwareprojekten her bestätigt wird: diese Richtung beflügelt die Kontrollillusion, nicht das Projekt. Gerade bei brenzligen Situationen und abgeschriebenen Projekten sind agile Ansätze deutlich erfolgreicher als klassische.
      Deshalb bin ich relativ zuversichtlich dass wir diesem Schicksal entgehen können :-)

  10. Ich finde das sehr gut!
    Ich seh´s bei mir in der Arbeit;
    Einem gehört die Firma bzw. ist der GF, aber wenns um die Arbeit geht, läuft alles auf dem gleichen Niveau ab. Es macht jeder alles, das ist perfekt.

  11. Yeah. Sehr nice Johann. Ich liebe das Matrix Bild. So isses, weiterpennen umd „business as usual“ oder ab in die aufregende neue Welt der Teal Organizations.

    Ich empfehle euch das gerade frisch entstehende Netzwerk von Frederic Laloux, dem Autor von „Reinventing Organizations“. Ist ein Jahr alt das Werk und für mich bereits das Standardwerk für modernes Organisationsdesign. Lies mal rein.

    Spannend wird es, wenn durch Druck von außen und ein paar Ab’s nach Auf’s weiter alles heterarchisch und fluide so weiterläuft. Dann festigt sich ein klares Bewußtsein über den Wert dieser neuen Arbeitsform. Das wünsche ich euch von Herzen. Niemals nie wieder die rote Pille!

  12. Pingback: Linkdump 22/2015 ... | Dirks Logbuch

    • Das mit den Lenkern und Entscheidern stimmt nur so halb, ich versuche es mal kurz darzustellen:
      Entscheidungen müssen beim Team liegen, sonst gibt es keine Eigenverantwortung und keine Selbstorganisationen. Das wurde mit dem Core Culture Questionnaire von William E. Schneider schön gezeigt: ich bekomme kein agil, wenn ich zeitgleich weiterhin Entscheidungen über Hierarchie – sei es Authorität oder Fachkompetenz – treffen.
      Deshalb stört klassisches Management in der authoritären wie in der transaktionalen Spielart. Lenken und Entscheiden gibt es also im klassischen Sinne nicht mehr.
      Die Führungsrolle wandelt sich damit zu einer Leadership-Rolle der Spielarten Servant Leadership, Coaching/Mentoring bzw. transformational Leadership.
      Es gibt eine einzige Ausnahmesituation, in der wieder transaktionale Führung gefragt ist: wenn die Selbstorganisation noch nicht existiert bzw. durch Teamumbau versagt. In diesem Fall müssen transaktionale Methoden angewandt werden, um es wiederherzustellen.
      Wer also tatsächlich in einer agilen Firma „lenkt“, „entscheidet“ oder „über Ziele steuert“, stört entweder die Selbstorganisation oder diese ist in Wahrheit noch nicht hergestellt.

  13. Pingback: Warum wir keine Titel und Positionen mehr haben

  14. Pingback: Symfony Live 2015 - The Second Day - Project A Techblog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.