Що робити, якщо менеджер токсичний, і як конфлікти вирішують в українських ІТ-компаніях

💡 Усі статті, обговорення, новини про HR — в одному місці. Приєднуйтесь до HR спільноти!

Як діяти ІТ-спеціалістам, якщо виник конфлікт із менеджером? Що в роботі менеджерів айтівці й компанії вважають червоним прапорцем і за яких умов справа може дійти до звільнення? Чому не варто замовчувати конфліктні ситуації та до кого звертатися по допомогу? Про це ми поспілкувалися з представниками ІТ-компаній і самими айтівцями.

Червоні прапорці в роботі менеджера

Першою ознакою токсичності менеджера, яку назвали ІТ-спеціалісти у розмові з DOU, був емоційний тиск. Наприклад, коли менеджер влаштовує стрес-тести, щоб випробувати на стійкість команду. Також ІТ-фахівці проти зверхнього ставлення керівника, коли він грубо вказує на помилки та публічно сварить людину.

«Менеджер завжди має залишатися менеджером, навіть у позаробочий час. Я чув про ситуацію в іншій компанії, коли на тимбілдингу PM дозволив собі розслабитися і почав грубіянити підлеглим, погрожуючи звільненням. Це зовсім не професійно», — зазначив Павло Сомко, Middle .NET Developer у Lionwood.software.

🚩🚩🚩

ІТ-компанії, з якими розмовляла редакція DOU, порадили айтівцям звертати увагу на такі проблеми та ініціювати їхнє вирішення:

  • Відсутність розподілених зон відповідальності. Кожен член команди має розуміти, яка його роль та до кого він може звернутися по допомогу за потреби.
  • Авторитарна поведінка. Менеджер не може нав’язувати свою думку та змушувати підлеглих робити все лише за його вказівками. Водночас члени команди мають усвідомлювати значення для бізнесу кожного завдання та могти висловити власну позицію.
  • Відсутність фідбеку або його неконкретність. Кожен член команди має розуміти, наскільки ефективно він виконує свою роботу та в чому його помилки. Компанії поділилися, що для цього вони використовують фідбек-листи та зустрічі менеджера з командою, зокрема one-to-one. Якщо менеджер скасовує такі зустрічі або дає зворотний зв’язок на кшталт «ти все робиш неправильно», це — червоний прапорець.
  • Нереалістичні терміни. Якщо менеджер дає джуніору два тижні на виконання завдання, яке фахівець мідл-рівня зазвичай виконує за місяць, то він не розуміє можливостей людини, яку найняв. А це свідчить про його непрофесіоналізм.
  • Ігнорування потреб команди. Співробітники також мають давати менеджеру фідбек щодо роботи та ситуації в команді. Це може стосуватися і їхніх завдань, і непорозумінь у команді, і ментального стану когось із колег. Менеджер мусить не лише дбати про клієнта, а й відстоювати інтереси команди. І якщо ви звертаєтеся, наприклад, до PM із запитаннями чи проханнями, а той постійно відправляє вас до когось іншого або каже «самі розберетесь», на це варто звернути увагу.
  • Зацікавленість лише фінансовими показниками. Найперше менеджер має цікавитися якістю проєкту та роботою команди, а лише потім — числами. Він повинен заглиблюватися в продукт, а не говорити «нам потрібно підняти цей показник будь-яким шляхом». І в жодному разі не підіймати маржинальність проєкту через звільнення співробітників.
  • Знецінення особистого часу колег. Звісно, бувають інциденти, коли співробітників просять допомогти в позаробочий час, але це потрібно узгоджувати з колегами. Якщо менеджер телефонує в особистий час колегам та вимагає долучитися до робочих питань, це поганий тон.
  • Неякісний онбординг. Менеджер має бути зацікавленим у тому, щоб колега адаптувався в колективі та увійшов у робочий ритм. Він не повинен вимагати від новачка одразу швидко виконувати завдання. Також йому варто розуміти, що деякі люди повільніше адаптуються, але згодом виконують свою роботу ефективно. Те ж саме стосується і джуніорів: найм фахівців цього рівня передбачає, що їм виділять час для навчання. І якщо PM звільняє новачків за те, що вони не надто швидко адаптуються, це ще один червоний прапорець.
  • Нехтування ідеями співробітників. Це може призвести до втрати талановитих фахівців та можливості досягати кращих результатів. Щоб побудувати ефективну команду, необхідно створити атмосферу, де кожен може вільно висловлювати свої думки та знати, що його почують.

Які якості в менеджері хочуть бачити айтівці та компанії

Представники ІТ-компаній, з якими ми поспілкувалися, зазначають, що місія менеджера — дбати про те, щоб усі сторони бізнес-процесу були задоволеними. Це клієнт, розробники та власне компанія, у якій він працює. Для цього йому варто вирішувати будь-які непорозуміння ще тоді, коли вони тільки зароджуються. Щоб ситуація не переросла в публічну сварку.

«Ми вважаємо, що менеджер — це не управлінець і не бос, а партнер, лідер команди. І він має першим вирішувати конфліктні ситуації. В нашій організації People Management конкретно лежить на менеджері. Тому 99% непорозумінь закінчуються діалогом з ним», — розповідає Андрій Поддубний, Engineering Director в Innovecs.

Айтівці в розмові з DOU наголосили, що для них важливо, щоб менеджер ставився до членів команди як до рівних собі. Без зверхності, тиску та диктаторської поведінки. Також для них цінно, коли менеджер знаходить час для комунікації та спокійно вислуховує іншу думку, навіть якщо спочатку не погоджується з нею.

«Професійні конфлікти виникають регулярно, і це нормально. Тут важливо не наполягати на особистій „єдино правильній“ думці та вислухати опонента. При цьому можна ставити дзеркальні запитання на кшталт „чи правильно я розумію, що ти хочеш / пропонуєш...“.

