Selbstorganisation und Gruppendynamik

Selbstorganisation ist ein Kennzeichen eines echten Teams. Das sagt sich so leicht. Ich formuliere es anders herum: Selbstorganisation zielgerichteter Arbeit entsteht als Ergebnis eines gruppendynamischen Prozesses den die Gruppe (das Projektteam) durchlebt. Die Gruppe durchlebt hierbei innere Rollenklärungen – weniger diplomatisch formuliert Machtkämpfe – und gibt sich Normen und Regeln. Die Gruppe erprobt und verfeinert das Beziehungsgeflecht. Am Ende entsteht ein Gerüst aus teilweise unausgesprochenen Normen, Regeln und Verhaltensmustern. Dieses Gerüst stellt die selbst geschaffene Organisation dar.

Ob in einer Gruppe eine gruppendynamische Rollenklärung stattgefunden hat lässt sich mit Kontrollfragen ermitteln. Salopp formuliert lässt sich über die Auswertung der Fragen grob differenzieren ob es sich um ein (selbstorganisiertes) Team, eine Arbeitsgruppe oder einen zerstrittenen Haufen handelt.¹

Ein paar Zahlen

Spannend wird es wenn man den Projekterfolg der Teams und Gruppen betrachtet. Nebenstehende Abbildung zeigt die Korrelation zwischen Projekterfolg, Team- und Gruppenausprägung und der Teamgröße ermittelt aus knapp 200 Software-Entwicklungsprojekten. Die Abbildung spricht in einer Hinsicht für sich: Die Erfolgsquote selbstorganisierter Teams ist 4-mal größer als jene der “Haufen” und deutlich größer als die Erfolgsquoten, die regelmäßig im Chaos-Report² ermittelt werden.³,⁴ Interessanterweise zeigt sich diese Korrelation bei sehr kleinen Projekten nicht. Das ist plausibel, in einem Miniteam findet weniger Gruppendynamik statt, die Organisation der Arbeit ist primär durch die Ziele des Projektes und ggf. die Vorgaben des Projektleiters vorgegeben. Selbst wenn offensichtlicher Zwist herrscht, können zwei oder drei Personen noch irgendwie zusammenarbeiten. Bei mehr als 4 Personen schlagen diese Zwistigkeiten jedoch dramatisch in die Erfolgsquote durch.

Selbstorganisation und Führung

In jeder Gruppe steckt viel Potential. Eine gewisse fachliche Eignung der Mitarbeiter für das anstehende Projekt setze ich jetzt einfach voraus. Es wird auch niemand auf die Idee kommen, für ein Streichkonzert eine Gruppe aus Pianisten zusammen zu stellen. Um das Potential der Gruppe zur Entfaltung kommen zu lassen bedarf es vielmehr einer bestimmten Grundhaltung als den Einsatz bestimmter Methoden: Selbstorganisation fällt nicht vom Himmel.

1. Eberhard Huber, Cleo Becker: Entstehung von Projekt- und Teamkulturen und ihr Einfluss auf den Projekterfolg in: Projekte als Kulturerlebnis, dpunkt.verlag 2009 ISBN 978-3-89864-629-1
2. Ergänzungen zum Chaos Report
3. Eberhard Huber, Sven Lindenhahn: TEAMWORK: Warum Projektteams erfolgreicher sind als Projektgruppen, Objektspektrum Ausgabe 02 / 2010
4. Sven Lindenhahn, Sebastian Günther, Eberhard Huber: Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten

Soweit die historische Theorie – warum funktioniert das Prinzip des Advocatus diaboli auch dann, wenn es beispielsweise um eine technische Entscheidung in einem Software-Entwicklungsteam geht. Im Prinzip kann es es in jeder anderen Gruppe, die vor einer Entscheidung steht, funktionieren.

