ПРО УВОЛЬНЕНИЯ #5

Завершаем тредик. Все предыдущие посты вот:
ПРО УВОЛЬНЕНИЕ #1
ПРО УВОЛЬНЕНИЕ #2
ПРО УВОЛЬНЕНИЕ #3
ПРО УВОЛЬНЕНИЕ #4

Теперь рассмотрим, а что, собственно, делать, если сходу не договорились. Пообщались, поторговались, но к единому консенсусу не пришли.

В этой ситуации есть несколько опций, как продолжать переговоры. Я не буду давать оценку ни одной из них (ни моральную, ни юридическую, ни какую-то еще). Просто знайте, что есть вот такие способы. А какой из них вам ближе, какой вы готовы применять, а какой ни в коем случае – решение за вами.

Вариант 1 – уйти в юридическую плоскость. Если вы решили прощаться с человеком, значит он вас чем-то не устраивает. Уволить по статье очень и очень сложно. И очень муторно, но можно. Здесь есть нюансы конкретной локации, в некоторых странах (например Скандинавия), компанию могут тут же слопать профсоюзы. Но, тем не менее, с помощью грамотного юриста все можно организовать. И тут главное – соблюсти чистоту всех необходимых документов. Скорее всего, это уже не задача руководителя или тимлида, тут должны работать профессионалы.

Многие люди, понимая к чему все идет, охотнее вернуться за стол переговоров. Но не все. Кто-то принципиально будет стоять на своем до конца. Будьте к этому готовы.

Если у вас вопрос сокращения, то все еще проще. Но дороже. Придется раскошелиться на выходное пособие, которое может оказаться сильно выше, чем вы пытались договориться. Но, как говорится, таков путь. Решаем вопрос по-закону.

Вариант 2 – использовать весь свой талант переговорщика. Здесь в ход идут уже более “грязные” приемы, различные манипуляции. В таком подходе важно вывести человека на эмоции, потому что в таком состоянии у него отключается конструктивность мышления и можно добиться импульсивных решений, которые будут вам на руку. Иногда это требует нескольких итераций общения. Но тут важно добиться своего как можно раньше, потому что с каждым последующим заходом ваша позиция слабеет, а позиция оппонента - укрепляется.

Вариант 3 – пытаться все-таки договориться. Что называется, “не мытьем, так катаньем”. Встречаться с сотрудником снова и снова, объяснять конструктивно и спокойно, что будущего у вашего сотрудничества нет и не будет, возвращаться к предложению, показывать, в чем здесь профит для сотрудника и почему ему следует принять это предложение. Рано или поздно ему надоест это, и он станет сговорчивее.

Вариант 4 – пойти на условия сотрудника. Чаще всего, основной и единственный камень преткновения – деньги. Если все делать сокращением по-закону, получается дороже. Компания хочет сэкономить, и заплатить поменьше. Вот здесь все расхождения и начинаются. Можно спросить сотрудника “в лоб”, какой размер выходного пособия его устроит, немного поторговаться и принять его условия. Получится дешевле, чем вариант 1.

Вот такие основные подходы. Повторюсь, я не берусь оценивать их. Просто знайте, что они есть. Это дает уверенность в успехе, даже когда все идет не совсем по плану.

Но лучше договаривайтесь. Помните то правило, с которого я все начинал: “принимать решение нужно, как менеджер, а реализовывать – как человек”.

Удачи, коллеги! Очень надеюсь, что этот материал вам никогда не пригодится. И велком в комментарии с вопросами!

ПРО НАЙМ #2

По мотивам активной дискуссии в посте ПРО НАЙМ. По просьбе @raiserspb и @JustManowar попробуем порассуждать, для технических руководителей насколько, все-таки, важны hard-skills.

Первое, на что хочется обратить внимание – роль руководителя. Да, тимлид тоже руководитель, и его это тоже касается. Вспомним 4 основные функции руководителя: планирование, организация, мотивация, контроль. Заметьте, ни слова про “писать код” 🙂