Адже часом здається, що опонент говорить нісенітниці, але насправді обом сторонам — розробнику і менеджеру — бракує розуміння ситуації», — Володимир Яцевський, CEO LiveArt, Presale & Project Management Expert.

Айтівцям також важливо, щоб менеджер прислухався до професійної позиції членів команди. Наприклад, коли девелопер бачить підводні камені в коді та попереджає про баг, який може спричинити проблеми у майбутньому.

Що робити, якщо виник конфлікт з менеджером

Читайте також: Як виявити токсичного колегу та що з ним робитиНепорозуміння з менеджером не обов’язково означає відкритий конфлікт. Іноді це емоційний дискомфорт або перешкоди в роботі з боку керівника. Фахівці ІТ-компаній радять ці питання також порушувати, адже для ефективної роботи важливо працювати в емоційно комфортних умовах.

ІТ-компанії час від часу проводять фідбек-сесії, де айтівці можуть дати зворотний зв’язок щодо роботи менеджера та розповісти про проблеми. Вони бувають у вигляді анкет або живого спілкування з HR та можуть відбуватися анонімно.

У деяких організаціях збір фідбеків проводять раз на квартал, в інших — щороку. Це залежить від того, наскільки великими є команди та як близько вони взаємодіють із менеджерами. Адже якщо в команді кілька осіб і вони щодня тісно співпрацюють з PM, то зазвичай більшість питань вирішуються відразу. І сам менеджер може легше оцінити ефективність взаємодії з колегами.

Після збору фідбеків HR-команда призначає зустрічі з розробниками та менеджерами, щоб допомогти розв’язати непорозуміння між ними. За потреби — залучає C-level Management.

Проте фахівці з ІТ-компаній радять не чекати фідбек-сесії, якщо виник конфлікт, а порушити це питання якомога швидше і для початку поговорити зі своїм менеджером сам на сам. А якщо все ж не вдається вирішити конфлікт, звертатися до HR. Також важливо зважати на те, що деякі менеджери є новачками у своїй справі й вони ще в процесі навчання. Тому прямий фідбек може бути цінним для них.

«Ми помічаємо, що найчастіше конфлікти виникають через недостатню комунікацію або нечітко сформульовані очікування від людини. Тому під час робочих непорозумінь передусім запитуємо менеджера, чи пояснив він колезі, якого результату чекає від нього. А чітко поставлене завдання — це спосіб уникнути конфліктів у майбутньому. Для цього можна проводити синки, використовувати спеціальні форми», — розповідає Дарина Кузьмик, Talent & Culture Lead у Railsware.

Павло Сомко, Middle .NET Developer у Lionwood.software, задля уникнення конфліктів радить від самого початку бути чесним з менеджером та відкрито комунікувати про проблеми, що виникають у роботі

«У мене були колеги, які хвилювалися за свій перформанс, через що на мітингах з менеджером перебільшували свої результати. А потім наздоганяли в неробочий час. Але іноді складалося так, що вони все ж не встигали завершити завдання вчасно. І тоді вже справді виникав конфлікт, адже в менеджера були зовсім інші очікування до результатів роботи».

Андрій Поддубний, Engineering Director в Innovecs, радить вирішувати конфлікт із мінімальною залученістю колег, щоб уникнути його ескалації.

«Зі свого досвіду можу сказати, що найефективніше конфлікти вирішуються саме всередині команди. Я як Engineering Director можу взяти на себе роль арбітра між менеджером і девелопером. Але важливо, щоб вони зустрілись та обговорили проблему. А якщо потрібно, запросити на цю розмову незалежну сторону як медіатора».

ІТ-фахівці радять під час конфлікту обом сторонам уникати зайвих емоцій у розмові, адже це може лише погіршити ситуацію.

«Коли я був розробником, у мене виникали непорозуміння з менеджером у період, коли я переходив з Front-end у Back-end. Тоді були завдання, які я виконувати не хотів. Добре, що мій PM мав холодну голову і спокійно пояснював важливість цих завдань або пропонував альтернативу.

Під час непорозумінь важливо „вимикати“ емоції, бо вони з великою ймовірністю лише нашкодять. Так конфлікт може перейти з професійного в особистий, і його буде вже важче вирішити», — додає Володимир Яцевський, CEO LiveArt, Presale & Project Management Expert.

«На мене свого часу дуже вплинула фраза „Люди не проти тебе, вони за себе“. Набагато легше реагувати та розвʼязувати конфлікти на роботі, якщо одразу усвідомлюєш свою емоційну реакцію та розумієш, що ні в кого немає мети „нападати“.

Більшість конфліктів — це справді просто різне бачення ролей у команді, продуктивності та підходів до роботи або лідерства. Звісно, всі ми живі люди, й іноді стаються досить емоційні розмови. Але дуже важливо після цього перепросити за бурхливу реакцію та ще раз обговорити питання конструктивно», — розповідає Ольга Гром, Delivery Manager у Master of Code Global.

План вирішення конфлікту

Юлія Грущинська, Global HR Business Partner у Ciklum, радить такі кроки для порозуміння з керівником:

  • Зрозумійте суть конфлікту та цілі, яких ви хочете досягти під час його вирішення. Це професійне чи особисте? Ви хочете досягти компромісу чи почути вибачення?
  • Виберіть час і місце для розмови, не намагайтеся спіймати керівника між зустрічами чи під час виконання важливого завдання. Попросіть виділити окремий час і виберіть місце, яке підійде вам обом. Підготуйте список запитань та аргументів, які ви хочете використати.
  • Під час розмови будьте ввічливими, але наполегливими. Не намагайтеся переходити на особисте, не ображайте, розмовляйте з повагою. Наприклад, замість фрази штибу «Ти постійно нехтуєш розкладом» краще скажіть: «Мене засмучує, коли ти змінюєш дедлайни, не порадившись зі мною».
  • Знайдіть вирішення питання, яке буде підходити вам обом. Головне — не визначити, хто винен і чий аргумент кращий, а поліпшити робочі стосунки й налагодити здорове та екологічне спілкування. Зосередьтеся на спільних цілях та ідеях, попросіть про зворотний зв’язок і пропозиції, будьте відкритими до конструктивної критики та компромісу.
  • Стежте за виконанням спільного плану. Повідомляйте про ваш прогрес. Оцініть вплив конфлікту на вашу продуктивність, поведінку вашого керівника та ваші власні очікування після вирішення непорозуміння. Якщо конфлікт не вичерпано, подумайте, чи потрібна вам допомога незалежної третьої сторони.

