ITÉlet

A Harvard Business Review szeptemberi száma a komplexitásról szól.

Még nem értem végig a HBR szeptemberi számával, de máris találtam egy zseniális cikket: Learning to Live with Complexity

A cikk olvasásához regisztráció kell, és mivel nem akarom a HBR üzletét rontani, ezért nem közlöm le újra a cikket, csak pár érdekes pontot és a véleményem.

Naszóval vállalatok és komplexitás. Kezdjük definíciókkal.

Egyszerű alatt azt értjük, amikor a munkafolyamat végrehajtása kevés lépésből áll és a végeredmény megjósolható. Ilyen például a varrás vagy amikor szöveg verünk be a falba.

Komplikált az a munkafolyamat, ami ugyan sok lépésből áll (bonyolult), de az egyes elemi lépések jól szabályozottak és megjósolhatóak, emiatt a teljes munkafolyamat eredménye megjósolható. Ilyen például a repülőgép vezetése – nagyon bonyolult, de minden szabályozott és a repülőgép előre várhatóan rendben le fog szállni.

Komplex az a munkafolyamat, ami sok lépésből áll, és a végeredmény nem megjósolható. Például a légi irányítás nem megjósolható, hiszen nagyban függ egyéb tényezőktől, pl időjárás, várakozó gépek, késés mértéke. Nem tudjuk, mikor száll le a repülőgép, csak azt tudjuk, hogy le fog szállni, valamikor, a lehetőségekhez képest hamar.

Érdemes felismerni, hogy az IT iparágra nagyon jellemzőek a komplex folyamatok. Egy informatikai projekt sok lépésből áll, amelyek végeredménye nem megjósolható. Kezdve azzal, hogy fejlesztés során bármikor felmerülhet egy műszaki probléma, és akkor még nem is beszéltünk a felhasználók felfogóképességének a projektre gyakorolt hatásaival. Amikor szoftverfejlesztésre becslést adunk és ütemtervet készítünk, akkor valójában egy komplex, tehát definíció szerint nem megjósolható eseményre adunk jóslást – ráadásul az IT menedzser feladata, hogy a jósgömbből és tyúkbélből kiolvasott számok a valóságban teljesüljenek is.

Tehát látható, hogy az IT menedzsernek nagyon is értenie kell egy komplex rendszer kezeléséhez.

Sajnos sok IT menedzser ezzel nincs tisztában, és azt gondolják, az informatika egy egyszerű – vagy legalábbis komplikált – rendszer, ahol a fejlesztés mindig adott időre készül el. Ez talán a legfontosabb a kompetens és az inkompetens IT vezetők között. Az inkompetens vezető sosem érti, hogy ha a fejlesztője 5 napot mondott egy munkára, akkor az miért nincs kész az 5. nap végén.

A HBR pontosan leírja, mik a komplex rendszer problémái, amikkel számolni kell(ene):

1) Nem várt mellékhatások: Szakmai berkekben elég annyit mondani, hogy regressziós hiba.

2) Sok apró esemény együttes hatása: Az események külön-külön nem okoznának problémát, együttesen viszont igen, például amikor egy interfészre túl sok felhasználó kapcsolódik és az együttes terhelés már bedönti a rendszert.

3) Elavult szabályok: Valamikor régen valaki hozott egy szabályt, amit mindenki követ, de ma már nem tudjuk, mi az oka és miért követjük.

4) A nagyobb kutya véleménye: A döntést a végén mindig egy ember hozza, és az az egy ember egyféleképpen látja a világot. Márpedig lehet, hogy a helyzetet több szemszögből, több oldalról kellene megvizsgálni, hogy a helyes döntéshez jussunk.

5) Az emberi elme befogadóképességének korlátai: Mivel emberek vagyunk, a saját emberi agyunk, az agyunk befogadóképessége korlátozza a rendszer megértését. Nem érthetünk mindenhez és nem láthatunk át mindent.

6) Saját szemünkben a gerendát: Sajnos az is egy nagyon emberi tulajdonság, hogy miközben egy adott dologra összpontosítunk, aközben más, sokkal fontosabb dolgot nem veszünk észre. Például nagyon a határidőre koncentrálunk és mindent ennek rendelünk alá, miközben a projekt összeomlik.

7) Fekete hattyú effektus: A nem várt, ritka eseményekre nem szokás felkészülni, márpedig a ritka események nagyon is sokszor következnek be. A sikeres menedzsert azt különbözteti meg a sikertelentől, hogy a sikeres felkészül a váratlanra is, például mi van, ha az éles indulás után a rendszer egy váratlan hiba miatt leáll. Plan for the best, prepare for the worst!

A HBR 3 megoldást javasol:

1) Pontosabb előrejelzés

2) Hatékonyabb kockázatkezelés

3) Ésszerűbb kompromisszumok

Ezek részletesen ki vannak fejtve a cikkben, aki kíváncsi olvassa el.

Most inkább visszatérnék a komplexitás okaihoz, és személyes tapasztalatok alapján IT menedzserek számára adnék tippet , hogyan kezelhetnék a komplexitást!

1) Nem várt mellékhatások

Kezdő menedzser: Abból a feltételezésből indul ki, hogy a változtatások egyszerűek, azok hatásai ismertek, éppen ezért nem lesznek mellékhatások. Mint amikor megnyomjuk a Play gombot a DVD lejátszón. Szoftvert fejleszteni egyszerű dolog.

Tapasztalt menedzser: Megkérdezi egy szakértő véleményét, illetve legalább 1 szakértőét. Ha az adott kérdés, adott változtatás több területtel összefügg, akkor inkább biztosra megy és több szakértőt is bevon. Olyan emberekkel dolgozik együtt, akik ismerik a változtatások mellékhatásait.

2) Sok apró esemény

Kezdő menedzser: Reaktív hozzáállás, mindig csak a jelennel foglalkozik és az adott kéréssel. Nem látja az összefüggéseket és nem látja, hogy a rendszerben hol vannak a szűk keresztmetszetek. Nem végez stress-tesztet.

Tapasztalt menedzser: Magas szinten átlátja a rendszert, tisztában van a szűk keresztmetszetekkel. Mindig ellenőrzi a rendszer komponenseinek teherbírását.

3) Elavult szabályok

Kezdő menedzser: Azért csinálja amit csinál, mert így szokás, mert mindig is így csináltuk.

Tapasztalt menedzser: Tisztában van azzal, miért kell a policy-t követni és mi történik akkor, ha nem követjük.

4) A nagyobb kutya véleménye

Kezdő menedzser: Egyszemélyi döntést hoz, hiszen övé a felelősség.

Tapasztalt menedzser: A döntésbe bevonja a szakértőket, közös vagy konszenzusos döntést hoz.

5) Az emberi agy korlátai

Kezdő menedzser: Mindent kézben tart, mindent irányit, ragaszkodik a hivatalos úthoz.

Tapasztalt menedzser: Delegál vagy felhatalmaz, hogy a munkát ne korlátozza be egyetlen ember teljesítőképessége.

6) Saját szemünkben a gerendát

Kezdő menedzser: Görcsösen ragaszkodik elképzelésekhez, tervekhez, határidőkhöz és „kiemelt kérésekhez”. Ha valaki kétségét fejezi ki, azt szőnyeg alá söpri a „cél” elérése érdekében.

Tapasztalt menedzser: Meghallgatja a véleményeket akkor is, ha azok eltérnek a vezetés véleményétől. Nem ragaszkodik görcsösen egyetlen célhoz, hiszen a sikerhez egyszerre több célt is el kell érni. Elfogadja azt, hogy a helyzet és a célok változnak, tehát a tervnek is változnia kell.

7) Fekete hattyú effektus

Kezdő menedzser: Feltételezi, hogy majd minden úgy történik, ahogyan a könyvben meg van írva. Feltételezi, hogy mindenki teljesít minden határidőt, nem lesznek csúszások és nem lesznek problémák.

Tapasztalt menedzser: Arra is felkészül, ami rosszul mehet. Ideje jelentős részében a váratlan események elkerülésével foglalkozik – azaz proaktív.

Így a végére még pár gondolat arról, hogy az informatika komplex-e. Először is, bizonyára sok más terület létezik, ami komplex, tehát az IT ebben bizonyára nem egyedi és nem speciális. Csak azt kell elfogadni, hogy az IT komplex, és ennek megfelelően kezelni.

Lehet, hogy valaki vitába száll majd és azt mondja, az IT cseppet sem komplex. Valóban igaz, hogy léteznek egyszerű, illetve nem komplex részterületei. Egy ITIL szerint szervezett 1. és 2. szintű helpdesk például elég kiszámítható módon működik, a minőségbiztosítás kötött módon, kiszámíthatóan dolgozik, és még sorolhatnám. Összességében azonban az egy informatikai szervezet, egy informatikai rendszer életében sok a komplexitás és a kiszámíthatatlanság. Például hogy egy fejlesztés mikor készül el, hogy egy hiba mikorra lesz kijavítva, hogy egy meglassult rendszer mikor lesz megint használható, vagy hogy mikor lesz végleges egy követelmény specifikáció.

A Harvard Business Review szeptemberi száma a komplexitásról szól.

Még nem értem végig a HBR szeptemberi számával, de máris találtam egy zseniális cikket: Learning to Live with Complexity

A cikk olvasásához regisztráció kell, és mivel nem akarom a HBR üzletét rontani, ezért nem közlöm le újra a cikket, csak pár érdekes pontot és a véleményem.

Naszóval vállalatok és komplexitás. Kezdjük definíciókkal.

Egyszerű alatt azt értjük, amikor a munkafolyamat végrehajtása kevés lépésből áll és a végeredmény megjósolható. Ilyen például a varrás vagy amikor szöveg verünk be a falba.

Komplikált az a munkafolyamat, ami ugyan sok lépésből áll (bonyolult), de az egyes elemi lépések jól szabályozottak és megjósolhatóak, emiatt a teljes munkafolyamat eredménye megjósolható. Ilyen például a repülőgép vezetése – nagyon bonyolult, de minden szabályozott és a repülőgép előre várhatóan rendben le fog szállni.