Значит ли это, что харды не нужны? Отнюдь! Но здесь важно понять смену парадигмы: для тимлида харды – уже не базовые компетенции, благодаря которым он может выполнять свою работу (как это у разработчика), а инструмент. Хорошие харды, хороший технический бэкграунд дает возможность эффективнее делать планирование, организацию, мотивацию и контроль. И чем технически сложнее проект, тем лучше нужно понимать контекст, тем важнее здесь харды.

Второй момент: тимлид – играющий тренер. Очень часто его функции распределяются в пропорциях, например 50/50: 50% времени управляешь командой, 50% времени сам пишешь код и решаешь инженерные задачи. Ну как уж тут без хардов? Это добавляет путаницы в вопросе. Естественно, если будут искать именно такого человека в найме, то и портрет будет состоять из 2 частей: тут вам и требования по технике (причем вагон, как у скиллового разработчика), и софты, поскольку лидерскую функцию тоже нужно закрывать.

Ну и третий момент – домен. Та область бизнеса, в которой идет работа над проектом/продуктом. Но здесь нужно четко различать причину и следствие. Далеко не всегда сложный технический домен означает высочайшие требования по хардам. По опыту, здесь гораздо больший отпечаток накладывают процессы и специфика бизнеса.

В качестве примера в дискуссии был выбран геймдев. Является ли геймдев технически сложным? Несомненно! Сложнее ли он, чем, например, банкинг? Большой вопрос. Но в банкинге, как правило, гораздо больше требований к софтам у руководителей, а в геймдеве - к хардам. Почему так?

Окунемся в процессы. Для банкинга свойственны 2 вещи. Первое – высокая интеграция с бизнесом и пользователями (а бизнес сложный). Второе – высокие требования к надежности и безопасности, что выливается в невысокую скорость изменений, довольно медленный цикл разработки. Вот поэтому софты приоритетнее.

Теперь геймдев. Здесь также я бы выделил 2 основных момента. Первое – очень много различных стримов в рамках каждого продукта. Здесь работают и художники, и дизайнеры геймплея, и много разных разработчиков под разные платформы и т д и т п. Отсюда, как раз, наличие большого количества продюсеров и других специальных менеджеров, кто чисто за софты – потому что все это надо синхронизировать и этим как-то управлять. Второе – очень высокая скорость time-to-market. А это означает огромный дефицит времени в принятии решений. Как это сочетать вместе, учитывая сложность синхронизации и целый штат продюсеров? Закрываться очень технически прокаченными тимлидами, чтобы они могли быстро и в одной голове решать как организационные, так и технические вопросы. Отсюда и высокие требования к хардам.

Резюмируя, я хочу еще раз подсветить мысль, что для инженерных руководителей харды не являются ненужными. Они нужны, и еще как нужны! Но важность софтов для этих позиций возрастает. И чем выше руководитель, тем выше требования к этим софтам. И баланс начинает уходить в эту сторону. Но это в среднем по больнице, а в каждой отрасли (а иногда и в каждой компании) бывают свои взгляды на это дело. И это нормально.

Коллеги, надеюсь получилось внести ясность. Велком в комменты для продолжения дискуссии 🙂

Друзья!

С радостью хочу анонсировать вам новый курс, который запускается на площадке Moscow Business School - "Система развития, мотивации и наставничества в ИТ".

Курс планируется оффлайн в Москве, но есть возможность подключаться онлайн. Ближайшая дата 19-21 октября. Ссылочка на программу вот https://mbschool.ru/seminars/237271

3 дня интенсивного тренинга, где разберем, как выстроить эти самые 3 системы в ИТ-компании. Причем, систему будем строить "слоями": для инженеров, для тимлидов, для руководителей, для бэкофиса.

Если вы руководитель, директор или head of HR, то этот курс для вас!

Курс Delivery Manager официально стартовал! Сегодня был первый вебинар

ПОРОКИ КОМАНД

Сегодня хочу порекомендовать вам классного автора – Патрик Ленсиони. У него порядка 20 книг, часть из них переведены на русский. Пишет в жанре бизнес-романов. Поэтому читать – превеликое удовольствие! Как художественная литература, реально. А еще и куча пользы профессиональной. В общем, очень рекомендую.