Як діяти, якщо складно говорити прямо

Буває, що після особистої розмови з менеджером конфлікт не вичерпується. Або ж виникають складні ситуації, коли конфлікт переходить особисті межі чи стосується етичних норм. У таких випадках ІТ-компанії радять айтівцям звертатися до HR, лінійного менеджера або іншого колеги, який відповідає за їхній розвиток у компанії.

«Ми в компанії нещодавно в тестовому режимі запустили онлайн-ресурс, де будь-який співробітник може подати скаргу та описати проблемну ситуацію. Наприклад, він відчуває емоційну небезпеку, був дискримінований або має інший конфлікт з менеджером. Ми залучаємо HR та Compliance-команду і залежно від складності ситуації вирішуємо, що робити далі.

Ми не ставимо обмеження, на які саме ситуації у взаєминах з менеджером людина може поскаржитися через цей ресурс. Якщо для неї це найкращий спосіб повідомити про проблему, то нехай вона це зробить і не замовчує. А відповідальна команда вже вирішить, як діяти з цією скаргою», — розповідає Вероніка Шеіна, HR Business Partner у Sigma Software.

Усі представники опитаних ІТ-компаній розповіли, що в них також є можливість повідомити про конфлікт анонімно. У такому разі HR або інший відповідальний співробітник не розголошує імені та деталей ситуації.

«Щоб фахівець не втрачав довіру до компанії, після його звернення HR може поспілкуватися з менеджером, не розголошуючи деталі. Наприклад, запитати, які в нього стосунки з командою та окремими її членами. Якщо менеджер не каже прямо про конфлікт із цим колегою, ми проводимо опитування в колективі. І якщо додаються інші скарги, то проводимо аналітику.

Коли вже маємо дані, даємо фідбек зі статистикою менеджеру, проводимо розмову з ним та командою. Це може бути налаштовано так, що HR спілкується з командами, а Head of HR розмовляє з менеджерами та C-level.

Така схема працює, коли в команді понад 10 співробітників. А якщо колектив маленький, працювати з анонімними зверненнями складніше. Адже керівник може легко з’ясувати, хто що сказав. У такому разі ми можемо порадити колезі взяти участь у майстеркласі, де розглядатимуть аналогічний кейс. Або якщо HR має гарні стосунки з менеджером, то може абстрактно обговорити з ним проблему. Запитати його експертну думку, подискутувати в процесі розмови, запропонувати альтернативну думку», — зазначає Марія Присяжна, HR Adviser в Yo-Da Wallet.

Фахівці вважають, що важливо, щоб у компанії була людина або навіть кілька людей, яким айтівець може відкрито розповісти про свій конфлікт з менеджером. Це допоможе йому почуватися в безпеці та мати довіру до колективу.

На думку айтівців, виносити конфлікт за межі колективу також варто тоді, коли він може нашкодити бізнесу. Якщо це не дрібні завдання, а те, що може негативно вплинути на реліз або принести збитки, а менеджер ігнорує це питання, тоді варто говорити з вищим керівництвом.

Також розробники поділилися, що для них є критичною ситуація, коли менеджер звинувачує одну людину в зафейленому релізі. Тоді вони радять звертатися до HR. Адже це може бути великим емоційним тиском для співробітника і негативно вплинути на його подальшу роботу в компанії.

Як діяти, коли виникає конфлікт зі стороною замовника

Планом дій у випадку непорозумінь між командою та менеджером з боку замовника або навпаки поділилася Лариса Баришева, Brand & Communication Specialist, ex Head of HR Communications.

Спершу відповідальні фахівці з’ясовують масштаби ситуації: чи виходить конфлікт за межі однієї команди, скільки він триває, проблема одноразова чи повторювана. Важливо дізнатися, чи був попередній досвід у компанії та з боку замовника з аналогічними кейсами. Далі — оцінюють об’єктивність аргументів обох сторін: чи не спотворена криза через емоції, якою є суть конфлікту.

План вирішення залежить від характеру непорозуміння. Якщо це був миттєвий конфлікт, співробітник може вирішити його за планом «стосунки — інформація — майбутнє».

Розгляньмо на прикладі. Уявімо, що під час зустрічі колега з боку замовника каже: «Ви ставите під сумнів мою експертність». Цю ситуацію варто вирішувати відразу. Для налагодження стосунків можна використати фразу «Я не мав цього на меті, я дуже поважаю тебе і твою роботу» та «Я також дратуюся, коли в моїй експертності сумніваються». Далі додаємо елемент інформації: «Імовірно, я не так зрозумів, що ти мав на увазі, і тому не дуже коректно висловився». І переходимо до майбутнього: «Будь ласка, пройдімося ще раз по тому, що ти розповідав, та сплануймо подальші дії».

Якщо конфлікт глибший, як-от непорозуміння в завданнях, різні очікування, культурні відмінності, потрібно визначити його причини. У такому разі фахівці збирають інформацію та залучають колег та замовника. Під час обговорення мають обов’язково бути присутні всі причетні до конфлікту, також можна запросити авторитетну для обох сторін людину, наприклад спеціаліста високої ланки.

Ще до зустрічі зі стороною замовника команді варто описати конфлікт та відкинути емоції й інтерпретації, залишивши лише факти. Гарною ідеєю буде підготувати кілька варіантів вирішення конфлікту до перемовин. На зустрічі важливо проговорити спільні цілі, мету проєкту та важливість для нього окремих завдань. Формулюємо план дій з чіткими термінами, відповідальними особами та бажаними результатами. І додаємо механізми моніторингу та плануємо зворотний зв’язок між колегами з обох сторін.