Komplex az a munkafolyamat, ami sok lépésből áll, és a végeredmény nem megjósolható. Például a légi irányítás nem megjósolható, hiszen nagyban függ egyéb tényezőktől, pl időjárás, várakozó gépek, késés mértéke. Nem tudjuk, mikor száll le a repülőgép, csak azt tudjuk, hogy le fog szállni, valamikor, a lehetőségekhez képest hamar.

Érdemes felismerni, hogy az IT iparágra nagyon jellemzőek a komplex folyamatok. Egy informatikai projekt sok lépésből áll, amelyek végeredménye nem megjósolható. Kezdve azzal, hogy fejlesztés során bármikor felmerülhet egy műszaki probléma, és akkor még nem is beszéltünk a felhasználók felfogóképességének a projektre gyakorolt hatásaival. Amikor szoftverfejlesztésre becslést adunk és ütemtervet készítünk, akkor valójában egy komplex, tehát definíció szerint nem megjósolható eseményre adunk jóslást – ráadásul az IT menedzser feladata, hogy a jósgömbből és tyúkbélből kiolvasott számok a valóságban teljesüljenek is.

Tehát látható, hogy az IT menedzsernek nagyon is értenie kell egy komplex rendszer kezeléséhez.

Sajnos sok IT menedzser ezzel nincs tisztában, és azt gondolják, az informatika egy egyszerű – vagy legalábbis komplikált – rendszer, ahol a fejlesztés mindig adott időre készül el. Ez talán a legfontosabb a kompetens és az inkompetens IT vezetők között. Az inkompetens vezető sosem érti, hogy ha a fejlesztője 5 napot mondott egy munkára, akkor az miért nincs kész az 5. nap végén.

A HBR pontosan leírja, mik a komplex rendszer problémái, amikkel számolni kell(ene):

1) Nem várt mellékhatások: Szakmai berkekben elég annyit mondani, hogy regressziós hiba.

2) Sok apró esemény együttes hatása: Az események külön-külön nem okoznának problémát, együttesen viszont igen, például amikor egy interfészre túl sok felhasználó kapcsolódik és az együttes terhelés már bedönti a rendszert.

3) Elavult szabályok: Valamikor régen valaki hozott egy szabályt, amit mindenki követ, de ma már nem tudjuk, mi az oka és miért követjük.

4) A nagyobb kutya véleménye: A döntést a végén mindig egy ember hozza, és az az egy ember egyféleképpen látja a világot. Márpedig lehet, hogy a helyzetet több szemszögből, több oldalról kellene megvizsgálni, hogy a helyes döntéshez jussunk.

5) Az emberi elme befogadóképességének korlátai: Mivel emberek vagyunk, a saját emberi agyunk, az agyunk befogadóképessége korlátozza a rendszer megértését. Nem érthetünk mindenhez és nem láthatunk át mindent.

6) Saját szemünkben a gerendát: Sajnos az is egy nagyon emberi tulajdonság, hogy miközben egy adott dologra összpontosítunk, aközben más, sokkal fontosabb dolgot nem veszünk észre. Például nagyon a határidőre koncentrálunk és mindent ennek rendelünk alá, miközben a projekt összeomlik.

7) Fekete hattyú effektus: A nem várt, ritka eseményekre nem szokás felkészülni, márpedig a ritka események nagyon is sokszor következnek be. A sikeres menedzsert azt különbözteti meg a sikertelentől, hogy a sikeres felkészül a váratlanra is, például mi van, ha az éles indulás után a rendszer egy váratlan hiba miatt leáll. Plan for the best, prepare for the worst!

A HBR 3 megoldást javasol:

1) Pontosabb előrejelzés

2) Hatékonyabb kockázatkezelés

3) Ésszerűbb kompromisszumok

Ezek részletesen ki vannak fejtve a cikkben, aki kíváncsi olvassa el.

Most inkább visszatérnék a komplexitás okaihoz, és személyes tapasztalatok alapján IT menedzserek számára adnék tippet , hogyan kezelhetnék a komplexitást!

1) Nem várt mellékhatások

Kezdő menedzser: Abból a feltételezésből indul ki, hogy a változtatások egyszerűek, azok hatásai ismertek, éppen ezért nem lesznek mellékhatások. Mint amikor megnyomjuk a Play gombot a DVD lejátszón. Szoftvert fejleszteni egyszerű dolog.

Tapasztalt menedzser: Megkérdezi egy szakértő véleményét, illetve legalább 1 szakértőét. Ha az adott kérdés, adott változtatás több területtel összefügg, akkor inkább biztosra megy és több szakértőt is bevon. Olyan emberekkel dolgozik együtt, akik ismerik a változtatások mellékhatásait.

2) Sok apró esemény

Kezdő menedzser: Reaktív hozzáállás, mindig csak a jelennel foglalkozik és az adott kéréssel. Nem látja az összefüggéseket és nem látja, hogy a rendszerben hol vannak a szűk keresztmetszetek. Nem végez stress-tesztet.

Tapasztalt menedzser: Magas szinten átlátja a rendszert, tisztában van a szűk keresztmetszetekkel. Mindig ellenőrzi a rendszer komponenseinek teherbírását.

3) Elavult szabályok

Kezdő menedzser: Azért csinálja amit csinál, mert így szokás, mert mindig is így csináltuk.

Tapasztalt menedzser: Tisztában van azzal, miért kell a policy-t követni és mi történik akkor, ha nem követjük.

4) A nagyobb kutya véleménye

Kezdő menedzser: Egyszemélyi döntést hoz, hiszen övé a felelősség.

Tapasztalt menedzser: A döntésbe bevonja a szakértőket, közös vagy konszenzusos döntést hoz.

5) Az emberi agy korlátai

Kezdő menedzser: Mindent kézben tart, mindent irányit, ragaszkodik a hivatalos úthoz.

Tapasztalt menedzser: Delegál vagy felhatalmaz, hogy a munkát ne korlátozza be egyetlen ember teljesítőképessége.

6) Saját szemünkben a gerendát

Kezdő menedzser: Görcsösen ragaszkodik elképzelésekhez, tervekhez, határidőkhöz és „kiemelt kérésekhez”. Ha valaki kétségét fejezi ki, azt szőnyeg alá söpri a „cél” elérése érdekében.

Tapasztalt menedzser: Meghallgatja a véleményeket akkor is, ha azok eltérnek a vezetés véleményétől. Nem ragaszkodik görcsösen egyetlen célhoz, hiszen a sikerhez egyszerre több célt is el kell érni. Elfogadja azt, hogy a helyzet és a célok változnak, tehát a tervnek is változnia kell.

7) Fekete hattyú effektus

Kezdő menedzser: Feltételezi, hogy majd minden úgy történik, ahogyan a könyvben meg van írva. Feltételezi, hogy mindenki teljesít minden határidőt, nem lesznek csúszások és nem lesznek problémák.

Tapasztalt menedzser: Arra is felkészül, ami rosszul mehet. Ideje jelentős részében a váratlan események elkerülésével foglalkozik – azaz proaktív.

Így a végére még pár gondolat arról, hogy az informatika komplex-e. Először is, bizonyára sok más terület létezik, ami komplex, tehát az IT ebben bizonyára nem egyedi és nem speciális. Csak azt kell elfogadni, hogy az IT komplex, és ennek megfelelően kezelni.

Lehet, hogy valaki vitába száll majd és azt mondja, az IT cseppet sem komplex. Valóban igaz, hogy léteznek egyszerű, illetve nem komplex részterületei. Egy ITIL szerint szervezett 1. és 2. szintű helpdesk például elég kiszámítható módon működik, a minőségbiztosítás kötött módon, kiszámíthatóan dolgozik, és még sorolhatnám. Összességében azonban az egy informatikai szervezet, egy informatikai rendszer életében sok a komplexitás és a kiszámíthatatlanság. Például hogy egy fejlesztés mikor készül el, hogy egy hiba mikorra lesz kijavítva, hogy egy meglassult rendszer mikor lesz megint használható, vagy hogy mikor lesz végleges egy követelmény specifikáció.

A Harvard Business Review szeptemberi száma a komplexitásról szól.

Még nem értem végig a HBR szeptemberi számával, de máris találtam egy zseniális cikket: Learning to Live with Complexity

A cikk olvasásához regisztráció kell, és mivel nem akarom a HBR üzletét rontani, ezért nem közlöm le újra a cikket, csak pár érdekes pontot és a véleményem.

Naszóval vállalatok és komplexitás. Kezdjük definíciókkal.

Egyszerű alatt azt értjük, amikor a munkafolyamat végrehajtása kevés lépésből áll és a végeredmény megjósolható. Ilyen például a varrás vagy amikor szöveg verünk be a falba.

Komplikált az a munkafolyamat, ami ugyan sok lépésből áll (bonyolult), de az egyes elemi lépések jól szabályozottak és megjósolhatóak, emiatt a teljes munkafolyamat eredménye megjósolható. Ilyen például a repülőgép vezetése – nagyon bonyolult, de minden szabályozott és a repülőgép előre várhatóan rendben le fog szállni.

Komplex az a munkafolyamat, ami sok lépésből áll, és a végeredmény nem megjósolható. Például a légi irányítás nem megjósolható, hiszen nagyban függ egyéb tényezőktől, pl időjárás, várakozó gépek, késés mértéke. Nem tudjuk, mikor száll le a repülőgép, csak azt tudjuk, hogy le fog szállni, valamikor, a lehetőségekhez képest hamar.

Érdemes felismerni, hogy az IT iparágra nagyon jellemzőek a komplex folyamatok. Egy informatikai projekt sok lépésből áll, amelyek végeredménye nem megjósolható. Kezdve azzal, hogy fejlesztés során bármikor felmerülhet egy műszaki probléma, és akkor még nem is beszéltünk a felhasználók felfogóképességének a projektre gyakorolt hatásaival. Amikor szoftverfejlesztésre becslést adunk és ütemtervet készítünk, akkor valójában egy komplex, tehát definíció szerint nem megjósolható eseményre adunk jóslást – ráadásul az IT menedzser feladata, hogy a jósgömbből és tyúkbélből kiolvasott számok a valóságban teljesüljenek is.

Tehát látható, hogy az IT menedzsernek nagyon is értenie kell egy komplex rendszer kezeléséhez.