И поговорить хочу про его самую популярную модель – 5 пороков команды. Ленсиони выделил 5 основных проблем, которые могут возникать в команде и очень деструктивно влиять на ее работу. Подчеркну, на работу команды, всей, целиком. Не обязательно это будет прямо коррелировать с результатами отдельных сотрудников (хотя, чаще всего коррелирует, конечно).

Итак, вот эти пороки:
1. Взаимное недоверие
2. Избегание конфликтов
3. Безответственность
4. Нетребовательность
5. Безразличие к результату

Интересно, что Ленсиони их видит пирамидой. Т е нельзя закрыть проблему более высокого уровня, если у вас еще активна проблема уровня ниже. И в таком формате, это отличная шпаргалка для задач командообразования (помните была серия постов про это?)

Как с этим работать? Проверять снизу вверх, как по чеклисту. Доверяют ваши сотрудники друг другу? Да? Ок. Идут ли они на конфликты? Да? Ок. Несут ли они персональную и общую ответственность за результаты работы? Да? Ок. Стремятся ли они сделать работу хорошо, чтобы другие коллеги могли пользоваться результатами их труда? Нет? Вот оно! На этом уровне останавливаемся, работаем. Исправляем, проверяем, движемся дальше, к безразличию к результатам.

Как лечить пороки:
- Взаимное недоверие лечится повышением прозрачности
- Избегание конфликтов лечится грамотной фасилитацией и фокусированием на конфликтах
- Безответственность лечится правильной мотивацией, чтобы сотрудники чувствовали, что от их результатов зависят результаты других коллег, а может, и всей компании
- Нетребовательность лечится некоторой агитацией, постоянным возвращением к ценностям, а также снова мотивацией, только уже мотивацией на общий командный результат, который должен быть важнее личного
- Безразличие к результату лечится качественным целеполаганием и постоянным корректированием действий сотрудников в соответствии со стратегическими целями и планами

Это если вкратце. У Ленсиони, конечно, все гораздо подробнее. И сильно поэтичнее 🙂

Вот такой инструмент еще можно положить в копилку инструментов аудита и командообразования. По-моему, неплохой. Пользуйтесь!

Коллеги!

В четверг, 29 июня, в 20.00 мск пройдет день открытых дверей Школы CTO Стратоплана. Расскажем про курс, про обучение, а также немного расскажу там про типажи CTO.

Зарегистрироваться можно тут https://stratoplan-school.com/events/ctoopenday/

ЖЦ ПРОДУКТА

Альберт Эйнштейн говорил, что делать одни и те же вещи раз за разом, и при этом ожидать различных результатов – признак сумасшествия. А я знаю пример, где это не так) Давайте поговорим сегодня про жизненный цикл продукта. Не проекта, а продукта. Это важно, они отличаются.

Выделяют 4 основных этапа ЖЦ продукта. И к ним можно добавить еще 2 по краям:
- Этап 0 – Разработка – Проработка идеи продукта, анализ его перспектив, поиск ресурсов и финансирования
- Этап 1 – Внедрение – Запуск и выход на рынок
- Этап 2 – Рост – Расширение аудитории, увеличение своей доли на рынке
- Этап 3 – Зрелость – Некоторое плато, стабилизация продаж и выручки
- Этап 4 – Спад – Покатились вниз, снижение продаж, потеря объемов рынка
- Этап 4+ – Уход – Возврат в безубыточность, доходы еле-еле покрывают расходы, закрытие продукта

На каждом этапе есть свои правила: на чем фокусироваться менеджеру продукта, какие риски учитывать, как оптимизировать этап и т д. Все не распишу, в один пост не уместится, к сожалению. А вот про фокусы внимания менеджера постараюсь раскрыть.

Итак, что должен делать МП на этапе 0, раработке? Очевидно, делать хороший стратегический анализ: рынка, конкурентов, возможностей продукта и т д. Главный вопрос, на который нужно найти ответ: есть ли у продукта будущее. И ответ должен быть не эмпирическим, а подкрепленным данными. Еще хорошо бы дешево потестировать гипотезы, поделать разные POC и посмотреть, как реагирует аудитория.