Окрім того, під час зустрічі можна посилатися на корпоративну культури чи внутрішні інструкції компанії (наприклад, щодо міжкультурної комунікації). Так ви зможете наводити чіткі аргументи щодо своїх дій.

Чи готові компанії звільнити менеджера через скарги

ІТ-компанії поділилися, що звільнення фахівця — це крайній крок у конфліктних ситуаціях. І зазвичай його прагнуть уникнути. Проте якщо йдеться про грубі порушення правил та ігнорування цінностей компанії, звільнення все ж бувають.

«У випадках, коли команда сигналізує, що їй складно працювати з менеджером, у нас є Talent Business Partner (TBP). Це спеціалісти, які моніторять загальну атмосферу в команді: збирають прямі відгуки спеціалістів і спеціалісток та проводять періодичні опитування. Так конфліктні ситуації вдається залагоджувати завчасно, через зворотний зв’язок від ТВР та безпосереднього керівника менеджера.

Якщо ситуація не стосується порушення внутрішніх правил компанії, менеджер дотримується її цінностей та працює в інтересах бізнесу, ми допомагаємо залагодити непорозуміння всередині команди або ж ротуємо його на інший проєкт, де він зможе краще проявити свої сильні сторони. А для команди шукаємо іншого керівника, який буде кращим вибором саме для цих людей і цього проєкту», — розповідає Роман Гапачило, VP, Talent Management в Intellias.

«Завжди варто зважати на те, наскільки менеджер є цінним для компанії. Якщо він продуктивний і добре працює зі стороною клієнта, можна створити „прозорий бар’єр“. Тобто залишити цю людину працювати з фінансовими показниками та вести комунікацію верхнього рівня, а для роботи з командою залучити проєкт-координатора», — радить Андрій Поддубний, Engineering Director в Innovecs.

Якщо ж ідеться про грубе порушення етичних норм, компанії не готові надалі працювати з такою людиною, навіть якщо вона була продуктивною в роботі.

«Чого ми не пробачаємо в компанії, то це гарасменту. У нас є політика щодо цього питання, і подати скаргу можна без залучення зайвих людей. Працівник має звернутися до конкретного фахівця з нашої команди, а ми далі вже проводимо розслідування. На умовах анонімності, звісно. Якщо факт гарасменту підтверджується — це підстава для звільнення одним днем», — розповідає Дарина Кузьмик, Talent & Culture Lead у Railsware.

Чому важливо говорити про конфлікти

Іноді айтівці не говорять про свої непорозуміння з менеджерами через страх, що ставлення до них може погіршитися або ж їх узагалі звільнять. Проте таке замовчування не є здоровим ні для самого фахівця, ні для компанії.

«Якщо співробітник буде приховувати свій конфлікт з керівником, він точно не змінить ситуацію на краще. Він втратить відчуття залученості та бажання розвиватися у компанії. Відповідно, погіршиться й перформанс. Тому важливо поділитися своєю проблемою з тією людиною в компанії, якій ти довіряєш.

Уявімо, що співробітника все-таки звільнили через його негативний фідбек щодо керівника. З погляду фінансової стабільності це погано. Але якщо компанія не допомагає працівнику розв’язати його проблему, то це не те місце, де він може реалізуватися. Тож у будь-якому разі не варто терпіти погане ставлення та дискомфорт на роботі. Потрібно використовувати інструменти, які пропонує компанія для обговорення подібних кейсів», — радить Вероніка Шеіна, HR Business Partner у Sigma Software.

Роман Гапачило розповідає, що атмосфера, у якій співробітник боїться розповідати про свої непорозуміння з керівництвом, може нашкодити й самій компанії.

«Якщо працівник не може вільно висловити свою думку в колективі, то компанії буде складно конкурувати на ринку. Адже якщо в людини є страх говорити щось про свого менеджера, то вона буде боятися і сказати альтернативну думку клієнту. Так компанія втрачає потенціал співробітників, а відповідно, і потенціал для інновацій.

Коли працівники не почуваються вільно, вони не будуть пропонувати нові ідеї, а отже, і приносити свою цінність компанії. В такому випадку компанія не зможе зростати та залучати нових клієнтів. Адже бізнес, що зростає, має бути відкритим. Коли люди почуваються захищеними, вони працюють ефективніше».


За участь у підготовці матеріалу також дякуємо Дмитру Вакуленку, Conversational Frontend Engineer у Master of Code Global, Ользі Дмитрук, HRD в JatApp, та Маргариті Кузнецовій, Team Lead HR в appflame.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось9
До обраногоВ обраному4
LinkedIn



71 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Менеджер має мати спеціальну освіту, без цього він приречений на маніпулятивну поведінку та зайву емоційність. Можливо, іноді замість освіти може бути хороший досвід, але це не точно.

Менеджеры, особенно проектные, самые бесполезные а зачастую и вредоносные роли в ИТ проектах.

Фахівці вважають, що важливо, щоб у компанії була людина або навіть кілька людей, яким айтівець може відкрито розповісти про свій конфлікт з менеджером. Це допоможе йому почуватися в безпеці та мати довіру до колективу.

цікаво що це за фахівці, є враження, що статтю писали без досвіду в ІТ.
Ревью 360 чи просто збір фідбеку по кожному має бути налагодженим процесом. З розумінням критеріїв і наслідків.
Якщо в компанії роблять просто роль для якоїсь людини, яка ні нащо не впливає, зато з якою можно поговорити, що це дає, чим це відрізняться від того, що хтось поговорив з друзями після роботи? Про формування довіри тут взагалі не буде мови.