Sajnos sok IT menedzser ezzel nincs tisztában, és azt gondolják, az informatika egy egyszerű – vagy legalábbis komplikált – rendszer, ahol a fejlesztés mindig adott időre készül el. Ez talán a legfontosabb a kompetens és az inkompetens IT vezetők között. Az inkompetens vezető sosem érti, hogy ha a fejlesztője 5 napot mondott egy munkára, akkor az miért nincs kész az 5. nap végén.

A HBR pontosan leírja, mik a komplex rendszer problémái, amikkel számolni kell(ene):

1) Nem várt mellékhatások: Szakmai berkekben elég annyit mondani, hogy regressziós hiba.

2) Sok apró esemény együttes hatása: Az események külön-külön nem okoznának problémát, együttesen viszont igen, például amikor egy interfészre túl sok felhasználó kapcsolódik és az együttes terhelés már bedönti a rendszert.

3) Elavult szabályok: Valamikor régen valaki hozott egy szabályt, amit mindenki követ, de ma már nem tudjuk, mi az oka és miért követjük.

4) A nagyobb kutya véleménye: A döntést a végén mindig egy ember hozza, és az az egy ember egyféleképpen látja a világot. Márpedig lehet, hogy a helyzetet több szemszögből, több oldalról kellene megvizsgálni, hogy a helyes döntéshez jussunk.

5) Az emberi elme befogadóképességének korlátai: Mivel emberek vagyunk, a saját emberi agyunk, az agyunk befogadóképessége korlátozza a rendszer megértését. Nem érthetünk mindenhez és nem láthatunk át mindent.

6) Saját szemünkben a gerendát: Sajnos az is egy nagyon emberi tulajdonság, hogy miközben egy adott dologra összpontosítunk, aközben más, sokkal fontosabb dolgot nem veszünk észre. Például nagyon a határidőre koncentrálunk és mindent ennek rendelünk alá, miközben a projekt összeomlik.

7) Fekete hattyú effektus: A nem várt, ritka eseményekre nem szokás felkészülni, márpedig a ritka események nagyon is sokszor következnek be. A sikeres menedzsert azt különbözteti meg a sikertelentől, hogy a sikeres felkészül a váratlanra is, például mi van, ha az éles indulás után a rendszer egy váratlan hiba miatt leáll. Plan for the best, prepare for the worst!

A HBR 3 megoldást javasol:

1) Pontosabb előrejelzés

2) Hatékonyabb kockázatkezelés

3) Ésszerűbb kompromisszumok

Ezek részletesen ki vannak fejtve a cikkben, aki kíváncsi olvassa el.

Most inkább visszatérnék a komplexitás okaihoz, és személyes tapasztalatok alapján IT menedzserek számára adnék tippet , hogyan kezelhetnék a komplexitást!

1) Nem várt mellékhatások

Kezdő menedzser: Abból a feltételezésből indul ki, hogy a változtatások egyszerűek, azok hatásai ismertek, éppen ezért nem lesznek mellékhatások. Mint amikor megnyomjuk a Play gombot a DVD lejátszón. Szoftvert fejleszteni egyszerű dolog.

Tapasztalt menedzser: Megkérdezi egy szakértő véleményét, illetve legalább 1 szakértőét. Ha az adott kérdés, adott változtatás több területtel összefügg, akkor inkább biztosra megy és több szakértőt is bevon. Olyan emberekkel dolgozik együtt, akik ismerik a változtatások mellékhatásait.

2) Sok apró esemény

Kezdő menedzser: Reaktív hozzáállás, mindig csak a jelennel foglalkozik és az adott kéréssel. Nem látja az összefüggéseket és nem látja, hogy a rendszerben hol vannak a szűk keresztmetszetek. Nem végez stress-tesztet.

Tapasztalt menedzser: Magas szinten átlátja a rendszert, tisztában van a szűk keresztmetszetekkel. Mindig ellenőrzi a rendszer komponenseinek teherbírását.

3) Elavult szabályok

Kezdő menedzser: Azért csinálja amit csinál, mert így szokás, mert mindig is így csináltuk.

Tapasztalt menedzser: Tisztában van azzal, miért kell a policy-t követni és mi történik akkor, ha nem követjük.

4) A nagyobb kutya véleménye

Kezdő menedzser: Egyszemélyi döntést hoz, hiszen övé a felelősség.

Tapasztalt menedzser: A döntésbe bevonja a szakértőket, közös vagy konszenzusos döntést hoz.

5) Az emberi agy korlátai

Kezdő menedzser: Mindent kézben tart, mindent irányit, ragaszkodik a hivatalos úthoz.

Tapasztalt menedzser: Delegál vagy felhatalmaz, hogy a munkát ne korlátozza be egyetlen ember teljesítőképessége.

6) Saját szemünkben a gerendát

Kezdő menedzser: Görcsösen ragaszkodik elképzelésekhez, tervekhez, határidőkhöz és „kiemelt kérésekhez”. Ha valaki kétségét fejezi ki, azt szőnyeg alá söpri a „cél” elérése érdekében.

Tapasztalt menedzser: Meghallgatja a véleményeket akkor is, ha azok eltérnek a vezetés véleményétől. Nem ragaszkodik görcsösen egyetlen célhoz, hiszen a sikerhez egyszerre több célt is el kell érni. Elfogadja azt, hogy a helyzet és a célok változnak, tehát a tervnek is változnia kell.

7) Fekete hattyú effektus

Kezdő menedzser: Feltételezi, hogy majd minden úgy történik, ahogyan a könyvben meg van írva. Feltételezi, hogy mindenki teljesít minden határidőt, nem lesznek csúszások és nem lesznek problémák.

Tapasztalt menedzser: Arra is felkészül, ami rosszul mehet. Ideje jelentős részében a váratlan események elkerülésével foglalkozik – azaz proaktív.

Így a végére még pár gondolat arról, hogy az informatika komplex-e. Először is, bizonyára sok más terület létezik, ami komplex, tehát az IT ebben bizonyára nem egyedi és nem speciális. Csak azt kell elfogadni, hogy az IT komplex, és ennek megfelelően kezelni.

Lehet, hogy valaki vitába száll majd és azt mondja, az IT cseppet sem komplex. Valóban igaz, hogy léteznek egyszerű, illetve nem komplex részterületei. Egy ITIL szerint szervezett 1. és 2. szintű helpdesk például elég kiszámítható módon működik, a minőségbiztosítás kötött módon, kiszámíthatóan dolgozik, és még sorolhatnám. Összességében azonban az egy informatikai szervezet, egy informatikai rendszer életében sok a komplexitás és a kiszámíthatatlanság. Például hogy egy fejlesztés mikor készül el, hogy egy hiba mikorra lesz kijavítva, hogy egy meglassult rendszer mikor lesz megint használható, vagy hogy mikor lesz végleges egy követelmény specifikáció.

A Harvard Business Review szeptemberi száma a komplexitásról szól.

Miért jobb egy változatos, multikulturális csapat?

Szervezetfejlesztés, csapatépítés vagy toborzás során felmerülhet a kérdés, hogy a csapat álljon-e csupa ugyanolyan, hasonszűrő emberekből, akik ugyanúgy gondolkodnak, vagy inkább csupa különböző emberből, akik mind egyedi látásmóddal rendelkeznek.

A válasz egyszerűen az, hogy a különbözőségek javítják a csapat teljesítményét.

Ennek bizonyítására egyszer részt vettem egy játékban. A játék arról szólt, hogy mindenki írjon össze annyi Tom Cruise filmet, amennyit csak tud. Tom Cruise rengeteg filmben játszott, jó hosszú listát lehet írni, és biztos, hogy senki sem látta mindet.

A játék első felében az volt a kitétel, hogy nem beszélhetünk egymással és nem is mutathatjuk meg a listát egymásnak. Mindenki írt annyi filmet, amennyit tudott, aztán összesítettük.

A játék második felében UGYANEZ volt a feladat, de most a csapattagok beszélhettek egymással. Először csak szimplán összefésültük a listákat, de aztán elkezdtünk beszélgetni. Volt aki emlékezett rá, hogy Tom Cruise csinált 2. világháborús filmet, de nem emlékezett a nevére. A másiknak viszont erre azonnal beugrott a Valkür.

Végeredményben jóval több filmet tudtunk EGYÜTT összeírni, mintha külön-külön dolgoztunk volna, és minél inkább különböző volt az ízlésünk, annál többféle filmet láttunk és annál hosszabb listát tudtunk írni.

(Erről a játékról már írtam korábban Mi az a csapatmunka? címmel)

A napi munka során is pont ugyanígy történik. Ha többfélék, különbözőek vagyunk, akkor többféle módszert és látásmódot tudunk beadni a közösbe, és mindig pont azt, amire szükség van. Különböző emberekkel mindig van valaki, aki éppen az adott helyzettel tud valamit kezdeni.

A csupa hasonszőrűből felépített csapatnak nem lesznek ötletei, illetve mindig csak egyféle.

Tehát ha sikeres csapatot építünk, akkor az legyen változatás, a munkatársak legyenek különbözőek származásra, háttérre, tudásra, életkorra és hozzáállásra (stb.) vonatkozóan.

Hogyan építhető egy ilyen diverz csapat?

1) Tudatos toborzással

2) Rotációval

A tudatos toborzás a legegyszerűbb. Kimondottan olyan jelöltet keresünk, akinek szakmai tudása és tapasztalata rendben van, de eltér az átlagtól. Például női informatikust egy csupa férfi programozó csapatba, egy fiatal de tehetséges titánt az öregek közé, egy nagy öreget a fiatal tehetségek közé, akkurátus tesztelőt a szélcsap programozók közé vagy kreatív embert a hagyományokhoz ragaszkodó csapatba. Talán nem túlzás a pozitív diszkrimináció kifejezés használata.

A változatosság természetesen érinti, érintheti a szakmai hátteret is. Mondjuk webes alkalmazást kell fejleszteni ASP.Net+MSSQL, akkor lehetőség szerint legyen benne egy ASP guru és egy SQL guru.

A változatosság biztosításának másik módszere a rotáció. A munkatársak háttere ismert, a csapatok ismertek, tehát néhány húzással fel lehet kavarni a vizet, hogy mindenhol legyen egy „másképp gondolkodó”.