Этап 1, внедрение – это время охвата. Фокус на маркетинге и рекламе, чтобы о продукте узнало как можно большее количество людей из вашей потенциальной ЦА. Также здесь важно провалидировать все, что вы там себе напланировали и насочиняли на прошлом этапе, а значит постоянно следить за ОС и фидбеками от пользователей, вносить корректировки в продукт. А еще, это этап нестабильный, непрогнозируемый, и расходов здесь больше, чем доходов. Поэтому нужно держать руку на пульсе финансов, не сжечь все деньги в рекламу (да, жечь туда надо, но не все).

Этап 2, активный рост – на этом этапе весь охват должен начать конвертироваться в захват. А основные усилия маркетинга и продаж смещаются в конвертацию лидов в реальные продажи. Поэтому на данном этапе важно не забыть перестроить маркетинг, не прожигать ресурсы на охват. А также наладить производство, чтобы обеспечить быстрый time-to-market, чтобы все изменения, которые запрашиваются клиентами, быстро до них долетали. Это поможет продавать.

Этап 3, зрелость – стабильно, можно расслабиться? Ни в коем случае! По сути, если вы дошли до этого этапа, значит основную свою ЦА вы уже выгребли, и дальше ее выискивать будет сложно. Поэтому нужно оптимизировать свой продукт, обеспечить минимально приемлемый уровень издержек, а всю свободную прибыль пускать на поиск и проработку новых ниш и новых идей продуктов. Скоро они вам понадобятся.

Спад этапа 4 – что здесь? Контролировать финансы, выжимать максимум из текущей клиентской базы, переносить ресурсы на новые продукты и/или рынки. Важно! Спад – это стабильное падение объема продаж и выручки, не какая-то разовая проблема, которую можно решить доработкой продукта. И связано это, чаще всего, с исчерпанием потенциала: вся ЦА проработана, новых клиентов уже не будет. Поэтому нет никакого смысла пытаться спасти продукт. Можно его усовершенствовать, но это должно быть уже принципиально новое решение, для новой ЦА.

Ну а на этапе ухода самое главное – не затянуть. Чтобы при закрытии продукта не остаться с какими-то долгами по обязательствам и не уйти в минус по деньгам.

Вот такая модель. Такие фокусы менеджера продукта. Пишите, насколько откликается?

Типажи СТО

В четверг провели День Открытых Дверей для Школы Технического Директора в Стратоплане.

Еще на старте первого потока, когда мы готовили самый первый модуль про роли и задачи СТО, пришла в голову интересная концепция. CTO - это же Chief Technical Officer. И каждое из этих слов что-то означает.

Chief - заведующий - это функция менеджера
Technical - технический - это функция технического лидера
Officer - член правления/руководитель функции - это стратегическая функция

И в каждой компании у СТО есть все 3, но баланс может меняться. И также в человеке, какая-то функция может быть прокачена лучше, какая-то хуже.

Получается модель "3 букв", подобная модели Адизеса. Можно выделить 8 основных типажей CTO: Cto, cTo, ctO, CTo, cTO, CtO, cto, CTO. У каждой есть свои смыслы, своя область применения. И развитие СТО также можно рассмотреть с точки зрения изменения баланса этих функций. В общем, просто и наглядно.

Вот про эту модель я подробно рассказывал на эфире. Посмотреть можно тут https://youtu.be/1hCnYSlo12o

Свеженькая статья про MVP: что такое, какие бывают, как правильно его создавать и какие инструменты помогают в этом. Приглашаю почитать!
https://habr.com/ru/companies/otus/articles/744776/

Друзья!

Хочу поделиться с вами своим новым проектом - серия воркшопов для тимлидов и руководителей "Инструменты начинающего руководителя" на площадке Инфостарт.

Начинаем пока с трех, дальше будем делать еще. Первые воркшопы будут про правильные коммуникации, постановку задач и делегирование, индивидуальную работу с сотрудниками.

"Сухая" теория, без воды, только самое основное. Практика, чтобы тут же потренироваться и закрепить новые знания. Все в онлайне, все удобно.

Посмотреть и зарегистрироваться можно здесь https://infostart.ru/edu/1889930/

Коллеги!

Я снова к вам с анонсом очередного крутого проекта 🙂

Запускаем на площадке OTUS новый курс "CTO / Технический директор". Старт планируем 29 августа. Посмотреть описание и программу можно тут https://otus.ru/lessons/cto/

