Please open Telegram to view this post
VIEW IN TELEGRAM
Как проводить skip level митинги
Про skip level встречи я рассказывал уже не раз, но на всякий случай напомню. Чем дальше вы от линейных сотрудников в корпоративной иерархии, тем сильнее вы отрываетесь от реальности. Чтобы к этому разрыву приложить подорожник, рекомендуется регулярно проводить 1-1 встречи с сотрудниками тех, кого вы менеджерите.
Вот несколько советов, как вытащить максимум пользы из этих встреч:
👉Предупредите заранее, о чем будет встреча, а не просто молча закидывайте ее в календарь. Иначе несколько беспокойных ночей вашему собеседнику точно гарантированы. Вы можете либо заранее написать про свой план со скип-левелами куда-то в общий канал в Slack, либо просто закинуть список вопросов на подумать.
👉Используйте эти встречи, чтобы узнать, как воспринимаются важные для вас изменения. Слушать агрегированную информацию или проводить опросы – это одно, а живой фидбэк – лучший источник фактов.
👉Используйте эти встречи, чтобы протестировать отношение к каким-то будущим планам. Довольно удобный способ прощупать почву.
👉Используйте эти встречи, чтобы перепроверить, насколько вы действительно смогли выровнять разные команды и донести какие-то важные мысли до людей.
👉Отмечайте хорошие и плохие паттерны, которые повторяются у разных людей. Это хорошие сигналы о том, что в организации что-то требует вашего внимания.
Про skip level встречи я рассказывал уже не раз, но на всякий случай напомню. Чем дальше вы от линейных сотрудников в корпоративной иерархии, тем сильнее вы отрываетесь от реальности. Чтобы к этому разрыву приложить подорожник, рекомендуется регулярно проводить 1-1 встречи с сотрудниками тех, кого вы менеджерите.
Вот несколько советов, как вытащить максимум пользы из этих встреч:
👉Предупредите заранее, о чем будет встреча, а не просто молча закидывайте ее в календарь. Иначе несколько беспокойных ночей вашему собеседнику точно гарантированы. Вы можете либо заранее написать про свой план со скип-левелами куда-то в общий канал в Slack, либо просто закинуть список вопросов на подумать.
👉Используйте эти встречи, чтобы узнать, как воспринимаются важные для вас изменения. Слушать агрегированную информацию или проводить опросы – это одно, а живой фидбэк – лучший источник фактов.
👉Используйте эти встречи, чтобы протестировать отношение к каким-то будущим планам. Довольно удобный способ прощупать почву.
👉Используйте эти встречи, чтобы перепроверить, насколько вы действительно смогли выровнять разные команды и донести какие-то важные мысли до людей.
👉Отмечайте хорошие и плохие паттерны, которые повторяются у разных людей. Это хорошие сигналы о том, что в организации что-то требует вашего внимания.
Rubick
Jade Rubick - Why and how to do skip level 1-1s
I share what I've learned about doing skip level 1-1s.
Парадокс Тога
Замечали ли вы, что многие продукты, которые создавались, чтобы упростить какие-то ваши задачи, со временем становятся все сложнее и сложнее? В заметочнике появляются какие-то командные режимы работы, таск-трекер обрастает функциональностью CRM, а почтовый клиент насильно онбордит вас в продвинутые фильтры, которыми вы никогда не будете подьзоваться.
Оказывается, у этого явления есть название – парадокс Тога, он же – парадокс сложности. Он заключается в том, что продукты, которые разрабатываются с целью упростить выполнение задач для пользователей, на самом деле приводят к появлению новых, более сложных задач.
Одна из версий причин парадокса состоит в следующем. Как только продукт начинает хорошо закрывать какие-то задачи, у пользователей появляется больше свободного времени. Они находят для себя новые задачи, и начинают требовать от продукта, чтобы он помогал решать и их. Этот цикл получается бесконечным – требования растут, продукт усложняется, и в итоге становится настолько сложным, что для простого решения его базовых задач нужно уже что-то новое.
Замечали ли вы, что многие продукты, которые создавались, чтобы упростить какие-то ваши задачи, со временем становятся все сложнее и сложнее? В заметочнике появляются какие-то командные режимы работы, таск-трекер обрастает функциональностью CRM, а почтовый клиент насильно онбордит вас в продвинутые фильтры, которыми вы никогда не будете подьзоваться.
Оказывается, у этого явления есть название – парадокс Тога, он же – парадокс сложности. Он заключается в том, что продукты, которые разрабатываются с целью упростить выполнение задач для пользователей, на самом деле приводят к появлению новых, более сложных задач.
Одна из версий причин парадокса состоит в следующем. Как только продукт начинает хорошо закрывать какие-то задачи, у пользователей появляется больше свободного времени. Они находят для себя новые задачи, и начинают требовать от продукта, чтобы он помогал решать и их. Этот цикл получается бесконечным – требования растут, продукт усложняется, и в итоге становится настолько сложным, что для простого решения его базовых задач нужно уже что-то новое.
Votito
Tog's paradox
Tog’s Paradox (also known as The Complexity Paradox or Tog’s ComplexityParadox) is an observation that products aiming to simplify a task for users tend toinspire new, more complex tasks. It’s one ...
Про найм сеньоров
Все больше и больше компаний отказываются от идеи нанимать и расти джунов, и хотят с порога получать матерых сеньоров. Проблема, конечно, очевидна – если никто не будет нанимать и обучать начинающих специалистов, то через несколько лет мы столкнемся с еще большим кризисом квалифицированных работников, чем есть на рынке сейчас.
Тема не новая, мы в канале ее уже довольно подробно обсуждали. Но вот несколько идей из новой статьи, которые мне понравились:
👉Бигтех все равно продолжит нанимать начинающих специалистов – у них есть и ресурсы, и кадровый голод там выражен сильнее. Но если такие компании останутся единственным способом войти в IT, мы на выходе получим инженеров, сильно заточенных под очень специфичную инженерную культуру, с сильным мнением по поводу технического стека, и не очень хорошо действующих в режиме неопределенности.
👉"Сеньорность" – понятие относительное, и значимая часть ценности опытных инженеров в хорошем понимании специфики именно их компании. Такое понимание появляется только с годами опыта. Найм джунов – возможность вырастить таких сеньоров самостоятельно. Поэтому, если вы планируете оставаться на своем рынке долго и расти, нанимать джунов точно надо.
Все больше и больше компаний отказываются от идеи нанимать и расти джунов, и хотят с порога получать матерых сеньоров. Проблема, конечно, очевидна – если никто не будет нанимать и обучать начинающих специалистов, то через несколько лет мы столкнемся с еще большим кризисом квалифицированных работников, чем есть на рынке сейчас.
Тема не новая, мы в канале ее уже довольно подробно обсуждали. Но вот несколько идей из новой статьи, которые мне понравились:
👉Бигтех все равно продолжит нанимать начинающих специалистов – у них есть и ресурсы, и кадровый голод там выражен сильнее. Но если такие компании останутся единственным способом войти в IT, мы на выходе получим инженеров, сильно заточенных под очень специфичную инженерную культуру, с сильным мнением по поводу технического стека, и не очень хорошо действующих в режиме неопределенности.
👉"Сеньорность" – понятие относительное, и значимая часть ценности опытных инженеров в хорошем понимании специфики именно их компании. Такое понимание появляется только с годами опыта. Найм джунов – возможность вырастить таких сеньоров самостоятельно. Поэтому, если вы планируете оставаться на своем рынке долго и расти, нанимать джунов точно надо.
Medium
The Senior Shortcut
Many have predicted the death of the “junior engineer” thanks to AI; after all, if AI can do all of the simple tasks, we don’t need to hire…
Моделируем рост инженерной команды
Если ваша компания серьезно думает о расходах, то рано или поздно встанет вопрос того, насколько эффективно расходуются деньги на инженерную команду, и как выстроить политики найма таким образом, чтобы ее стоимость не росла значительно со временем.
Автор строит довольно простую модель, в которой можно покрутить несколько вещей:
👉Частота найма для каждого грейда
👉Частота повышения между грейдами
👉Частота увольнений на каждом грейде
Вообще, вы можете сами поиграться с этой моделью, подставив туда близкие к реальности коэффициенты конкретно вашей компании. Общие выводы такие:
👉Если при увольнении инженера вы открываете вакансию на тот же самый грейд, то количество сеньоров со временем будет значительно расти.
👉Вместо этого лучше использовать политику "нанимаем замену на уровень ниже".
👉Если вы хотите, чтобы процент сеньоров не поднимался выше определенного уровня, единственный способ это обеспечить – ввести ограничение сверху.
Если ваша компания серьезно думает о расходах, то рано или поздно встанет вопрос того, насколько эффективно расходуются деньги на инженерную команду, и как выстроить политики найма таким образом, чтобы ее стоимость не росла значительно со временем.
Автор строит довольно простую модель, в которой можно покрутить несколько вещей:
👉Частота найма для каждого грейда
👉Частота повышения между грейдами
👉Частота увольнений на каждом грейде
Вообще, вы можете сами поиграться с этой моделью, подставив туда близкие к реальности коэффициенты конкретно вашей компании. Общие выводы такие:
👉Если при увольнении инженера вы открываете вакансию на тот же самый грейд, то количество сеньоров со временем будет значительно расти.
👉Вместо этого лучше использовать политику "нанимаем замену на уровень ниже".
👉Если вы хотите, чтобы процент сеньоров не поднимался выше определенного уровня, единственный способ это обеспечить – ввести ограничение сверху.
Как менеджерам не попасть под сокращения
Регулярные массовые сокращения стали уже привычной новостью. Только за прошедший месяц сходу вспоминается два громких лэйоффа в ABBYY и в Miro. Логика выбора того, кого сократить, в каждом конкретном случае отличается, но можно выделить общие паттерны, которые увеличивают или уменьшают ваши риски.
Какие категории сотрудников обычно попадают под сокращения:
👉Accodentally Invisible. Работа, которую они делают, не видна топ-менеджменту, даже если она важная
👉Faded Glory. Когда-то сделали важный проект, но в последнее время он перестал быть кому-ьо интересен.
👉Needs Auxiliary Management. Есть заметные со стороны проблемы с качеством работы, коммитментами, софт-скиллами, так что для работы с ними требуется прилагать больше усилий.
👉Kingdom of None. Если всю или значимую часть команды сокращают, то менеджер попадает туда же под раздачу. Это касается не только прямого менеджера, но и любых технических лидов.
Вот несколько советов, как тимлиду и его команде уменьшить свои шансы попасть под лэйофф:
👉Активно помогать людям в своей команде находить возможности достичь заметных всем результатов. Верно и обратное – как только вы понимаете, что проекты, над которыми вы работаете, не важны топ-менеджменту, надо либо найти возможность вернуть им актуальность, либо перевести команду куда-то еще.
👉Помогать своей команде достигать этих результатов, в том числе быстро и явно рассказывая им про проблемы с их перфомансом.
👉Делать так, чтобы работа вашей команды была заметна топ-менеджменту, и ее важность была понятна. Это особенно важно для всяких около-инфраструктурных штук, которые влияют вообще на все, но абсолютно невидимы со стороны.
Регулярные массовые сокращения стали уже привычной новостью. Только за прошедший месяц сходу вспоминается два громких лэйоффа в ABBYY и в Miro. Логика выбора того, кого сократить, в каждом конкретном случае отличается, но можно выделить общие паттерны, которые увеличивают или уменьшают ваши риски.
Какие категории сотрудников обычно попадают под сокращения:
👉Accodentally Invisible. Работа, которую они делают, не видна топ-менеджменту, даже если она важная
👉Faded Glory. Когда-то сделали важный проект, но в последнее время он перестал быть кому-ьо интересен.
👉Needs Auxiliary Management. Есть заметные со стороны проблемы с качеством работы, коммитментами, софт-скиллами, так что для работы с ними требуется прилагать больше усилий.
👉Kingdom of None. Если всю или значимую часть команды сокращают, то менеджер попадает туда же под раздачу. Это касается не только прямого менеджера, но и любых технических лидов.
Вот несколько советов, как тимлиду и его команде уменьшить свои шансы попасть под лэйофф:
👉Активно помогать людям в своей команде находить возможности достичь заметных всем результатов. Верно и обратное – как только вы понимаете, что проекты, над которыми вы работаете, не важны топ-менеджменту, надо либо найти возможность вернуть им актуальность, либо перевести команду куда-то еще.
👉Помогать своей команде достигать этих результатов, в том числе быстро и явно рассказывая им про проблемы с их перфомансом.
👉Делать так, чтобы работа вашей команды была заметна топ-менеджменту, и ее важность была понятна. Это особенно важно для всяких около-инфраструктурных штук, которые влияют вообще на все, но абсолютно невидимы со стороны.
Chelsea Troy
What layoffs teach us about technical leadership
By the way, you can listen to me read this post aloud on my Patreon, along with many other audio recordings. In March I published a piece called How do we evaluate people for their technical leader…
Please open Telegram to view this post
VIEW IN TELEGRAM
Как группа становится командой: фаза нормализации
Новая глава (а вернее, даже сразу несколько) эпоса Дмитрия Болдырева про бригаду монтажников, которых забросили далеко-далеко в тайгу, и они постепенно учатся работать вместе, проходя все те же этапы, что и любая команда разработки.
В этот раз разбирается, что с группой происходит после фазы шторминга и острого конфликта: как именно люди переживают произошедшее, как пересматриваются устоявшиеся порядки в группе, отношение ее участников к ситуации и друг к другу.
Новая глава (а вернее, даже сразу несколько) эпоса Дмитрия Болдырева про бригаду монтажников, которых забросили далеко-далеко в тайгу, и они постепенно учатся работать вместе, проходя все те же этапы, что и любая команда разработки.
В этот раз разбирается, что с группой происходит после фазы шторминга и острого конфликта: как именно люди переживают произошедшее, как пересматриваются устоявшиеся порядки в группе, отношение ее участников к ситуации и друг к другу.
Telegraph
Как группа становится командой, часть 3. Стадия нормализации отношений
Дмитрий Болдырев
Исправляем недостаток стратегического фреймворка Румельта
Продолжаю топить за то, что лучшая книга, которая может вас научить тому, что такое стратегия – "Good Strategy, Bad Strategy". Ключевая идея автора книги, Ричарда Румельта, в том, что хорошая стратегия должна строиться вокруг челленджей, которые компании требуется преодолеть, чтобы достичь своих целей. Вокруг этих челленджей выстраивается ядро стратегии – набор "направляющих политик" – принципов, по которым вы работаете, и конкретных усиляющих друг друга действий.
Так вот, мне всегда казалось, что во фреймворке не хватает одного важного компонента – ставок на то, как будет развиваться будущее. Вера компании в какой-то конкретный сценарий должна сильно влиять на принимаемые решения. Поэтому я всегда в разделе с диагнозом старался в явном виде описать, каким мы видим будущее, и почему верим, что оно будет именно таким.
Точка зрения автора статьи полностью совпадает с моей, но он преисполнился настолько, что даже обсудил ее в переписке с самим Румельтом. В общем, если вы уже читали книгу, статью точно рекомендую. Если не читали – ну вы поняли, что делать на выходных.
Кстати, благодаря этой статье я узнал, что сравнительно недавно Румельт выпустил продолжение – The Crux. Как прочитаю, обязательно поделюсь впечатлениями!
Продолжаю топить за то, что лучшая книга, которая может вас научить тому, что такое стратегия – "Good Strategy, Bad Strategy". Ключевая идея автора книги, Ричарда Румельта, в том, что хорошая стратегия должна строиться вокруг челленджей, которые компании требуется преодолеть, чтобы достичь своих целей. Вокруг этих челленджей выстраивается ядро стратегии – набор "направляющих политик" – принципов, по которым вы работаете, и конкретных усиляющих друг друга действий.
Так вот, мне всегда казалось, что во фреймворке не хватает одного важного компонента – ставок на то, как будет развиваться будущее. Вера компании в какой-то конкретный сценарий должна сильно влиять на принимаемые решения. Поэтому я всегда в разделе с диагнозом старался в явном виде описать, каким мы видим будущее, и почему верим, что оно будет именно таким.
Точка зрения автора статьи полностью совпадает с моей, но он преисполнился настолько, что даже обсудил ее в переписке с самим Румельтом. В общем, если вы уже читали книгу, статью точно рекомендую. Если не читали – ну вы поняли, что делать на выходных.
Кстати, благодаря этой статье я узнал, что сравнительно недавно Румельт выпустил продолжение – The Crux. Как прочитаю, обязательно поделюсь впечатлениями!
Kellblog
Strategy as a Series of Beliefs
I’m always looking for better ways to distill strategy. My favorite strategy author is Richard Rumelt, who wrote Good Strategy, Bad Strategy and the more recent but less acclaimed follow-on, The Crux. I love Rumelt’s work for two reasons: Much … Continue…
Ошибки начинающих техлидов в принятии решений
Часто при принятии решений техлиды полагаются на общепринятые практики, не понимая смысла за ними. В итоге они применяются в контексте, для которого не предназначены, не решают исходной проблемы, и создают новые. Плюс к этому возникают разные неприятные сайд-эффекты. Например, менеджер не может внятно ответить на вопрос зачем он сделал то, что сделал. А команда вообще может настроиться против примененной практики, даже если в будущем она будет вполне себе применима.
Как пример – техлид может затащить автотесты в проект, в котором они только мешают, тем самым саботировав их использование командой в будущем в других местах.
Помимо этой ошибки, автор разбирает еще две – создание постоянного давления на команду от искуственных дедлайнов и паралич в принятии решений, вызванной попыткой удовлетворить вообще все возможные критерии.
Часто при принятии решений техлиды полагаются на общепринятые практики, не понимая смысла за ними. В итоге они применяются в контексте, для которого не предназначены, не решают исходной проблемы, и создают новые. Плюс к этому возникают разные неприятные сайд-эффекты. Например, менеджер не может внятно ответить на вопрос зачем он сделал то, что сделал. А команда вообще может настроиться против примененной практики, даже если в будущем она будет вполне себе применима.
Как пример – техлид может затащить автотесты в проект, в котором они только мешают, тем самым саботировав их использование командой в будущем в других местах.
Помимо этой ошибки, автор разбирает еще две – создание постоянного давления на команду от искуственных дедлайнов и паралич в принятии решений, вызванной попыткой удовлетворить вообще все возможные критерии.
Chelsea Troy
Decision-Making Pitfalls for Technical Leaders
By the way, you can listen to me read this post aloud on my Patreon, along with many other audio recordings. Tech’s favorite party trick is promoting programmers into leadership roles with ze…
Про приоритизацию в больших компаниях
👉Не бывает одной самой приоритетной задачи, вы неизбежно закончите тем, что будете балансировать между несколькими проектами, каждый из которых оценивается как самый важный. Одна из причин – оргдизайн в больших компаниях не поспевает за изменениями приоритетов.
👉Большинство топ-менеджеров понимает, что приоритеты будут постоянно меняться, поэтому они больше думают про распределение бюджета между командами. Поэтому, если вам кажется, что вам не спускают явной стратегии и приоритизации, не забывайте, что где-то там за кулисами это происходит, но на другом уровне.
👉Перераспределять приоритеты сложно из-за человеческих страхов. Очень легко провести логическую связь между понижением приоритета или отменой проекта и вероятностью своего собственного сокращения.
👉Не бывает одной самой приоритетной задачи, вы неизбежно закончите тем, что будете балансировать между несколькими проектами, каждый из которых оценивается как самый важный. Одна из причин – оргдизайн в больших компаниях не поспевает за изменениями приоритетов.
👉Большинство топ-менеджеров понимает, что приоритеты будут постоянно меняться, поэтому они больше думают про распределение бюджета между командами. Поэтому, если вам кажется, что вам не спускают явной стратегии и приоритизации, не забывайте, что где-то там за кулисами это происходит, но на другом уровне.
👉Перераспределять приоритеты сложно из-за человеческих страхов. Очень легко провести логическую связь между понижением приоритета или отменой проекта и вероятностью своего собственного сокращения.
Linkedin
For a long time, I had very naive ideas about prioritization. Here's what… | John Cutler | 63 comments
For a long time, I had very naive ideas about prioritization. Here's what I've learned over the years.
1. Unless you are a tiny startup, your company is designed to do multiple high-priority things at once. The argument, "Well, if everything is high priority…
1. Unless you are a tiny startup, your company is designed to do multiple high-priority things at once. The argument, "Well, if everything is high priority…
Про системное моделирование
Помните, на прошлой неделе я выкладывал статью с моделью роста инженерной команды в зависимости от политик найма на разные грейды? Так вот, держите продолжение – автор рассказывает, как вообще работать с системным моделированием, в каких кейсах оно может быть полезно, какой тулинг использовать, и как применять при разработке технической стратегии.
Помните, на прошлой неделе я выкладывал статью с моделью роста инженерной команды в зависимости от политик найма на разные грейды? Так вот, держите продолжение – автор рассказывает, как вообще работать с системным моделированием, в каких кейсах оно может быть полезно, какой тулинг использовать, и как применять при разработке технической стратегии.
Lethain
Using systems modeling to refine strategy.
While I was probably late to learn the concept
of strategy testing,
I might have learned about systems modeling too early in my career,
stumbling on Donella Meadows’ Thinking in Systems: A Primer
before I began my career in software.
Over the years, I’ve…
of strategy testing,
I might have learned about systems modeling too early in my career,
stumbling on Donella Meadows’ Thinking in Systems: A Primer
before I began my career in software.
Over the years, I’ve…
Результаты большого исследования тимлидов
Я проводил исследования мобильных разработчиков, продактов и тимлидов довольно долго, еще с 2017 года. И вот этот рисерч – первый, который проводился вообще без меня, так как я решил полностью выйти из проекта. Поэтому я вдвойне рад, что у ребят все получилось, и несу вам разные интересные инсайты из него:
👉Основные обязанности руководителя: собеседования, развитие людей и оценка перфоманса.
👉Напрямую зарплатами своей команды управляет только половина линейных тимлидов.
👉Большинство руководителей тратит на написание кода не больше 30% своего времени.
👉Самыми важными навыками считают умение работать с людьми и командами. А вот, например, обеспечение качества болтается где-то в самом низу списка, что заставляет где-то грустить одного Виталия Шароватова.
👉Самая разочаровавшая всех книга – "Как пасти котов" 😅
👉Основной критерий выбора компании для работы – зарплата.
Я проводил исследования мобильных разработчиков, продактов и тимлидов довольно долго, еще с 2017 года. И вот этот рисерч – первый, который проводился вообще без меня, так как я решил полностью выйти из проекта. Поэтому я вдвойне рад, что у ребят все получилось, и несу вам разные интересные инсайты из него:
👉Основные обязанности руководителя: собеседования, развитие людей и оценка перфоманса.
👉Напрямую зарплатами своей команды управляет только половина линейных тимлидов.
👉Большинство руководителей тратит на написание кода не больше 30% своего времени.
👉Самыми важными навыками считают умение работать с людьми и командами. А вот, например, обеспечение качества болтается где-то в самом низу списка, что заставляет где-то грустить одного Виталия Шароватова.
👉Самая разочаровавшая всех книга – "Как пасти котов" 😅
👉Основной критерий выбора компании для работы – зарплата.
Friction logs
Догфудинг – один из лучших способов улучшить свой продукт. Вы надеваете на себя шапку своего типичного пользователя, пробуете от его лица выполнить какие-то сценарии, и жутко страдаете, когда понимаете, насколько плохо все продумано в мелочах.
Но попробовать и пострадать – этого мало. С результатами такого эксперимента хорошо бы что-то сделать. В статье предлагают создавать на их основе специальные документы, friction logs, которые описывают каждую неудобную мелочь, с которой вы столкнулись, включая эмоции, которые в этот момент испытали.
Догфудинг – один из лучших способов улучшить свой продукт. Вы надеваете на себя шапку своего типичного пользователя, пробуете от его лица выполнить какие-то сценарии, и жутко страдаете, когда понимаете, насколько плохо все продумано в мелочах.
Но попробовать и пострадать – этого мало. С результатами такого эксперимента хорошо бы что-то сделать. В статье предлагают создавать на их основе специальные документы, friction logs, которые описывают каждую неудобную мелочь, с которой вы столкнулись, включая эмоции, которые в этот момент испытали.
Sbensu
How to: friction logs
Friction logs are a technique to improve your own products and understand others. You use the produdct the way a real user would and write down every single moment you experience some form of negative emotion.
Forwarded from Тимлид не спит: разбор менеджерских болей, вопросов и кейсов
Публикуем новый кейс + разбор от экспертов канала!
👉 Кейс #9 Политический конфликт
Директор отдела смежников имеет личный конфликт с директором вашего отдела из-за неразделенных амбиций(ваш отобрал область задач и влияния у другого пару лет назад). Это сильно мешает работе твоей команды, когда вам нужно иметь дело с зоной ответственности смежников. Тяжелые кодревью, невозможность синхронизировать планы или получить апрув на изменения в пересекающихся доменах стали вашей реальностью последние пару лет. Все потому, что у соседей когда-то забрали кусок предметки и то не вы.
Топы уровнем выше признают проблему, но не могут ничего с этим сделать. Оба директора компетентны и решают задачи бизнеса хорошо. Проблема усугубляется тем, что уже ваша команда накопила вагон обидок и претензий, и начинает предвзято относится к соседям во всех вопросах.
Найти общие вектора и договориться тоже не получается, потому что договариваться никто не хочет.
Что делать не понятно. С уровня руководителя команды помирить директоров сложно, да и вроде не твоя задача. Команда, домен и работа нравится, но воевать за каждый шаг в предметке надоело и мне и команде. Очевидное решение для топов вернуть домен назад вместе с командой, но к смежникам в отдел идти уже никто не захочет в силу накопленного негативного опыта. Да и странно из-за обидок и амбиций двух людей дамажить работу нескольких команд.
❔Поделитесь, решали ли что-то подобное. Может кто-то медиацию пробовал или что-то похожее?
💬Разбор от экспертов
Кейс разбирали:
👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного обшения", управляющий партнер Школы менеджмента Стратоплан
👉 Миша Шляхов @tehaleph - техлид из Tutu.ru
👉 Кейс #9 Политический конфликт
Директор отдела смежников имеет личный конфликт с директором вашего отдела из-за неразделенных амбиций(ваш отобрал область задач и влияния у другого пару лет назад). Это сильно мешает работе твоей команды, когда вам нужно иметь дело с зоной ответственности смежников. Тяжелые кодревью, невозможность синхронизировать планы или получить апрув на изменения в пересекающихся доменах стали вашей реальностью последние пару лет. Все потому, что у соседей когда-то забрали кусок предметки и то не вы.
Топы уровнем выше признают проблему, но не могут ничего с этим сделать. Оба директора компетентны и решают задачи бизнеса хорошо. Проблема усугубляется тем, что уже ваша команда накопила вагон обидок и претензий, и начинает предвзято относится к соседям во всех вопросах.
Найти общие вектора и договориться тоже не получается, потому что договариваться никто не хочет.
Что делать не понятно. С уровня руководителя команды помирить директоров сложно, да и вроде не твоя задача. Команда, домен и работа нравится, но воевать за каждый шаг в предметке надоело и мне и команде. Очевидное решение для топов вернуть домен назад вместе с командой, но к смежникам в отдел идти уже никто не захочет в силу накопленного негативного опыта. Да и странно из-за обидок и амбиций двух людей дамажить работу нескольких команд.
❔Поделитесь, решали ли что-то подобное. Может кто-то медиацию пробовал или что-то похожее?
💬Разбор от экспертов
Кейс разбирали:
👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного обшения", управляющий партнер Школы менеджмента Стратоплан
👉 Миша Шляхов @tehaleph - техлид из Tutu.ru
Telegraph
👉 Кейс #9 "Политический конфликт"
Разбор от экспертов 👉Александр: Чтобы ответить на вопрос «Что делать?», нужно понимать, что у нас всегда есть три способа реагирования на любую ситуацию: 1. Изменить ситуацию. 2. Принять ее. 3. Озвучить свое отношение к происходящему и выйти. К сожалению…
Как техдолг влияет на AI
Лучше всего AI инструменты вроде Cursor работают на кодовых базах, которые разбиты на модули с понятными названиями и зоной ответственности. Иначе говоря, чем проще вам объяснить все взаимодействия и потоки данных в коде, тем проще генеративному AI будет с ними работать.
Из этого проистекает довольно очевидная мысль, о которой я раньше не думал – чем больше у вас технического долга, тем меньше пользы вы будете получать от использования AI, а разница в скорости разработки в сравнении с новыми проектами вырастет еще сильнее.
Лучше всего AI инструменты вроде Cursor работают на кодовых базах, которые разбиты на модули с понятными названиями и зоной ответственности. Иначе говоря, чем проще вам объяснить все взаимодействия и потоки данных в коде, тем проще генеративному AI будет с ними работать.
Из этого проистекает довольно очевидная мысль, о которой я раньше не думал – чем больше у вас технического долга, тем меньше пользы вы будете получать от использования AI, а разница в скорости разработки в сравнении с новыми проектами вырастет еще сильнее.
www.gauge.sh
AI Makes Tech Debt More Expensive - Gauge - Solving the monolith/microservices dilemma
AI increases the penalty for low quality code. Gauge is solving the monolith/microservices dilemma. We’re building tools to untangle codebases through incremental modularization. Our open-source toolkit supports defining and enforcing rules for interfaces…
Как доводить до успеха проекты в бигтехе
В больших компаниях проект считается запущенным не в тот момент, когда он задеплоен на прод, или когда им начали пользоваться люди. Запущенным он считается тогда, когда топ-менеджмент в это поверит. Иначе говоря, если ваша система задеплоена, но СЕО очень не доволен результатом – это провал.
Из этого следует, что ответственному за запуск проекта инженеру нужно думать не только о коде и об архитектуре, но и про следующие вещи:
👉Иметь четкое представление о том, какую пользу компания хочет получить от вашего проекта. Это могут быть как явные вещи, вроде денег и пользователей, так и менее явные, например, личная заинтересованность какого-то VP.
👉Поддерживать доверие к вам заинтересованных в проекте менеджеров. Ни у кого из них не будет технического контекста происходящего, поэтому во всем, что касается сроков и рисков, они будут полагаться на ваше суждение. Если доверие пропадет, шансы проекта на успех резко снизятся.
👉Оставлять себе достаточно свободного времени, чтобы иметь возможность быстро среагировать на неожиданные проблемы и сомнения каких-то соседних команд и стейкхолдеров.
👉Пытаться предугадать возможные будущие проблемы и заранее продумывать, как митигировать эти риски. Хороший способ делать это – регулярно задавать себе вопрос "Что мне могло бы помешать выпустить проект прямо сегодня?"
В больших компаниях проект считается запущенным не в тот момент, когда он задеплоен на прод, или когда им начали пользоваться люди. Запущенным он считается тогда, когда топ-менеджмент в это поверит. Иначе говоря, если ваша система задеплоена, но СЕО очень не доволен результатом – это провал.
Из этого следует, что ответственному за запуск проекта инженеру нужно думать не только о коде и об архитектуре, но и про следующие вещи:
👉Иметь четкое представление о том, какую пользу компания хочет получить от вашего проекта. Это могут быть как явные вещи, вроде денег и пользователей, так и менее явные, например, личная заинтересованность какого-то VP.
👉Поддерживать доверие к вам заинтересованных в проекте менеджеров. Ни у кого из них не будет технического контекста происходящего, поэтому во всем, что касается сроков и рисков, они будут полагаться на ваше суждение. Если доверие пропадет, шансы проекта на успех резко снизятся.
👉Оставлять себе достаточно свободного времени, чтобы иметь возможность быстро среагировать на неожиданные проблемы и сомнения каких-то соседних команд и стейкхолдеров.
👉Пытаться предугадать возможные будущие проблемы и заранее продумывать, как митигировать эти риски. Хороший способ делать это – регулярно задавать себе вопрос "Что мне могло бы помешать выпустить проект прямо сегодня?"
Seangoedecke
How I ship projects at big tech companies
What I think about when I'm lead engineer on a project
Как договариваться о росте хедкаунта
Чтобы убедить менеджера выделить вам в команду больше людей, вам в первую очередь надо убедить его в том, что команда в своем текущем составе уже отлично справляется. Для этого вам надо выровняться по следующим вопросам:
👉Решаемая командой проблема важна
👉Все согласны с выбранным подходом к решению этой проблемы
👉Команда в своем текущем составе уже отлично справляется с разработкой этого решения
👉Как конкретно добавление новых людей повлияет на результаты решения проблемы: скорость, качество, что-то еще
Чтобы убедить менеджера выделить вам в команду больше людей, вам в первую очередь надо убедить его в том, что команда в своем текущем составе уже отлично справляется. Для этого вам надо выровняться по следующим вопросам:
👉Решаемая командой проблема важна
👉Все согласны с выбранным подходом к решению этой проблемы
👉Команда в своем текущем составе уже отлично справляется с разработкой этого решения
👉Как конкретно добавление новых людей повлияет на результаты решения проблемы: скорость, качество, что-то еще
Lethain
How to get more headcount.
One of the recurring challenges that teams face is getting headcount to support their initiatives.
A similar problem is the idea that a team can’t get a favored project into their roadmap.
In both cases, teams often create a story about how clueless executives…
A similar problem is the idea that a team can’t get a favored project into their roadmap.
In both cases, teams often create a story about how clueless executives…
Please open Telegram to view this post
VIEW IN TELEGRAM
Тактики выживания в корпорации
Держите плейлист на выходные из 15 коротких видео про разные аспекты выживания в корпорации.
Я их еще не посмотрел, но за автора могу ручаться – я буквально недавно проходил его курс про product sense, и мне очень понравился и его опыт, и то, как он мыслит.
Держите плейлист на выходные из 15 коротких видео про разные аспекты выживания в корпорации.
Я их еще не посмотрел, но за автора могу ручаться – я буквально недавно проходил его курс про product sense, и мне очень понравился и его опыт, и то, как он мыслит.
YouTube
Navigating Your Organization Like a Pro
Want to learn more from me? I teach 2 courses to ambitious product people: Improving your Product Sense: https://bit.ly/product-sense Managing your Product C...