A legegyszerűbb, ha különböző nációkat keverünk meg, illetve egy homogén csapatba berakunk egy külföldit. A kulturális eltérések elég nagy különbséget jelentenek ahhoz, hogy pozitív kihatással legyenek a csapat teljesítményére. Sajnos az emberek alapvetően az ugyanolyan országból érkező kollégákkal szeretnének dolgozni (magyar a magyarral, francia a franciával, stb), ezt tudatosan le kell rombolni. Például lehet homogén a csapat, de legyen külföldi a főnök.

Tegyük fel, sikerült ezt megvalósítani, van egy vegyes csapat. Itt jön a következő probléma: hogyan lehet egy vegyes csapatot vezetni?

A különböző emberek ugyanis különböző módon oldják meg a feladatokat, különböző módon közelítik meg a problémát. A különbözőség miatt másképp kell bánni velük, és más feladatra lesznek alkalmasak. Egy ilyen csapatot sokkal nehezebb vezetni és motiválni, mint a sablonra vágott egységdroidokat.

A multikulturális csapatban a vezető nem tehet mást, mint alkalmazkodik. Ha például van a csapatban egy angol, egy francia és egy indiai, akkor napra késznek kell lenni az angol labdarúgás, a francia belpolitika és az indiai filmek terén. Türelmesnek és elfogadónak kell lennie, mert sokszor – főleg elsőre – a különbözőségek hátránynak tűnnek. Túl kell lépni a téves első benyomáson, és eljutni oda, hogy a különbözőségek hátrányból előnybe forduljanak.

Az általános gyakorlat az, hogy egy diverz csapat esetén fel kell osztani a feladatokat a munkatársak preferenciái alapján (ahol preferencia alatt nem a személyes kívánságokat értem, hanem azokat a feladatokat, amikben az adott kolléga jó). Tehát ha mondjuk van egy 5 fős csapatunk, és mindenki totál különböző, akkor ki kell alakítani 5 különböző szerepkört/feladatkört/munkakört. A szerepköröket le kell határolni és jól definiálni, hogy ne legyen közöttük ellentét. A szerepkörök alapján mindig eldönthető, melyik feladat kihez tartozik.

Ha csapat-dinamikára hagyatkozunk, ezek a szerepek amúgy is kialakulnának maguktól, tehát akkor már egyszerűbb tudatosan megtervezni.

Személy szerint én más módszert követek. A munkatársra szabott munkakörrel az a baj, hogy így a munkatárs egyedivé és nélkülözhetetlenné válik (a nélkülözhetetlen embert ki kell rúgni ugyebár), továbbá hogy nehezen fogjuk tudni azonos módon terhelni őket (lehet hogy valaki túl sok munkát kap, miközben más keveset). Éppen ezért én a feladatköröket a feladatok alapján alakítom ki, és ehhez passzolom hozzá a munkatársakat.

A jól behatárolt és elhatárolt feladatkörök helyett inkább célokat adok, de a feladatokat személyre delegálás helyett közösnek határozom meg. Mindenki a saját céljait menedzseli, de ugyanakkor felelős a többiek céljainak támogatásáért. A munkatársak nem azon a feladaton dolgoznak, ami a munkaköri leírásban szerepel, hanem ahol a legtöbbet tudják hozzátenni a csapat közös céljaihoz – és ami az adott szituációban a legfontosabb. Ez persze csak úgy tud működni, ha mindenki tisztában van a csapat és a többiek céljaival, illetve ha folyamatos a kommunikáció és a visszajelzés. Nem épülnek ki falak a szerepek között, ezért a szerepek átjárhatóak, adott helyzetben egy munkatárs kiesése nincs kihatással a csapat teljesítményére.

Nem ritkán a feladat kiosztása egyszerűen úgy történik, hogy feldobom a témát a csapatnak, és megkérdezem, hogy ki vállalja.

Mi a helyzet, ha a főnök „más”?

Nem csak a beosztottak lehetnek vegyesek, hanem a főnökök is. Főleg ha a cégnél tudatos rotáció zajlik, akkor a csapat 2-3 évente áteshet főnökváltáson, ahol egymástól szögesen eltérő – hozzáállásban, vezetői stílusban, szakmai háttérben – menedzserek bukkannak fel és hozzák a maguk – a többiekétől teljesen eltérő – módszereit.

Nos, a kegyetlen valóság az, hogy mindegy milyen a főnök, alkalmazkodni kell hozzá. (Fentebb azt javasoltam a főnöknek, hogy alkalmazkodjon a csapathoz – ennek mindkét irányba meg kell történnie.)

Lehet, hogy az előző főnök kreatív és szabadelvű volt, nem érdekelték a határidők és a folyamatok, miközben a következő főnöknél mindent élére kell állítani.

Ezek a váltások elsőre bosszantóak, esetleg demotiválóak lehetnek a csapatra nézve. Az emberek mindig félnek a változástól, és hát az új főnök az új módszereivel közvetlen fenyegetést jelent a megszokásokkal szemben. A félelem azonban alaptalan – az új főnöknek nem érdeke, hogy tönkretegye a csapatot, hiszen akkor ő is bukik. Másrészt pedig az új főnök ilyen helyzetben azzal nyugtathatja meg a csapatot, ha kijelenti, nem kíván változtatni semmit (és ehhez tartja magát egy darabig).

Az új főnök egyébként új lehetőség – lehetőség arra, hogy új dolgokat tanuljunk el tőle. A szakmai fejlődéshez fontos az, hogy mindig legyen mit tanulni a főnökünktől, és ez akkor a maximális, ha időnként új főnököt kapunk.

Mi a teendő, ha új munkahelyünkön mi vagyunk a „más”, a többiektől különböző?

Alkalmazkodni, alkalmazkodni és keményen dolgozni.

Miért jobb egy változatos, multikulturális csapat?

Szervezetfejlesztés, csapatépítés vagy toborzás során felmerülhet a kérdés, hogy a csapat álljon-e csupa ugyanolyan, hasonszűrő emberekből, akik ugyanúgy gondolkodnak, vagy inkább csupa különböző emberből, akik mind egyedi látásmóddal rendelkeznek.

A válasz egyszerűen az, hogy a különbözőségek javítják a csapat teljesítményét.

Ennek bizonyítására egyszer részt vettem egy játékban. A játék arról szólt, hogy mindenki írjon össze annyi Tom Cruise filmet, amennyit csak tud. Tom Cruise rengeteg filmben játszott, jó hosszú listát lehet írni, és biztos, hogy senki sem látta mindet.

A játék első felében az volt a kitétel, hogy nem beszélhetünk egymással és nem is mutathatjuk meg a listát egymásnak. Mindenki írt annyi filmet, amennyit tudott, aztán összesítettük.

A játék második felében UGYANEZ volt a feladat, de most a csapattagok beszélhettek egymással. Először csak szimplán összefésültük a listákat, de aztán elkezdtünk beszélgetni. Volt aki emlékezett rá, hogy Tom Cruise csinált 2. világháborús filmet, de nem emlékezett a nevére. A másiknak viszont erre azonnal beugrott a Valkür.

Végeredményben jóval több filmet tudtunk EGYÜTT összeírni, mintha külön-külön dolgoztunk volna, és minél inkább különböző volt az ízlésünk, annál többféle filmet láttunk és annál hosszabb listát tudtunk írni.

(Erről a játékról már írtam korábban Mi az a csapatmunka? címmel)

A napi munka során is pont ugyanígy történik. Ha többfélék, különbözőek vagyunk, akkor többféle módszert és látásmódot tudunk beadni a közösbe, és mindig pont azt, amire szükség van. Különböző emberekkel mindig van valaki, aki éppen az adott helyzettel tud valamit kezdeni.

A csupa hasonszőrűből felépített csapatnak nem lesznek ötletei, illetve mindig csak egyféle.

Tehát ha sikeres csapatot építünk, akkor az legyen változatás, a munkatársak legyenek különbözőek származásra, háttérre, tudásra, életkorra és hozzáállásra (stb.) vonatkozóan.

Hogyan építhető egy ilyen diverz csapat?

1) Tudatos toborzással

2) Rotációval

A tudatos toborzás a legegyszerűbb. Kimondottan olyan jelöltet keresünk, akinek szakmai tudása és tapasztalata rendben van, de eltér az átlagtól. Például női informatikust egy csupa férfi programozó csapatba, egy fiatal de tehetséges titánt az öregek közé, egy nagy öreget a fiatal tehetségek közé, akkurátus tesztelőt a szélcsap programozók közé vagy kreatív embert a hagyományokhoz ragaszkodó csapatba. Talán nem túlzás a pozitív diszkrimináció kifejezés használata.

A változatosság természetesen érinti, érintheti a szakmai hátteret is. Mondjuk webes alkalmazást kell fejleszteni ASP.Net+MSSQL, akkor lehetőség szerint legyen benne egy ASP guru és egy SQL guru.

A változatosság biztosításának másik módszere a rotáció. A munkatársak háttere ismert, a csapatok ismertek, tehát néhány húzással fel lehet kavarni a vizet, hogy mindenhol legyen egy „másképp gondolkodó”.

A legegyszerűbb, ha különböző nációkat keverünk meg, illetve egy homogén csapatba berakunk egy külföldit. A kulturális eltérések elég nagy különbséget jelentenek ahhoz, hogy pozitív kihatással legyenek a csapat teljesítményére. Sajnos az emberek alapvetően az ugyanolyan országból érkező kollégákkal szeretnének dolgozni (magyar a magyarral, francia a franciával, stb), ezt tudatosan le kell rombolni. Például lehet homogén a csapat, de legyen külföldi a főnök.

Tegyük fel, sikerült ezt megvalósítani, van egy vegyes csapat. Itt jön a következő probléma: hogyan lehet egy vegyes csapatot vezetni?

A különböző emberek ugyanis különböző módon oldják meg a feladatokat, különböző módon közelítik meg a problémát. A különbözőség miatt másképp kell bánni velük, és más feladatra lesznek alkalmasak. Egy ilyen csapatot sokkal nehezebb vezetni és motiválni, mint a sablonra vágott egységdroidokat.

