Как хвастаться своей работой

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

Есть несколько правил, которые позволяют хвастаться своими успехами таким образом, чтобы это не воспринималось противоестественно и было полезно другим людям:

👉Идеально, когда про вас рассказывают другие люди. Для этого нужно уметь вовремя оказывать помощь тем, кому она может пригодиться. Например, когда кто-то работает над знакомой вам задачей, вы можете поделиться своим опытом, или скинуть сохранившиеся документы.
👉Регулярно делитесь в релевантных каналах синтезом результатов своей работы в таком формате, чтобы это было полезно другим. Например, закончив большой проект, поделитесь lessons learned. Не забудьте дойти и до тех, кто когда-то высказывал интерес к этому проекту.
👉Не создавайте дополнительной работы для других, и явно пишите, зачем вы шарите что-то – требуется ли от читателей какое-то действие, или просто показываете для ознакомления.
👉Почаще делитесь и результатами других людей. Все как в одном из примеров выше – если кто-то работает над проблемой, а вы встречали релевантные идеи у кого-то еще, обязательно пришлите их человеку.
👉Избегайте частых ошибок: не шарьте работу плохого качества, не уделяйте слишком много внимания процессу вместо результатов и инсайтов, делитесь работой других чаще, чем своей.

Советы по созданию линеек грейдов

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

Но если вы уверены, что вам нужно описание карьерных уровней, вот набор советов от человека, который первым выложил карьерный фреймворк своей компании в открытый доступ:

👉Не давайте HR составлять описания уровней, получится фигня. Определять требуемый уровень экспертизы для разных уровней вообще не их работа.
👉Детали важны. Если ваше описание уровней похоже на гороскоп, оно будет только вредить. Субъективных штук вроде "high impact", "large systems" не избежать, но вы можете постараться минимизировать количество таких абстрактных терминов, и дать хоть какую-то шкалу для их оценки.
👉Хороший способ объяснить смысл и логику за табличкой – сопроводить ее подробным блог-постом.
👉Постарайтесь не превращать эту табличку в чек-лист компетенций, который гарантирует промо на следующий уровень по его заполнению. Промо – функция не только навыков человека, но и текущих потребностей компании.
👉Будьте честными – не для каждой профессии можно подготовить линейку от самых низких уровней до VP.

Про big bets

Big bet – типичное название для большой и стратегически важной инициативы, в которой напрямую заинтересован СЕО или кто-то из топов. Чаще всего они тащат за собой кучу скрытых рисков и проблем, включая ухудшение морали команды и отток ресурсов от других важных направлений.

Отличительные признаки большой ставки:

1️⃣Топ-менеджмент говорит о ней таким образом, как будто у нее нет никаких продуктовых и бизнесовых рисков, и единственное, что может пойти не так – execution.
2️⃣Проект получает не меньше ресурсов, чем полноценные зрелые направления, несмотря на свою раннюю стадию.
3️⃣Он заявляется как стратегически важный.

Так вот, лидить такой проект чаще всего плохая идея. Вот почему:

👉Как я и сказал выше, топ-менеджеры слишком верят в то, что проект выстрелит – поэтому если он провалится, то вся вина будет на лиде, который не смог его заделиверить.
👉Из-за вот этой чрезмерной уверенности, такие проекты минуют все стадии адекватной продуктовой разработки – часто нет ни исследования рынка, не проверки продуктовой гипотезы, вообще ничего. Короче говоря, big bet – это очень конкретное решение для несформулированной и непроверенной проблемы.

Учимся учиться на инцидентах

Происходит инцидент. Минимально необходимое требование – потушить пожар и вернуть ваш продукт в рабочее состояние. Задача со звездочкой – найти и устранить корневую причину его возникновения. Стандартная техника для этого – RCA, Root Cause Analysis. Это очень прямолинейный подход с понятной ценностью для команд. Но в больших и сложных системах только RCA бывает недостаточно.

Тут на сцену выходит сравнительно новый подход LFI, Learning from Incidents. В отличие от RCA, главная цель LFI – узнать новые детали про то, как работает система, и обогатить ментальную модель тех, кто ее поддерживает. Логика простая – очень часто в процессе устранения инцидента помимо корневой проблемы можно узнать много других интересных вещей и выявить какие-то проблемы, которые могут отстрелить где-то в будущем.

Иначе говоря, RCA фокусируется на known unknowns, а LFI – unknown unknowns.

Про уровни AI fluency

Умение грамотно использовать AI постепенно становится обязательным требованием во многих компаниях. Zapier рассказывают, как они классифицируют это умение в рамках разных ролей. В общем виде выделяют четыре уровня:

1️⃣Unacceptable: AI-скептики, не используют никакие инструменты, отрицают их ценность.
2️⃣Capable: Есть хотя бы несколько месяцев опыта работы с самыми популярными инструментами.
3️⃣Adoptive: Встраивают AI в свои личные привычки и воркфлоу. Умеют писать качественные промпты и улучшать их, связывать модели друг с другом, автоматизировать задачи.
4️⃣Transformative: Используют AI не как инструмент, а как способ создать что-то новое, что было бы невозможным еще пару лет назад.

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

Как LLM могут помочь с личным бэклогом

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

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

В статье есть конкретные промпты, если решите попробовать.

Баланс между отсутствием и микроменеджментом

Работа менеджера – направлять команду на решение правильных проблем и делать так, чтобы со временем она начинала работать все лучше. Вовлеченность менеджера в команду балансирует между двумя крайностями:

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

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

Ephemeral Task Force как способ решения кросскомандных проблем

Держите еще один инструмент оргдизайна в вашу копилку – Ephemeral Task Force.

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

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

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

Что важно – у такого task force есть четко определенная задача, по достижению которой его расформировывают. Разные проблемы требуют разных составов участников, поэтому превращать такую команду в постоянный комитет скорее вредно.

Как AI влияет на способность думать

The fun has been sucked out of the process of creation because nothing I make organically can compete with what AI already produces—or soon will. All of my original thoughts feel like early drafts of better, more complete thoughts that simply haven’t yet formed inside an LLM.

Про что говорит автор – из-за постоянной работы с LLM он чувствует, что постепенно разучивается самостоятельно думать. Вместо самостоятельной интеллектуальной работы, с глубоким изучением источников, проработкой гипотез, встреченными тупиками и нерешенными задачами, гораздо проще написать промпт, закинуть его в чат, и сразу же получить разжеванный ответ. И, хоть конечный результат будет тем же самым, теряется много ценного, что ты получал в процессе самостоятельного исследования. Голые факты не заменяют знания.

Это касается любых областей знания, программирования в том числе. Буквально на днях друг рассказывал про молодого разработчика в своей команде, который более-менее справляется со своими задачами, генерируя весь код через AI, но часто не может объяснить, как он конкретно работает – причем не столько потому, что он не способен разобраться, сколько потому, что не хочет и не готов вникать без помощи LLM.

Как быть руководителем своего друга

👉Ключевое правило – явно разделять две роли и стараться их не смешивать. То, в какой именно роли в каждом взаимодействии вы находитесь, должно быть ясно и вам, и другу. Простой способ это сделать – явно сказать что-то вроде "Так, давай переключимся в рабочий режим".
👉Страшнее всего давать друзьям негативную обратную связь, потому что есть риск разрушить отношения. Но можно посмотреть на ситуацию с другой стороны – между вами уже есть доверие, друг знает, что у вас в его отношении только лучшие намерения. И это стоит использовать – "Я ценю, что могу быть супер открытым с тобой и рассказать все как есть".
👉Еще один способ наметить границы – говорить не от своего лица, а от бизнеса – что-то вроде "этого требует работа".
👉Иногда роли все-таки приходится немного смешивать. Например, вы можете рассказать неприятные новости в своей шапочке руководителя, а затем явно сказать, что сейчас будете говорить как друг, и включить дополнительную эмпатию.

Давайте обсудим, а проблема ли это? Насколько каждый участник команды должен быть вовлечен в то, что делают остальные? Отсутствие любопытства в чужом стеке – дисфункция или нормальное продуктивное поведение?

Как превратить группу в команду

Если вы помните, несколько месяцев назад Дмитрий Болдырев публиковал серию статей и видео про то, что вообще такое команда, и рассматривал историю группы суровых монтажников из прицела модели forming-storming-norming-performing. Но знать про то, как команды работают, это только часть дела. Самое сложное – их создавать!

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

Что подается на вход:
👉Люди – все, что касается индивидуальных особенностей членов команды
👉Группа – социальные и психологические факторы, влияющие на работу коллектива
👉Контекст – влияние организационного и глобального окружения на работу команды
👉Работа – особенности выполняемого задания

Какие рычаги есть:
👉Система управления командой – процессы, помогающие воздействовать на все перечисленные выше элементы
👉Командные взаимодействия – процессы взаиможействия между участниками
👉Эмерджентные состояния – эмоциональные и мотивационные состояния, которые возникают у группы в целом и её отдельных участников

Что получаем на выходе системы:
👉Результаты – оценка успешности

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