In jeder Entscheidungssituation stehen gedanklich mehrere Lösungsansätze im Raum. Ich schreibe bewusst gedanklich – selbst bei einer methodisch gut vorbereiteten Diskussion mit vielen Kärtchen an der Wand wird manche Idee erst im Laufe der Diskussion in den Köpfen der Beteiligten entstehen. Da die Kunst des Gedankenlesens noch nicht sehr weit verbreitet ist, bleiben diese Ideen verborgen bis sie ausgesprochen werden. Das klingt trivial ist es aber nicht. Es gibt eine mehrere Hindernisse, die dafür sorgen, dass eine Idee in einer Gruppe nicht geäußert wird. Jede “abweichende” Idee erzeugt im ersten Moment eine Abwehrhaltung. Selbst hervorragend gute und praktikable Ideen erzeugen im ersten Moment Widerstand. Dieses Widerstandsgefühl schlägt auf den Ideen-Aussprecher zurück und verunsichert ihn oder sie ein wenig. Das passiert IMMER – es ist gewissermaßen so sicher wie das Amen in der Kirche. In einem sehr gut eingespielten Team wird dieses Widerstandsgefühl sehr schnell überwunden, die Idee findet entsprechend schnell Eingang in die Diskussion. Wenn aber ein Hauch von Unsicherheit im Raum schwebt, kann dieser Widerstand hartnäckig sein, entsprechend wird die Idee leicht zerredet und verschwindet wieder – was bleibt ist Frustration. Diese potentielle Frustration “nicht gehört zu werden” ist eines der Hindernisse, die verhindern dass Ideen nicht einmal ausgesprochen werden. Die Angst vor dem Widerstandsgefühl und die resultierende Verunsicherung ist das andere.

Jetzt kommt der Advocatus diaboli ins Spiel. Er nimmt bewusst eine Gegenposition ein und äußert eine provozierend abweichende Idee. Der Widerstand, der sich im ersten Moment regt, wird damit beim Advocatus diaboli abgeladen, jemand anderes der bisher gezögert hatte seine nicht ganz so radikale Idee zu äußern hat den Rücken frei und rückt seine Idee raus – damit kommt die Diskussion mit neuen Aspekten besser in Schwung. Ggf. muss der Advocatus im weiteren Verlauf noch mehrmals eingreifen und Ideen ins Rennen werfen. Er nimmt schrittweise die Unsicherheit aus dem Spiel in dem er signalisiert, dass Querdenken erlaubt ist – dies kommt dann letztendlich der Qualität der Lösung zu gute.

Das hört sich ganz einfach an. Es gibt aber dennoch zwei Punkte auf die zu achten ist. Es kann nicht jeder den Advocatus diaboli spielen. Der Effekt, dass die Unsicherheit abgebaut wird, tritt nur ein, wenn der Advocatus selbst eine relativ sichere Rolle im Team hat und von anderen weitgehend akzeptiert ist. Wenn der unerfahrene Neuling eine teuflische Idee äußert, erntet er vielleicht Gelächter, vielleicht werden die Augen verdreht aber niemand wird dadurch ermuntert selbst eine gewagte Idee zu äußern. Der zweite Punkt auf den zu achten ist, ist die Dosierung. Wenn dieses Prinzip zu häufig angewandt wird, nutzt es sich schnell ab und verliert seine Wirkung. Der “Advocatus diaboli” wird dann zum “Advocatus diabolicus” d.h. dem teuflischen Anwalt, der scheinbar immer dagegen ist und letztendlich der Diskussion und der Gruppe mehr schadet als nützt.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell-Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”.

Die oben genannten Merkmale eines Teams sowie die Fähigkeit der Selbstorganisation sind leider keine Selbstverständlichkeiten noch entstehen sie von heute auf morgen. Sie entwickeln sich im Zuge eines Teamentwicklungsprozesses den jede Gruppe zwangsläufig durchlaufen muss. Unabhängig von der jeweiligen Gruppe läuft diese Entwicklung in einem Prozess mit mehreren Phasen ab. Das Tuckman – Modell wird häufig verwendet und identifiziert fünf Phasen¹:

- Forming,
- Storming,
- Norming,
- Performing
- Reforming