A multikulturális csapatban a vezető nem tehet mást, mint alkalmazkodik. Ha például van a csapatban egy angol, egy francia és egy indiai, akkor napra késznek kell lenni az angol labdarúgás, a francia belpolitika és az indiai filmek terén. Türelmesnek és elfogadónak kell lennie, mert sokszor – főleg elsőre – a különbözőségek hátránynak tűnnek. Túl kell lépni a téves első benyomáson, és eljutni oda, hogy a különbözőségek hátrányból előnybe forduljanak.

Az általános gyakorlat az, hogy egy diverz csapat esetén fel kell osztani a feladatokat a munkatársak preferenciái alapján (ahol preferencia alatt nem a személyes kívánságokat értem, hanem azokat a feladatokat, amikben az adott kolléga jó). Tehát ha mondjuk van egy 5 fős csapatunk, és mindenki totál különböző, akkor ki kell alakítani 5 különböző szerepkört/feladatkört/munkakört. A szerepköröket le kell határolni és jól definiálni, hogy ne legyen közöttük ellentét. A szerepkörök alapján mindig eldönthető, melyik feladat kihez tartozik.

Ha csapat-dinamikára hagyatkozunk, ezek a szerepek amúgy is kialakulnának maguktól, tehát akkor már egyszerűbb tudatosan megtervezni.

Személy szerint én más módszert követek. A munkatársra szabott munkakörrel az a baj, hogy így a munkatárs egyedivé és nélkülözhetetlenné válik (a nélkülözhetetlen embert ki kell rúgni ugyebár), továbbá hogy nehezen fogjuk tudni azonos módon terhelni őket (lehet hogy valaki túl sok munkát kap, miközben más keveset). Éppen ezért én a feladatköröket a feladatok alapján alakítom ki, és ehhez passzolom hozzá a munkatársakat.

A jól behatárolt és elhatárolt feladatkörök helyett inkább célokat adok, de a feladatokat személyre delegálás helyett közösnek határozom meg. Mindenki a saját céljait menedzseli, de ugyanakkor felelős a többiek céljainak támogatásáért. A munkatársak nem azon a feladaton dolgoznak, ami a munkaköri leírásban szerepel, hanem ahol a legtöbbet tudják hozzátenni a csapat közös céljaihoz – és ami az adott szituációban a legfontosabb. Ez persze csak úgy tud működni, ha mindenki tisztában van a csapat és a többiek céljaival, illetve ha folyamatos a kommunikáció és a visszajelzés. Nem épülnek ki falak a szerepek között, ezért a szerepek átjárhatóak, adott helyzetben egy munkatárs kiesése nincs kihatással a csapat teljesítményére.

Nem ritkán a feladat kiosztása egyszerűen úgy történik, hogy feldobom a témát a csapatnak, és megkérdezem, hogy ki vállalja.

Mi a helyzet, ha a főnök „más”?

Nem csak a beosztottak lehetnek vegyesek, hanem a főnökök is. Főleg ha a cégnél tudatos rotáció zajlik, akkor a csapat 2-3 évente áteshet főnökváltáson, ahol egymástól szögesen eltérő – hozzáállásban, vezetői stílusban, szakmai háttérben – menedzserek bukkannak fel és hozzák a maguk – a többiekétől teljesen eltérő – módszereit.

Nos, a kegyetlen valóság az, hogy mindegy milyen a főnök, alkalmazkodni kell hozzá. (Fentebb azt javasoltam a főnöknek, hogy alkalmazkodjon a csapathoz – ennek mindkét irányba meg kell történnie.)

Lehet, hogy az előző főnök kreatív és szabadelvű volt, nem érdekelték a határidők és a folyamatok, miközben a következő főnöknél mindent élére kell állítani.

Ezek a váltások elsőre bosszantóak, esetleg demotiválóak lehetnek a csapatra nézve. Az emberek mindig félnek a változástól, és hát az új főnök az új módszereivel közvetlen fenyegetést jelent a megszokásokkal szemben. A félelem azonban alaptalan – az új főnöknek nem érdeke, hogy tönkretegye a csapatot, hiszen akkor ő is bukik. Másrészt pedig az új főnök ilyen helyzetben azzal nyugtathatja meg a csapatot, ha kijelenti, nem kíván változtatni semmit (és ehhez tartja magát egy darabig).

Az új főnök egyébként új lehetőség – lehetőség arra, hogy új dolgokat tanuljunk el tőle. A szakmai fejlődéshez fontos az, hogy mindig legyen mit tanulni a főnökünktől, és ez akkor a maximális, ha időnként új főnököt kapunk.

Mi a teendő, ha új munkahelyünkön mi vagyunk a „más”, a többiektől különböző?

Alkalmazkodni, alkalmazkodni és keményen dolgozni.

Miért jobb egy változatos, multikulturális csapat?

Szervezetfejlesztés, csapatépítés vagy toborzás során felmerülhet a kérdés, hogy a csapat álljon-e csupa ugyanolyan, hasonszűrő emberekből, akik ugyanúgy gondolkodnak, vagy inkább csupa különböző emberből, akik mind egyedi látásmóddal rendelkeznek.

A válasz egyszerűen az, hogy a különbözőségek javítják a csapat teljesítményét.

Ennek bizonyítására egyszer részt vettem egy játékban. A játék arról szólt, hogy mindenki írjon össze annyi Tom Cruise filmet, amennyit csak tud. Tom Cruise rengeteg filmben játszott, jó hosszú listát lehet írni, és biztos, hogy senki sem látta mindet.

A játék első felében az volt a kitétel, hogy nem beszélhetünk egymással és nem is mutathatjuk meg a listát egymásnak. Mindenki írt annyi filmet, amennyit tudott, aztán összesítettük.

A játék második felében UGYANEZ volt a feladat, de most a csapattagok beszélhettek egymással. Először csak szimplán összefésültük a listákat, de aztán elkezdtünk beszélgetni. Volt aki emlékezett rá, hogy Tom Cruise csinált 2. világháborús filmet, de nem emlékezett a nevére. A másiknak viszont erre azonnal beugrott a Valkür.

Végeredményben jóval több filmet tudtunk EGYÜTT összeírni, mintha külön-külön dolgoztunk volna, és minél inkább különböző volt az ízlésünk, annál többféle filmet láttunk és annál hosszabb listát tudtunk írni.

(Erről a játékról már írtam korábban Mi az a csapatmunka? címmel)

A napi munka során is pont ugyanígy történik. Ha többfélék, különbözőek vagyunk, akkor többféle módszert és látásmódot tudunk beadni a közösbe, és mindig pont azt, amire szükség van. Különböző emberekkel mindig van valaki, aki éppen az adott helyzettel tud valamit kezdeni.

A csupa hasonszőrűből felépített csapatnak nem lesznek ötletei, illetve mindig csak egyféle.

Tehát ha sikeres csapatot építünk, akkor az legyen változatás, a munkatársak legyenek különbözőek származásra, háttérre, tudásra, életkorra és hozzáállásra (stb.) vonatkozóan.

Hogyan építhető egy ilyen diverz csapat?

1) Tudatos toborzással

2) Rotációval

A tudatos toborzás a legegyszerűbb. Kimondottan olyan jelöltet keresünk, akinek szakmai tudása és tapasztalata rendben van, de eltér az átlagtól. Például női informatikust egy csupa férfi programozó csapatba, egy fiatal de tehetséges titánt az öregek közé, egy nagy öreget a fiatal tehetségek közé, akkurátus tesztelőt a szélcsap programozók közé vagy kreatív embert a hagyományokhoz ragaszkodó csapatba. Talán nem túlzás a pozitív diszkrimináció kifejezés használata.

A változatosság természetesen érinti, érintheti a szakmai hátteret is. Mondjuk webes alkalmazást kell fejleszteni ASP.Net+MSSQL, akkor lehetőség szerint legyen benne egy ASP guru és egy SQL guru.

A változatosság biztosításának másik módszere a rotáció. A munkatársak háttere ismert, a csapatok ismertek, tehát néhány húzással fel lehet kavarni a vizet, hogy mindenhol legyen egy „másképp gondolkodó”.

A legegyszerűbb, ha különböző nációkat keverünk meg, illetve egy homogén csapatba berakunk egy külföldit. A kulturális eltérések elég nagy különbséget jelentenek ahhoz, hogy pozitív kihatással legyenek a csapat teljesítményére. Sajnos az emberek alapvetően az ugyanolyan országból érkező kollégákkal szeretnének dolgozni (magyar a magyarral, francia a franciával, stb), ezt tudatosan le kell rombolni. Például lehet homogén a csapat, de legyen külföldi a főnök.

Tegyük fel, sikerült ezt megvalósítani, van egy vegyes csapat. Itt jön a következő probléma: hogyan lehet egy vegyes csapatot vezetni?

A különböző emberek ugyanis különböző módon oldják meg a feladatokat, különböző módon közelítik meg a problémát. A különbözőség miatt másképp kell bánni velük, és más feladatra lesznek alkalmasak. Egy ilyen csapatot sokkal nehezebb vezetni és motiválni, mint a sablonra vágott egységdroidokat.

A multikulturális csapatban a vezető nem tehet mást, mint alkalmazkodik. Ha például van a csapatban egy angol, egy francia és egy indiai, akkor napra késznek kell lenni az angol labdarúgás, a francia belpolitika és az indiai filmek terén. Türelmesnek és elfogadónak kell lennie, mert sokszor – főleg elsőre – a különbözőségek hátránynak tűnnek. Túl kell lépni a téves első benyomáson, és eljutni oda, hogy a különbözőségek hátrányból előnybe forduljanak.

Az általános gyakorlat az, hogy egy diverz csapat esetén fel kell osztani a feladatokat a munkatársak preferenciái alapján (ahol preferencia alatt nem a személyes kívánságokat értem, hanem azokat a feladatokat, amikben az adott kolléga jó). Tehát ha mondjuk van egy 5 fős csapatunk, és mindenki totál különböző, akkor ki kell alakítani 5 különböző szerepkört/feladatkört/munkakört. A szerepköröket le kell határolni és jól definiálni, hogy ne legyen közöttük ellentét. A szerepkörök alapján mindig eldönthető, melyik feladat kihez tartozik.

Ha csapat-dinamikára hagyatkozunk, ezek a szerepek amúgy is kialakulnának maguktól, tehát akkor már egyszerűbb tudatosan megtervezni.

