#117. Аналітика все ще тільки ритуал
Часто зтикаюсь з тим що дизайнери трохи агресивно просять аналітику, або пояснюють помилки чи проблеми тому що не дали аналітику.
Але здебільшого я бачу що це робиться, бо так "треба". Проблема також в тому, що у більшості продуктів тієї аналітики особливо нема. А якщо навіть і є — дизайнери туди все одно не заходять.
Аналітика стала ритуалом. Просять, бо навчили на курсах, хайп-статтях і постах. Але не навчили що з нею реально робити і як будувати на ній гіпотези чи збирати докази.
Дизайнер має приймати рішення на основі даних — звучить розумно, але шо робити далі? Як заходити в Amplitude (чи не його, зараз купа систем), шо шукати, як читати маленькі цифри — цього, як правило, ніхто не показує. А якщо і показує — в загальних словах, без конкретики. А ще стат.значимість.
В результаті три типові ситуації:
- даних нема взагалі (більшість продуктів саме такі),
- дані є але дизайнер не знає як туди дивитись,
- доступи є але ніхто не заходить.
І у всіх трьох — аналітика залишається темою розмов, а не роботи.
Я думаю шо проблема тут не в доступах, а в навчанні і звичках. Якщо немає скілу — ти не робиш, якщо скіл є — робиш.
Коли в команді немає культури роботи з даними, типова історія скинути це все на продакта: хай робить зводки, приносить дані. "Якщо мені не принесли цифри, то я не винен".
Аналітика це не панацея, аналітика не скаже що робити. Далеко не завжди те шо вона є — вирішує всі проблеми.
Мій меседж шо треба зупинитися і подумати, шо конкретно ви хочете отримати, коли пушите аналітику. Бо якщо нічого конкретно, то ви просто втрачаєте репутацію в очах команди, рекрутера, наймаючого менеджера.
Аналітика це про те що відбувається. Рішення все одно ваше, його все одно доведеться приймати самому, і тільки аналітики не вистачить.
Що дизайнерам реально треба від аналітики
Не “глибоке занурення”. Не “ідеальна дата”. І точно не “аналітика скаже нам, що робити”. Потрібен верхньорівневий sanity-check свої рішень.
Мінімум, який швидко дає контекст:
- базова воронка або ключова конверсія по сценарію, який ви чіпаєте
- 1-2 зрізи (платформа/країна/сегмент — що у вас є)
- просте “до/після” як орієнтир, а не як доказ
Типові граблі, які я бачу постійно
1. “Я не лізу, поки не зрозумію все” — так можна не лізти взагалі. А потім чесно казати “аналітика складна”.
2. Маленькі цифри і фальшиві висновки — 10 людей натиснули одне, 50 інше, і вже хочеться приймати рішення, бо відсотки то різні. Часто це не значить нічого. Просто шум, який виглядає переконливо.
3. Очікування, що дані замінять прийняття рішень — не замінять. Доведеться все одно самим формулювати гіпотези і робити вибір.
Як покращувати ситуацію в компанії
1. Зробіть мінімальний едукейшн-івент
Один воркшоп на 60–90 хв. Показати: де дивитись базове, як читати 2–3 типові чарти, і що робити з малими числами. Повторювати періодично і в тому числі на онбордингу.
2. Вшийте аналітику в постановку задач
Додайте в бриф пункт “подивитись Amplitude”. І вимогу: 1–2 скріни або лінк на дашборд прямо в контекст задачі. Це мінімальний стандарт, який змушує реально зайти й подивитись, а не просто “попросити аналітику”.
Аналітика не дасть вам відповідей, але допоможе прибрати частину фантазій. А клеріті, як правило, ніхто не приносить. Її доводиться забирати самому.
Часто зтикаюсь з тим що дизайнери трохи агресивно просять аналітику, або пояснюють помилки чи проблеми тому що не дали аналітику.
Але здебільшого я бачу що це робиться, бо так "треба". Проблема також в тому, що у більшості продуктів тієї аналітики особливо нема. А якщо навіть і є — дизайнери туди все одно не заходять.
Аналітика стала ритуалом. Просять, бо навчили на курсах, хайп-статтях і постах. Але не навчили що з нею реально робити і як будувати на ній гіпотези чи збирати докази.
Дизайнер має приймати рішення на основі даних — звучить розумно, але шо робити далі? Як заходити в Amplitude (чи не його, зараз купа систем), шо шукати, як читати маленькі цифри — цього, як правило, ніхто не показує. А якщо і показує — в загальних словах, без конкретики. А ще стат.значимість.
В результаті три типові ситуації:
- даних нема взагалі (більшість продуктів саме такі),
- дані є але дизайнер не знає як туди дивитись,
- доступи є але ніхто не заходить.
І у всіх трьох — аналітика залишається темою розмов, а не роботи.
Я думаю шо проблема тут не в доступах, а в навчанні і звичках. Якщо немає скілу — ти не робиш, якщо скіл є — робиш.
Коли в команді немає культури роботи з даними, типова історія скинути це все на продакта: хай робить зводки, приносить дані. "Якщо мені не принесли цифри, то я не винен".
Аналітика це не панацея, аналітика не скаже що робити. Далеко не завжди те шо вона є — вирішує всі проблеми.
Мій меседж шо треба зупинитися і подумати, шо конкретно ви хочете отримати, коли пушите аналітику. Бо якщо нічого конкретно, то ви просто втрачаєте репутацію в очах команди, рекрутера, наймаючого менеджера.
Аналітика це про те що відбувається. Рішення все одно ваше, його все одно доведеться приймати самому, і тільки аналітики не вистачить.
Що дизайнерам реально треба від аналітики
Не “глибоке занурення”. Не “ідеальна дата”. І точно не “аналітика скаже нам, що робити”. Потрібен верхньорівневий sanity-check свої рішень.
Мінімум, який швидко дає контекст:
- базова воронка або ключова конверсія по сценарію, який ви чіпаєте
- 1-2 зрізи (платформа/країна/сегмент — що у вас є)
- просте “до/після” як орієнтир, а не як доказ
Типові граблі, які я бачу постійно
1. “Я не лізу, поки не зрозумію все” — так можна не лізти взагалі. А потім чесно казати “аналітика складна”.
2. Маленькі цифри і фальшиві висновки — 10 людей натиснули одне, 50 інше, і вже хочеться приймати рішення, бо відсотки то різні. Часто це не значить нічого. Просто шум, який виглядає переконливо.
3. Очікування, що дані замінять прийняття рішень — не замінять. Доведеться все одно самим формулювати гіпотези і робити вибір.
Як покращувати ситуацію в компанії
1. Зробіть мінімальний едукейшн-івент
Один воркшоп на 60–90 хв. Показати: де дивитись базове, як читати 2–3 типові чарти, і що робити з малими числами. Повторювати періодично і в тому числі на онбордингу.
2. Вшийте аналітику в постановку задач
Додайте в бриф пункт “подивитись Amplitude”. І вимогу: 1–2 скріни або лінк на дашборд прямо в контекст задачі. Це мінімальний стандарт, який змушує реально зайти й подивитись, а не просто “попросити аналітику”.
Аналітика не дасть вам відповідей, але допоможе прибрати частину фантазій. А клеріті, як правило, ніхто не приносить. Її доводиться забирати самому.
👍18❤7
#118. Чому перформанс-ревью частіше імпровізація ніж система
Про очікування які існують тільки в голові менеджера і що з цим робити
Ще одна з поширених проблем в менеджменті це формування і донесення очікувань від роботи.
Людина приходить: "хочу більше грошей, я класно працюю".
Менеджер: "ну так ми тебе і наймали шоб ти класно працював".
Пауза.
Людина: "окей, а шо мені тоді треба зробити шоб отримати підвищення?"
— Треба перевищити очікування.
— Які? Як?
— Ну... зробити шось неймовірне.
На цьому розмова зазвичай закінчується. Людина не знає шо запитати. Менеджер — шо відповісти.
"Відповідає очікуванням" — це не комплімент. Це підтвердження шо базова домовленість виконана. Людину найняли на посаду, вона робить шо на цій посаді треба. Клас, молодець. Це і є "відповідає". Не більше і не менше.
Але де тоді межа між "відповідає" і "перевищує"? Хто її встановлює? Встановлює менеджер і межа досить субʼєктивна.
І тут починаються питання. Чи сформував ти як менеджер собі розуміння шо таке "норма" до того як оцінювати. Чи уважно дивишся на роботу. Чи збираєш фідбек з інших сторін шоб не судити тільки зі свого кута.
Найчастіше очікування або не сформульовані взагалі, або такі абстрактні шо їх не перевіриш, або з'являються постфактум — коли вже треба давати оцінку.
Фактично — вони існують тільки в голові. Якщо їх не проговорили наперед — це не система оцінки, це імпровізація. І "перевищити очікування" тоді означає вгадати шо там у цій голові.
Але є ще один рівень.
Очікування менеджера теж не у вакуумі. Вони залежать від того шо керівництво вважає важливим, від культури компанії, від того шо взагалі помічається і цінується.
Я бачив таке: менеджер щиро вважає шо дизайн — це красиво, естетично, доступно, за всіма гайдлайнами. І оцінює команду саме по цьому. А бізнес хоче конверсію, ретеншн, швидкість.
В результаті дизайнер може системно "перевищувати очікування" свого менеджера і при цьому не створювати жодної цінності для компанії. Ну і навпаки теж буває — коли людина робить важливі речі, але "не відповідає" бо менеджер дивиться не туди.
І ще один момент.
Навіть якщо людина справді перевищує очікування — це ще не означає шо їй щось винні.
В аутсорсі і агенціях вигідно вирощувати людей: ростуть скіли — ростуть рейти з клієнтів. В продуктових компаніях ця логіка не завжди працює — ROI інший. Бо платять не за зростання людини, а за зростання продукту. В аутсорсі продукт — це люди, а в продукті — ну ви поняли.
Компанія платить не за зусилля і не за старання, а за вплив на результат.
Коротше, якщо очікування не можна пояснити — їх не існує.
Про очікування які існують тільки в голові менеджера і що з цим робити
Ще одна з поширених проблем в менеджменті це формування і донесення очікувань від роботи.
Людина приходить: "хочу більше грошей, я класно працюю".
Менеджер: "ну так ми тебе і наймали шоб ти класно працював".
Пауза.
Людина: "окей, а шо мені тоді треба зробити шоб отримати підвищення?"
— Треба перевищити очікування.
— Які? Як?
— Ну... зробити шось неймовірне.
На цьому розмова зазвичай закінчується. Людина не знає шо запитати. Менеджер — шо відповісти.
"Відповідає очікуванням" — це не комплімент. Це підтвердження шо базова домовленість виконана. Людину найняли на посаду, вона робить шо на цій посаді треба. Клас, молодець. Це і є "відповідає". Не більше і не менше.
Але де тоді межа між "відповідає" і "перевищує"? Хто її встановлює? Встановлює менеджер і межа досить субʼєктивна.
І тут починаються питання. Чи сформував ти як менеджер собі розуміння шо таке "норма" до того як оцінювати. Чи уважно дивишся на роботу. Чи збираєш фідбек з інших сторін шоб не судити тільки зі свого кута.
Найчастіше очікування або не сформульовані взагалі, або такі абстрактні шо їх не перевіриш, або з'являються постфактум — коли вже треба давати оцінку.
Фактично — вони існують тільки в голові. Якщо їх не проговорили наперед — це не система оцінки, це імпровізація. І "перевищити очікування" тоді означає вгадати шо там у цій голові.
Але є ще один рівень.
Очікування менеджера теж не у вакуумі. Вони залежать від того шо керівництво вважає важливим, від культури компанії, від того шо взагалі помічається і цінується.
Я бачив таке: менеджер щиро вважає шо дизайн — це красиво, естетично, доступно, за всіма гайдлайнами. І оцінює команду саме по цьому. А бізнес хоче конверсію, ретеншн, швидкість.
В результаті дизайнер може системно "перевищувати очікування" свого менеджера і при цьому не створювати жодної цінності для компанії. Ну і навпаки теж буває — коли людина робить важливі речі, але "не відповідає" бо менеджер дивиться не туди.
І ще один момент.
Навіть якщо людина справді перевищує очікування — це ще не означає шо їй щось винні.
В аутсорсі і агенціях вигідно вирощувати людей: ростуть скіли — ростуть рейти з клієнтів. В продуктових компаніях ця логіка не завжди працює — ROI інший. Бо платять не за зростання людини, а за зростання продукту. В аутсорсі продукт — це люди, а в продукті — ну ви поняли.
Компанія платить не за зусилля і не за старання, а за вплив на результат.
Коротше, якщо очікування не можна пояснити — їх не існує.
❤24👍5🔥1
#119. Ніхто не виділить тобі час на редизайн
Бачив таке не раз: команда хоче зробити редизайн або нарешті нормально дослідити користувачів. Проходить квартал. Нічого не зроблено. Команда каже: нам не поставили в пріоритет, не виділили часу, нікому це не потрібно. Але справа не в часі і пріоритетах.
І логіка начебто є: завжди є релізний цикл, завжди є гарячі задачі на вчора, забитий беклог. Редизайн — важливо, але потім, коли з'явиться вікно. Тільки вікна не буває.
Ніхто не виділяє час на те чого не існує
Ніхто ніколи свідомо не виділяє час на розмиту задачу. Беклог не зберігає наміри, він зберігає задачі.
"Редизайн" і "user research" — це не задачі. Поки немає відповіді на "що конкретно хочемо змінити", "який ризик зменшуємо", "що дізнаємось і що далі з цим робимо" — це не потрапить у пріоритет. Ніколи.
Ніхто в здоровому глузді не дасть недосвідченому дизайнеру експериментувати з складними мутними задачами. А досвідченому не треба давати, він сам візьме. Бо він на досвіді знає навіщо їх треба робити, заради якого результату, може їх декомпозувати. А недосвідченому треба спочатку піддивитись це в когось на практиці, або вчитись декомпозувати до мікроскопічних кроків.
Безпечні задачі
Є пул задач на котрі простіше знайти мотивацію, і навіть не розуміючи шо з ними робити — пропхати їх в беклог правдами і не правдами.
Дизайн-системна інфраструктура, аксесібіліті, якоюсь юзабіліті-двіжуха — задачі теж мутні, але за них є соціальне схвалення. Курси кажуть що це важливо. Спільноти обговорюють. В соцмережах лайкають. За них не осудять — вони виглядають правильно і "дизайнерськи". Є активність, є що показати на ревью.
Але це не те шо потрібно продукту чи компанії саме зараз.
Просто коли немає чіткого і зрозумілого напряму куди рухатись — люди рухаються туди де є відчуття зрозумілого результату і схвалення ззовні.
Що робити
Досвідчений дизайнер не приходить з "хочу зробити редизайн". Він робить кроки самостійно, а потім приходить з конкретикою: "ось де ми втрачаємо користувачів, ось що хочу перевірити, ось що зроблю за два тижні і що ми з цього дізнаємось".
Перед тим як ми зробили Documents X в Readdle, я прийшов до свого продакта і сказав "Я знаю як заредизайнити класно всю апку за місяць, а потім за 2-3 місяці максимум це задевелопити". А там ми ще й фічей потім накрутили топових.
Перший результат — кредит довіри. Кредит довіри — левередж. Левередж — час і ресурс на більше.
Коротше, ніхто не виділить тобі час на редизайн чи щось інше велике — доки це побажання, а не набір зрозумілих задач із зрозумілим очікуванним результатом.
Бачив таке не раз: команда хоче зробити редизайн або нарешті нормально дослідити користувачів. Проходить квартал. Нічого не зроблено. Команда каже: нам не поставили в пріоритет, не виділили часу, нікому це не потрібно. Але справа не в часі і пріоритетах.
І логіка начебто є: завжди є релізний цикл, завжди є гарячі задачі на вчора, забитий беклог. Редизайн — важливо, але потім, коли з'явиться вікно. Тільки вікна не буває.
Ніхто не виділяє час на те чого не існує
Ніхто ніколи свідомо не виділяє час на розмиту задачу. Беклог не зберігає наміри, він зберігає задачі.
"Редизайн" і "user research" — це не задачі. Поки немає відповіді на "що конкретно хочемо змінити", "який ризик зменшуємо", "що дізнаємось і що далі з цим робимо" — це не потрапить у пріоритет. Ніколи.
Ніхто в здоровому глузді не дасть недосвідченому дизайнеру експериментувати з складними мутними задачами. А досвідченому не треба давати, він сам візьме. Бо він на досвіді знає навіщо їх треба робити, заради якого результату, може їх декомпозувати. А недосвідченому треба спочатку піддивитись це в когось на практиці, або вчитись декомпозувати до мікроскопічних кроків.
Безпечні задачі
Є пул задач на котрі простіше знайти мотивацію, і навіть не розуміючи шо з ними робити — пропхати їх в беклог правдами і не правдами.
Дизайн-системна інфраструктура, аксесібіліті, якоюсь юзабіліті-двіжуха — задачі теж мутні, але за них є соціальне схвалення. Курси кажуть що це важливо. Спільноти обговорюють. В соцмережах лайкають. За них не осудять — вони виглядають правильно і "дизайнерськи". Є активність, є що показати на ревью.
Але це не те шо потрібно продукту чи компанії саме зараз.
Просто коли немає чіткого і зрозумілого напряму куди рухатись — люди рухаються туди де є відчуття зрозумілого результату і схвалення ззовні.
Що робити
Досвідчений дизайнер не приходить з "хочу зробити редизайн". Він робить кроки самостійно, а потім приходить з конкретикою: "ось де ми втрачаємо користувачів, ось що хочу перевірити, ось що зроблю за два тижні і що ми з цього дізнаємось".
Перед тим як ми зробили Documents X в Readdle, я прийшов до свого продакта і сказав "Я знаю як заредизайнити класно всю апку за місяць, а потім за 2-3 місяці максимум це задевелопити". А там ми ще й фічей потім накрутили топових.
Перший результат — кредит довіри. Кредит довіри — левередж. Левередж — час і ресурс на більше.
Коротше, ніхто не виділить тобі час на редизайн чи щось інше велике — доки це побажання, а не набір зрозумілих задач із зрозумілим очікуванним результатом.
❤19🤔4🔥1
#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. Як я і писав раніше, позиціонування важливе, і подаватись з нерелевантним досвідом — мало сенсу. Зі сторони кандидата це виглядає як "ну я думаю я розберусь в домені", а зі сторони хайрингу це "якщо це не зіркове сіві по іншим показникам, то я не готовий давати шанс людині розбиратися". Тобто конкуренція і так велика, точно будуть люди з більшим розумінням домену, хто зможе увірватись значно швидше.
Ринок маленький, черга велика. Треба точити сіві і портфель під вакансію щоб підвищити шанси.
Закривав того тижня позицію сініор продакт дизайнера в команді, то подумав може колегам хайрінг-менеджерам буде цікаво порівняти цифри, а тим хто шукає — зрозуміти краще шо взагалі відбувається на одній конкретній вакансії.
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. Як я і писав раніше, позиціонування важливе, і подаватись з нерелевантним досвідом — мало сенсу. Зі сторони кандидата це виглядає як "ну я думаю я розберусь в домені", а зі сторони хайрингу це "якщо це не зіркове сіві по іншим показникам, то я не готовий давати шанс людині розбиратися". Тобто конкуренція і так велика, точно будуть люди з більшим розумінням домену, хто зможе увірватись значно швидше.
Ринок маленький, черга велика. Треба точити сіві і портфель під вакансію щоб підвищити шанси.
❤26
#121. Що будувати першим у новій команді
Як будувати shared reality коли люди ще не навчились читати одне одного
Коли команда нова — або зовсім нова, або наполовину перетрясена — менеджер часто очікує від неї поведінки зрілої команди. Логічно: люди досвідчені, завдання зрозуміле, процеси є. І все одно шось не клеїться.
Хтось каже шо цілі незрозумілі. Хтось шо не вистачає відчуття команди — є задачі, але немає відчуття шо ми разом. Мітинги є, але якісь порожні. Рішення приймаються повільніше ніж хотілось би. Кожен тягне своє.
Це не ознака поганої команди. Це нормальна фаза.
Нова команда — навіть з класних людей — це ще не команда в психологічному сенсі. Організаційно вона існує: є структура, є ролі, є загальний канал. Але shared reality ще немає. У кожного своя картина того, як тут прийнято думати, хто шо вирішує, шо важливо, а шо ні. Доки ці картини не почали перетинатись — команда і буде відчуватись не як команда, навіть якщо всі стараються.
Важливо тут не переплутати. Дисфункційна команда — де є токсик, зіпсовані стосунки, хронічні конфлікти — це окрема проблема з іншими ліками. Нова команда яка ще не сформувалась — зовсім інший кейс.
Тому на ранньому етапі задача менеджера — не налаштовувати процеси. А будувати цю спільну картину.
Використовувати 1:1 не тільки для задач. Починати варто з безпеки. Коли люди просять "більше живого спілкування" — вони рідко мають на увазі корпоратив. Вони хочуть зрозуміти менеджера: як він думає, як реагує, де можна бути відвертим. Це перевірка безпеки. І поки вона не пройдена — всі наступні кроки будуть половинчастими.
Переформатувати регулярні мітинги. Якщо зустріч можна замінити повідомленням — вона не будує команду. Вона просто синхронізує таски. Команда формується коли люди думають разом, сперечаються, дивляться на одну проблему з різних боків. Ознака шо це починає працювати — коли на мітингах з'являються незгоди. Не конфлікти, а незгоди. Люди почали довіряти достатньо шоб говорити відверто.
Зробити "чому" видимим. Менеджер часто думає шо він пояснив ціль. Але насправді — оголосив результат. "Нам треба підняти конверсію на 15%" — це результат. Шо за ним стоїть? Чому саме 15%? Які варіанти розглядались? Де є простір для рішень команди, а де вже вирішено? Без цього кожен заповнює прогалини сам — і заповнює по-різному. Спільний контекст — це не слайд з цілями. Це розуміння розумового шляху, який привів до рішення. Та і якби люди розуміли всі пояснення — це був би другий світ.
Будувати зв'язки між людьми, не тільки через менеджера. Якщо вся взаємодія йде через менеджера — він стає bottleneck, а команда не навчиться читати одне одного. Спільна робота, пар-розбори, крос-функціональні обговорення — все це прискорює формування shared reality.
Не поспішати з оптимізацією. Нова команда ще не навчилась нормально комунікувати, а менеджер вже вводить KPI, матриці і правила. Спочатку — система взаємодії. Потім — все решта.
Коротше, сильна команда — це не коли всі дружать. А коли люди достатньо розуміють і довіряють одне одному, шоб ефективно працювати в невизначеності. Менеджер будує це першим — систему взаємодії між людьми. Процеси, KPI і структури — потім.
Як будувати shared reality коли люди ще не навчились читати одне одного
Коли команда нова — або зовсім нова, або наполовину перетрясена — менеджер часто очікує від неї поведінки зрілої команди. Логічно: люди досвідчені, завдання зрозуміле, процеси є. І все одно шось не клеїться.
Хтось каже шо цілі незрозумілі. Хтось шо не вистачає відчуття команди — є задачі, але немає відчуття шо ми разом. Мітинги є, але якісь порожні. Рішення приймаються повільніше ніж хотілось би. Кожен тягне своє.
Це не ознака поганої команди. Це нормальна фаза.
Нова команда — навіть з класних людей — це ще не команда в психологічному сенсі. Організаційно вона існує: є структура, є ролі, є загальний канал. Але shared reality ще немає. У кожного своя картина того, як тут прийнято думати, хто шо вирішує, шо важливо, а шо ні. Доки ці картини не почали перетинатись — команда і буде відчуватись не як команда, навіть якщо всі стараються.
Важливо тут не переплутати. Дисфункційна команда — де є токсик, зіпсовані стосунки, хронічні конфлікти — це окрема проблема з іншими ліками. Нова команда яка ще не сформувалась — зовсім інший кейс.
Тому на ранньому етапі задача менеджера — не налаштовувати процеси. А будувати цю спільну картину.
Використовувати 1:1 не тільки для задач. Починати варто з безпеки. Коли люди просять "більше живого спілкування" — вони рідко мають на увазі корпоратив. Вони хочуть зрозуміти менеджера: як він думає, як реагує, де можна бути відвертим. Це перевірка безпеки. І поки вона не пройдена — всі наступні кроки будуть половинчастими.
Переформатувати регулярні мітинги. Якщо зустріч можна замінити повідомленням — вона не будує команду. Вона просто синхронізує таски. Команда формується коли люди думають разом, сперечаються, дивляться на одну проблему з різних боків. Ознака шо це починає працювати — коли на мітингах з'являються незгоди. Не конфлікти, а незгоди. Люди почали довіряти достатньо шоб говорити відверто.
Зробити "чому" видимим. Менеджер часто думає шо він пояснив ціль. Але насправді — оголосив результат. "Нам треба підняти конверсію на 15%" — це результат. Шо за ним стоїть? Чому саме 15%? Які варіанти розглядались? Де є простір для рішень команди, а де вже вирішено? Без цього кожен заповнює прогалини сам — і заповнює по-різному. Спільний контекст — це не слайд з цілями. Це розуміння розумового шляху, який привів до рішення. Та і якби люди розуміли всі пояснення — це був би другий світ.
Будувати зв'язки між людьми, не тільки через менеджера. Якщо вся взаємодія йде через менеджера — він стає bottleneck, а команда не навчиться читати одне одного. Спільна робота, пар-розбори, крос-функціональні обговорення — все це прискорює формування shared reality.
Не поспішати з оптимізацією. Нова команда ще не навчилась нормально комунікувати, а менеджер вже вводить KPI, матриці і правила. Спочатку — система взаємодії. Потім — все решта.
Коротше, сильна команда — це не коли всі дружать. А коли люди достатньо розуміють і довіряють одне одному, шоб ефективно працювати в невизначеності. Менеджер будує це першим — систему взаємодії між людьми. Процеси, KPI і структури — потім.
❤18
#122. Хороший менеджер будує систему, а сильний — систему, яка розвиває себе сама
Базовий рівень менеджменту — організувати систему так, щоб вона працювала. Команда зібрана, процеси запущені, задачі виконуються. Це вже непросто.
Але є рівень далі.
Наступний рівень — організувати систему так, щоб вона покращувала себе сама. Без постійного менеджерського поштовху.
Як це виглядає на практиці:
- команда проводить нормальні дизайн-критики без тебе
- люди самі підсвічують проблеми в процесах — а не чекають поки помітить менеджер
- фідбек-культура існує бо це норма, а не бо ти щоразу нагадуєш
- команда сама помічає дизайн-борг і пропонує шо з ним робити
- люди синхронізуються між собою, а не через тебе як роутер
Простий тест: шо в команді покращилось само по собі за останній рік без твого прямого втручання?
Це не значить, що після цього менеджер стає не потрібен, але є різниця між тим, коли системі для руху потрібен ти — і тим, коли вона рухається і без тебе.
Тобто різниця не в тому, наскільки добре ти керуєш, а в тому, шо відбувається коли тебе немає.
Базовий рівень менеджменту — організувати систему так, щоб вона працювала. Команда зібрана, процеси запущені, задачі виконуються. Це вже непросто.
Але є рівень далі.
Наступний рівень — організувати систему так, щоб вона покращувала себе сама. Без постійного менеджерського поштовху.
Як це виглядає на практиці:
- команда проводить нормальні дизайн-критики без тебе
- люди самі підсвічують проблеми в процесах — а не чекають поки помітить менеджер
- фідбек-культура існує бо це норма, а не бо ти щоразу нагадуєш
- команда сама помічає дизайн-борг і пропонує шо з ним робити
- люди синхронізуються між собою, а не через тебе як роутер
Простий тест: шо в команді покращилось само по собі за останній рік без твого прямого втручання?
Це не значить, що після цього менеджер стає не потрібен, але є різниця між тим, коли системі для руху потрібен ти — і тим, коли вона рухається і без тебе.
Тобто різниця не в тому, наскільки добре ти керуєш, а в тому, шо відбувається коли тебе немає.
🔥20❤7
#123. Як зробити спілкування на вантуванах більш персональним
Якось на консультаційному дзвінку дизайн-менеджер запитав: "Як зробити спілкування з репортом більш персональним? Ми спілкуємось регулярно, але якось поверхово."
Гарне питання. І дуже часте.
Типова картина: ван-ту-ван відбувається щотижня. Говорите про задачі, трохи про вихідні, може про новини — і розходитесь. Нікому не незручно. А потім виявляється що в людини щось відбувається — і ви навіть не підозрювали.
Ніби спілкувались. Але по суті — ні.
Рівні спілкування
Gary Smalley виділив п'ять рівнів спілкування — ще в 70-х, але для робочих стосунків досі актуально:
Ритуали або смолток — "привіт, як справи, як вихідні". Потрібні для початку, але поганий фінальний стан.
Факти — обмін інформацією. "Задача не закрита", "є зустріч в п'ятницю". Безпечно, бо з фактами не посперечаєшся.
Погляди — думки, оцінки, інтерпретації. Тут вже є ризик: можна підставитись, можна не погодитись.
Почуття — що реально відбувається з людиною. Потрібна довіра і готовність бути чесними — з обох сторін.
Відвертість — розмова про найглибше: страхи, цілі, сумніви, мрії.
Більшість робочих стосунків зависають між першим і другим рівнем. Це безпечна зона — обидва не ризикують. І тому нічого справжнього не відбувається.
Де це відчувається
Ви говорите про задачі — і це нормально. Але якщо через рік ви досі не знаєте що реально мотивує людину, що її дратує, що вона хоче далі — це симптом.
Часто проблема не в репорті. А в тому, що ви самі не виходите з безпечного простору першими. Якщо менеджер тримається в зоні фактів — люди зазвичай туди ж і лишаються.
Шо з цим робити
Часто в мене бувають дзвінки з репортами на яких ми взагалі не торкаємось задач. Тільки — шо робили на вихідних, які переживання допікають по життю, в яку гру грали, якісь історії. І це одні з найкорисніших дзвінків.
Кілька речей, які допомагають
Годинний формат. Не 30 хвилин — бо к 30 хвилинам тільки починається двіж. Якщо дуже зайняті — краще година раз на два тижні ніж пів години щотижня.
Готуйтесь. Якщо між дзвінками щось прийшло в голову — занотуйте. Принесіть щось своє: спостереження, питання, рефлексію, книжку. Дзвінок де ви прийшли з порожніми руками дає відчуття шо людина вам не дуже цікава.
Прибирайте телефон. Навіть вимкнений телефон в руках дає відчуття шо ви десь інде. Це помітно навіть на відео-дзвінках.
Будьте справжніми. Ваші питання не повинні виглядати як анкета. Якщо людина вам реально цікава — це відчувається. Якщо ні — теж.
Рухатись до глибшого спілкування можна тільки якщо ви самі відкриті першими. Не техніка, не формат. Просто справжній інтерес до людини.
Де ви зараз з кожним репортом на цій шкалі?
Якось на консультаційному дзвінку дизайн-менеджер запитав: "Як зробити спілкування з репортом більш персональним? Ми спілкуємось регулярно, але якось поверхово."
Гарне питання. І дуже часте.
Типова картина: ван-ту-ван відбувається щотижня. Говорите про задачі, трохи про вихідні, може про новини — і розходитесь. Нікому не незручно. А потім виявляється що в людини щось відбувається — і ви навіть не підозрювали.
Ніби спілкувались. Але по суті — ні.
Рівні спілкування
Gary Smalley виділив п'ять рівнів спілкування — ще в 70-х, але для робочих стосунків досі актуально:
Ритуали або смолток — "привіт, як справи, як вихідні". Потрібні для початку, але поганий фінальний стан.
Факти — обмін інформацією. "Задача не закрита", "є зустріч в п'ятницю". Безпечно, бо з фактами не посперечаєшся.
Погляди — думки, оцінки, інтерпретації. Тут вже є ризик: можна підставитись, можна не погодитись.
Почуття — що реально відбувається з людиною. Потрібна довіра і готовність бути чесними — з обох сторін.
Відвертість — розмова про найглибше: страхи, цілі, сумніви, мрії.
Більшість робочих стосунків зависають між першим і другим рівнем. Це безпечна зона — обидва не ризикують. І тому нічого справжнього не відбувається.
Де це відчувається
Ви говорите про задачі — і це нормально. Але якщо через рік ви досі не знаєте що реально мотивує людину, що її дратує, що вона хоче далі — це симптом.
Часто проблема не в репорті. А в тому, що ви самі не виходите з безпечного простору першими. Якщо менеджер тримається в зоні фактів — люди зазвичай туди ж і лишаються.
Шо з цим робити
Часто в мене бувають дзвінки з репортами на яких ми взагалі не торкаємось задач. Тільки — шо робили на вихідних, які переживання допікають по життю, в яку гру грали, якісь історії. І це одні з найкорисніших дзвінків.
Кілька речей, які допомагають
Годинний формат. Не 30 хвилин — бо к 30 хвилинам тільки починається двіж. Якщо дуже зайняті — краще година раз на два тижні ніж пів години щотижня.
Готуйтесь. Якщо між дзвінками щось прийшло в голову — занотуйте. Принесіть щось своє: спостереження, питання, рефлексію, книжку. Дзвінок де ви прийшли з порожніми руками дає відчуття шо людина вам не дуже цікава.
Прибирайте телефон. Навіть вимкнений телефон в руках дає відчуття шо ви десь інде. Це помітно навіть на відео-дзвінках.
Будьте справжніми. Ваші питання не повинні виглядати як анкета. Якщо людина вам реально цікава — це відчувається. Якщо ні — теж.
Рухатись до глибшого спілкування можна тільки якщо ви самі відкриті першими. Не техніка, не формат. Просто справжній інтерес до людини.
Де ви зараз з кожним репортом на цій шкалі?
❤16🔥5👍2
#124. Чому CTO існує майже в кожній компанії, а CDO — ні?
Якось говорили з моїм менеджером про те куди росте дизайн-менеджер, типу чи має сенс очолювати і продакт-дизайн, і маркетинг-дизайн одночасно.
Так от я далеко в цьому не впевнений.
Маркетинговий дизайн виконує цілі CMO. Продуктовий — цілі CPO. Об'єднувати можна, але скоріше в тому випадку, якщо компанія ще невелика і був дефіцит людей.
Але я став думати, що ніхто не сперечається про роль CTO, наприклад, — а питання "чи потрібен головний дизайнер" абсолютно нормальне навіть у великих компаніях (але зараз не про корпорації).
Тому зараз порозмірковую на ніфіга собі контроверсійну тему, приберіть дітей від екранів телевізора.
Мені здається питання в сфері відповідальності і "об'єкті управління".
У кожного на C-рівні є щось конкретне, чим він управляє і за що відповідає.
CTO — платформа, архітектура, технічний борг, надійність, безпека. Це реальний актив компанії.
CPO — продукт, метрики, retention, активація, LTV, цінність для клієнта.
CRO/CMO — гроші, через відповідальність за канали залучення клієнтів і їх конверсію в платника.
Прибери будь-кого з них — за кілька кварталів компанія це відчує. Конкретно і боляче.
А тепер CDO. Чим він управляє?
Якщо відповідь — "дизайнерами і дизайн-системою" — це не об'єкт управління на рівні бізнесу. Це засоби.
Якщо відповідь — "customer experience" — починається конфлікт. Бо customer experience — це ж і є продукт. Там вже живе CPO.
Якщо відповідь — "ми несемо розуміння клієнта" — і тут конфлікт. Бо хороший CPO вже давно окопався в user research, JTBD і customer insights.
А що наприклад з Chief Legal Officer (котрий теж не те шо б в кожній компанії є). Юридичний департамент існує, має бюджет і людей. Але юристи наче ніколи не претендували на стратегічний об'єкт управління — вони управляють специфічною експертизою, котра не пересікається з іншими С-напрямами.
Дизайн же часто хоче бути за одним столом з CPO і CTO, але поки не може чітко пояснити — за що саме хоче відповідати.
У великих компаніях дизайн завжди стає окремою системою зі своїми стандартами, процесами, кар’єрними треками і внутрішніми платформами на кшталт дизайн-систем. Саме тому ролі на кшталт Head of Design або VP Design виглядають цілком логічно.
Але питання інше: чи достатньо цього для окремої функції на рівні C-suite?
Прибери CTO — що станеться? За кілька кварталів почнуться проблеми з надійністю, масштабом, технічним боргом. Платформа — це незалежна система зі своїми законами.
Прибери CDO — продукт не перестане існувати. Компанія не втратить здатність продавати чи розробляти. Наслідки скоріше будуть накопичуватися через фрагментацію і різні стандарти. Дизайнери розійдуться по продуктових і маркетингових командах. Можливо, якість просяде (а може й ні).
Це неприємна думка для дизайнерів, але мені здається про це корисно подумати, тому що дизайн роками говорить про "місце за столом", про стратегічний вплив, про те що нас не пускають і не розуміють.
Але може питання не в тому що не пускають, а в тому що дизайну як дисципліні досі важко сформулювати — за що саме він хоче відповідати. Чим він хоче "володіти" в термінах, які зрозумілі бізнесу.
Багато сильних дизайн-лідерів рано чи пізно починають керувати не тільки дизайном.
До їхньої відповідальності додаються Research, Customer Experience, Innovation, Product management. Тобто той самий CX вже виходить за межі продуктового департаменту.
Можливо тому що вплив у компаніях зазвичай зростає разом із шириною відповідальності.
І тоді виникає незручне питання.
Якщо шлях до більшого впливу майже завжди проходить через розширення сфери відповідальності за межі дизайну — то чи є дизайн самодостатньою бізнес-функцією? І на яких етапах?
Якось говорили з моїм менеджером про те куди росте дизайн-менеджер, типу чи має сенс очолювати і продакт-дизайн, і маркетинг-дизайн одночасно.
Так от я далеко в цьому не впевнений.
Маркетинговий дизайн виконує цілі CMO. Продуктовий — цілі CPO. Об'єднувати можна, але скоріше в тому випадку, якщо компанія ще невелика і був дефіцит людей.
Але я став думати, що ніхто не сперечається про роль CTO, наприклад, — а питання "чи потрібен головний дизайнер" абсолютно нормальне навіть у великих компаніях (але зараз не про корпорації).
Тому зараз порозмірковую на ніфіга собі контроверсійну тему, приберіть дітей від екранів телевізора.
Мені здається питання в сфері відповідальності і "об'єкті управління".
У кожного на C-рівні є щось конкретне, чим він управляє і за що відповідає.
CTO — платформа, архітектура, технічний борг, надійність, безпека. Це реальний актив компанії.
CPO — продукт, метрики, retention, активація, LTV, цінність для клієнта.
CRO/CMO — гроші, через відповідальність за канали залучення клієнтів і їх конверсію в платника.
Прибери будь-кого з них — за кілька кварталів компанія це відчує. Конкретно і боляче.
А тепер CDO. Чим він управляє?
Якщо відповідь — "дизайнерами і дизайн-системою" — це не об'єкт управління на рівні бізнесу. Це засоби.
Якщо відповідь — "customer experience" — починається конфлікт. Бо customer experience — це ж і є продукт. Там вже живе CPO.
Якщо відповідь — "ми несемо розуміння клієнта" — і тут конфлікт. Бо хороший CPO вже давно окопався в user research, JTBD і customer insights.
А що наприклад з Chief Legal Officer (котрий теж не те шо б в кожній компанії є). Юридичний департамент існує, має бюджет і людей. Але юристи наче ніколи не претендували на стратегічний об'єкт управління — вони управляють специфічною експертизою, котра не пересікається з іншими С-напрямами.
Дизайн же часто хоче бути за одним столом з CPO і CTO, але поки не може чітко пояснити — за що саме хоче відповідати.
У великих компаніях дизайн завжди стає окремою системою зі своїми стандартами, процесами, кар’єрними треками і внутрішніми платформами на кшталт дизайн-систем. Саме тому ролі на кшталт Head of Design або VP Design виглядають цілком логічно.
Але питання інше: чи достатньо цього для окремої функції на рівні C-suite?
Прибери CTO — що станеться? За кілька кварталів почнуться проблеми з надійністю, масштабом, технічним боргом. Платформа — це незалежна система зі своїми законами.
Прибери CDO — продукт не перестане існувати. Компанія не втратить здатність продавати чи розробляти. Наслідки скоріше будуть накопичуватися через фрагментацію і різні стандарти. Дизайнери розійдуться по продуктових і маркетингових командах. Можливо, якість просяде (а може й ні).
Це неприємна думка для дизайнерів, але мені здається про це корисно подумати, тому що дизайн роками говорить про "місце за столом", про стратегічний вплив, про те що нас не пускають і не розуміють.
Але може питання не в тому що не пускають, а в тому що дизайну як дисципліні досі важко сформулювати — за що саме він хоче відповідати. Чим він хоче "володіти" в термінах, які зрозумілі бізнесу.
Багато сильних дизайн-лідерів рано чи пізно починають керувати не тільки дизайном.
До їхньої відповідальності додаються Research, Customer Experience, Innovation, Product management. Тобто той самий CX вже виходить за межі продуктового департаменту.
Можливо тому що вплив у компаніях зазвичай зростає разом із шириною відповідальності.
І тоді виникає незручне питання.
Якщо шлях до більшого впливу майже завжди проходить через розширення сфери відповідальності за межі дизайну — то чи є дизайн самодостатньою бізнес-функцією? І на яких етапах?
❤11👍2❤🔥1👀1
отут мій друг і колега пан Іван Роговченко ще написав мені по темі вище)
❤2
Forwarded from Ivan Rohovchenko
Різниця достатньо проста.
По-перше, CDO - це людина, яка працює на рівні C-level, і це значить, що компанія бачить дизайн як елемент стратегії.
Зазвичай люди потрапляють на C-level тоді, коли компанія бачить функцію як стратегічний інструмент. Наприклад, туди потрапляє маркетинг або технології - тому що вони можуть давати якусь конкретну перевагу на маркеті. Тобто, це історія про роботу зі стратегією і вплив на неї.
Дизайн потрапляє туди, наприклад, в моєму випадку (попередній експіріенс), бо фаундерам було чітко зрозуміло, що компанія хоче конкурувати за рахунок комунікацій, креативу, експіріенсу в цифрових продуктах. І в принципі це відбулося - дизайн став елементом стратегії.
Плюс, з точки зору керування функцією. У монопродуктовій компанії наявність CDO, коли всього 30 людей, і з них 6 запихувати на C-level - це типу ту-мач. Але якщо ми говоримо про кілька продуктів, які ще, можливо, працюють на різних ринках і мають різні бренди, то цю функцію треба консолідувати. Знову ж таки, працювати з нею на стратегічному рівні: навіщо вона треба, які пріоритети, які задачі і так далі.
Тобто, давай так: CDO - це людина, яка будує дизайн як одну зі стратегічних переваг компанії. За рахунок чого будується бренд, за рахунок чого будується комунікація, а взаємодія з цифровими продуктами виходить за рамки цифрового середовища - наприклад, у магазини. І в цьому велика відмінність.
Для мене це дуже зрозумілий і чіткий меседж - коли та чи інша функція є на C-level, а коли ні.
По-перше, CDO - це людина, яка працює на рівні C-level, і це значить, що компанія бачить дизайн як елемент стратегії.
Зазвичай люди потрапляють на C-level тоді, коли компанія бачить функцію як стратегічний інструмент. Наприклад, туди потрапляє маркетинг або технології - тому що вони можуть давати якусь конкретну перевагу на маркеті. Тобто, це історія про роботу зі стратегією і вплив на неї.
Дизайн потрапляє туди, наприклад, в моєму випадку (попередній експіріенс), бо фаундерам було чітко зрозуміло, що компанія хоче конкурувати за рахунок комунікацій, креативу, експіріенсу в цифрових продуктах. І в принципі це відбулося - дизайн став елементом стратегії.
Плюс, з точки зору керування функцією. У монопродуктовій компанії наявність CDO, коли всього 30 людей, і з них 6 запихувати на C-level - це типу ту-мач. Але якщо ми говоримо про кілька продуктів, які ще, можливо, працюють на різних ринках і мають різні бренди, то цю функцію треба консолідувати. Знову ж таки, працювати з нею на стратегічному рівні: навіщо вона треба, які пріоритети, які задачі і так далі.
Тобто, давай так: CDO - це людина, яка будує дизайн як одну зі стратегічних переваг компанії. За рахунок чого будується бренд, за рахунок чого будується комунікація, а взаємодія з цифровими продуктами виходить за рамки цифрового середовища - наприклад, у магазини. І в цьому велика відмінність.
Для мене це дуже зрозумілий і чіткий меседж - коли та чи інша функція є на C-level, а коли ні.
❤8👍1