Der Verlauf der Teamentwicklung, ist aufgrund der individuellen Mitglieder und der unterschiedlichen Rahmenbedingungen, jedoch nie identisch und ist wie die Gruppe an sich jeweils ein Unikat. Dementsprechend ist es möglich, dass die Gruppe eine bereits abgeschlossene Phase immer wieder aufs Neue wiederholt. So wird zum Beispiel die Forming-Phase infolge häufiger Personalwechsel oft mehrfach durchlaufen. Die Dauer der einzelnen Entwicklungsphasen sowie die des gesamten Entwicklungsprozess ist ebenfalls von Gruppe zu Gruppe unterschiedlich. Manche Gruppen schaffen es möglicherweise nicht vor Projektende die Performing-Phase zu erreichen. Während dieser Phasen befasst sich die Gruppe unbewusst mit den Themen Zugehörigkeit, Rollen, Macht und Vertrauen  ². Und dann stellt sich noch das Thema der gruppeneigenen Kultur, die im Laufe des Teamentwicklungsprozesses entstehen kann  ³.

Unser Modell des Teamuhrwerks ® integriert die Phasen, die Themen und die Kulturbildung  ⁴:

Nach Klärung der Zugehörigkeit und der gemeinsamen Vision eines Ziels in der Entstehungsphase kommt es im ersten Drittel des Projektes (Vergewisserung) wie in jeder Gruppe zu unabdingbaren Rollenkonflikten. Jede Gruppe muss zu ihrer eigenen stabilen Rollenverteilung kommen. Einige Rollen wie die des Projektleiters sind gewissermaßen strukturell vorgegeben andere, wie z. B. die inoffiziellen Rollen, sind offen. Auch wenn manche Rollen vorbesetzt sind, werden sie dennoch hinterfragt werden. In gewisser Weise findet in jeder Gruppe eine gewisse Rangelei um die Führungsposition statt. Es gibt aber nicht nur Führungsrollen zu besetzen, es gibt weitere inoffizielle Rollen, die besetzt werden: wie z. B. Spaßmacher, Konfliktlöser, Problemlöser, Arbeiter, Spezialisten und Ideengeber⁵. Wer welche Rolle besetzen wird, hängt von den individuellen Eigenschaften der Mitarbeiter und der Zusammensetzung der Gruppe ab. Die Rollen-Besetzung wird mehr oder weniger offen, konstruktiv oder aggressiv verhandelt. Werden die Rollen zügig verteilt und erweist sich die Verteilung als stabil ist ein wichtiger Schritt der Teamentwicklung getan. Die Rollenverteilung und eine Verständigung auf gemeinsame Werte und Normen sind zugleich das Fundament auf dem dann später eine Projektkultur entstehen kann.
In den Phasen „Vergewisserung“ und „Kulturbildung“ werden letztendlich Spielregeln bzgl. der Zusammenarbeit und für die erfolgreiche Selbstorganisation vereinbart. Wird hier kein tragfähiger Kompromiss erzielt, besteht die Möglichkeit, dass die Gruppe im Handeln (performing) beeinträchtigt sein wird. Ist dieser Kompromiss, der sich unter anderem in einer funktionierenden teaminternen Entscheidungsstruktur äußert, vorhanden sprechen wir von einer konstruktiv verlaufenen Teamentwicklung. In diesem Falle hat sich die Gruppe zu einem echten Team entwickelt. Hierbei sei angemerkt, dass die teaminterne Entscheidungsstruktur nicht mit einer Hierarchie verwechselt werden darf, es handelt sich mehr um eine informelle und unbewusste Vereinbarung.