Személy szerint én más módszert követek. A munkatársra szabott munkakörrel az a baj, hogy így a munkatárs egyedivé és nélkülözhetetlenné válik (a nélkülözhetetlen embert ki kell rúgni ugyebár), továbbá hogy nehezen fogjuk tudni azonos módon terhelni őket (lehet hogy valaki túl sok munkát kap, miközben más keveset). Éppen ezért én a feladatköröket a feladatok alapján alakítom ki, és ehhez passzolom hozzá a munkatársakat.

A jól behatárolt és elhatárolt feladatkörök helyett inkább célokat adok, de a feladatokat személyre delegálás helyett közösnek határozom meg. Mindenki a saját céljait menedzseli, de ugyanakkor felelős a többiek céljainak támogatásáért. A munkatársak nem azon a feladaton dolgoznak, ami a munkaköri leírásban szerepel, hanem ahol a legtöbbet tudják hozzátenni a csapat közös céljaihoz – és ami az adott szituációban a legfontosabb. Ez persze csak úgy tud működni, ha mindenki tisztában van a csapat és a többiek céljaival, illetve ha folyamatos a kommunikáció és a visszajelzés. Nem épülnek ki falak a szerepek között, ezért a szerepek átjárhatóak, adott helyzetben egy munkatárs kiesése nincs kihatással a csapat teljesítményére.

Nem ritkán a feladat kiosztása egyszerűen úgy történik, hogy feldobom a témát a csapatnak, és megkérdezem, hogy ki vállalja.

Mi a helyzet, ha a főnök „más”?

Nem csak a beosztottak lehetnek vegyesek, hanem a főnökök is. Főleg ha a cégnél tudatos rotáció zajlik, akkor a csapat 2-3 évente áteshet főnökváltáson, ahol egymástól szögesen eltérő – hozzáállásban, vezetői stílusban, szakmai háttérben – menedzserek bukkannak fel és hozzák a maguk – a többiekétől teljesen eltérő – módszereit.

Nos, a kegyetlen valóság az, hogy mindegy milyen a főnök, alkalmazkodni kell hozzá. (Fentebb azt javasoltam a főnöknek, hogy alkalmazkodjon a csapathoz – ennek mindkét irányba meg kell történnie.)

Lehet, hogy az előző főnök kreatív és szabadelvű volt, nem érdekelték a határidők és a folyamatok, miközben a következő főnöknél mindent élére kell állítani.

Ezek a váltások elsőre bosszantóak, esetleg demotiválóak lehetnek a csapatra nézve. Az emberek mindig félnek a változástól, és hát az új főnök az új módszereivel közvetlen fenyegetést jelent a megszokásokkal szemben. A félelem azonban alaptalan – az új főnöknek nem érdeke, hogy tönkretegye a csapatot, hiszen akkor ő is bukik. Másrészt pedig az új főnök ilyen helyzetben azzal nyugtathatja meg a csapatot, ha kijelenti, nem kíván változtatni semmit (és ehhez tartja magát egy darabig).

Az új főnök egyébként új lehetőség – lehetőség arra, hogy új dolgokat tanuljunk el tőle. A szakmai fejlődéshez fontos az, hogy mindig legyen mit tanulni a főnökünktől, és ez akkor a maximális, ha időnként új főnököt kapunk.

Mi a teendő, ha új munkahelyünkön mi vagyunk a „más”, a többiektől különböző?

Alkalmazkodni, alkalmazkodni és keményen dolgozni.

Miért jobb egy változatos, multikulturális csapat?

Az empowerment leggyengébb láncszeme a vezető, erről szeretnék most bővebben írni

Mivel az empowerment egy fontos, de kevéssé ismert módszer, ezért 3 részes cikksorozatot szentelnék neki. A következő két részben a csapat felépítéséről és a magyar informatikusok sajátosságairól lesz szó, de most a legfontosabb dologgal kezdeném: a menedzserrel.

Kezdjük definícióval. Az empowerment (magyarul talán felhatalmazás) azt jelenti, hogy a beosztottak szabadságot kapnak, hogy feladataikban, feladataik végrehajtása során önállóan döntsenek. A döntési jog azzal jár, hogy növekszik a felelősségvállalás, a motiváció, és ezzel együtt a teljesítmény.

A pozitív hatások miatt az empowerment egyértelműen hasznos és kívánatos dolog – és akkor még nem is beszéltem a kreativitásról, az innovációról és a szervezeti hatékonyságról.

Természetesen nem minden esetben alkalmazható, nyilvánvalóan ez a körülmények függvénye. Az informatika például tipikusan az a terület, ahol alkalmazható.

Még mielőtt mindenki túlságosan belelkesülne: megvalósítani nem egyszerű. A legnehezebb dolog nem a csapat kiválasztása, felépítése vagy átalakítása, hanem annak a felismerése, hogy empowerment-re szükség van, és megtanulni az empowerment-hez szükséges eszközöket.

Ez ugyanis nem jön magától, nem reflexszerű. Amikor valakit váratlanul, mindenféle előzetes képzés nélkül kineveznek vezetőnek, akkor automatikusan a command-and-control-hoz nyúl: hatalmát felhasználva utasításokat ad, ellenőriz és büntet.

Sok vezető egész egyszerűen nem is hallott arról, hogy a csapatot fel is lehet hatalmazni. Nincs előttük példa, sosem látták, ezért számukra amolyan városi legenda lesz – semmi esetre sem próbálják meg „éles” környezetben.

Tehát amikor egy menedzser már hallott róla és utánanéz, már meg is tette a legjelentősebb lépést előre.

Hogyan sajátíthatja el egy vezető az empowerment művészetét?

Sajnos ez olyan dolog, amit könyvből vagy egy blogon olvasott érdekes cikk alapján nem lehet elsajátítani. A „learn on the job” a már korábban említett okok miatt nem működik.

Mindenképpen kell egy látható példa, egy jó vezető aki csinálja és akitől el lehet lesni a fortélyokat. Léteznek tanfolyamok - itt Magyarországon is – amikre el lehet menni és meg lehet tanulni.

Számomra az jelentette a fordulópontot, amikor külföldre mentem hosszabb időre dolgozni, és ott élesben láttam ezt működni. Annyira erős volt az élmény, hogy kvázi leradírozta a korábbi rossz vezetői mintákat, és beégette a helyeset. Éppen emiatt nem tudok konkrét, gyors utat adni az empowerment elsajátítására – nem tudok mondani könyv címet, amit az ember elolvasva megtanulja az alapokat.

Az empowerment elterjedését, a vezetők ezirányú szándékát jelentősen hátráltatja a téma elfogadottsága (illetve el nem fogadottsága) Magyarországon. A sikeres vezető sztereotípiájához hozzátartozik, hogy mindent keményen fog, és kitapossa a szuszt is a beosztottaiból. Amikor annak idején állást kerestem, és az interjún a pozitív hozzáállásról vagy a felhatalmazásról beszéltem, akkor bamba szemekkel néztek rám. Olyan megjegyzéseket kaptam, hogy „érdekes elmélet”.

Ez nyilvánvalóan egy ördögi kör: amíg a felhatalmazás nem elfogadott, addig diktátor típusú vezetőket keresnek, de amíg a diktátor típusúak vannak többségben, addig nem is fog elterjedni az empowerment.

A sikeres empowerment alkalmazásához feltétlenül szükséges a téma vállalaton belüli elfogadása (vagy legalábbis megtűrése), és a főnökünk pozitív hozzáállása. Sajnos sok helyen maga a céges kultúra teszi lehetetlenné a felhatalmazást. Akkor sem javasolnám kipróbálni, ha a főnökünk szerint „marhaság”.

Az empowerment elfogadásának feltétele, hogy a vállalat teljesítmény orientált legyen. Tehát amikor nem akarnak beleszólni a módszerekbe, amíg azok a módszerek hozzák az eredményt.

További feltétel, hogy – legalábbis a felszínen – az emberi értékek fontosak legyenek. A „respect people” nélkül nem megy.

Tegyük fel, hogy a vezető eldöntötte az empowerment bevezetését, ismeri is és látott is másokat ezt gyakorolni. Mi legyen a következő lépés, mit csináljon?

Az empowerment mindig a vezetővel kezdődik és a vezetővel végződik. A vezető az, aki elindítja a változást, ő változik először. 5 fő pontot említenék:

1) Vezető gondolkodásmódja

2) Erőforrások biztosítása

3) Információ megosztása

4) Jogkörök és döntési lehetőségek biztosítása

5) Csapat viselkedésének megváltozása

1) Vezető gondolkodásmódja

Mint írtam, a legelső lépés, hogy a vezető saját gondolkodásmódján változtat. A hagyományos feltételezés – „a beosztottak lopnak, csalnak, hazudnak” – helyett ennek pontosan az ellenkezőjét kell tenni: feltételezni, hogy a beosztottak jó szakértők és elvégzik a munkájukat. Mindenkiről a legjobbat kell gondolni (legalábbis addig, amíg ennek ellenkezőjét be nem bizonyítja).

Még akkor is, ha egy beosztott kevéssé képzett vagy nem a zsenialitás szobra, de tiszteljük meg mint embert és bánjunk vele normálisan.

Mindenképpen ez a legelső lépés, hiszen a vezetői példamutatás fogja beindítani a folyamatot.

2) Erőforrások biztosítása

Ahhoz, hogy a beosztottak képesek legyenek önállóan dönteni, el kell látni őket a munkájukhoz szükséges minden eszközre, alapanyagra, hozzáférésre és erőforrásra.

Ha a beosztottaknak lépten-nyomon a főnökükhöz kell rohangálni jóváhagyásokért és eszközöket kérni, akkor nem lesznek önállóak. A szükséges eszközök hiánya nem csak fizikailag, hanem mentálisan is gátolja a munkavégzést. Egyrészt ürügy lesz arra, hogy a munka ne haladjon, másrészt pedig a szükséges eszközök utáni rohangálás frusztrációt okoz és időt vesz el az értékteremtéstől.

Az erőforrások közé sorolom az olyan mentálhigiéniás dolgokat is, mint például kávéautomata, konyha, parkolóhely. Ha a beosztottak azt látják, hogy a főnökük MINDENT biztosít a munkavégzéshez, akkor az pozitív lökést ad számukra – arról nem is beszélve, hogy lecsökken a holt idő és nem veszik el feleslegesen munkaidő.