12 июля в 20.00 мск проведем первый открытый урок. Будем обсуждать, почему разных СТО так много, как определить свой тип, куда и как развиваться для этого.

Регистрируйтесь и приходите поучаствовать!

СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА

Наставничество – дело добровольное. Хочешь – менторишь. Хочешь – обращаешься к ментору.

Но есть и другие кейсы. Например, практика наставничества в компании. И тут уж как повезет, выбирать получается не всегда. Кого назначили – с тем и работать.

И в таком случае, это задача. Нельзя просто взять и прекратить наставничать, если, например, не получилось нормальные отношения выстроить. Терпишь и делаешь, как еще.

Знакомо? Бывало такое?

В подобной схеме взаимодействия сложных ситуаций бывает очень много. Самые распространенные, топ 3, так сказать:

1. Личная неприязнь – никак не получается подружиться, иногда доходит даже до запросов на смену наставника

2. Плохие результаты – менти работает заметно хуже, чем от него ожидается

3. Яйцо курицу учит – подопечный больший эксперт, чем наставник, и польза таких отношений явно сыпется

Что делать? Для каждой проблемы решение свое. Начнем с первого кейса – личная неприязнь.

В чем может быть причина? Да в чем угодно! Разные взгляды на что-то. Разные ценности. Разные подходы к работе. Разные стили одежды. Разный график гигиенических процедур. Бывает, что просто так человек бесит, ни с того ни с сего. На одноклассника похож, которого ты не долюбливал, например. Причины не важны, важны эффект. А эффект – отношения не выстраиваются.

Что делать? Совет простой: забить на эти самые отношения. Вам работать надо, а не дружить. Переводите все взаимодействие в конструктивное русло. Установите основные “правила игры” и работайте по ним, достигая общих результатов по задаче.

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

На словах все просто. В чем же здесь изюм? В том, что это все должен проделать наставник. Инициировать разговор по душам, составить “правила игры”, предложить их и договориться с подопечным.

А наставники, очень часто, чего-то ждут. В лучшем случае, эскалируют вопрос HR-у или начальству. А тут надо бы инициативушку проявить. Тогда и проблема будет не проблемой. Вот и все.

Много текста получилось. Остальные 2 проблемы разберу тогда в следующем посте.

Делитесь своими историями. Как решали? Насколько откликается?

ДОКУМЕНТАЦИЯ

“Человеку без документов строго воспрещается существовать!” говорил товарищ Шариков в “Собачьем сердце”. Программным продуктам, по-хорошему, тоже не стоит. Документация нужна и важна. Но часто на нее забивают. Давайте разбираться, почему все так.

Топ-5 проблем с документацией:
1. Документации нет. Вообще. Совсем
2. В документации свалка. Бардак, стало быть
3. Документация неактуальная. Когда то давно написали и больше не обновляли
4. Документация слишком сложная. И по структуре, и по содержанию. Пользоваться лишний раз не хочется
5. Документации ПОКА нет. Мое любимое) “Мы сейчас релиз сдадим, и потом спокойненько все напишем, как положено”. Только вот это ПОТОМ уже не наступает

Почему так? Ответ на поверхности.

Есть 4 причины, почему человек что-то не делает: не понимает, не может, не умеет и не хочет. Распространенная когнитивная ловушка думать, что всегда это пункт 4 – не хочет. Чаще всего, причина какая-то другая.

Но в случае с документацией, это как раз оно! Не хочет! Инженеры не любят возиться с документацией. Даже ненавидят. Дай хоть малейшую возможность этим не заниматься – и они ей тут же воспользуются.

Что делать? Ответ также на поверхности. Варианта тут 2:
1. Добавить им мотивации (скорее всего, это будет морковка сзади, т е наказывать за плохую документацию)
2. Снижать дискомфорт до минимума (совсем убрать не выйдет, но хорошенько оптимизировать этот фронт работ можно)

Про первый вариант подробно писать не буду, итак все понятно. Давайте про второй.

Как снижать дискомфорт:

1. Показывать и доказывать пользу от документации. Через примеры. “Вот Петя заболел, без связи, а тебе надо поправить багу в его модуле. Ты документацию взял, все быстро понял и поправил. А без документации сидел бы неделю, расшифровывал эту Петину тайнопись”

