⌘53. Сказати, але не донести

Дуже часто будь-який керівник (і я в тому числі) припускається помилки – презентує співробітникам нову метрику чи процес, але не доносить: як тут досягати результату.

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

Що станеться за місяць після впровадження нової метрики? Співробітники почнуть приходити зі скаргами “ми на це не впливаємо”, “ми не можемо досягти цих показників”, а потім і з пропозиціями “скасуймо цей показник і повернемося до того, що було”.

Керівник зобов’язаний не просто розповісти, а показати як співробітникам впливати на нову метрику.

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

Можна писати пост на корпоративний блог із текстом “для цього використовуйте наше api”. А можна писати, що “наше api вигідне”, “у нас вигідні ціни (ось вони)”, “більше тисячі клієнтів вже користуються”, “ось специфікація”, “а питання можна поставити тут, а спробувати тут”.

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