Megjegyzem, hogy az erőforrások biztosítása nem csak az empowerment miatt szükséges, hanem úgy általában is. Elvileg nem mondtam semmi újat.

3) Információ megosztása

Ahhoz, hogy a beosztottak önállóan végezhessék munkájukat, és döntéseket hozhassanak, információra van szükségük. Az információ is egyfajta erőforrás, ami nélkül nem lehet dolgozni.

Abból az alaptézisből kell kiindulni, hogy a kommunikációból sosem elég – vigyük szándékosan túlzásba!

A problémák JELENTŐS része abból származik, hogy valaki nem kapott meg egy számára szükséges információt. Ennek elkerülésére a következőket javaslom:

- Tudatosan derítsük fel és építsük ki a formális kommunikációs csatornákat – ügyfelekkel, vezetőkkel, számunkra fontos másik csapatokkal, a beosztottainkkal. A formális kommunikációnak alakuljanak ki a szabályai, tehát ki mikor kivel hogyan mit oszt meg (sablon dokumentumok és táblázatok használata)

- Szükség van rövid, de rendszeres csapaton belüli kommunikációra

- Osszunk meg minden információt azonnal!

- A kommunikáció legyen kétirányú: a beosztott tájékoztatja a főnökét, a főnök tájékoztatja a beosztottat. Mindkét irány ugyanannyira fontos!

- Legyen rendszeres privát megbeszélés a beosztottakkal

- A vezető készítsen hosszú távú tervet a csapat számára (stratégia) és ezt mindenki ismerje meg

- Visszajelzés: mind a pozitívumokról, mind a negatív dolgokról. Természetesen dicsérni mindenki előtt, nyilvánosan kell, negatív üzenetet pedig óvatosan és privát.

- Lehessen kérdezni a főnöktől.

Az információ gyors megosztásával az is elkerülhető, hogy rosszindulatú pletykák keringjenek. A rendszeres és gyors kommunikáció növeli a vezető iránti bizalmat, és növeli a csapat ellenállását a váratlan helyzetekkel szemben.

Bizonyos vezetők szeretik monopolizálni az információt, hiszen az információ hatalom. Azonban a hatalmat másképp is fent lehet tartani. Tükörbe kell nézni, és megkérdezni magunktól, hogy az információ monopóliumának feladásával megtartjuk-e az irányítást a csapat felett, vagy sem.

4) Döntési lehetőség biztosítása

Ha a beosztottak számára minden eszköz és információ rendelkezésre áll, akkor megnyílik a lehetőség, hogy a beosztottak döntsenek. Értelemszerűen amíg a feltételek nem adottak, addig nincs lehetőség jól dönteni.

Mit is értünk „döntés” alatt? A szakmai feladatokra vonatkozó szakmai döntéseket, egy adott feladatot hogyan oldjanak meg, vagy melyik feladatot először. Esetleg azt, hogy egy feladatot nem így kell elkezdeni, vagy az a feladat nem is feloldható.

Ez úgy érhető el, ha a vezető a „hogyan” helyett (mikromenedzsment) a célokra összpontosít. A beosztottaknak nem részletes utasításokat, hanem célokat kell adni, a célokhoz megvilágosítani a kontextust és a hátteret.

Azt kell feltételezni (és elvárni), hogy amennyiben a munkatársak akadállyal szembesülnek a feladat végrehajtása során, akkor majd eldöntik, hogyan oldják fel.

A vezető nem utasít, legfeljebb tanácsol vagy kérdez – vagyis alapvetően coaching-ol. Amikor műszaki kérdésről van szó, a vezető nem dönt, hanem megkérdezi a kérdéses beosztottat, hogy mi a véleménye. A csapat vezetése tehát elsősorban célok, és nem feladatok meghatározásával történik.

A döntési jog azt is jelentik, amennyiben a beosztott döntést hozott, azt a vezető elfogadja és támogatja. Előfordulhat például, hogy a döntés később hibásnak bizonyul – ilyen esetben is a vezetőnek maximálisan ki kell állnia a döntés és a beosztott mellett. (Természetesen amikor a  munkatárs sokszor dönt rosszul, az már orvoslandó eset)

Megjegyzem, hogy a vezetőnek amúgy is ki kell állnia a beosztottai és a döntések mellett, akár használja az empowerment-et, akár nem. Amikor valaki hibázik – emberek vagyunk, hibázunk – akkor sem szabad szembefordulni a csapattal.

5) Csapat hozzáállása

Természetesen ahhoz, hogy mindez működjön, szükség van a munkatársak megfelelő hozzáállása. A megfelelő hozzáállás alatt azt értem, hogy a munkatársak nem csak utasításra várnak, hanem képesek önállóan dolgozni, képesek egy váratlanul felbukkanó probléma esetén önállóan eldönteni, mi a helyes megoldás, képesek a helyes megoldást kivitelezni, és tisztában vannak a célok jelentőségével.

Sajnos ez nem olyan egyszerű. Ha valaki számára ismeretlen, idegen az empowerment, akkor eltart egy darabig, amíg a gondolkodásmódot a megfelelő irányba tereljük.

Erről fogok írni a következő cikkben.

Hogyan tudja elfogadtatni a menedzser a főnökével az empowerment-et?

Az empowerment csak egy eszköz, ezért nem jelent fundamentális változást a menedzser feladatait illetően. A csapatot továbbra is a menedzser vezeti, a végrehajtandó célok nem változnak, továbbra is van ellenőrzés, és aki nem teljesít az továbbra is repül a munkahelyéről.

Ilyen értelemben az empowerment nem jelent változást és nincs szükség „buy-in”-re.

Hozzátenném, hogy bizonyos méretek és szervezeti felépítés mellett az empowerment nem választás kérdése, hanem kötelező. Egy menedzser csak adott számú beosztottat tud közvetlenül felügyelni, ezen felül „kénytelen” megbízni bennük és bízni az önálló munkavégzésben.

Kinek a felelőssége az empowerment?

Csakis is kizárólag a vezetőé.

Milyen konfliktusokkal jár az empowerment alkalmazása?

Az 5-ös pontban említettek szerint a csapat „felépítése” lesz az elsődleges konfliktus.

Ezen felül konfliktus lehet/lesz a többi menedzserrel. Egy diktatórikus, hard eszközökkel operáló „rivális” menedzser szemében ugyanis az empowerment 180 fokos ellentéte a „normálisnak”, és ezért a felhatalmazó-támogató vezetőre úgy tekint, mint amatőrre. Pontosan ezért van szükség eredmény centrikus környezetre, ahol a csapat eredményessége elég bizonyíték lesz a módszer helyességére.

További konfliktusforrást jelenthet, ha az empowerment bevezetés sikeres lesz és a csapatunk motivált, miközben a többi csapat nem az. Aki nem lép egyszerre, nem kap rétest estére!

Az empowerment leggyengébb láncszeme a vezető, erről szeretnék most bővebben írni

Mivel az empowerment egy fontos, de kevéssé ismert módszer, ezért 3 részes cikksorozatot szentelnék neki. A következő két részben a csapat felépítéséről és a magyar informatikusok sajátosságairól lesz szó, de most a legfontosabb dologgal kezdeném: a menedzserrel.

Kezdjük definícióval. Az empowerment (magyarul talán felhatalmazás) azt jelenti, hogy a beosztottak szabadságot kapnak, hogy feladataikban, feladataik végrehajtása során önállóan döntsenek. A döntési jog azzal jár, hogy növekszik a felelősségvállalás, a motiváció, és ezzel együtt a teljesítmény.

A pozitív hatások miatt az empowerment egyértelműen hasznos és kívánatos dolog – és akkor még nem is beszéltem a kreativitásról, az innovációról és a szervezeti hatékonyságról.

Természetesen nem minden esetben alkalmazható, nyilvánvalóan ez a körülmények függvénye. Az informatika például tipikusan az a terület, ahol alkalmazható.

Még mielőtt mindenki túlságosan belelkesülne: megvalósítani nem egyszerű. A legnehezebb dolog nem a csapat kiválasztása, felépítése vagy átalakítása, hanem annak a felismerése, hogy empowerment-re szükség van, és megtanulni az empowerment-hez szükséges eszközöket.

Ez ugyanis nem jön magától, nem reflexszerű. Amikor valakit váratlanul, mindenféle előzetes képzés nélkül kineveznek vezetőnek, akkor automatikusan a command-and-control-hoz nyúl: hatalmát felhasználva utasításokat ad, ellenőriz és büntet.

Sok vezető egész egyszerűen nem is hallott arról, hogy a csapatot fel is lehet hatalmazni. Nincs előttük példa, sosem látták, ezért számukra amolyan városi legenda lesz – semmi esetre sem próbálják meg „éles” környezetben.

Tehát amikor egy menedzser már hallott róla és utánanéz, már meg is tette a legjelentősebb lépést előre.

Hogyan sajátíthatja el egy vezető az empowerment művészetét?

Sajnos ez olyan dolog, amit könyvből vagy egy blogon olvasott érdekes cikk alapján nem lehet elsajátítani. A „learn on the job” a már korábban említett okok miatt nem működik.

Mindenképpen kell egy látható példa, egy jó vezető aki csinálja és akitől el lehet lesni a fortélyokat. Léteznek tanfolyamok - itt Magyarországon is – amikre el lehet menni és meg lehet tanulni.

Számomra az jelentette a fordulópontot, amikor külföldre mentem hosszabb időre dolgozni, és ott élesben láttam ezt működni. Annyira erős volt az élmény, hogy kvázi leradírozta a korábbi rossz vezetői mintákat, és beégette a helyeset. Éppen emiatt nem tudok konkrét, gyors utat adni az empowerment elsajátítására – nem tudok mondani könyv címet, amit az ember elolvasva megtanulja az alapokat.

Az empowerment elterjedését, a vezetők ezirányú szándékát jelentősen hátráltatja a téma elfogadottsága (illetve el nem fogadottsága) Magyarországon. A sikeres vezető sztereotípiájához hozzátartozik, hogy mindent keményen fog, és kitapossa a szuszt is a beosztottaiból. Amikor annak idején állást kerestem, és az interjún a pozitív hozzáállásról vagy a felhatalmazásról beszéltem, akkor bamba szemekkel néztek rám. Olyan megjegyzéseket kaptam, hogy „érdekes elmélet”.