2. Автоматизировать все, что только можно автоматизировать. Чтоб прям минимум действий руками. Автогенерация на максималках

3. Совместить написание документации и написание кода. Например, писать комменты, из которых потом автоматом генерируется документация. Не надо будет переключаться из любимой IDE, да и переключения контекста между задачами не произойдет. А значит, не нужно будет себя заставлять и пересиливать каждый раз, чтобы заняться документацией

4. Ввести правила и регламенты. А еще назначить ответственного, пусть следит за качеством документации. Попахивает вариантом про мотивацию, но сюда тоже подходит

5. Хороший удобный инструмент. Конечно же! Чтоб не бесил. Чтоб простой и понятный. Чтоб удобно было и созидать доки, и потом их находить и использовать

Вот такие рекомендации. Нам помогало. Попробуйте и вы!

СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА #2

Продолжение поста СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА

Разобрались с проблемой #1 – личная неприязнь. Теперь давайте поговорим про #2 – плохие результаты.

Ситуация простая: подопечный работает, показывает результаты, но они заметно хуже, чем ожидалось. И, вроде как, вы ему не начальник, нет полноценных инструментов мотивации. Но повлиять на это как-то нужно.

Здесь есть 2 момента, о которых следует подумать.

Первое – классические 4 причины. Почему сотрудник делает что-то не очень хорошо? Не понимает? Не умеет? Не может? Не хочет? Надо проверить первые 3, прежде чем вешать ярлык “лентяй” или “лоуперформер” на человека.

А второе – сотрудник в стрессе. Когда применяют наставничество? В основном, это либо онбординг нового сотрудника, либо адаптация в новой должности, либо помощь в переходе на новую должность. Что означает новые задачи. Это все выход из комфорта, это все стресс. Человек в стрессе ищет опору, и оттого часто начинает работать заметно хуже и медленнее, чем обычно.

Таким образом, первое, что нужно сделать – “понять и простить”. Подтвердить или опровергнуть эти 2 гипотезы. Если что-то подтверждается – помочь человеку справиться с проблемой, оказать поддержку. Ну а если уж наблюдения показывают, что стресса нет и чувак просто “не хочет” работать нормально, то тут классические “учить/лечить/мочить”.

Бывает кейс другой. Подвид исходного. Когда сотрудник работает нормально, но времени при этом тратит на себя уйму. Вашего времени. Самого ценного ресурса руководителя и наставника. Это тоже отклонение от нормы, с этим тоже нужно работать.

Скорее всего, если такое происходит – это ваша заслуга. Сами позволяете так тратить ваше время. Помните мы говорили о “правилах игры”? Вот здесь снова они. Нужно их задать, договориться, и дальше соблюдать. А если сотрудник их нарушает – возвращать его к правилам.

Так вот. Если эти “правила игры” вы не зададите явно, то их придумает сотрудник. Просто определит свою зону комфорта и будет в ней работать. И в его картине мира будет все ок, он ж сам у себя в голове “договорился”. Поэтому правила и границы нужно проговаривать. Лучше сразу, изначально. Определить график и формат взаимодействия, круг вопросов, формы эскалации и т д.

Кто везет – на том и едут. Так что первый вопрос, который нужно задать самому себе – а не я ли это все позволил? И если понимаете, что вы, то договоритесь о правилах и соблюдайте контрактинг.

История не только про наставничество. Подходит в любой ситуации, где нужно управлять людьми.

Новая статья про выбор каналов привлечения для IT-продуктов. Про CJM и как им пользоваться в этом деле.
https://habr.com/ru/companies/otus/articles/747046/

Друзья!
13 июля в 19.00 мск проведу онлайн митап на тему "Гореть, но не сгорать. Топ-5 лайфхаков для руководителя в IT". Поговорим про правильную зону ответственности тимлида, про баланс, про ресурс.
Зарегистрироваться можно здесь https://meetup.otus.ru/corp-burnout

Видео вчерашнего эфира в OTUS https://youtu.be/ID00rQLV-hQ

Разговаривали о том, как руководителю сохранять трезвость ума, не перегорать и не афигивать от происходящего