Прочитайте Тома Демарко, є такий сенс. Більшість суттєвих конфліктів можна вирішити тільки за допомогою посередника. Іноді просто поговорити — тобто виказати свої претензії ротом, це вже вирішення 99% проблем. Звісно є купа конфліктів які мають лише силове вирішення, тобто задіюють владу, йдуть з роботи, б’ють морду і т.п. Якщо до вас докапались гопники на вулиці — крім дати в пику та відправити в нокаут або дати деру, нема там ніякого механізму вирішення конфлікту. На роботі бувають конфлікти обох типів, які є сенс вирішувати і які нема.

Я кажу про системність і процеси, ви кажете те що 99% проблем вирішиться просто сказав щось комусь, можна спитати звідки ви берете статистику в 99%?

В більшості галер ніхто і ніколи не питає ніяких фідбеків про ПМа. Єдине що може врятувати умовного ліда чи сіньора в такій ситуаціі, якщо заздалегідь була налагоджена тісна комунікація з ДД і вище, а також збір пруфів і прикладів некомпетентності ПМа. Та навіть це не факт що допоможе і скоріше за все буде важко, бо прохавані ПМи ні за що не відповідають, а тільки делегують. Тому швидше, простіше і ефективніше міняти проект чи галеру.

Тому вони й галери (а не просунуті компанії), що там не побудовані елементаріші процеси :-)

В Фейсбуку проводять Performance Management не лише для оцінки себе, але й своїх колег і свого менеджера.

О памятаю на одній з галер таке проводили і HRи сказали що це анонімно, але насправді всі знали що це не анонімно і якщо ти напишеш правду то прийдуть в першу чергу за тобою. Моя перша і остання галера :)

Цікаво, що менеджер зазвичай має володіти навичками Conflict Resolutions. Тобто він відповідальний за конфлікт менеджмент. Особливо якщо ми говоримо про Ліда напрямку. За 2 квартали достатньо подивитись на прогрес в комунікації.

Зі сторони команди: якщо твій мікро-менеджер прогресує — з цим можна працювати. Є 10 пунктів, як покращити взаємодію з мікро менеджментом.

І там 11 пункт — про те, що треба змінити проєкт та/чи команду.

Conflict Management як дисципліна має вивчатися в наших школах та університетах, як це відбувається в інших розвинутих країнах. Тоді це стане загальною практикою і буде використовуватися всіма учасниками процесу, а не лише поодинокими менеджерами. Життя стане кращим для всіх.

як це відбувається в інших розвинутих країнах.

Ми вже помітили як це відбувається. Віддати жертву нападнику.

Хто і кого віддав? Звідки цей фаталізм?

Наш ПМ-італієць настільки неконфліктний, що навіть не взмозі відстояти інтереси команди перед іншими командами))

А які інтереси команди йому треба відстоювати — у вас там бійка за їжу, чи що? :-)

У нас є паралельні проєкти, від яких залежить наш. Бувають ситуації, коли нам щось від них треба (наприклад, імплементація фічі в спільному модулі, але це їх репо, і розробка на їх стороні), а їм пофіг. Буває, що вони отримують якісь бізнес-вимоги (які стануть в нагоді і нам), але з нами не діляться. Немає в нього якоїсь наполегливості — когось впевнено попросити щось для нас зробити.

Та не вирішують конфлікти. Просто звільняють DevOps і беруть наступного і лишають того ж самого тех ліда, який власне і є токсіком і мудаком. І потім вся ця історія повторюється знову. )

Як це зі сторони виглядає. Є техлід тобто кваліфікований ну думку керівника спеціаліст, така собі персона якій цей керівник делегував повноваження перевіряти технічну якість проекту. І цей спеціаліст — напевно каже комусь з виконавців, що йому щось не подобається у якихось питаннях не обов’язково він насправді правий, запросто виконавець може навести вагомі факти та аргументи на користь своєї думки і доказати свою правоту.
А у відповідь від виконавця — «то козел та токсик». Так це себе і топити в такій ситуації конфлікту інтересів. Це якраз той хто не виконує розпорядження техліда в даній ситуації виглядає як криво, при чому запросто саме токсичним — тобто пасивно агресує і має претензії іншого характеру.
А так-то воно так, то техліда можуть теж бути питання — якщо він просто бюрократ який каже ні без аргументації і грає в політику.

Ну, навіть якщо з аргументаціями каже, то це не сильно допомагає, бо доколупатись можна завжди до будь-чого при бажаніі. Наприклад, чому в тебе в коментах в git акроніми написані малими буквами, а не великими, або чому ти назвав цю варіейблу так, а не інакше, ну і т.д. Тобто такі дрібязкові речі ні на шо не впливають, але людина любить позайобувати тіму своїм педантизмом, від якого уже просто морально нудить і тіпає, коли ця людина пише тобі в слак.

Буває таке, тут зазвичай це щось по типу «дергає за косички» — хоче про щось з вами поговорити, та шукає привід. А може і просто шукає рапорт, а ви при цьому думаєте що саботує, ваш перформанс. Там діє — спитати пораду, «де прочитати про классний кодстайл».
Навмисно чи не навмисно саботують по іншому. Спочатку зникають на бознаскільки і цим блокують роботу, потім з’являються за день до дедлайну і викатують по 50+ зауважень, більша частина з яких — «в тебе кома не того кольору» це коли дої...тись треба. Коли про не навмисно — йдуть з’ясовувати вимоги вже на етапі ревью. І замість закрити якусь таску там йде коло переробок, переглядів і т.д. Будь якого PM-а така ситуація реально бісить, це ламає усі плани, графіки та зобов’язання. Навмисні саботажники про це чудово знають.

Коли переходиш на особистості, варто враховувати, що твої публічні образи може прочитати той самий тех лід.

Маю сказати лише одне щодо

беруть наступного

Раптово, з тим DevOps, якого найняли після тебе, в мене не було майже жодного питання (систематично так точно) ані щодо якості коду, ані щодо оформлення commit messages, та й взагалі технічний рівень відрізнявся дуже відчутно і, на жаль, не на твою користь.

Тому, можливо, справа не в токсичності, а в тому, що є різні компанії з різною планкою вимог до якості та ретельності виконаної роботи?

