Вышла книга "Made at Intel"
Несколько последних лет на Хабре регулярно натыкался на серию постов менеджера-ветерана из Интела с разными историями про то, как была устроена их кухня. Причем историями довольно откровенными, после которых не возникало желания побежать туда работать.
Так вот, спустя несколько лет публикаций, автор, Валерий Черепенников, завернул все эти истории в книгу. Я еще не читал, но планирую в ближайшие месяцы – потом обязательно поделюсь впечатлениями!
Несколько последних лет на Хабре регулярно натыкался на серию постов менеджера-ветерана из Интела с разными историями про то, как была устроена их кухня. Причем историями довольно откровенными, после которых не возникало желания побежать туда работать.
Так вот, спустя несколько лет публикаций, автор, Валерий Черепенников, завернул все эти истории в книгу. Я еще не читал, но планирую в ближайшие месяцы – потом обязательно поделюсь впечатлениями!
Литрес
«Made at Intel: Сделано в Intel» – Валерий Черепенников | ЛитРес
Эта книга приоткроет дверь в закрытый мир ведущих транснациональных IT-корпораций. Её автор – Валерий Черепенников – проработал на руководящих должностях более 25 лет. Занимал посты директора «Интел»…
Snow melts at the periphery
Чем более сеньорный вы менеджер, тем сильнее вы рискуете оторваться от реальности. Самостоятельное общение с пользователями легко и быстро вытесняется просмотром аналитических дэшбордов и сводок, а погружение в инфраструктурные проблемы заменяется ленивым поглядыванием на первые несколько строк постмортемов.
В статье предлагают хороший совет, который может помочь удержать контакт с реальностью – завести побольше прямых связей с людьми, которые находятся близко к пользователям, клиентам или непосредственному коду. Таким образом вы будете получать рассказы о проблемах из первых уст от людей, на которых они влияют больше всего. Короче говоря, дружите с саппортерами, продажниками, и линейными программистами, даже если вы большой руководитель.
Чем более сеньорный вы менеджер, тем сильнее вы рискуете оторваться от реальности. Самостоятельное общение с пользователями легко и быстро вытесняется просмотром аналитических дэшбордов и сводок, а погружение в инфраструктурные проблемы заменяется ленивым поглядыванием на первые несколько строк постмортемов.
В статье предлагают хороший совет, который может помочь удержать контакт с реальностью – завести побольше прямых связей с людьми, которые находятся близко к пользователям, клиентам или непосредственному коду. Таким образом вы будете получать рассказы о проблемах из первых уст от людей, на которых они влияют больше всего. Короче говоря, дружите с саппортерами, продажниками, и линейными программистами, даже если вы большой руководитель.
Как подсидеть тимлида
Я тут недавно переносил свой блог на новый движок, и вспомнил, что у меня есть много нетленок, которыми и сейчас не грех поделиться! А пятница – идеальный день для того, чтобы обсудить, как правильно подсиживать своего тимлида.
Некоторые из советов:
👉Попросите тимлида добавлять вас во все его кодревью под предлогом того, что хотите учиться у лучших. Пуллреквестов скорее всего будет мало, поэтому на стендапах громко предлагайте свою помощь и намекайте, что от всех в команде ожидается одинаковый вклад.
👉Ни один тимлид не видит по-настоящему ценности в своей работе, бейте в эту точку! На стендапе попросите тимлида рассказать, чем он занимается на работе. После его историй о встречах и передвижении задачек по доске, повторите вопрос «А сделал-то что?».
👉Посоветуйте всем коллегам начать ходить по собеседованиям, чтобы оценить свою стоимость на рынке. Можете даже сами им подходящие вакансии сбрасывать. Они неминуемо вернутся с большими офферами и придут с ними к тимлиду – пусть знает, что он сидит на пороховой бочке.
👉Организуйте хакатон и сколотите команду из коллег. Когда тимлид спросит, почему его не позвали, скажите, что программисты на Excel и Exchange вам были не нужны.
Расскажите в комментариях, какие новые способы подсиживания появились в последние годы!
Я тут недавно переносил свой блог на новый движок, и вспомнил, что у меня есть много нетленок, которыми и сейчас не грех поделиться! А пятница – идеальный день для того, чтобы обсудить, как правильно подсиживать своего тимлида.
Некоторые из советов:
👉Попросите тимлида добавлять вас во все его кодревью под предлогом того, что хотите учиться у лучших. Пуллреквестов скорее всего будет мало, поэтому на стендапах громко предлагайте свою помощь и намекайте, что от всех в команде ожидается одинаковый вклад.
👉Ни один тимлид не видит по-настоящему ценности в своей работе, бейте в эту точку! На стендапе попросите тимлида рассказать, чем он занимается на работе. После его историй о встречах и передвижении задачек по доске, повторите вопрос «А сделал-то что?».
👉Посоветуйте всем коллегам начать ходить по собеседованиям, чтобы оценить свою стоимость на рынке. Можете даже сами им подходящие вакансии сбрасывать. Они неминуемо вернутся с большими офферами и придут с ними к тимлиду – пусть знает, что он сидит на пороховой бочке.
👉Организуйте хакатон и сколотите команду из коллег. Когда тимлид спросит, почему его не позвали, скажите, что программисты на Excel и Exchange вам были не нужны.
Расскажите в комментариях, какие новые способы подсиживания появились в последние годы!
Etolstoy
Как подсидеть тимлида
Тимлид никогда не решит уволиться по своей воле, потому что это не работа, а сказка. Его нужно сломать и не оставить ему другого выхода. Давайте разберемся, как сделать так, чтобы он пришел к этой мысли самостоятельно!
Должен ли тимлид оставаться техническим специалистом
Чтобы ответить на этот вопрос, важно различать два понятия: быть техническим и контрибьютить. Под "быть техническим" подразумевается поддержание уровня знания технологий, устройства системы и контекста работы команды без непосредственного вовлечения в решение задач. Под "контрибьютить" – активно писать код или другим образом работать с технологиями напрямую.
Так вот, основная идея статьи в том, что менеджер в большинстве случаев контрибьютить не должен, но вот техническим быть обязан. Это помогает лучше понимать челленджи команды, говорить на одном языке с инженерами, принимать взвешенные решения, помогать своей команде расти.
Ну а дальше идут разные советы про то, как оставаться техническим. Часть из них давно понятны, но несколько показались мне любопытными:
👉Жестко таймфреймить время в неделю, которое вы тратите на поддержание своего технического уровня.
👉Принимать участие в технических митингах.
👉Помогать команде писать документацию.
👉Пилить внутренние инструменты.
Ну а я еще раз поделюсь советом, который даю всем начинающим менеджерам по этому вопросу. Мне кажется, что писать код или другим образом участвовать в работе команды – абсолютно нормально, но до той поры, пока эта работа не вытесняет менеджерские задачи. На практике это значит, что вы можете брать задачи из бэклога команды, но они не должны быть блокирующими. Если менеджерская работа вытеснит их выполнение, никто не должен пострадать.
Чтобы ответить на этот вопрос, важно различать два понятия: быть техническим и контрибьютить. Под "быть техническим" подразумевается поддержание уровня знания технологий, устройства системы и контекста работы команды без непосредственного вовлечения в решение задач. Под "контрибьютить" – активно писать код или другим образом работать с технологиями напрямую.
Так вот, основная идея статьи в том, что менеджер в большинстве случаев контрибьютить не должен, но вот техническим быть обязан. Это помогает лучше понимать челленджи команды, говорить на одном языке с инженерами, принимать взвешенные решения, помогать своей команде расти.
Ну а дальше идут разные советы про то, как оставаться техническим. Часть из них давно понятны, но несколько показались мне любопытными:
👉Жестко таймфреймить время в неделю, которое вы тратите на поддержание своего технического уровня.
👉Принимать участие в технических митингах.
👉Помогать команде писать документацию.
👉Пилить внутренние инструменты.
Ну а я еще раз поделюсь советом, который даю всем начинающим менеджерам по этому вопросу. Мне кажется, что писать код или другим образом участвовать в работе команды – абсолютно нормально, но до той поры, пока эта работа не вытесняет менеджерские задачи. На практике это значит, что вы можете брать задачи из бэклога команды, но они не должны быть блокирующими. Если менеджерская работа вытеснит их выполнение, никто не должен пострадать.
hybridhacker.email
Should you Stay Technical as an Engineering Manager?
Navigating the Balance Between Engineering Management and Technical Expertise
Новые выпуски Подлодочных подкастов
На прошлой неделе выпустили два эпизода, которыми хочу с вами поделиться!
1️⃣Подлодка про тест-кейсы. Если вы лидите команду, в которой есть тестировщики – отличный выпуск, чтобы разобраться, а какие артефакты должны получаться на выходе у хорошего тестировщика, как оптимизировать постоянно растущее количество тестов и каким софтом пользоваться, чтобы держать все под контролем.
2️⃣Бреслав и Ложечкин про увольнения. Как понимать, с кем и когда надо расставаться, и как на это влияет межкультурный контекст.
На прошлой неделе выпустили два эпизода, которыми хочу с вами поделиться!
1️⃣Подлодка про тест-кейсы. Если вы лидите команду, в которой есть тестировщики – отличный выпуск, чтобы разобраться, а какие артефакты должны получаться на выходе у хорошего тестировщика, как оптимизировать постоянно растущее количество тестов и каким софтом пользоваться, чтобы держать все под контролем.
2️⃣Бреслав и Ложечкин про увольнения. Как понимать, с кем и когда надо расставаться, и как на это влияет межкультурный контекст.
podlodka.io
Podlodka #359 – Тест-кейсы
Результат работы программистов – код. Дизайнеров – макеты и красивые иконки. А вот с тестировщиками все намного интереснее! Вместе с Анастасией Заречневой, тестировщицей из JetBrains и создательницей сообщества QA Sisters, мы разбираемся, что такое тестовая…
Уверены, что ваши софтскилы не вредят команде?
Пройдите тест, чтобы узнать ответ, и получите приглашение на встречу закрытого «Грейд клуба» Яндекс Практикума.
«Грейд клуб» — закрытый офлайн-клуб,
где лидеры цифровой индустрии драйвят сферу развития IT-специалистов.
Среди спикеров HR, T&D, лидеры цифровых команд, EdTech-инфлюенсеры и другие эксперты IT-индустрии.
Формат: офлайн
Место встречи: Community, Космодамианская наб., 2, Москва
Дата и время: 28 февраля в 19:00
Подробнее
Реклама. ООО Яндекс ИНН 7736207543
Пройдите тест, чтобы узнать ответ, и получите приглашение на встречу закрытого «Грейд клуба» Яндекс Практикума.
«Грейд клуб» — закрытый офлайн-клуб,
где лидеры цифровой индустрии драйвят сферу развития IT-специалистов.
Среди спикеров HR, T&D, лидеры цифровых команд, EdTech-инфлюенсеры и другие эксперты IT-индустрии.
Формат: офлайн
Место встречи: Community, Космодамианская наб., 2, Москва
Дата и время: 28 февраля в 19:00
Подробнее
Реклама. ООО Яндекс ИНН 7736207543
Please open Telegram to view this post
VIEW IN TELEGRAM
Критика современной культуры менеджмента
Немного утрированная, но от этого не менее честная критика засилья менеджеров среднего звена в современных компаниях:
👉Менеджерам с карьерной точки зрения выгоднее решать проблемы, а не предотвращать их появление
👉Из-за переизбытка митингов, согласований и процессов ради процессов разработка подорожала в разы
👉Слишком много офисной политики, при отказе от участия в которой даже хорошие менеджеры в итоге страдают
👉Фиксация на трекинге продуктивности, который эту продуктивность убивает
Немного утрированная, но от этого не менее честная критика засилья менеджеров среднего звена в современных компаниях:
👉Менеджерам с карьерной точки зрения выгоднее решать проблемы, а не предотвращать их появление
👉Из-за переизбытка митингов, согласований и процессов ради процессов разработка подорожала в разы
👉Слишком много офисной политики, при отказе от участия в которой даже хорошие менеджеры в итоге страдают
👉Фиксация на трекинге продуктивности, который эту продуктивность убивает
Задумайтесь: зачем вашей компании, например, agile-трансформация?
Изменения должны к чему-то приводить. Это ведь не дань моде, а путь из точки А – в точку Б. Вы внедряете это, чтобы что?
На вебинаре «Change management или что делать менеджеру, когда вводные поменялись» вы познакомитесь с тем, как управлять изменениями правильно.
✅ Вы узнаете:
• Как выработать системный подход к изменениям
• Как идентифицировать и оценивать изменения
• Как разрабатывать планы по управлению изменениями
• Как оценивать результаты управления изменениями
• Как преодолевать сопротивление сотрудников
Вебинар проведёт Влас Старцев. Эксперт по управлению стартапами и крупными продуктами
Будет интересно: руководителям компаний и менеджерам изменений.
Начало вебинара: 28 февраля, 19:00 МСК
Участие бесплатное
👉 Записаться на вебинар 👈
Изменения должны к чему-то приводить. Это ведь не дань моде, а путь из точки А – в точку Б. Вы внедряете это, чтобы что?
На вебинаре «Change management или что делать менеджеру, когда вводные поменялись» вы познакомитесь с тем, как управлять изменениями правильно.
✅ Вы узнаете:
• Как выработать системный подход к изменениям
• Как идентифицировать и оценивать изменения
• Как разрабатывать планы по управлению изменениями
• Как оценивать результаты управления изменениями
• Как преодолевать сопротивление сотрудников
Вебинар проведёт Влас Старцев. Эксперт по управлению стартапами и крупными продуктами
Будет интересно: руководителям компаний и менеджерам изменений.
Начало вебинара: 28 февраля, 19:00 МСК
Участие бесплатное
👉 Записаться на вебинар 👈
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576Как демотивировать команду правильно
Манипуляции – главный инструмент любого тимлида, без которого управлять командой невозможно. Держите еще одну мою старую статью про то, как привести команду к повиновению, дергая за тонкие струны человеческой души!
👉Ваша главная задача – показать, что нет пределов совершенству. Поэтому вместо «стало хорошо» используйте фразу «теперь хотя бы не так плохо».
👉Людей мотивирует самостоятельность и демотивирует контроль. Никогда напрямую не говорите своим сотрудникам, чего от них ожидаете, и как оценивается их работа – неизвестность вдохновляет, и они вас удивят!
👉Любой уважающий себя тимлид еще с пеленок должен заучить, что деньги не являются мотивационным фактором. Мотивировать могут только интересные проекты, дружные команды и вкусный кофе на кухне.
👉Никогда не слушайте просьб поднять зарплату. Люди сами не знают чего хотят – а ваша работа, как тимлида, им это объяснить.
👉Людям важно видеть пример перед глазами. Почаще сравнивайте их друг с другом публично, чтобы все знали, за кем нужно тянуться.
Дисклеймер для слишком серьезных подписчиков канала: конечно же, это вредные советы, которые высмеивают плохих руководителей.
Манипуляции – главный инструмент любого тимлида, без которого управлять командой невозможно. Держите еще одну мою старую статью про то, как привести команду к повиновению, дергая за тонкие струны человеческой души!
👉Ваша главная задача – показать, что нет пределов совершенству. Поэтому вместо «стало хорошо» используйте фразу «теперь хотя бы не так плохо».
👉Людей мотивирует самостоятельность и демотивирует контроль. Никогда напрямую не говорите своим сотрудникам, чего от них ожидаете, и как оценивается их работа – неизвестность вдохновляет, и они вас удивят!
👉Любой уважающий себя тимлид еще с пеленок должен заучить, что деньги не являются мотивационным фактором. Мотивировать могут только интересные проекты, дружные команды и вкусный кофе на кухне.
👉Никогда не слушайте просьб поднять зарплату. Люди сами не знают чего хотят – а ваша работа, как тимлида, им это объяснить.
👉Людям важно видеть пример перед глазами. Почаще сравнивайте их друг с другом публично, чтобы все знали, за кем нужно тянуться.
Подготовка к лэйоффам в Dropbox
Вот вы все посмеялись над советами по демотивации команды и подсиживанию тимлида, а менеджер в Dropbox, похоже, воспринял их всерьез!
Абсолютно кафкианские истории того, как тимлид учит своих сотрудников саботировать работу другой команды, чтобы их сократили первыми.
Вот вы все посмеялись над советами по демотивации команды и подсиживанию тимлида, а менеджер в Dropbox, похоже, воспринял их всерьез!
Абсолютно кафкианские истории того, как тимлид учит своих сотрудников саботировать работу другой команды, чтобы их сократили первыми.
Где пересекаются продакт и тимлид
Буквально на днях я в очередной раз в своей жизни проходил через замечательное (без шуток, оно правда обычно довольно полезно) упражнение – договориться о том, а что же именно ожидается от тимлидов в нашей компании. И я очень активно топил за то, что любой, даже начинающий тимлид должен быть на полшишечки продакт-менеджером. Как минимум, хорошо понимать, кто является клиентом и пользователем того, что производит его команда, и владеть рыночным контекстом. В Роадмапе Тимлида я топлю за то же самое, там целая отдельная продуктовая веточка есть.
С продактами ситуация очень похожая. Хороший продакт может в течение долгого времени заменять собой тимлида команды, так как пот управленческим скиллам они довольно сильно совпадают. В долгую это не очень устойчивая конструкция, но вот на условные полгода – вполне себе.
Так вот, о чем это я. Так получилось, что мой канал читает очень много как тимлидов, так и продакт-менеджеров(чему я очень рад, так как сам все еще не могу определиться, кем я больше являюсь 😄 ) . И вот для всех из вас, кто хочет прокачивать свои продуктовые навыки, у меня есть папка с кучей крутейших каналов про различные аспекты продакт-менеджмента. Я сам читаю большую часть каналов оттуда, и дико рекомендую и вам. Вот несколько моих любимых:
👉Канал Ани Подображной, которая была продактом в Авито, а сейчас рулит AI движем в Тиньке. Мы с ней как-то записывали офигенный выпуск Подлодки про приоритизацию. Если не слушали – вам точно надо!
👉Канал "Hard Client" Стаса Хрусталева, эксперта по Customer experience, который регулярно делает обзор хороших и плохих UX паттернов в ecommerce и других сферах.
👉Канал "ProductDo", который ведут несколько ребят, топящих за важность технического бэкграунда для продакта, и обучающих технических PMов.
🔗Подписаться сразу на все каналы
Буквально на днях я в очередной раз в своей жизни проходил через замечательное (без шуток, оно правда обычно довольно полезно) упражнение – договориться о том, а что же именно ожидается от тимлидов в нашей компании. И я очень активно топил за то, что любой, даже начинающий тимлид должен быть на полшишечки продакт-менеджером. Как минимум, хорошо понимать, кто является клиентом и пользователем того, что производит его команда, и владеть рыночным контекстом. В Роадмапе Тимлида я топлю за то же самое, там целая отдельная продуктовая веточка есть.
С продактами ситуация очень похожая. Хороший продакт может в течение долгого времени заменять собой тимлида команды, так как пот управленческим скиллам они довольно сильно совпадают. В долгую это не очень устойчивая конструкция, но вот на условные полгода – вполне себе.
Так вот, о чем это я. Так получилось, что мой канал читает очень много как тимлидов, так и продакт-менеджеров
👉Канал Ани Подображной, которая была продактом в Авито, а сейчас рулит AI движем в Тиньке. Мы с ней как-то записывали офигенный выпуск Подлодки про приоритизацию. Если не слушали – вам точно надо!
👉Канал "Hard Client" Стаса Хрусталева, эксперта по Customer experience, который регулярно делает обзор хороших и плохих UX паттернов в ecommerce и других сферах.
👉Канал "ProductDo", который ведут несколько ребят, топящих за важность технического бэкграунда для продакта, и обучающих технических PMов.
🔗Подписаться сразу на все каналы
Исследование Microsoft про продуктивность разработчиков
Еще одно исследование, подтверждающее пользу вложений в developer experience сразу на нескольких уровнях: продуктивности самого разработчика, его команды и всей организации. Вот несколько интересных, хоть и интуитивно очевидных выводов:
👉Разработчики, которые выделяют значимые периоды времени для сосредоточенной работы, чувствуют себя на 50% продуктивнее тех, кто так не делает.
👉Интересность решаемой задачи дает 30% дополнительной воспринимаемой продуктивности.
👉Глубокое понимание кодовой базы дает 42% продуктивности.
Еще одно исследование, подтверждающее пользу вложений в developer experience сразу на нескольких уровнях: продуктивности самого разработчика, его команды и всей организации. Вот несколько интересных, хоть и интуитивно очевидных выводов:
👉Разработчики, которые выделяют значимые периоды времени для сосредоточенной работы, чувствуют себя на 50% продуктивнее тех, кто так не делает.
👉Интересность решаемой задачи дает 30% дополнительной воспринимаемой продуктивности.
👉Глубокое понимание кодовой базы дает 42% продуктивности.
Queue
DevEx in Action: A study of its tangible impacts: Queue: Vol 21, No 6
DevEx (developer experience) is garnering increased attention at many software organizations
as leaders seek to optimize software delivery amid the backdrop of fiscal tightening
and transformational technologies such as AI. Intuitively, there is ...
as leaders seek to optimize software delivery amid the backdrop of fiscal tightening
and transformational technologies such as AI. Intuitively, there is ...
Опыт Meta с генерацией юнит-тестов с помощью LLM
Meta написала поверх LLM инструмент для улучшения качества написанных людьми юнит-тестов и генерации новых. Качество аутпута и отсутствие галлюцинаций гарантируются набором специальных фильтров. Кажется, это первый отчет об использовании генераторов тестов на масштабе огромного продакшн проекта.
Результаты такие:
👉75% сгенерированных тестов билдятся корректно, 57% работает стабильно, 25% повышают фактическое тестовое покрытие.
👉По оценке инженеров, проверявших результаты, 11.5% тестовых классов стали лучше, чем были до. А всего в итоге было принято 73% предложений по улучшению.
Как по мне, офигенный кейс использования LLM! Что думаете?
Meta написала поверх LLM инструмент для улучшения качества написанных людьми юнит-тестов и генерации новых. Качество аутпута и отсутствие галлюцинаций гарантируются набором специальных фильтров. Кажется, это первый отчет об использовании генераторов тестов на масштабе огромного продакшн проекта.
Результаты такие:
👉75% сгенерированных тестов билдятся корректно, 57% работает стабильно, 25% повышают фактическое тестовое покрытие.
👉По оценке инженеров, проверявших результаты, 11.5% тестовых классов стали лучше, чем были до. А всего в итоге было принято 73% предложений по улучшению.
Как по мне, офигенный кейс использования LLM! Что думаете?
arXiv.org
Automated Unit Test Improvement using Large Language Models at Meta
This paper describes Meta's TestGen-LLM tool, which uses LLMs to automatically improve existing human-written tests. TestGen-LLM verifies that its generated test classes successfully clear a set...
Что меняется для менеджера менеджеров
Переход от управления линейными сотрудниками к управлению другими менеджерами, на мой взгляд, еще более сложный и неочевидный, чем стандартный переход из разработчика в тимлида. Наткнулся на пока что не оконченную серию статей про разные аспекты этого перехода, о которых надо знать. Вот несколько хороших мыслей оттуда:
👉Ваша основная роль – смотреть за тем, чтобы тимлиды и продакты в ваших командах работали эффективно, и устранять различные внешние помехи для команд.
👉Фокус с аутпутов смещается на ауткамы – на вашем уровне как раз появляется возможность видеть общий контекст и влиять на него, которой может не быть у тимлида.
👉Вместо прямого решения проблем за тимлидов, важно уметь в непрямые методы – задавать вопросы, подсказывать слепые зоны, коачить.
Переход от управления линейными сотрудниками к управлению другими менеджерами, на мой взгляд, еще более сложный и неочевидный, чем стандартный переход из разработчика в тимлида. Наткнулся на пока что не оконченную серию статей про разные аспекты этого перехода, о которых надо знать. Вот несколько хороших мыслей оттуда:
👉Ваша основная роль – смотреть за тем, чтобы тимлиды и продакты в ваших командах работали эффективно, и устранять различные внешние помехи для команд.
👉Фокус с аутпутов смещается на ауткамы – на вашем уровне как раз появляется возможность видеть общий контекст и влиять на него, которой может не быть у тимлида.
👉Вместо прямого решения проблем за тимлидов, важно уметь в непрямые методы – задавать вопросы, подсказывать слепые зоны, коачить.
Medium
Managing managers — what changes?
You’ve mastered the art of managing engineering teams, excelling in stand-ups, planning sessions, and 1:1s. You’ve built a harmonious…
Откуда у компаний берется плохая стратегия
Казалось бы, книгу "Хорошая стратегия, плохая стратегия" читал любой уважающий себя менеджер. При этом скоммуницированная стратегия большинства компаний под критерии хорошей не подходит никак. Самое простое объяснение – в топ-менеджменте сидят ленивые и бесполезные люди, как и всегда, чаще всего спровоцировано фундаментальной ошибкой атрибуции. А вот эти объяснения уже более вероятны:
👉У компании действительно нет единой стратегии. Но при этом она есть у отдельных людей в руководстве. Кто-то умеет хорошо убеждать других в конкретных ее частях, кто-то – не очень.
👉Скоммуницированная вам стратегия – это только прилизанный публичный нарратив, из которого убрали какие-то приватные куски, которые не надо знать всем.
👉В целом стратегия является результатом переговорного и политического процесса. Вместо объективно правильной в общем виде стратегии вы получаете правильную для кого-то конкретного в компании.
👉Стратегия по определению долгосрочна. При этом не все, кто прикладывает к ней руку, планируют задерживаться в компании надолго.
👉Стратегия на самом деле есть, и процесс ее выработки был построен правильно. Но она не скоммуницирована, и находится у руководителя в голове.
👉Главная стратегическая ставка уже сделана какое-то время назад, а все остальное – не важные детали. При этом вы замечаете только их.
Казалось бы, книгу "Хорошая стратегия, плохая стратегия" читал любой уважающий себя менеджер. При этом скоммуницированная стратегия большинства компаний под критерии хорошей не подходит никак. Самое простое объяснение – в топ-менеджменте сидят ленивые и бесполезные люди, как и всегда, чаще всего спровоцировано фундаментальной ошибкой атрибуции. А вот эти объяснения уже более вероятны:
👉У компании действительно нет единой стратегии. Но при этом она есть у отдельных людей в руководстве. Кто-то умеет хорошо убеждать других в конкретных ее частях, кто-то – не очень.
👉Скоммуницированная вам стратегия – это только прилизанный публичный нарратив, из которого убрали какие-то приватные куски, которые не надо знать всем.
👉В целом стратегия является результатом переговорного и политического процесса. Вместо объективно правильной в общем виде стратегии вы получаете правильную для кого-то конкретного в компании.
👉Стратегия по определению долгосрочна. При этом не все, кто прикладывает к ней руку, планируют задерживаться в компании надолго.
👉Стратегия на самом деле есть, и процесс ее выработки был построен правильно. Но она не скоммуницирована, и находится у руководителя в голове.
👉Главная стратегическая ставка уже сделана какое-то время назад, а все остальное – не важные детали. При этом вы замечаете только их.
The Beautiful Mess
TBM 275: "Bad" Strategy. Why?
I often speak to people who lament the fact that their company strategy doesn’t match the "good strategy" descriptions discussed in books, talks, research, and popular examples. “With so much information out there, why don’t we have a real strategy?” The…
Инженерные практики для разработки LLM приложений
Команда Мартина Фаулера делится опытом адаптации стандартных инженерных практик под контекст разработки приложения поверх LLM.
👉Автотесты: проверка вывода LLM для разных сценариев, оценка соответствия вывода определенным параметрам, проверка устойчивости к промпт-атакам.
👉Последовательный рефакторинг промптов.
👉Быстрый сбор и анализ фидбэка пользователей.
👉Базовые инженерные и архитектурные навыки.
Команда Мартина Фаулера делится опытом адаптации стандартных инженерных практик под контекст разработки приложения поверх LLM.
👉Автотесты: проверка вывода LLM для разных сценариев, оценка соответствия вывода определенным параметрам, проверка устойчивости к промпт-атакам.
👉Последовательный рефакторинг промптов.
👉Быстрый сбор и анализ фидбэка пользователей.
👉Базовые инженерные и архитектурные навыки.
Как руководителю «не сгореть» на работе? Зачастую российские менеджеры замыкают процессы на себе и занимаются ручным управлением. Как изменить ситуацию?
21 марта ЭКОПСИ запускает новый поток курса Академии ПРМ (Практик регулярного менеджмента). Этот курс позволит освоить конкретные управленческие действия, которые помогут руководителю решать основные задачи в области делегирования, контроля и достижения результата, обратной связи. В основе — опыт ведущих компаний России, внедривших практики регулярного менеджмента (Газпром, Евраз, Сибур и др.)
За 2-3 часа в неделю участники курса научатся:
– Настраивать процесс планирования
– Проводить продуктивные совещания
– Давать полезную и конструктивную обратную связь
– Оценивать эффективность сотрудников
– Развивать команду
Чтобы вы могли получить представление о материалах курса сегодня, ЭКОПСИ открывает доступ к памятке по работе с обратной связью. Вы можете её скачать на странице курса.
Познакомьтесь с программой и оставьте заявку на участие на сайте
21 марта ЭКОПСИ запускает новый поток курса Академии ПРМ (Практик регулярного менеджмента). Этот курс позволит освоить конкретные управленческие действия, которые помогут руководителю решать основные задачи в области делегирования, контроля и достижения результата, обратной связи. В основе — опыт ведущих компаний России, внедривших практики регулярного менеджмента (Газпром, Евраз, Сибур и др.)
За 2-3 часа в неделю участники курса научатся:
– Настраивать процесс планирования
– Проводить продуктивные совещания
– Давать полезную и конструктивную обратную связь
– Оценивать эффективность сотрудников
– Развивать команду
Чтобы вы могли получить представление о материалах курса сегодня, ЭКОПСИ открывает доступ к памятке по работе с обратной связью. Вы можете её скачать на странице курса.
Познакомьтесь с программой и оставьте заявку на участие на сайте