Was hat das mit Projektmanagement zu tun? Ein Projekt ist darauf angewiesen, dass das Projektteam effizient und zielgerichtet arbeitet. Gruppendynamisch gesprochen: “Ein Projektteam muss die Phase des zielgerichteten Handelns” erreichen und zwar nicht irgendwann sondern spätestens zur Halbzeit des Projektes, sonst hat das Projekt ein Problem. Diesen Entwicklungsprozess der Gruppe zum Team zu unterstützen ist eine Aufgabe, die oft vernachlässigt wird. Projektleiter, die diese Aufgabe wahrnehmen – das heißt die Gruppendynamik nicht dem Zufall überlassen – haben deutlich mehr Chancen Projekte erfolgreich abzuschließen. In der agilen Software-Entwicklung wurde die Notwendigkeit auf das Team zu achten bereits erkannt. So wird z.B. im Falle von Scrum diese Aufgabe einer konkreten Rolle dem “Scrum-Master” zugeordnet. Die Sorge um das Team, die Begleitung des Gruppenentwicklungsprozesses sollte nicht auf agile Projekte beschränkt bleiben sondern zum Standardrepertoire des Projektmanagments werden. ProjektleiterInnen benötigen ein Gespür für die Gruppe und die Bereitschaft mit gezielten Interventionen und Anpassungen des Projektablaufs den gruppendynamischen Fortschritt der Gruppe zu stützen.

Fortsetzung folgt

1. Tuckman, Bruce W.: Developmental Sequence in Small Groups, Psychological Bulletin, vol. 63, 1965, pp. 384-399.
2. Antons, Klaus et al. Gruppenprozesse verstehen: Gruppendynamische Forschung und Praxis. Wiesbaden: VS Verlag für Sozialwissenschaften 2 2004
3. Cleo Becker, Eberhard Huber, Entstehung von Projekt- und Teamkulturen und ihr Einfluss auf den Projekterfolg in: Projekte als Kulturerlebnis, dpunkt.verlag 2009 ISBN 978-3-89864-629-1
4. Das Team-Uhrwerk – Steuerung des Gruppen-Prozesses in Projekt-Teams
5. Belbin, R. Meredith Team Roles at Work, Oxford, Butterworth-Heinemann 1993

Leider ist diese Aufteilung oft nur ein frommer Wunsch. Die Wirklichkeit sieht anders aus.

In der ersten Hälfte eines Projektes, wenn die Projektgruppe noch in einer frühen Entwicklungsphase steckt, die interne Rollenverteilung oder weniger diplomatisch formuliert die Hackordnung noch nicht klar ist, werden die Botschaften einen höheren Beziehungsanteil aufweisen. Woher kommt dieser Beziehungsanteil. Eine unklare Rollenverteilung bedeutet, dass z.B. die folgenden Fragen noch nicht geklärt sind:

- Wer unterstützt wen?
- Wer kann sich auf wen verlassen?

Unter dem Gesichtspunkt einer Hackordnung käme noch folgende Frage hinzu:

- Wer hat wem was zu sagen?

Dass die Gesamtleitung durch den Projektleiter wahrgenommen wird, mag in den meisten Fällen unstrittig sein. Viele Detailfragen können aber gar nicht vollständig von der Projektleitung beantwortet werden. Hier muss das Projektteam selbst Antworten finden oder eben klären wer in welchen Fällen das Sagen hat. Diese Fragen spiegeln letztendlich die Unsicherheit der Beziehungen in der Projektgruppe. Die Klärung dieser Fragen läuft naturgemäß nicht reibungsfrei ab gelegentlich kommt es zum Streit, allerdings wird in den seltensten Fällen „über Beziehungen“ diskutiert. Statt dessen werden Stellvertreterdiskussionen geführt. In SW-Entwicklungsprojekten wird häufig über Richtlinien zur Code-Dokumentation diskutiert, die genaue Struktur der Dateiablage ist ebenfalls ein beliebtes Thema. Wird hier wirklich über die Sache diskutiert. Nein – es geht darum wer das letzte Wort hat, wer die Entscheidung fällt, wer das Sagen hat. Im Bild des Kommunikationsmodelles mit den 4 Aspekten stellt sich eine Botschaft einer solchen Diskussion wie folgt dar:

Unter der Oberfläche steckt ein großer Beziehungsanteil, jede Äußerung auf der Sachebene hat gewissermaßen einen Zweck in der laufenden Rollenklärung oder im ungünstigeren Fall im Machtkampf. Die Kampfbotschaft versteckt sich gewissermaßen hinter der Sachinformation.

Es stellt sich nun die Frage wie Beteiligte oder ein Projektleiter, der ggf. eine solche Diskussion moderieren muss, mit diesem Wissen umgeht. Die Auseinandersetzungen und die Stellvertreterdiskussionen sind notwendig und für das Team von großer Bedeutung. Ein Verzicht oder ein Unterbinden von (scheinbaren) Stellvertreter-Diskussionen wäre schädlich wohingegen ein konstruktiverer Verlauf der Diskussion dem Projekt in mehrfacher Hinsicht zu Gute kommt. Wie solche oder andere konfliktbeladene Diskussionen moderiert werden können wird Gegenstand des nächsten Beitrags über die Projektmanagement-Checklisten sein.

- Kennen alle den Auftraggeber?
- Ist eindeutig, wer das Team leitet?
- Ist eindeutig, wer zum Team gehört?
- Kennt jeder seine Aufgabe?
- Sind alle Fähigkeiten bekannt?
- Wissen wir, welche Unterstützung benötigt wird?
- Wissen wir, wer wen unterstützt?
- Ist klar, wer welche Entscheidungen trifft?

Die erste Frage scheint banal, ist sie aber nicht. In Projekten, die aus unterschiedlichen Bereichen eines Unternehmens besetzt werden, herrscht keineswegs Einigkeit über den Auftraggeber, hier spiegeln sich oft die unterschiedlichen Interessen der Unternehmensbereiche. Es ist Aufgabe des Projektleiters das zu klären und im Team klar zu machen wer der Auftraggeber ist. Mit der Klärung dieser Frage ist ein erster Schritt für die Struktur- und Rollenklärung getan. Damit kommen wir zur nächsten Frage. Ist eindeutig klar “wer das Team leitet“? Die erste Antwort „der (die) Projektleiter(in)“ erscheint logisch. Der oder die Betreffende muss sich aber fragen: Stimmt die Antwort auch in der gelebten Praxis? Hat vielleicht nicht immer jemand anderes das letzte Wort, die Assistentin der Geschäftsleitung aufgrund Ihrer Nähe zur Führungsetage oder in einem technisch-lastigen Projekt der Spezialist aus der IT-Abteilung. Gleich im Anschluss stellt sich die Frage der Zugehörigkeit, in manchen Projekten herrscht ein Kommen und Gehen von Mitarbeitern, sei es durch Umbesetzungen, Kapazitäts-Engpässen, scheinbarer Unlust oder einem gelegentlichen Vorbeischauen von Führungskräften aus der Linienorganisation. Solche Fluktuationen lassen sich nicht immer vermeiden auch die saubere Trennung zwischen Projekt- und Linienorganisation gelingt nicht immer, dennoch muss immer klar bleiben wer gehört dazu und wer nicht. Wenn hier Unklarheiten bestehen ist die weitere Entwicklung der Projektgruppe zum echten Team gehemmt.

Die nächsten Fragen nach Aufgaben, Fähigkeiten und benötigter Unterstützung gehören eng zusammen. Die Kenntnisse und Fähigkeiten der Mitarbeiter müssen zum Projekt passen. Und wenn zu Beginn Kenntnisse fehlen müssen diese (gemeinsam) aufgebaut werden oder ggf. durch externe Unterstützung ergänzt werden. Und wieder klingt ein wenig Banalität durch, aber Hand aufs Herz – der Fall des guten Cobol-Programmierers, der in ein Java Projekt gesteckt wird ist leider kein Märchen. Im Einzelfall mag dies gelingen, wenn aber im Java Projekt überhaupt kein Java Entwickler dabei ist wird es spannend.