Наприклад, в компанії, де я працюю зараз, мене так само ревʼювлять (попри те, що архітектор, а архітектори тут майже окрема «каста»). I, так, цілком бувають коментарі щодо речей, які могли б здатися «незначними дрібницями». Але — якість, вона якість у всьому, і в першу чергу у дрібницях.

Чи всім підходить такий стиль роботи? Звісно, що ні. Певен, є повно компаній, де цього не вимагають. Тому, якби ти сказав «не спрацювалися, не зійшлися в стилях роботи» — я б з цим цілком погодився. Але до чого тут токсичність (яка, взагалі-то, зовсім про інше)?

Ну, хоч хтось вам зміг догодити.) Але бачу, що і там були зауваження, в принципі — очікувано.
Щодо якості проекту: звучить досить сумнівно. Цікаво, ви все ще використовуєте мої старі «неякісні» костилі в вашому «якісному» проекті?)

Досить багато чого було суттєво перероблено; власне, цим новий DevOps займався перші кілька тижнів після онбордингу.

Але, якісь речі з розряду некритичних певно могли залишити «як є» суто з міркувань обмежень по строках та бюджету.

Лол, так це ти перейшов на особистості. Явний токсік.

Я цілком розумію бажання «песочіти» керівництво та, при цьому, бажано — щоб за це нічого не було )

Але ж для цього є дуже простий шлях — робить це під анонімним акаунтом. І, тоді, взагалі ніяких проблем — на якомусь абстрактному проекті абстрактний керівник... (далі купа хейту та лайливих слів :) ). Ні, ну, можливо, якісь дуже чутливі особистості підуть після цього «вираховувати по айпі», якщо впізнають в описі себе, але то вже скоріш з розряду міфів та легенд.

Зовсім інша справа — коли робиш таке під реальним імʼям. Зовсім не тому, що «знайдуть та покарають». А тому, що, принаймні для певної кількості людей це однозначно вказує на те, про кого саме йде мова, і конфлікт виноситься в публічну площину. А, в такому разі, «відповідач» вже цілком має моральне право також публічно викласти свій погляд на ситуацію. Так це працює в дорослому світі.

Ну камон. Просто нащо опускатись до його рівня.

Ви вже визначіться за кого ви) Бо шось геть різне пишете. То «явний токсік», то «не будь як він». Камон)

Ні, ну це взагалі була б клініка, якби реєструвати анонімний акк, аби лише написати коментар.) Навіть не спеціально про тебе і не про компанію, що, власне, не було ціллю, а лише щоб тут поділитись своїми думками і неприємним досвідом, не вказуючи конкретних даних та осіб. Інші он нижче пишуть подібне і зовсім не з аконімних акаунтів, але щось їхні менеджери зовсім не спішать їм відповідати аналогічно тобі. Хоча, теж могли б, при бажанні. ;) Чи ж може просто не всі вони читають цей форум? Вху новз. :D

Різниця між твоїм коментарем та тими коментарями, на які ти посилаєшся, полягає в тому, что у авторів тих коментарів вистачає витримки та виховання не переходити на особисті образи та не називати людей «токсиками» та «мудаками».

Для мене дані епітети таки необхідні були для визначенея тієї ситуації в якій опинився я і мій попередник — інший DevOps, якого теж, до речі, звільнили, бо «ви не спрацювались». Не вказавши їх, дехто міг би й не зрозуміти суті проблеми. Але тут з’явився дехто і «допоміг» своїм «вдалим виступом». Що ж, нехай буде. )

Насправді, ніяких «особистих» образ не було — фраза була досить абстрактною, і як би Ви не відповіли на повідомлення і не зізналися на публіку, що мова була саме про Вас — ніхто б і не здогадався про кого це :-)

Взгляд со стороны:

начальном посте не было ни одного слова ни про компанию ни про иное.
Не было ничего такого как «персонаж А в компании Б делал или не делал». Ни фамилии ни компании. Ничего что могло бы говорить о некой ситуации в конкретной точке или времени.

А потом пришли Вы и решили на публичной площадке рассказать какой автор плохой работник и как он не соот. «высоким стандартам» организации.

лично мое оценочное суждение всего сказанного:
— ваше поведение сигнализирует о том, что с Вами и соот. структурой дел лучше не иметь НИКАКИХ.
Мало ли кто и что подумает завтра о слове, жесте или ином и мало ли что придумает чтобы «парешать со слишком умным»
Сегодня публично прямо обвинять в проф. некомпетентности а завтра что похуже придумаете потому что кому-то что-то показалось ....

А потом пришли Вы и решили на публичной площадке рассказать какой автор плохой работник

Хм, тобто цього не було:

і лишають того ж самого тех ліда, який власне і є токсіком і мудаком

Як на мене, все Dmytro Lapshyn правильно зробив.

Цікавим є той момент, що принаймні одне з тих слів є в назві теми, в якій ми всі тут зараз пишемо і розмова саме про це — токсичних менеджерів і нездатність компаній ставати на бік звичайних працівників при вирішенні в тімі конфліктних моментів. Тому назвавши людину токсичною я не вважаю це якоюсь особистою образою. Бо мабуть тоді і автору теми не треба було його тут взагалі використовувати, аби не давати приклад іншим, якщо даним словом не можна користуватися? Чи не так?) Чи не варто навіть було взагалі створювати цю тему? Бо як же можна віднести людину до класу токсичних, при цьому не використавши це слово? Може ви нам поясните? Чи вас бентежить саме не «токсичний» а те інше слово? Якщо ж замінити на одне з його потенціно можливих визначень в вікіпедії «неприємна людина» це щось змінить?)

Мене взагалі це не бентежить :) Навпаки, мене забавляє як у сніжинок палають дупці, як тільки їм починають відповідати у їх же стилі

З чого ви взагалі взяли, що у когось щось палає? Ми лише обмінялися думками з приводу того, що думаємо відносно один одного от і все. ;)

Як на мене, все Dmytro Lapshyn правильно зробив.

