У меня есть для вас подарок. Он поможет вам побеждать в переговорах.

Ведь когда устраиваешься на работу — переговоры о зарплате. Хочешь больше людей — переговоры о найме и ресурсах.

Крис Восс 27 лет проводил переговоры в ФБР, в том числе — с похитителями и настоящими террористами. Его методы спасали жизни. Теперь он учит этому бизнес.

Мой подарок — выжимка из его книги "Никаких компромиссов". В выжимке: система ведения переговоров, набор инструментов, конкретных приемов и критериев успеха. Если у вас есть время, купите и прочитайте книгу целиком. Если нет, мой гайд на 6 страниц поможет начать использовать методику. Без воды.

Бесплатно. Без email, регистрации и СМС. Просто заберите и используйте на следующей встрече.

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

Надеюсь, подарок вам понравится. Приятного чтения!

P.S. Если примените хотя бы одну технику на следующей неделе и она сработает — напишите в комментариях. Мне важна обратная связь.

Инфекция CTO. Или парадокс накрутчиков в российском IT менеджменте.

Заметили, как каждый второй в IT за последние пару лет начал описывать свою должность как C-level?

И всё бы ничего — можно было бы просто посмеяться со стороны, если бы это не стало напоминать тот самый фильтр «опыта от трёх лет», который железобетонно перекрыл дорогу новичкам в российское IT.

Теперь, чтобы манагеру просто попасть на некоторые мероприятия или выступить там, нужно стать волком и прикрутить к себе громкий титул, желательно с буквой C. Причём никого не волнует, ты CTO Google Cloud или CTO стартапа из трёх человек, основанного твоим другом вчера. И все это делают.

Но это ещё цветочки. С поиском работы началось то же самое. Ни результативность, ни достижения, ни проекты, ни твои навыки никого не интересуют. Отфильтруют тебя только по двум вещам: сколько у тебя штатных единиц в подчинении и насколько громко сияет буква «С» в твоём титуле. Причем, это одновременно стреляет и по компаниям, которые теперь вынуждены плодить псевдо-С-level вакансии, чтобы люди соглашались у них работать.

А дальше — пока слабохарактерные кодеры, не умеющие врать, честно проходят миллионы алгоритмических интервью и системных дизайнов, чтобы работать за копейки, просто нужно успешно сказать про «700 тысяч человек в подчинении», добавить, какой ты великий CTO/CDO/CIO/CPO, и получить работу очередного «CTO» в следующей компании.

При этом в реальности, когда мы говорим о Top Management Team (TMT) или Senior Leaders — то это группа руководителей, влияющих на организацию целиком. Сюда входят CEO, CFO, CTO, CIO, CMO и другие «chief»-роли. Это те, кто определяют стратегию и направление развития компании в целом.

Так что если ты — тимлид команды из трёх человек и не отчитываешься генеральному директору или совету директоров, то пожалуйста, прекрати позориться, выдумывать себе C-level титулы и притворяться большим боссом.

Нет, ты не C-level. Эти роли в компании — единичный товар. Не бывает так, чтобы у тебя в конторе была сотня таких же бедолаг на букву «С».

Открой трудовую, посмотри, что там написано. Вразумительно и с чувством прочти это вслух, можешь даже не читать название своей компании, чтобы не разрушить картинку Волка с Уолл-стрит у себя в голове. А потом, напиши это у себя в подписи под именем. Спасибо.

PS возможно, таким честным постом обижу многих своих товарищей и знакомых. Но этим лишь докажу свою правоту. Поэтому воспринимайте это как мягкий укол, чтобы сделать нашу общую с вами индустрию лучше. Обнимаю! Всегда ваш, "завистливый не-CTO-но-мог-бы-быть" Кулешов.

Почему ретроспективы не работают

Многие ретроспективы дисфункциональны. Вместо того, чтобы служить механизмом continuous improvement, они помогают команде отпустить чувство вины по поводу проблем, которые не чинятся. Так получается, потому что стандартный исход ретроспективы – записать все проблемы в трекер, и либо вообще больше к ним не возвращаться, либо немного поисследовать, и только потом забить.

При этом, если покопать в Toyota Production System, откуда вообще пошла идея continuous improvement, можно найти конкретные вещи, которых не хватает сломанным ретроспективам:

👉В TPS у всех участников производственного процесса есть возможность (и более того, требование) остановить процесс разработки, когда обнаруживается проблема – вместо того, чтобы вернуться к ней только через пару недель на запланированной ретроспективе.
👉В TPS проблему пытаются исправить сразу же, не откладывая. В наших реальностях мы пытаемся быстро ее запатчить, обещая, что в будущем обязательно вернемся и поправим как надо – но приоритеты до этого никогда не доходят.
👉В TPS у результатов root cause analysis есть четкие дедлайны, ответственные и понятный ожидаемый исход. Сравните со стандартными "улучшить процесс" или "обновить документацию", которые появляются после ретроспектив.
👉В TPS действия, которые предпринимают по итогам инцидента, должны не давать повторяться исходной проблеме. Иначе говоря, это постоянные решения, а не временные.