Hinter der nächsten Frage „wer unterstützt wen“ steckt etwas sehr wichtiges. Wenn die vorangegangenen Fragen schlüssig beantwortet sind, also allen klar ist wer die Leitung hat, woher der Auftrag kommt, welche Kenntnisse gebraucht werden und wer diese hat ist es an der Zeit zu klären wer wen unterstützt. Das ist keine reine Frage der Kenntnisse, nicht jeder Mitarbeiter kann auch gut erklären, die Arbeitsweisen der Mitarbeiter sind womöglich nicht kompatibel – der eine kann mit Unterbrechungen seiner Arbeit gut umgehen, der andere weniger. Es kommt also darauf an ein bewusstes Unterstützungsnetzwerk im Team entstehen zu lassen. Jede(r) braucht das Gefühl im Notfall jemanden fragen zu können und dieser jemand kann (leider) nicht immer der Projektleiter sein.

Die Frage nach den Entscheidungen schließt gewissermaßen den Kreis, es muss nicht zwingend sein, dass alle Entscheidungen vom Projektleiter getroffen werden, manche Entscheidungen gehören definitiv zum Auftraggeber, manche Detailentscheidungen sind vielleicht besser bei Spezialisten im Team aufgehoben. Unabdingbar für das Team ist jedoch, dass die Verteilung der Entscheidungen klar und allen bekannt ist.

Diese 8 Fragen stecken einen Rahmen für eine Entwicklung der Gruppe zum Team ab. Bestehen bei den Antworten Unklarheiten ist das der Nährboden auf dem Konflikte entstehen und gedeihen. Können sie klar und zweifelsfrei beantwortet und die Antworten auch kommuniziert werden, besteht eine gute Chance, dass sich das Team entwickelt und eine hohe Leistungsfähigkeit erreicht.

Die Entwicklung einer Gruppe läuft in Phasen. In der Entstehungs-Phase wird z.B. die Zugehörigkeit zur Gruppe geklärt. In weiteren Phasen – siehe Bild – werden die Regeln der Zusammenarbeit geklärt. In Abhängigkeit vom konstruktiven Verlauf dieser Phasen entwickelt sich die Gruppe zum leistungsfähigen Team, verbleibt im Zustand einer halbwegs arbeitsfähigen Gruppe oder verändert sich mit fatalen Folgen für das Projekt zum zerstrittenen, arbeitsunfähigen Haufen.

In Projektteams wird es wie in jeder Gruppe zu Rollenkonflikten kommen. Das ist ein unvermeidlicher Vorgang. Jede Gruppe muss zu ihrer eigenen Hackordnung oder etwas vornehmer formuliert zu einer stabilen Rollenverteilung kommen. Manche Rollen wie die des Projektleiters sind gewissermaßen vorbesetzt, andere sind offen. Auch wenn die Rolle des Projektleiters vorbesetzt ist, so wird sie hinterfragt werden und es muss sich noch erweisen ob er sich tatsächlich als der “Leiter und Entscheider” erweist. In gewisser Weise findet in jeder Gruppen eine gewisse Rangelei um die Führungsposition statt. Es gibt aber nicht nur Führungsrollen zu besetzen, es gibt weitere Gruppenrollen, die besetzt werden müssen: Spaßmacher, Konfliktlöser, Problemlöser, Arbeiter, Spezialist, Ideengeber und weitere. Wer welche Rolle besetzen wird, hängt von den individuellen Eigenschaften der Teammember und von der Zusammensetzung des Teams ab. All diese Rollen-Besetzungen werden mehr oder weniger offen, konstruktiv oder agressiv verhandelt. Werden die Rollen zügig verteilt und erweist sich die Verteilung als stabil ist ein wichtiger Schritt für das Projekt getan. In vielen Projekten ist jedoch das Gegenteil der Fall: das Hinterfragen und Streiten dauert das ganze Projekt an und am Ende sind alle froh, dass das Projekt vorbei ist. Das Projekt hat das Budget überzogen und die üblichen Vorurteile über die anderen sind mal wieder bestätigt. Woran liegt das?

Konflikt der Subkulturen