Так, зробити камінг-аут на публіку про те, що саме про нього йшла мова — це сильний вчинок :-)

В мене єдине питання: нащо це робити? Це ж ескалація ситуації і вона яскраво демонструє, що лід неспроможний контролювати себе. Ніякої персональної образи в його бік не прозвучало — лише вони двоє знають один про одного, для решти читачів ДОУ це лише абстрактне спілкування.

мій досвід покахує що конфлікти з ПМ не вирішуються, HR та старше керівництво стають на сторону ПМ, навіть якщо його рішення шкодять проекту. Тому, або міняти проект або міняти компанію.

навіть якщо його рішення шкодять проекту

А звідки ви про це знаєте ? Насправді вони можуть шкодити особисто вам, частіше за усе так воно і є. Там можуть бути і бізнес стратегія, де свідомо йдуть на те щоби «спалити ресурси» ну тобто культура 996 — а потім усі допобаченя. Такі інтереси проекту, якщо хтось здогадався або дізнався раніше часу — ну його раніше строку і виставлять на мороз (що в цілому fail fast раніше сядеш — раніше вийдеш). Кінцева мета будь якого підприємства в отриманні прибутку. І так світ повний відвертого бізнес лайна.
У PM-ів так само як і будь кого є своя кваліфікація. І так коли роблять сполучення, аля молода дівчина/хлопець з тільки но з ін’язу і дядечко техлід — це відоме джерело конфлікту, де фірма чи акаунт гарантовано втратить дядечка техліда. Так само два тімліда чи два менеджери на одному проекті. Постійні «тімбілдінги» тобто команда так і не сформувалась і т.п.

А звідки ви про це знаєте ?

бо я працював на цьому проекті.

У PM-ів так само як і будь кого є своя кваліфікація. І

ПМ був представлений як досвічений. При цьому замість того, щоб застваити працюювати «свого» БА скидав пройоби у вимогах на відповідальність команди.

А, ну і коли дійшло до керівництва то. попросли з проекту мене, хоча всі погоджувались, що моя. точка зору має підстави.

Це ж класіка — тримати команду максимально в зоні Junior та Middle, а сіньйорів відсувати подалі. А потім, якщо команда впоралася — то звісно молодець погонич, бо все класно спланував. Якщо з факап на факапі — то це винні джуни, у них досвіду немає і вони косячать на кожному кроці. Безпрограшна стратегія, якщо поєднати з мікроменеджментом і власноруч складаними репортами про роботу команди.

Такого не бачів. А в цілому керівництву зазвичай глибоко фіолетово з якої конкретно причини хтось постійно факапить. Просто міняють та і усе. Стосується будь якого найманого працівника, бізнес партнерів тощо.

Це системний підхід. Таке собі. Як результат, бізнес перетворюється на суцільну «текучку» з розумінням того, що компанія нікого не цінить.

Ну буває, в мене не так вже і давно теж таке було. Я толком не міг працювати з тим BA — бо як на мене рівень його кваліфікації саме як бізнес аналіста, дорівнював 0.0 і він мене усе більше і більше бісив, при цьому керівництво навісило генеральські еполети, я вже на силу тримався щоб не виказати обом усе, що я про них думаю. Що цікаво до того працював з іншим BA з того же самого акаунту і навпаки давно не мав справу з такими кваліфікованими людьми.
Та справа була в тому що саме в них був, вихід на клієнта і певна робоча репутація з цим клієнтом. В мене ніфіга не було, крім того я знаходився в країні в якій йде війна.
Тому так воно і є, перед тим як качати права — треба дивитись які в тебе можливості, і якщо ти в такий ситуації — то особисто винний, що опинився в такій ситуації, дозволив соєю діяльністю або бездіяльністю, щоб з тобою так трапилось.

Наприклад, коли відповідальність ПМа за провальне рішення доведена переписками і вказівками, але знайти інженера трохи легше, ніж знайти менеджера і тому ПМа не звільняють. Плюс, прохавані ПМи зав’язують на себе всі процеси таким чином, що їх звільнення банально заімпактить все, до чого людина була дотична.
Я знаю ситуацію, коли ПМа намагалися звільнити рік, і всеодно не змогли без імпакту на делівері.

Подивіться на зарплатні менеджерів і на кількість відгуків на вакансії. Насправді усе навпаки — в менеджмент як в нас так і на заході преться величезна купа людей. Будьмо відверті гуманітаріїв завжди більше за технарів, вивчення іноземної мови для людини природньо, навідміну від складних абстракцій та точних наук.
А навчитись будувати діаграму Ганта чи будувати сітьовий графік можна за два дні. Скласти екзамен на Srum Master за пару місяців і $700. Тобто поріг входу в рази менший ніж скажімо у Frontend не кажучи вже про : AI, Blockchain або 3-D графіку.
Хоча так само як і з програмістами, або продавцями, трейдерами, брокерами і т.д , між початківцем середнім рівнем і експертом прірва. Може і відносно легко написати Hello World і це зробить будь який студент. При цьому на тій самій технології спроектувати і створити крупну систему — вже треба досвід роботи в 5+ років, і не просто досвід — а купа професійних знань, гори прочитаних книг, тренінгів, конференцій і т.д.
Те саме з менеджментом — якщо людина щось навіть знає як робиться (а це дуже далеко не усі навіть гадку мають), це далеко не одне і те саме, що вона вміє це робити на практиці вірно. Але якщо вміє — то працювати з такими саме задоволення.
Щодо імпакту bus factor — то таке стосується просто усіх, а тим більше керівників. Навіть прибиральницю замінити вже буде чогось коштувати, просто може не сказати де шафа з речами на якомусь поверсі, де брати воду, де лежать ключі — а то і залишити їх вдома і т.п. І буде певного рівню геморой. З ІТ проектами — заміна керівника це величезний геморой.

