FTKONF-073
Amikor a főnököd a csapatra hárítja a felelősséget
Helyzet
„A vezető a csapatot hibáztatja a kudarcért: hogyan védekezzünk?” · „Manager blaming team for failure, how to counter” · szerző: user1450877 · CC BY-SA
Egy kiskereskedelmi cég belső fejlesztőcsapata a második nagy, látványos projektbukása előtt áll két éven belül. A csapat tagjai kerülő úton tudják meg: a fejlesztési vezetőjük a menedzsment és az ügyvezető felé a csapatot nevezi meg bűnbaknak. A csapat szerint viszont a kudarc okai vezetői döntések: integrálhatatlan rendszereket választottak, minden szenior figyelmeztetést ignoráltak (sőt büntettek), a problémákat kifelé letagadták, a határidők önkényesek voltak. A fejlesztők közben hétvégéket is beáldozva dolgoztak a végkimerülésig. Két év alatt így nem egyetlen sérelem, hanem sérelmek egész rendszere gyűlt fel a csapat és a vezető között: elhallgattatás, kizárás a meetingekből, mások előtti hibáztatás. A csapat most azon gondolkodik, hogy kollektíven kérjen meghallgatást az ügyvezetőtől, de nem tudja, jó ötlet-e, és hogyan érdemes belevágni.
A forrásposzt teljes szövege (magyarul és angolul)
Az eredeti Stack Exchange-kérdés hű magyar fordítása · szerző: user1450877 · The Workplace, q131404 · CC BY-SA.
Egy kiskereskedelmi cég belső szoftverfejlesztő csapatának tagja vagyok. Jelenleg egy nagy projekten dolgozunk, és minden valószínűség szerint el fog bukni. Ezen a ponton gyakorlatilag vége.
Az elmúlt két évet nézve ez lesz a csapat második nagy visszhangú kudarca, nemcsak abban az értelemben, hogy nem szállítottuk le, amit kértek, hanem abban is, hogy egyáltalán semmi értékeset nem szállítottunk. Ez idő alatt mást nem is csináltunk.
A fejlesztőcsapat több tagja különböző emberektől tudta meg a cégen belül, hogy a csapat vezetője (aki csak az elmúlt két évben lett fejlesztési vezető) most a fejlesztőcsapatra keni ezt a kudarcot a menedzsment többi tagja, köztük az ügyvezető igazgató felé.
Ez teljesen félrevezető beállítása annak, miért bukott el ez és a korábbi projekt. A kudarc okai mind a menedzsmentre vezethetők vissza. Szerintem az alábbi okok vezettek a projektek bukásához:
- Az üzleti rendszereket a menedzsment úgy választotta ki, hogy nem gondolta végig, hogyan (és egyáltalán) tudunk-e integrálódni velük. Nem illenek ahhoz, ahogy a cég működik, és nem illeszkednek a jelenlegi munkafolyamatainkhoz. A cég többi része nem hajlandó a munkafolyamatait az új rendszerekhez igazítani.
- A csapat minden tanácsát figyelmen kívül hagyja a fejlesztési vezető. A csapat minden egyes szenior tagja a projekt indulásának pillanatától mondta, hogy az teljesen kivitelezhetetlen: egyszerűen nem létezett olyan technikai megoldás, amelyet megvalósíthattunk volna, és amely feloldotta volna a választott platform korlátait, miközben lehetővé teszi, hogy a cég úgy működjön, ahogy szeretett volna. A tanácsokat és figyelmeztetéseket nemcsak figyelmen kívül hagyták, hanem aktívan üldözték is: akik figyelmeztetést fogalmaztak meg, azokat megbüntették.
- A figyelmeztetések sosem jutottak túl a csapatunkon. A menedzsment egyetlen más tagja sem tud a projekt súlyos hiányosságairól. Nulla az átláthatóság a csapatunkban. Kifelé mindent rendben lévőnek és ütemterv szerint haladónak jelentenek, miközben belül hetek óta tudjuk, hogy a dolog soha nem fog működni. A külső részlegek csak néhány nappal korábban értesülnek a csúszó határidőkről, pedig jóval előre figyelmeztethetnénk őket.
- A projekt- és csapatirányítás diszfunkcionális és kifejezetten inkompetens. A feladatok homályosak és kidolgozatlanok. A szükséges kritikus döntéseket az utolsó pillanatig nem hozzák meg, ami többletmunkát és komoly problémákat okoz a már feltételezett megoldásokkal. A szélső eseteket figyelmen kívül hagyják, ha kényelmetlenek. Minden munkát néhány kulcsember végez, így miközben elvileg mindannyian el vagyunk havazva, valójában néhányan túlterheltek, mások pedig folyton feladatot kénytelenek kérni. A kommunikáció borzalmas; akik problémákat vetettek fel, azokat kizárják a hívásokból és meetingekből, így nem tudják, mi történik, és nem tudnak érdemben hozzájárulni. A problémák és a javasolt megoldások ismeretét szigorúan titkosként kezelték, és a legtöbb ember elől elzárták.
- Önkényes határidők, amelyek teljesen elszakadtak az elvégzendő munkától.
A fejlesztőcsapat a végkimerülésig dolgozott, pluszmunkával, néha hétvégéken is, hogy megoldást hozzon létre. A kudarc nem az elköteleződésünk vagy a technikai képességeink hiányán múlt.
Hogyan védekezhetünk az ellen, hogy minket hibáztassanak ezért a kudarcért? Azon gondolkodunk, hogy közösen kérünk egy megbeszélést az ügyvezető igazgatóval, hogy elmondjuk az aggályainkat. Jó ötlet ez? Mi lenne a legjobb módja egy ilyen megbeszélésnek?
Original Stack Exchange question · author: user1450877 · The Workplace, q131404 · CC BY-SA.
I'm part of an internal software development team at a retail business. We're currently working on a major project and in all likelihood it's going to fail. It's pretty much over at this point.
Over the last two years this will be the second high profile failure the team has had, not only failure in terms of failing to delivery what was asked but in terms of delivering anything of value at all. We haven't done anything else in that time.
Several members of the development team have found out from various people around the business that the team's manager, who has only been a development manager for these past two years, is now blaming this failure on the development team to the rest of the management, including the managing director.
This is a complete mischaracterization of why this and previous projects have failed. The reasons for failure have all been due to management. These are a list of reasons that I think caused the failure of projects.
- Business systems have been chosen by management with no thought of how/if we can integrate with them. They do not suit how the business operates and do not fit our current workflows. The rest of the business is unwilling to change workflow to fit the new systems.
- All advice from the team is ignored by the development manger. Every single senior member of the team has said from the moment the project started that it was completely unfeasible, there was simply not a technical solution that we could have implemented that would have solved the limitations of the chosen platform and enabled the business to operate as it wanted. Not only were advice and warnings ignored but were actively persecuted; people that raised warnings were punished.
- All warnings were never surfaced beyond our team. No other member of the management team know about the serious short comings of the project. There is zero transparency in our team. Things are reported externally as being okay and on schedule despite us internally knowing for weeks that things are never going to work. External departments only know a few days in advance of missed deadlines despite us being able to warn them well in advance.
- Project and team management is dysfunctional and outright incompetent. Tasks are vague and unspecified. Critical decisions that are needed are not taken until the last minute, which creates additional work and serious problems with existing assumed solutions. Edge cases are ignored when inconvenient. All work is done by a few core team members, so while we are all supposed to be busy, it's a situation where a few are busy and others have to keep asking for stuff to do. Communication is terrible; people that have raised problems are excluded from calls and meetings so they don't know what's going on and can't contribute productively. Knowledge of the problems and proposed solutions has been treated as top secret and kept from most people.
- Arbitrary deadlines that are completely unmoored from the work that needs to be done.
The development team have been working to breaking point, working extra including some weekends, to try to create a solution. The failure is not due to our lack of commitment or technical ability.
How can we counter being blamed for this failure? We are thinking about collectively asking for a meeting with the managing director to put across our concerns. Is this a good idea? What would be the best way to approach a meeting like that?
A közösség legjobbnak ítélt válasza (10 szavazat)
Szerző: user35316 · CC BY-SA
„Good managers know that blame always belongs to leadership; bad managers try to shift blame away from themselves. … Your manager's behavior is unimportant, your upper management's reaction to his behavior is what is important."
Lényeg (magyarul): A hibáztató vezető viselkedése önmagában diagnózis: jó vezető tudja, hogy a kudarc végső felelőssége a vezetésé. A kulcskérdés nem az, mit csinál a vezetőd, hanem az, hogyan reagál rá a felsővezetés: ha egészséges, magától átlát rajta, és a csapatnak nem lesz baja; ha maga is hibáztató kultúrát visz, akkor a hely eleve rossz volt, és menni érdemes. Kiegészítő válasz (Malisbad, 1): ha mégis léptek, a fegyver a dokumentáció (ticket-rendszer, amit a vezető nem tud átírni) és az írásba foglalt, mindenki által aláírt közös panasz, kinevezett „szóvivő" nélkül, mert a láthatóan élenjárót példastatuálásból kirúghatják.
Valós forrás: „Manager blaming team for failure, how to counter” · szerző: user1450877 · Stack Exchange / The Workplace (q131404) · CC BY-SA · magyar fordítás, anonimizálva. Az eredeti poszt →