Школа менеджмента «Стратоплан» проводит два бесплатных онлайн курса Teamlead:101 и СТО:101

Вам на Teamlead:101, если:

— хотели попробовать себя в роли тимлида в безопасной среде, в окружении тренеров и опытных коллег
— вы тимлид, но не хватает инструментов и точек опоры в управлении; люди саботируют, вы овертаймите
— не можете перейти из роли специалиста в “лида”

22-23 июля, с 9 — 12 Киев/Мск по этой ссылке: https://bit.ly/3Od8umL

А СТО:101 в случае:

— если хотите идти к позиции, но не знаете, в какую сторону двинуться; понять про вас ли это
— если «играете на всех дудках и барабанах сразу» и выгораете
— нет инструментов и метрик; решения принимаются на основе «я так чувствую», а не на основе фактов и цифр

22-23 июля, с 10 — 13 Киев/Мск по этой ссылке: https://bit.ly/3XUW0TZ

Что получите на выходе:

— протестируете себя, как руководителя, на реальной практике
— набор инструментов, решающих 90% проблем в работе с командой и проектами
— сертификат, за вашу работу в эти два дня

Регистрируйтесь!

Коллеги, к посту выше - буду оба дня на СТО101. Расскажу немного про типы СТО, что там у СТО про менеджмент, и про стратегические функции.
Бесплатное мероприятие с целой кучей полезного контента!

Написал подробную статью про жизненный цикл продукта (по мотивам одного из постов). Про саму концепцию, про особенности каждого этапа, про правильные фокусы продуктового менеджера.
https://habr.com/ru/companies/otus/articles/748178/

СИНДРОМ САМОЗВАНЦА

Откуда берется синдром самозванца? Сидишь такой, работаешь работу, и вдруг бац! “Я недостаточно хорош…”. “А правильно ли я понял задачу?”. И другие похожие вариации одного и того же вопроса.

Если по-простому, то причина – недостаток подкрепления, обратной связи. Дальше есть разница в количестве и глубине этой обратной связи: есть те, кому достаточно, чтоб на них не орали, а есть те, кому надо чуть ли не эссе написать со всеми его заслугами и успехами, и все равно будет мало. Но в общем, причина одна – мы ждем подтверждения и не получаем.

Синдром самозванца – вещь неприятная. Иррациональная. Заставляет постоянно делать себя лучше, работать больше, выдавать результат, на который нужно потратить всего себя, весь ресурс. Как итог – быстрое выгорание. Ну потому что опять же, вы стараетесь, но обратной связи снова недостаточно.

Очень опасная штука для начинающих руководителей. Особенно тимлидов. Потому что делаешь свои новые тимлидские задачи, пытаешься как-то для себя “закрепиться” здесь. Ловишь самозванца. Хочешь работать лучше. И идешь делать то, в чем ты уже был хорош раньше, например, код писать. В итоге топишь себя еще больше в рабочих часах, не успеваешь делать нормально свою новую тимлидскую работу, еще больше сомневаешься в своих достижениях. Жуть, одним словом. Порочный круг.

Что делать? Зависит от стадии. Часто причины уходят куда-то очень глубоко в психику, и помочь вам сможет только специалист по этой самой психике. Если случай попроще, то нужно взять и добиться этой самой обратной связи.

Варианты:

1. Требовать ОС от своего руководителя. Может даже, какой-то процесс завести, аля 1/1 пару раз в месяц, чтобы быть в тонусе все время

2. Вести учет своих результатов в каком-то формате, чтобы можно было взглянуть на весь список и такой: “Да, я реально много сделал, я молодец”

3. Посмотреть на других людей вокруг и убедиться, что они тоже лажают. И разрешить себе лажать. Не хочется говорить банальностей, но не лажает тот, кто ничего не делает

4. Пройти некий ассессмент по своим компетенциям. Это может быть обучение (примерно треть запросов из того, что я вижу, именно про это – убедиться, что я делаю все правильно и по науке). Или, допустим, менторинг, с опытным в вашей области экспертом

Наверняка, есть еще. Но это первое, что пришло мне в голову. Дополняйте своими версиями в комментариях. Будем побеждать всеобщего внутреннего самозванца 🙂