Ez nyilvánvalóan egy ördögi kör: amíg a felhatalmazás nem elfogadott, addig diktátor típusú vezetőket keresnek, de amíg a diktátor típusúak vannak többségben, addig nem is fog elterjedni az empowerment.

A sikeres empowerment alkalmazásához feltétlenül szükséges a téma vállalaton belüli elfogadása (vagy legalábbis megtűrése), és a főnökünk pozitív hozzáállása. Sajnos sok helyen maga a céges kultúra teszi lehetetlenné a felhatalmazást. Akkor sem javasolnám kipróbálni, ha a főnökünk szerint „marhaság”.

Az empowerment elfogadásának feltétele, hogy a vállalat teljesítmény orientált legyen. Tehát amikor nem akarnak beleszólni a módszerekbe, amíg azok a módszerek hozzák az eredményt.

További feltétel, hogy – legalábbis a felszínen – az emberi értékek fontosak legyenek. A „respect people” nélkül nem megy.

Tegyük fel, hogy a vezető eldöntötte az empowerment bevezetését, ismeri is és látott is másokat ezt gyakorolni. Mi legyen a következő lépés, mit csináljon?

Az empowerment mindig a vezetővel kezdődik és a vezetővel végződik. A vezető az, aki elindítja a változást, ő változik először. 5 fő pontot említenék:

1) Vezető gondolkodásmódja

2) Erőforrások biztosítása

3) Információ megosztása

4) Jogkörök és döntési lehetőségek biztosítása

5) Csapat viselkedésének megváltozása

1) Vezető gondolkodásmódja

Mint írtam, a legelső lépés, hogy a vezető saját gondolkodásmódján változtat. A hagyományos feltételezés – „a beosztottak lopnak, csalnak, hazudnak” – helyett ennek pontosan az ellenkezőjét kell tenni: feltételezni, hogy a beosztottak jó szakértők és elvégzik a munkájukat. Mindenkiről a legjobbat kell gondolni (legalábbis addig, amíg ennek ellenkezőjét be nem bizonyítja).

Még akkor is, ha egy beosztott kevéssé képzett vagy nem a zsenialitás szobra, de tiszteljük meg mint embert és bánjunk vele normálisan.

Mindenképpen ez a legelső lépés, hiszen a vezetői példamutatás fogja beindítani a folyamatot.

2) Erőforrások biztosítása

Ahhoz, hogy a beosztottak képesek legyenek önállóan dönteni, el kell látni őket a munkájukhoz szükséges minden eszközre, alapanyagra, hozzáférésre és erőforrásra.

Ha a beosztottaknak lépten-nyomon a főnökükhöz kell rohangálni jóváhagyásokért és eszközöket kérni, akkor nem lesznek önállóak. A szükséges eszközök hiánya nem csak fizikailag, hanem mentálisan is gátolja a munkavégzést. Egyrészt ürügy lesz arra, hogy a munka ne haladjon, másrészt pedig a szükséges eszközök utáni rohangálás frusztrációt okoz és időt vesz el az értékteremtéstől.

Az erőforrások közé sorolom az olyan mentálhigiéniás dolgokat is, mint például kávéautomata, konyha, parkolóhely. Ha a beosztottak azt látják, hogy a főnökük MINDENT biztosít a munkavégzéshez, akkor az pozitív lökést ad számukra – arról nem is beszélve, hogy lecsökken a holt idő és nem veszik el feleslegesen munkaidő.

Megjegyzem, hogy az erőforrások biztosítása nem csak az empowerment miatt szükséges, hanem úgy általában is. Elvileg nem mondtam semmi újat.

3) Információ megosztása

Ahhoz, hogy a beosztottak önállóan végezhessék munkájukat, és döntéseket hozhassanak, információra van szükségük. Az információ is egyfajta erőforrás, ami nélkül nem lehet dolgozni.

Abból az alaptézisből kell kiindulni, hogy a kommunikációból sosem elég – vigyük szándékosan túlzásba!

A problémák JELENTŐS része abból származik, hogy valaki nem kapott meg egy számára szükséges információt. Ennek elkerülésére a következőket javaslom:

- Tudatosan derítsük fel és építsük ki a formális kommunikációs csatornákat – ügyfelekkel, vezetőkkel, számunkra fontos másik csapatokkal, a beosztottainkkal. A formális kommunikációnak alakuljanak ki a szabályai, tehát ki mikor kivel hogyan mit oszt meg (sablon dokumentumok és táblázatok használata)

- Szükség van rövid, de rendszeres csapaton belüli kommunikációra

- Osszunk meg minden információt azonnal!

- A kommunikáció legyen kétirányú: a beosztott tájékoztatja a főnökét, a főnök tájékoztatja a beosztottat. Mindkét irány ugyanannyira fontos!

- Legyen rendszeres privát megbeszélés a beosztottakkal

- A vezető készítsen hosszú távú tervet a csapat számára (stratégia) és ezt mindenki ismerje meg

- Visszajelzés: mind a pozitívumokról, mind a negatív dolgokról. Természetesen dicsérni mindenki előtt, nyilvánosan kell, negatív üzenetet pedig óvatosan és privát.

- Lehessen kérdezni a főnöktől.

Az információ gyors megosztásával az is elkerülhető, hogy rosszindulatú pletykák keringjenek. A rendszeres és gyors kommunikáció növeli a vezető iránti bizalmat, és növeli a csapat ellenállását a váratlan helyzetekkel szemben.

Bizonyos vezetők szeretik monopolizálni az információt, hiszen az információ hatalom. Azonban a hatalmat másképp is fent lehet tartani. Tükörbe kell nézni, és megkérdezni magunktól, hogy az információ monopóliumának feladásával megtartjuk-e az irányítást a csapat felett, vagy sem.

4) Döntési lehetőség biztosítása

Ha a beosztottak számára minden eszköz és információ rendelkezésre áll, akkor megnyílik a lehetőség, hogy a beosztottak döntsenek. Értelemszerűen amíg a feltételek nem adottak, addig nincs lehetőség jól dönteni.

Mit is értünk „döntés” alatt? A szakmai feladatokra vonatkozó szakmai döntéseket, egy adott feladatot hogyan oldjanak meg, vagy melyik feladatot először. Esetleg azt, hogy egy feladatot nem így kell elkezdeni, vagy az a feladat nem is feloldható.

Ez úgy érhető el, ha a vezető a „hogyan” helyett (mikromenedzsment) a célokra összpontosít. A beosztottaknak nem részletes utasításokat, hanem célokat kell adni, a célokhoz megvilágosítani a kontextust és a hátteret.

Azt kell feltételezni (és elvárni), hogy amennyiben a munkatársak akadállyal szembesülnek a feladat végrehajtása során, akkor majd eldöntik, hogyan oldják fel.

A vezető nem utasít, legfeljebb tanácsol vagy kérdez – vagyis alapvetően coaching-ol. Amikor műszaki kérdésről van szó, a vezető nem dönt, hanem megkérdezi a kérdéses beosztottat, hogy mi a véleménye. A csapat vezetése tehát elsősorban célok, és nem feladatok meghatározásával történik.

A döntési jog azt is jelentik, amennyiben a beosztott döntést hozott, azt a vezető elfogadja és támogatja. Előfordulhat például, hogy a döntés később hibásnak bizonyul – ilyen esetben is a vezetőnek maximálisan ki kell állnia a döntés és a beosztott mellett. (Természetesen amikor a  munkatárs sokszor dönt rosszul, az már orvoslandó eset)

Megjegyzem, hogy a vezetőnek amúgy is ki kell állnia a beosztottai és a döntések mellett, akár használja az empowerment-et, akár nem. Amikor valaki hibázik – emberek vagyunk, hibázunk – akkor sem szabad szembefordulni a csapattal.

5) Csapat hozzáállása

Természetesen ahhoz, hogy mindez működjön, szükség van a munkatársak megfelelő hozzáállása. A megfelelő hozzáállás alatt azt értem, hogy a munkatársak nem csak utasításra várnak, hanem képesek önállóan dolgozni, képesek egy váratlanul felbukkanó probléma esetén önállóan eldönteni, mi a helyes megoldás, képesek a helyes megoldást kivitelezni, és tisztában vannak a célok jelentőségével.

Sajnos ez nem olyan egyszerű. Ha valaki számára ismeretlen, idegen az empowerment, akkor eltart egy darabig, amíg a gondolkodásmódot a megfelelő irányba tereljük.

Erről fogok írni a következő cikkben.

Hogyan tudja elfogadtatni a menedzser a főnökével az empowerment-et?

Az empowerment csak egy eszköz, ezért nem jelent fundamentális változást a menedzser feladatait illetően. A csapatot továbbra is a menedzser vezeti, a végrehajtandó célok nem változnak, továbbra is van ellenőrzés, és aki nem teljesít az továbbra is repül a munkahelyéről.

Ilyen értelemben az empowerment nem jelent változást és nincs szükség „buy-in”-re.

Hozzátenném, hogy bizonyos méretek és szervezeti felépítés mellett az empowerment nem választás kérdése, hanem kötelező. Egy menedzser csak adott számú beosztottat tud közvetlenül felügyelni, ezen felül „kénytelen” megbízni bennük és bízni az önálló munkavégzésben.

Kinek a felelőssége az empowerment?

Csakis is kizárólag a vezetőé.

Milyen konfliktusokkal jár az empowerment alkalmazása?

Az 5-ös pontban említettek szerint a csapat „felépítése” lesz az elsődleges konfliktus.

Ezen felül konfliktus lehet/lesz a többi menedzserrel. Egy diktatórikus, hard eszközökkel operáló „rivális” menedzser szemében ugyanis az empowerment 180 fokos ellentéte a „normálisnak”, és ezért a felhatalmazó-támogató vezetőre úgy tekint, mint amatőrre. Pontosan ezért van szükség eredmény centrikus környezetre, ahol a csapat eredményessége elég bizonyíték lesz a módszer helyességére.

További konfliktusforrást jelenthet, ha az empowerment bevezetés sikeres lesz és a csapatunk motivált, miközben a többi csapat nem az. Aki nem lép egyszerre, nem kap rétest estére!