як ПМ можу сказати, що нас дофіга і більше, бо знання і навички не настільки специфічні, як наприклад у інженерів, маркетологів чи бляха будь-кого. Тому ПМів багато, зп в 2 рази менша за девелоперів, як правило. Якщо токсичного ПМа не хочуть звільняти, а звільняють класного інженера, то тут тільки два варіанти
1. Налагоджені звʼязки ПМа з керівництвом. І тому він може просувати любу свою фігню
2. Або ПМ насправді не токсік, а інженер не святий. А хтось просто не бачить повної картини.

Та з точки зору проєкту, замінити ПМа вигідніше, ніж міняти гарний ресурс.

Згодний, зазвичай ПМи мають вибудований канал комунікації і репортингу напряму до топів, а інженери в це майже не залучені. Тому 100 повідомлень від ПМа важко переважити одним-двома репортами на ретроспективі, і керівництво приходить до інженера з запитаннями, маючи вже сформовану позицію і bias.
ПМи мають банально більше ресурсів на ведення конфліктів, це ж частина їхніх обов’язків у перемовинах. Тому не дивно, що здебільшого вони виграють конфлікти з інженерами.

Может быть потому, что у ПМа есть basic social skills.

І що? Є купа людей із excellent social skills які порушують ПДР, але це не робить їх правими.)

Зміна проекту або компанії, тільки так.

Це легкий шлях, але він «lose»-«lose».

Це шлях коли є повага до себе

Кожен знаходить самоповагу для себе в своєму: хтось бігає від проблеми як заєць, а хтось вирішує проблему :-)

Хтось ссить проти вітру, а хтось поважає свій час і віддає перевагу працювати з крутими менеджерами ;)

Для крутих спеціалістів менеджер не потрібний: сеньори знають, що робити і як робити. Але для джунів — так, це честь :-)

Проблема тільки в тому що багацько сіньйорів на наших галерах це по факту максимум джумідли, які впевнені що все знають і ніхто їм не потрібен.

Я про справжніх сеньорів.

А де луз для інженера? Тільки мотивація для чергового career move.

Луз це вимушене рішення йти з компанії не за своїм бажанням.

Іноді айтівці не говорять про свої непорозуміння з менеджерами через страх, що ставлення до них може погіршитися або ж їх узагалі звільнять.

Это штатная практика многих компаний и команд. Если ты говоришь о проблеме — ты и есть проблема со всеми вытекающими. И даже если сразу за «правдоискательство» человеку по голове не прилетит, то во внутренних документах все равно будет проставлено «не лоялен» и так далее

Это штатная проблема для авторитарной иерархической системы управления, где вопрос о проблемах разрешается поднимать только тем у кого есть соответствующие для этого полномочия. Остальное считается в такой системе — прямым нарушением субординации.
Внесения анализа проблем и предложений в систему управления т.е. систематическое улучшение коллективом методик и технологий собственной работы, это в общем одна из основ систем менеджмента.
Первую систему — т.е. по существу римский легион, нельзя назвать полностью не правильной. Когда вопрос идёт об унификации общих подходов и системе рекрутинга и обучения (муштра), эта система себя проявила очень эффективной в течении тысячелетий. Поставить «сильно умных на место» с их инициативами в такой системе командир обязан. Когда имеете дело с новичками часто это разумно, придумывать придумки будете только после демонстрации того что умеете выполнять штатно согласно утвержденной инструкции или устава, к тому же заслужите доверие командира. Тоесть обладаете подтвержденной квалификацией и обладаете исполнительностью. Полномочия на принятие решений только в порядке командной иерархии.
Не смотря на очень высокую эффективность иерархической системы управления во многих отраслях человеческой деятельности, во всех креативных областях она показала себя провальной. Вообще в промышленности и особенно в ИТ, где IBM пытались ее применят еще в 60-е годы прошлого столетия, для организации массового производства ПО.

Так і є. Але це в компаніях, так званих акваріумах, — великі компанії де рибки не відчувають своєї причетності до бізнесу та до результатів взагалі. Рибки живуть іншими категоріями — типу від зарплати до зарплати, бізнес це теж влаштовує бо менеджити велику машину не так просто — і якось воно працює. Іноді рибки переходять в малі компанії і влаштовують там такі самі порядки. Рибкам все рівно що еффективно а що ні — головне це вдовольнити якісь свої амбіції (показати хто головний), рибкам дуже боляче коли акваріум розбивається, вони інтуїтивно шукають інший акваріум з такими самими умовами.

Посередник, як варіант — коли вас не слухають може через третю особу можна буде прийти консенсусу. Бо може і так статись, з дуже великою долею вірогідності — що той менеджер до якого ви будете йти на співбесіду набере на телефон вашого поточного, щоб поцікавитись про вас. До якого рівня поглибиться конфлікт після цього можете здогадатись.

Як ви це собі бачите, тобто на джині рекрутер набере на телефон вашого поточного менеджера і це з

дуже великою долею вірогідності

?

Рекрутери дуже часто товаришують і спілкуються. Це не так дивно, фірм які займаються +/- тим самим не так вже і багато. Усі рекрутери великих галер одина з одною товаришують, бачились на усяких : евентах, хакатонах тощо. І так вони цей нетверкінг — як професіонали часто цінують більше ніж поточне місце роботи і роботодавця. Там куча фішок їх профессій типу баз кандидатів, хедхантінгу і т.п.
А також у менеджерів з найму є нетверкінг і він дуже вагомий насправді. Інша справа є їм діло чи нема, бо треба закрити вакансію бігом та сатафити ресурс, бо гроші замовник не заплатить чи конкуренти тиснуть контракта. Тоді — звісно, морочитись не будуть. Умовно треба мілд фронтендер — тех співбесіду проходе, якихось видимих лаж нема — нема різниці де він взявся, з ринку взявся.

Виглядає що ви не юзали джині

За кордоном ця практика більш розвинена — тут згодем. Деякі продуктові типу Оракла фідбеки, але теж від контактів кого ви самі вказали, тому часто і отримують умовно фейкові контакти.

Підписатись на коментарі