Вхід Реєстрація
Реклама
Ваше рекламне місце
Забронюйте цей слот без конкуренції на обраний період.
Купити рекламу →
Логотип телеграм спільноти - Вова і свідома компетентність
Додано 06 гру 2025

Вова і свідома компетентність

@good_design_manager
Кількість підписників: 1 132
Фото: 13
Відео: 17
Посилання: 80
Опис:
Як бути хорошим дизайн-менеджером, а не херовим. Канал для лідів, хедів, менеджерів, і тих хто хоче ними стати. Гайд як прокачатись в дизайн-менеджменті і лідерстві: https://safonov.us/guide

👥 Кількість підписників

1 132
Середній/День:: 0
Середній/Тиждень:: -2
Середній/Місяць:: -6

👁️ Середній перегляд на повідомлення

724
Середній/День:: 907
Середній/Тиждень:: 655
ERR: 63.96%

📊 Кількість повідомлень на день

0.2
Останній день: 0
Середнє за тиждень: 0
Середнє за день: 0.2

Історія зміни статуса

Офіційно не підтверджена 2025-12-06

Стіна

Статистика telegram каналу

Різниця достатньо проста.По-перше, CDO - це людина, яка працює на рівні C-level, і це значить, що компанія бачить дизайн як елемент стратегії. Зазвичай люди потрапляють на C-level тоді, коли компанія бачить функцію як стратегічний інструмент. Наприклад, туди потрапляє маркетинг або технології - тому що вони можуть давати якусь конкретну перевагу на маркеті. Тобто, це історія про роботу зі стратегією і вплив на неї.Дизайн потрапляє туди, наприклад, в моєму випадку (попередній експіріенс), бо фаундерам було чітко зрозуміло, що компанія хоче конкурувати за рахунок комунікацій, креативу, експіріенсу в цифрових продуктах. І в принципі це відбулося - дизайн став елементом стратегії.Плюс, з точки зору керування функцією. У монопродуктовій компанії наявність CDO, коли всього 30 людей, і з них 6 запихувати на C-level - це типу ту-мач. Але якщо ми говоримо про кілька продуктів, які ще, можливо, працюють на різних ринках і мають різні бренди, то цю функцію треба консолідувати. Знову ж таки, працювати з нею на стратегічному рівні: навіщо вона треба, які пріоритети, які задачі і так далі.Тобто, давай так: CDO - це людина, яка будує дизайн як одну зі стратегічних переваг компанії. За рахунок чого будується бренд, за рахунок чого будується комунікація, а взаємодія з цифровими продуктами виходить за рамки цифрового середовища - наприклад, у магазини. І в цьому велика відмінність.Для мене це дуже зрозумілий і чіткий меседж - коли та чи інша функція є на C-level, а коли ні.
#123. Як зробити спілкування на вантуванах більш персональнимЯкось на консультаційному дзвінку дизайн-менеджер запитав: "Як зробити спілкування з репортом більш персональним? Ми спілкуємось регулярно, але якось поверхово."Гарне питання. І дуже часте.Типова картина: ван-ту-ван відбувається щотижня. Говорите про задачі, трохи про вихідні, може про новини — і розходитесь. Нікому не незручно. А потім виявляється що в людини щось відбувається — і ви навіть не підозрювали.Ніби спілкувались. Але по суті — ні.Рівні спілкуванняGary Smalley виділив п'ять рівнів спілкування — ще в 70-х, але для робочих стосунків досі актуально:Ритуали або смолток — "привіт, як справи, як вихідні". Потрібні для початку, але поганий фінальний стан.Факти — обмін інформацією. "Задача не закрита", "є зустріч в п'ятницю". Безпечно, бо з фактами не посперечаєшся.Погляди — думки, оцінки, інтерпретації. Тут вже є ризик: можна підставитись, можна не погодитись.Почуття — що реально відбувається з людиною. Потрібна довіра і готовність бути чесними — з обох сторін.Відвертість — розмова про найглибше: страхи, цілі, сумніви, мрії.Більшість робочих стосунків зависають між першим і другим рівнем. Це безпечна зона — обидва не ризикують. І тому нічого справжнього не відбувається.Де це відчуваєтьсяВи говорите про задачі — і це нормально. Але якщо через рік ви досі не знаєте що реально мотивує людину, що її дратує, що вона хоче далі — це симптом.Часто проблема не в репорті. А в тому, що ви самі не виходите з безпечного простору першими. Якщо менеджер тримається в зоні фактів — люди зазвичай туди ж і лишаються.Шо з цим робитиЧасто в мене бувають дзвінки з репортами на яких ми взагалі не торкаємось задач. Тільки — шо робили на вихідних, які переживання допікають по життю, в яку гру грали, якісь історії. І це одні з найкорисніших дзвінків.Кілька речей, які допомагаютьГодинний формат. Не 30 хвилин — бо к 30 хвилинам тільки починається двіж. Якщо дуже зайняті — краще година раз на два тижні ніж пів години щотижня.Готуйтесь. Якщо між дзвінками щось прийшло в голову — занотуйте. Принесіть щось своє: спостереження, питання, рефлексію, книжку. Дзвінок де ви прийшли з порожніми руками дає відчуття шо людина вам не дуже цікава.Прибирайте телефон. Навіть вимкнений телефон в руках дає відчуття шо ви десь інде. Це помітно навіть на відео-дзвінках.Будьте справжніми. Ваші питання не повинні виглядати як анкета. Якщо людина вам реально цікава — це відчувається. Якщо ні — теж.Рухатись до глибшого спілкування можна тільки якщо ви самі відкриті першими. Не техніка, не формат. Просто справжній інтерес до людини.Де ви зараз з кожним репортом на цій шкалі?
#122. Хороший менеджер будує систему, а сильний — систему, яка розвиває себе самаБазовий рівень менеджменту — організувати систему так, щоб вона працювала. Команда зібрана, процеси запущені, задачі виконуються. Це вже непросто.Але є рівень далі.Наступний рівень — організувати систему так, щоб вона покращувала себе сама. Без постійного менеджерського поштовху.Як це виглядає на практиці:- команда проводить нормальні дизайн-критики без тебе- люди самі підсвічують проблеми в процесах — а не чекають поки помітить менеджер- фідбек-культура існує бо це норма, а не бо ти щоразу нагадуєш- команда сама помічає дизайн-борг і пропонує шо з ним робити- люди синхронізуються між собою, а не через тебе як роутерПростий тест: шо в команді покращилось само по собі за останній рік без твого прямого втручання?Це не значить, що після цього менеджер стає не потрібен, але є різниця між тим, коли системі для руху потрібен ти — і тим, коли вона рухається і без тебе.Тобто різниця не в тому, наскільки добре ти керуєш, а в тому, шо відбувається коли тебе немає.
#121. Що будувати першим у новій командіЯк будувати shared reality коли люди ще не навчились читати одне одногоКоли команда нова — або зовсім нова, або наполовину перетрясена — менеджер часто очікує від неї поведінки зрілої команди. Логічно: люди досвідчені, завдання зрозуміле, процеси є. І все одно шось не клеїться.Хтось каже шо цілі незрозумілі. Хтось шо не вистачає відчуття команди — є задачі, але немає відчуття шо ми разом. Мітинги є, але якісь порожні. Рішення приймаються повільніше ніж хотілось би. Кожен тягне своє.Це не ознака поганої команди. Це нормальна фаза.Нова команда — навіть з класних людей — це ще не команда в психологічному сенсі. Організаційно вона існує: є структура, є ролі, є загальний канал. Але shared reality ще немає. У кожного своя картина того, як тут прийнято думати, хто шо вирішує, шо важливо, а шо ні. Доки ці картини не почали перетинатись — команда і буде відчуватись не як команда, навіть якщо всі стараються.Важливо тут не переплутати. Дисфункційна команда — де є токсик, зіпсовані стосунки, хронічні конфлікти — це окрема проблема з іншими ліками. Нова команда яка ще не сформувалась — зовсім інший кейс.Тому на ранньому етапі задача менеджера — не налаштовувати процеси. А будувати цю спільну картину.Використовувати 1:1 не тільки для задач. Починати варто з безпеки. Коли люди просять "більше живого спілкування" — вони рідко мають на увазі корпоратив. Вони хочуть зрозуміти менеджера: як він думає, як реагує, де можна бути відвертим. Це перевірка безпеки. І поки вона не пройдена — всі наступні кроки будуть половинчастими.Переформатувати регулярні мітинги. Якщо зустріч можна замінити повідомленням — вона не будує команду. Вона просто синхронізує таски. Команда формується коли люди думають разом, сперечаються, дивляться на одну проблему з різних боків. Ознака шо це починає працювати — коли на мітингах з'являються незгоди. Не конфлікти, а незгоди. Люди почали довіряти достатньо шоб говорити відверто.Зробити "чому" видимим. Менеджер часто думає шо він пояснив ціль. Але насправді — оголосив результат. "Нам треба підняти конверсію на 15%" — це результат. Шо за ним стоїть? Чому саме 15%? Які варіанти розглядались? Де є простір для рішень команди, а де вже вирішено? Без цього кожен заповнює прогалини сам — і заповнює по-різному. Спільний контекст — це не слайд з цілями. Це розуміння розумового шляху, який привів до рішення. Та і якби люди розуміли всі пояснення — це був би другий світ.Будувати зв'язки між людьми, не тільки через менеджера. Якщо вся взаємодія йде через менеджера — він стає bottleneck, а команда не навчиться читати одне одного. Спільна робота, пар-розбори, крос-функціональні обговорення — все це прискорює формування shared reality.Не поспішати з оптимізацією. Нова команда ще не навчилась нормально комунікувати, а менеджер вже вводить KPI, матриці і правила. Спочатку — система взаємодії. Потім — все решта.Коротше, сильна команда — це не коли всі дружать. А коли люди достатньо розуміють і довіряють одне одному, шоб ефективно працювати в невизначеності. Менеджер будує це першим — систему взаємодії між людьми. Процеси, KPI і структури — потім.
#120. Трохи цифр з реального хайрингуЗакривав того тижня позицію сініор продакт дизайнера в команді, то подумав може колегам хайрінг-менеджерам буде цікаво порівняти цифри, а тим хто шукає — зрозуміти краще шо взагалі відбувається на одній конкретній вакансії.25 березня відкрили і запостили вакансію — 20 квітня був прийнятий офер (27 календарних днів, 19 робочих).197 → 1Подались 197 кандидатів. Я уважно передивився кожного особисто, шо б знизити вірогідність пропуску класних людей. Автоматичної системи відбору в нас нема, якщо що, і я думаю це добре.17 кандидатів я пропустив на етап до рекрутера. Трошки перегрузив я рекрутера звісно, але якось домовились.10 попали на "професійне інтервью" до мене.4 я пропустив на співбесіду до продакт-менеджера, шо б він подивився зі свого боку, і на людину яка піде до нього в команду.3 попали на останній етап до COO/HRD. Це в основному перевірка на культурно-мотиваційний фіт.Ну і зрозуміло 1 офер.Статистика по реджектам82 (42%) not enough experience — тобто я подивився сіві, портфель і тд, і це не дотягувало до потреб вакансії.56 (29%) irrelevant skills — це ті в кого досвіду достатньо в цілому, але він не підходить під мою вакансію. Наприклад, хардовий досвід в аутсорсі, або фінтеку/крипті, або чистий UX, або маркетинг-дизайн.18 (9%) not a fit — тут трошки специфічно вийшло — в основному сюди попали ті хто очевидно не знають українську мову на вільному рівні. Але також я додавав сюди тих хто подавався з якихось причин декілька разів підряд, шо б не заплутатись де оригінальна подача.16 (8%) not a cultural fit — сюди попали спеціалісти з гембли.8 (4%) position closed — в цей статус попали ті хто на будь-якому етапі вже не встиг на момент прийняття оферу фіналістом.6 (3%) salary expectations — це ті хто написав в очікуваннях більше чим був мій максимальний бюджет на цю позицію. Чесно кажучи, я очікував тут буде значно більше людей.4 (2%) job hopper — це ті в кого в сіві вказана купа позицій не більше ніж по півроку на кожній.Ще 4 людини попали в категорії overqualified або ми не змогли з ними зв'язатись.Висновки1. Як і завжди, більшість кандидатів відсіюється на етапі загального фіту по сіві і портфелю.2. 197 подач до одного оферу — це досить висока конкуренція, хоча я очікував шо буде значно більше. Я думаю це пов'язано з тим, що в Skylum в нас в основному україномовний ринок, який звісно менше світового.3. Як я і писав раніше, позиціонування важливе, і подаватись з нерелевантним досвідом — мало сенсу. Зі сторони кандидата це виглядає як "ну я думаю я розберусь в домені", а зі сторони хайрингу це "якщо це не зіркове сіві по іншим показникам, то я не готовий давати шанс людині розбиратися". Тобто конкуренція і так велика, точно будуть люди з більшим розумінням домену, хто зможе увірватись значно швидше.Ринок маленький, черга велика. Треба точити сіві і портфель під вакансію щоб підвищити шанси.
#119. Ніхто не виділить тобі час на редизайнБачив таке не раз: команда хоче зробити редизайн або нарешті нормально дослідити користувачів. Проходить квартал. Нічого не зроблено. Команда каже: нам не поставили в пріоритет, не виділили часу, нікому це не потрібно. Але справа не в часі і пріоритетах.І логіка начебто є: завжди є релізний цикл, завжди є гарячі задачі на вчора, забитий беклог. Редизайн — важливо, але потім, коли з'явиться вікно. Тільки вікна не буває.Ніхто не виділяє час на те чого не існуєНіхто ніколи свідомо не виділяє час на розмиту задачу. Беклог не зберігає наміри, він зберігає задачі. "Редизайн" і "user research" — це не задачі. Поки немає відповіді на "що конкретно хочемо змінити", "який ризик зменшуємо", "що дізнаємось і що далі з цим робимо" — це не потрапить у пріоритет. Ніколи.Ніхто в здоровому глузді не дасть недосвідченому дизайнеру експериментувати з складними мутними задачами. А досвідченому не треба давати, він сам візьме. Бо він на досвіді знає навіщо їх треба робити, заради якого результату, може їх декомпозувати. А недосвідченому треба спочатку піддивитись це в когось на практиці, або вчитись декомпозувати до мікроскопічних кроків.Безпечні задачіЄ пул задач на котрі простіше знайти мотивацію, і навіть не розуміючи шо з ними робити — пропхати їх в беклог правдами і не правдами.Дизайн-системна інфраструктура, аксесібіліті, якоюсь юзабіліті-двіжуха — задачі теж мутні, але за них є соціальне схвалення. Курси кажуть що це важливо. Спільноти обговорюють. В соцмережах лайкають. За них не осудять — вони виглядають правильно і "дизайнерськи". Є активність, є що показати на ревью.Але це не те шо потрібно продукту чи компанії саме зараз.Просто коли немає чіткого і зрозумілого напряму куди рухатись — люди рухаються туди де є відчуття зрозумілого результату і схвалення ззовні.Що робитиДосвідчений дизайнер не приходить з "хочу зробити редизайн". Він робить кроки самостійно, а потім приходить з конкретикою: "ось де ми втрачаємо користувачів, ось що хочу перевірити, ось що зроблю за два тижні і що ми з цього дізнаємось".Перед тим як ми зробили Documents X в Readdle, я прийшов до свого продакта і сказав "Я знаю як заредизайнити класно всю апку за місяць, а потім за 2-3 місяці максимум це задевелопити". А там ми ще й фічей потім накрутили топових.Перший результат — кредит довіри. Кредит довіри — левередж. Левередж — час і ресурс на більше.Коротше, ніхто не виділить тобі час на редизайн чи щось інше велике — доки це побажання, а не набір зрозумілих задач із зрозумілим очікуванним результатом.
#118. Чому перформанс-ревью частіше імпровізація ніж системаПро очікування які існують тільки в голові менеджера і що з цим робитиЩе одна з поширених проблем в менеджменті це формування і донесення очікувань від роботи.Людина приходить: "хочу більше грошей, я класно працюю".Менеджер: "ну так ми тебе і наймали шоб ти класно працював".Пауза. Людина: "окей, а шо мені тоді треба зробити шоб отримати підвищення?"— Треба перевищити очікування.— Які? Як?— Ну... зробити шось неймовірне.На цьому розмова зазвичай закінчується. Людина не знає шо запитати. Менеджер — шо відповісти."Відповідає очікуванням" — це не комплімент. Це підтвердження шо базова домовленість виконана. Людину найняли на посаду, вона робить шо на цій посаді треба. Клас, молодець. Це і є "відповідає". Не більше і не менше.Але де тоді межа між "відповідає" і "перевищує"? Хто її встановлює? Встановлює менеджер і межа досить субʼєктивна.І тут починаються питання. Чи сформував ти як менеджер собі розуміння шо таке "норма" до того як оцінювати. Чи уважно дивишся на роботу. Чи збираєш фідбек з інших сторін шоб не судити тільки зі свого кута.Найчастіше очікування або не сформульовані взагалі, або такі абстрактні шо їх не перевіриш, або з'являються постфактум — коли вже треба давати оцінку. Фактично — вони існують тільки в голові. Якщо їх не проговорили наперед — це не система оцінки, це імпровізація. І "перевищити очікування" тоді означає вгадати шо там у цій голові.Але є ще один рівень.Очікування менеджера теж не у вакуумі. Вони залежать від того шо керівництво вважає важливим, від культури компанії, від того шо взагалі помічається і цінується.Я бачив таке: менеджер щиро вважає шо дизайн — це красиво, естетично, доступно, за всіма гайдлайнами. І оцінює команду саме по цьому. А бізнес хоче конверсію, ретеншн, швидкість.В результаті дизайнер може системно "перевищувати очікування" свого менеджера і при цьому не створювати жодної цінності для компанії. Ну і навпаки теж буває — коли людина робить важливі речі, але "не відповідає" бо менеджер дивиться не туди.І ще один момент.Навіть якщо людина справді перевищує очікування — це ще не означає шо їй щось винні. В аутсорсі і агенціях вигідно вирощувати людей: ростуть скіли — ростуть рейти з клієнтів. В продуктових компаніях ця логіка не завжди працює — ROI інший. Бо платять не за зростання людини, а за зростання продукту. В аутсорсі продукт — це люди, а в продукті — ну ви поняли.Компанія платить не за зусилля і не за старання, а за вплив на результат.Коротше, якщо очікування не можна пояснити — їх не існує.
#117. Аналітика все ще тільки ритуалЧасто зтикаюсь з тим що дизайнери трохи агресивно просять аналітику, або пояснюють помилки чи проблеми тому що не дали аналітику.Але здебільшого я бачу що це робиться, бо так "треба". Проблема також в тому, що у більшості продуктів тієї аналітики особливо нема. А якщо навіть і є — дизайнери туди все одно не заходять.Аналітика стала ритуалом. Просять, бо навчили на курсах, хайп-статтях і постах. Але не навчили що з нею реально робити і як будувати на ній гіпотези чи збирати докази.Дизайнер має приймати рішення на основі даних — звучить розумно, але шо робити далі? Як заходити в Amplitude (чи не його, зараз купа систем), шо шукати, як читати маленькі цифри — цього, як правило, ніхто не показує. А якщо і показує — в загальних словах, без конкретики. А ще стат.значимість.В результаті три типові ситуації: - даних нема взагалі (більшість продуктів саме такі), - дані є але дизайнер не знає як туди дивитись,- доступи є але ніхто не заходить.І у всіх трьох — аналітика залишається темою розмов, а не роботи. Я думаю шо проблема тут не в доступах, а в навчанні і звичках. Якщо немає скілу — ти не робиш, якщо скіл є — робиш.Коли в команді немає культури роботи з даними, типова історія скинути це все на продакта: хай робить зводки, приносить дані. "Якщо мені не принесли цифри, то я не винен".Аналітика це не панацея, аналітика не скаже що робити. Далеко не завжди те шо вона є — вирішує всі проблеми. Мій меседж шо треба зупинитися і подумати, шо конкретно ви хочете отримати, коли пушите аналітику. Бо якщо нічого конкретно, то ви просто втрачаєте репутацію в очах команди, рекрутера, наймаючого менеджера.Аналітика це про те що відбувається. Рішення все одно ваше, його все одно доведеться приймати самому, і тільки аналітики не вистачить.Що дизайнерам реально треба від аналітикиНе “глибоке занурення”. Не “ідеальна дата”. І точно не “аналітика скаже нам, що робити”. Потрібен верхньорівневий sanity-check свої рішень. Мінімум, який швидко дає контекст:- базова воронка або ключова конверсія по сценарію, який ви чіпаєте- 1-2 зрізи (платформа/країна/сегмент — що у вас є)- просте “до/після” як орієнтир, а не як доказТипові граблі, які я бачу постійно1. “Я не лізу, поки не зрозумію все” — так можна не лізти взагалі. А потім чесно казати “аналітика складна”.2. Маленькі цифри і фальшиві висновки — 10 людей натиснули одне, 50 інше, і вже хочеться приймати рішення, бо відсотки то різні. Часто це не значить нічого. Просто шум, який виглядає переконливо.3. Очікування, що дані замінять прийняття рішень — не замінять. Доведеться все одно самим формулювати гіпотези і робити вибір.Як покращувати ситуацію в компанії1. Зробіть мінімальний едукейшн-івентОдин воркшоп на 60–90 хв. Показати: де дивитись базове, як читати 2–3 типові чарти, і що робити з малими числами. Повторювати періодично і в тому числі на онбордингу.2. Вшийте аналітику в постановку задачДодайте в бриф пункт “подивитись Amplitude”. І вимогу: 1–2 скріни або лінк на дашборд прямо в контекст задачі. Це мінімальний стандарт, який змушує реально зайти й подивитись, а не просто “попросити аналітику”.Аналітика не дасть вам відповідей, але допоможе прибрати частину фантазій. А клеріті, як правило, ніхто не приносить. Її доводиться забирати самому.
#116. Intent does not matterТипова сцена на ревью: людина чує фідбек — і щиро дивується. Вона ж так старалась. Вона ж хотіла як краще. Вона ж стільки думала над цим завданням, переживала, не спала. Звідки раптом негатив?Зсередини це виглядає абсолютно логічно. Але проблема в тому, що вона і менеджер/компанія дивляться на одну й ту саму ситуацію через зовсім різні шкали.Як ми оцінюємо себе- Я старався- Я хотів як краще- Я довго думав над цим- Хтось же мав спробувати→ Отже, я молодець.Як ми оцінюємо інших- Що вийшло?- Яка користь для команди або продукту?- Якщо результату немає значить спеціаліст "так собі"... Слабенький.Ніхто тут особливо не злий і не несправедливий. Штука в тому, що свої наміри ми знаємо — весь контекст, всі думки, всі переживання. А чужих намірів просто не видно. Видно тільки результат. Тому і оцінки різні.Звідси росте половина конфліктів в командах:- образи на ревью ("я ж так старався, чому не помічають?")- нерозуміння промоушнів ("я роблю більше за всіх, чому не підвищують?")- здивування зарплатам і бонусам- конфлікти дизайнер PM- конфлікти співробітник менеджерЯкось я грав у God of War — і там є сцена де Кратос, бог війни, зупиняє сина після помилки і коли той виправдовується каже: "Intent does not matter, only consequences."Намір не має значення. Тільки наслідки.Кар'єра майже завжди оцінюється по outcome, а не по intent. Система не бачить твоїх намірів. Вона бачить результат. І ніхто не зобов'язаний копати глибше. Бо намір це субʼєктивно.І це стосується не тільки джунів. Я бачив мідлів і сеньйорів з роками досвіду, які щиро не розуміли чому їх не підвищують. Вони старались. Вони дійсно старались. Але не вміли переводити наміри в результати — і показувати ці результати.Що з цим робити- Формулювати результат заздалегідь. До початку роботи — домовитись як виглядає успіх. Не "я зроблю дизайн", а "після цього ми матимемо X".- Міряти результат. Не "я зробив", а "ось що змінилось після того як я зробив".- Комунікувати результат. Якщо ніхто не знає — вважай його не було.Коротше, старатись — необхідно, але недостатньо. Система оцінює наслідки, а не наміри. І якщо не навчитись їх в першу чергу досягати, а в другу ще й показувати — відчуття що тебе недооцінюють буде постійним. І, на жаль, з боку системи це буде справедливо.
#115. Нелояльність до менеджера — це глухий кутЧастий кейс у командах: людина не погоджується зі своїм менеджером.Вона бачить проблеми в рішеннях, процесах або культурі, і замість того, щоб адаптуватися чи змінити контекст, починає з цим боротися. Зʼявляються спроби довести, що менеджер неправий, знайти підтримку у колег і топ-менеджерів або підсвітити “реальну проблему” на ширшому рівні.Зсередини це може виглядає абсолютно раціонально. Людина не просто чинить опір — вона вважає, що хоче зробити краще, виправити помилки і досягти кращого результату (інколи це так, але частіше ні). Часто є відчуття, що якщо достатньо чітко пояснити ситуацію, всі "розберуться" і визнають, що ти — герой.Але в більшості організацій це працює інакше. Компанія майже завжди стане на сторону менеджера. Навіть якщо він "неідеальний" або допускає помилки, його будуть розвивати, підтримувати і намагатися вирівняти через зворотний звʼязок.Конфлікт же знизу вгору частіше сприймається як деструктивна ініціатива. Це швидше сигнал, що з цією людиною складно працювати і вона створює додаткові ризики для команди.У цьому місці часто плутають поняття лояльності. Її сприймають або як сліпу згоду, або як щось токсичне і принизливе. Насправді лояльність значно простіша і практичніша. Це не про те, щоб мовчати або підтримувати будь-яке рішення. Це про розуміння того, в якій системі ти працюєш і які в ній правила гри.У кожного менеджера є свої цілі, обмеження і KPI. І твоя роль у цій системі — допомагати досягати цих цілей. Це не означає відмову від критичного мислення. Можна і потрібно давати фідбек, сперечатись, пропонувати альтернативи. Але різниця в тому, чи ти працюєш всередині цієї логіки, чи намагаєшся її зламати.Окремий важливий момент — це ситуації, коли ти не згоден з рішенням, але воно вже прийняте.Таке буде регулярно. Не всі рішення будуть ідеальними, не всі будуть збігатися з твоїм баченням, і не завжди в тебе буде достатньо аргументів або впливу, щоб це змінити.Тепер задача не саботувати рішення і не доводити заднім числом, що "воно було поганим". Тепер задача — зробити його настільки добре, наскільки це можливо в заданих умовах.Для мене це в тому числі ознака зрілості — зрілий спеціаліст вміє відпустити дискусію в момент, коли рішення прийнято, і переключитися в режим виконання. Незрілий — продовжує боротьбу через пасивний опір, затягування, зниження якості, токсичні розмови.Твій менеджер — це точка, через яку ти створюєш цінність в компанії. Не абстрактна "компанія", не "користувач", не "продукт", а конкретна людина з конкретними очікуваннями до твоєї роботи. А в нього чи неї так само є свій менеджер. І так до того, хто фінансує всю цю вечірку: фаундери, борд, інвестори.Тому якщо виникає системна незгода — не з окремими рішеннями, а з підходом, цілями і способом роботи — це вже не про дискусію. Якщо немає довіри і бажання працювати в цій логіці, проблема не в культурі і не в політиці. Це означає, що ти не в тій команді.Що робитиА. Синхронізуватись: зрозуміти очікування, домовитись про правила гри.Б. Пробувати впливати корректно і професійно: через аргументи, через результат, через довіру.В. Йти: без драми, без "останнього слова", без спроб "довести правду".Нелояльність у цій історії не дає виграшної стратегії. Вона не допомагає змінити систему, але стабільно шкодить репутації і зʼїдає твій час.Ти або граєш в цю гру разом з менеджером, або витрачаєш час дарма.