Zur Definition einer Kultur möchte ich auf diesen Beitrag hinweisen. Zusammengefasst ist eine Kultur ein System von Konzepten, die sich mit folgenden immer tiefer gehenden Begriffen benennen lassen: Symbole, Rituale, Helden, Normen sowie Grundannahmen.Es handelt sich um einen Kulturkonflikt. Die Zugehörigkeit zu einer anderen Kultur erschwert die gruppeninterne Rollenklärung erheblich. Das beginnt bei den oberflächlichen Merkmalen wie der Kleidung. Die Spanne reicht vom Stöckelschuh der Geschäftsführungs-Assistentin bis zu den Sandalen des Software-Entwicklers. Vom Business-Anzug des SAP Spezialisten bis zum Karo-Hemd des Datenbankadministrators. Unwichtige Äußerlichkeiten? Keineswegs! Wenn jemand zu einem Termin in einer – in meinen Augen – unangemessenen Kleidung erscheint, werde ich ohne es zu wollen schon ein wenig voreingenommen sein d.h. die Saat des Missverständnisses ist schon gelegt. Es geht weiter mit Sprache, Begüßungsritualen, Witzen. Was die einen lachend auf dem Boden kugeln lässt – *rofl – lässt die anderen nur säuerlich lächeln. Zurück zur Rollenklärung in der Gruppe: In jeder Gruppe gibt es einen “Spaßmacher” eine Person, die für die gute Laune sorgt. Es lässt sich jetzt schon erahnen, dass die Besetzung der Spaßmacher-Rolle in einer Gruppe, die sich aus unterschiedlichen Kulturen zusammensetzt, schwierig werden kann. Die humorvollen, lockeren Kreativen auf der einen, die bierernsten SAP-Spezialisten auf der anderen Seite. Dazwischen der respektlose Karo-Hemd tragende Datenbank-Administrator, der sich über alle lustig macht. Das wäre jetzt ein erster Blik auf die oberflächlichen und offensichtlichen kulturellen Differenzen.

Die Spitze des Eisberges

“Meritokratie” geht auf den Soziologen Michael Young zurück. In einer Meritokratie werden Herrscher aufgrund ihrer Leistung ausgewählt. Bei IT-Spezialisten ist eine meritokratische Grundhaltung häufig anzutreffen. Der Senior-Entwickler mit großer Erfahrung hat mehr Einfluss und Macht als der Junior-Entwickler.Wie bei einem Eisberg liegt auch bei Kulturkonflikten der größte Teil unter der Oberfläche. Die tiefer liegenden kulturellen Differenzen haben schwerwiegendere Auswirkungen auf die Rollenklärung im Team. Die Normen und Grundannahmen bzgl. Führung und Loyalität unterscheiden sich in den genannten Subkulturen erheblich. Die Subkultur der IT-Spezialisten huldigt oft einem ausgeprägten meritokratischen Führungsprinzip. Dies wird z.B auch in den Visitenkarten Zusätzen wie “Senior-Entwickler” oder “Junior-Entwickler” deutlich. Andere Abteilungs-Subkulturen der gleichen Firma legen hingegen mehr Wert auf die hierarchische Stellung im Gesamtorganigramm. Die möglicherweise stattfindende Machtprobe mit dem gesetzten Projektleiter erfolgt also unter völlig anderen Vorzeichen je nach dem aus welcher Subkultur der “Fragende” stammt. Unter diesem Blickwinkel betrachtet bekommt z.B. die oft zu hörende Frage “Welche Erfahrung haben Sie?” ein ganz neues Gewicht.

und wie geht es weiter

In weiteren Beiträgen werde ich das Thema “Subkultur und Rollenkonflikt” weiter vertiefen. Der nächste Beitrag wird der Beschreibung konkreter und wichtiger Subkulturen (Kreativ, Technik, SAP, Verwaltung) gewidmet sein. Im dritten Teil wird es dann um konkrete Lösungsansätze für das Management derart “interkultureller Projekte” gehen.

hier gehts zum nächsten Beitrag