Катя Лысенко пригласила меня побатлиться с ней, задавая друг другу вопросы, которые мы обычно задаём на собеседованиях лидам.
Я подготовил 4 каверзных кейса, уверен, Катя принесёт чего-нибудь даже похлеще 🙃
Прожарка состоится 19 августа в рамках Tg-конференции 🎙 Рупор лида 3: Lead в поиске.
А вот сама конференция стартует 18 августа и продлится аж до 22 августа, и все 5 дней много разных интересных спикеров будут говорить про найм глазами нанимающих менеджеров, а именно:
👉 18-ое августа, Татьяна Гороховская — Hiring-позиция: в огне, но с чек-листом
👉 19-ое августа, Тёма Пулявин (это я) + Катя Лысенко — Коньки-горбунки собеседований или отсобеседуй меня полностью
👉 20-ое августа, Круглый стол — Что я узнал про найм за 1.5 года: битва AI, выгорание, кризис рынка ИТ
👉 21-ое августа, Саша Поломодов — System design глазами нанимающего
👉 22-ое августа, Иван Доронин — Если ты Lead, который ищет работу
Конференция бесплатная, а для того, чтобы стать слушателем надо вступить в канал конференции.
Подключайся, точно будет жарко 🔥
Я подготовил 4 каверзных кейса, уверен, Катя принесёт чего-нибудь даже похлеще 🙃
Прожарка состоится 19 августа в рамках Tg-конференции 🎙 Рупор лида 3: Lead в поиске.
А вот сама конференция стартует 18 августа и продлится аж до 22 августа, и все 5 дней много разных интересных спикеров будут говорить про найм глазами нанимающих менеджеров, а именно:
👉 18-ое августа, Татьяна Гороховская — Hiring-позиция: в огне, но с чек-листом
👉 19-ое августа, Тёма Пулявин (это я) + Катя Лысенко — Коньки-горбунки собеседований или отсобеседуй меня полностью
👉 20-ое августа, Круглый стол — Что я узнал про найм за 1.5 года: битва AI, выгорание, кризис рынка ИТ
👉 21-ое августа, Саша Поломодов — System design глазами нанимающего
👉 22-ое августа, Иван Доронин — Если ты Lead, который ищет работу
Конференция бесплатная, а для того, чтобы стать слушателем надо вступить в канал конференции.
Подключайся, точно будет жарко 🔥
😎8🤔2
Тебе, как лиду, важно строить рабочие отношения со своим руководителем, основанные на доверии. Чем выше уровень доверия, тем меньше со стороны руководителя контроля, и тем больше у тебя свободы и автономности в принятии решений.
Доверие нужно заслужить, и обычно оно появляется через закрытые качественно и в срок проекты.
Но бывает так, что ты только вышел на новую работу и на тебя сразу падают большие проекты-долгострои, которые завершатся только через несколько месяцев. Доверия ещё в полном объёме нет, а вот уровень свободы и автономности, необходимый для реализации этих проектов, нужен уже прямо сейчас. Что делать?
Тебе нужна «маленькая победа» 🏆
У любого руководителя есть набор проблемок, о которых он редко вспоминает, но каждый раз — с большой грустью. Обычно это гигиенические или низкоприоритетные задачи, попытки решить которые предпринимались много раз, но безуспешно. В какой-то момент руководитель отчаялся, смирился и принял их как факт, с которым придётся жить — как в анекдоте про ёжиков, которые плакали, кололись, но продолжали есть кактус.
Самое интересное, что на такие проблемы зачастую нужно просто взглянуть свежим взглядом, подойти с другой стороны, соорганизовать несколько смежных (и не всегда дружных) команд — и проблема решается, а руководитель становится счастливым.
И вот твоя задача — найти такую проблему, которая:
👉 действительно заметна и болезненна для руководителя
👉 решается быстро
👉 даёт чёткий, осязаемый результат
И решить её 💪
Это и будет твоя «маленькая победа» — закрытый в короткие сроки проектик, которого от тебя не ожидали, но который давно «болел» у руководителя. Этой маленькой победой ты покажешь, что он сделал правильный выбор, наняв тебя, что ты умеешь решать проблемы и что уровень доверия к тебе можно повышать.
Тут главное не увлечься и не забыть о том, что это должна быть факультативная работа, которую ты сделаешь как бы невзначай, в свободное от основной работы время. В рабочее время ты должен быть занят важными задачами, порученными руководителем, и сроки или качество их выполнения не должны пострадать из-за этой задачки. Решение же такой «забытой» проблемы должно нести wow-эффект для руководителя, он не должен даже подозревать, что ты фокусируешься на её решении.
Принеси результат невзначай, мол, проходил мимо, увидел непорядок, сделал то и это — и стало заметно лучше.
При этом очень важно не ошибиться с выбором проблемы. Если возьмёшь не ту, да ещё и преподнесёшь её как большую победу, легко получить удивлённое лицо руководителя с прямым вопросом: «Слушай, а почему ты вместо важных задач занимаешься непонятно чем?».
Поэтому не бросайся на то, что тебе кажется больным — попробуй разузнать о проблемах:
👉 у смежников — других лидов твоего руководителя
👉 у своей команды
👉 у предыдущего лида команды, если это возможно
И чтобы обезопасить себя от неправильного выбора, преподноси результат ненавязчиво — тогда даже в случае промаха он не будет выглядеть как бесполезная трата ресурсов.
Доверие нужно заслужить, и обычно оно появляется через закрытые качественно и в срок проекты.
Но бывает так, что ты только вышел на новую работу и на тебя сразу падают большие проекты-долгострои, которые завершатся только через несколько месяцев. Доверия ещё в полном объёме нет, а вот уровень свободы и автономности, необходимый для реализации этих проектов, нужен уже прямо сейчас. Что делать?
Тебе нужна «маленькая победа» 🏆
У любого руководителя есть набор проблемок, о которых он редко вспоминает, но каждый раз — с большой грустью. Обычно это гигиенические или низкоприоритетные задачи, попытки решить которые предпринимались много раз, но безуспешно. В какой-то момент руководитель отчаялся, смирился и принял их как факт, с которым придётся жить — как в анекдоте про ёжиков, которые плакали, кололись, но продолжали есть кактус.
Самое интересное, что на такие проблемы зачастую нужно просто взглянуть свежим взглядом, подойти с другой стороны, соорганизовать несколько смежных (и не всегда дружных) команд — и проблема решается, а руководитель становится счастливым.
И вот твоя задача — найти такую проблему, которая:
👉 действительно заметна и болезненна для руководителя
👉 решается быстро
👉 даёт чёткий, осязаемый результат
И решить её 💪
Это и будет твоя «маленькая победа» — закрытый в короткие сроки проектик, которого от тебя не ожидали, но который давно «болел» у руководителя. Этой маленькой победой ты покажешь, что он сделал правильный выбор, наняв тебя, что ты умеешь решать проблемы и что уровень доверия к тебе можно повышать.
Тут главное не увлечься и не забыть о том, что это должна быть факультативная работа, которую ты сделаешь как бы невзначай, в свободное от основной работы время. В рабочее время ты должен быть занят важными задачами, порученными руководителем, и сроки или качество их выполнения не должны пострадать из-за этой задачки. Решение же такой «забытой» проблемы должно нести wow-эффект для руководителя, он не должен даже подозревать, что ты фокусируешься на её решении.
Принеси результат невзначай, мол, проходил мимо, увидел непорядок, сделал то и это — и стало заметно лучше.
При этом очень важно не ошибиться с выбором проблемы. Если возьмёшь не ту, да ещё и преподнесёшь её как большую победу, легко получить удивлённое лицо руководителя с прямым вопросом: «Слушай, а почему ты вместо важных задач занимаешься непонятно чем?».
Поэтому не бросайся на то, что тебе кажется больным — попробуй разузнать о проблемах:
👉 у смежников — других лидов твоего руководителя
👉 у своей команды
👉 у предыдущего лида команды, если это возможно
И чтобы обезопасить себя от неправильного выбора, преподноси результат ненавязчиво — тогда даже в случае промаха он не будет выглядеть как бесполезная трата ресурсов.
😎10🤨3🤔1
Я тут напросился к Саше Поломодову на подкаст.
Если кто не знает Сашу — прямо сейчас рекомендую вбить в YouTube «Поломодов» и наслаждаться бесконечным количеством роликов про то, как Саша рассказывает, как проводить и как проходить секции system design интервью.
С Сашей я познакомился пару лет назад на выезде CPO&CTO-клуба Avito в Бодруме (мы, кстати, на фото оттуда), и до сих пор не перестаю восхищаться его продуктивностью и энергией.
Поговорили очень лампово про мой карьерный трек, как я запускал биржу контента 15 лет назад и сделал своё казино с крестиками-ноликами 🙈
В такую серую дождливую летнюю погоду самое то — укутаться в плед, взять чай с лимоном и 2,5 часа послушать подкаст.
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
Если кто не знает Сашу — прямо сейчас рекомендую вбить в YouTube «Поломодов» и наслаждаться бесконечным количеством роликов про то, как Саша рассказывает, как проводить и как проходить секции system design интервью.
С Сашей я познакомился пару лет назад на выезде CPO&CTO-клуба Avito в Бодруме (мы, кстати, на фото оттуда), и до сих пор не перестаю восхищаться его продуктивностью и энергией.
Поговорили очень лампово про мой карьерный трек, как я запускал биржу контента 15 лет назад и сделал своё казино с крестиками-ноликами 🙈
В такую серую дождливую летнюю погоду самое то — укутаться в плед, взять чай с лимоном и 2,5 часа послушать подкаст.
Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.
1😎15🤔2
Так уж исторически сложилось, что я собеседую всех кандидатов на руководящие позиции в свой ИТ-департамент в Ситидрайв. Это небольшая встреча-знакомство на 30–40 минут, на которой я составляю второе мнение о кандидате и передаю его нанимающему менеджеру для оценки рисков. Сейчас у нас открыто несколько таких позиций, поэтому за последние несколько недель у меня было достаточно встреч, чтобы заметить одну тенденцию у некоторых кандидатов.
В этом потоке мне отчётливо запомнились два кандидата. Опыт лидерства у них только на последнем месте работы, и лидами они там стали не за выдающиеся управленческие навыки и не за умение организовывать работу, развивать людей, собирать команду и отвечать за результат, а за то, что были самыми опытными разработчиками в команде и лучше всех понимали, как устроен проект. Так, после ухода лида их кто-то назначил лидом вместо ушедшего.
И вот третий такой кандидат и побудил меня написать эту заметку. Он — крепкий технарь, но точно не руководитель. И я ему задаю вопрос: «Слушай, а если вместо руководящей позиции мы тебе предложим инженерную, ты согласишься?». Тут он сразу приободрился, одобрительно начал кивать головой и подчеркнул: «Это будет даже лучше!». Я ему начал объяснять, что в этом случае мы будем оценивать его как инженера, и есть немаленькая вероятность, что именно столько, сколько он хочет, мы предложить не сможем, и спросил – готов ли он двигаться по своим ожиданиям. Тут я получил категоричный отказ, мол, он уже привык к такому уровню заработка и меньше получать никак не хочет.
Что говорить, и в моей практике был аналогичный случай, когда я пришёл в небольшую команду, где был супер-гуру-разработчик, который знал проект до последнего винтика, спасал сервис при инцидентах и писал сложный код. Людей стало чуть больше, и я назначил его лидом небольшой команды. Но вместо того, чтобы развивать команду и фокусировать её на достижении результата, он продолжал тушить пожары и писал код за троих. Год я вкладывался в него и растил из него лида, но, кажется, скорее потерял хорошего разработчика и получил плохого руководителя 😢
И таких историй масса, и они случаются на разных уровнях. И чем выше — тем страшнее. В другой компании руководителем разработки сделали бывшего разработчика, который дольше всех работал в компании. И вот его пять команд в 30 человек жили своей жизнью, а он жил своей — писал сложные алгоритмы и решал инциденты в сервисах, о которых знал только он 🫠
Получается, что хороший подчинённый далеко не всегда становится хорошим руководителем. Новая должность, а особенно переход на руководящую должность с линейной — это другой майндсет, другие задачи и обязанности, которым нужно учиться с нуля.
Это как хороший продажник редко становится хорошим директором по продажам — ведь директор по продажам должен уметь нанимать хороших продажников, а не сам продавать лучше всех. И вот мы повышаем успешных сотрудников за прошлые заслуги, даём им должность выше, где нужны уже совсем другие навыки, и тем самым делаем их некомпетентными 😢 И через какое-то время можно наблюдать, как в компании ключевые руководящие посты оказываются заняты людьми, которые топчутся на месте и продолжают делать то, что делали раньше, хотя от них уже ждут другого.
Я в своих наблюдениях не одинок — всё, о чём я тут пишу, было подмечено канадским исследователем Лоуренсом Дж. Питером ещё в 1969 году в книге «The Peter Principle: Why Things Always Go Wrong».
И вот Принцип Питера гласит: «В иерархических организациях сотрудники имеют тенденцию подниматься по служебной лестнице до уровня своей некомпетентности. В итоге каждый стремится занять должность, которую он не способен выполнять».
Что делать, шеф?
❗️Перестать делать то же самое, что ты делал до этого, и рассчитывать на то, что этого достаточно или что это именно то, что от тебя ожидают. Воспринимай новую должность как новую профессию и начинай учиться.
И если ты понимаешь, что это не твоё — не страшно сделать шаг назад, чтобы потом сделать два шага вперёд 😎
В этом потоке мне отчётливо запомнились два кандидата. Опыт лидерства у них только на последнем месте работы, и лидами они там стали не за выдающиеся управленческие навыки и не за умение организовывать работу, развивать людей, собирать команду и отвечать за результат, а за то, что были самыми опытными разработчиками в команде и лучше всех понимали, как устроен проект. Так, после ухода лида их кто-то назначил лидом вместо ушедшего.
И вот третий такой кандидат и побудил меня написать эту заметку. Он — крепкий технарь, но точно не руководитель. И я ему задаю вопрос: «Слушай, а если вместо руководящей позиции мы тебе предложим инженерную, ты согласишься?». Тут он сразу приободрился, одобрительно начал кивать головой и подчеркнул: «Это будет даже лучше!». Я ему начал объяснять, что в этом случае мы будем оценивать его как инженера, и есть немаленькая вероятность, что именно столько, сколько он хочет, мы предложить не сможем, и спросил – готов ли он двигаться по своим ожиданиям. Тут я получил категоричный отказ, мол, он уже привык к такому уровню заработка и меньше получать никак не хочет.
Что говорить, и в моей практике был аналогичный случай, когда я пришёл в небольшую команду, где был супер-гуру-разработчик, который знал проект до последнего винтика, спасал сервис при инцидентах и писал сложный код. Людей стало чуть больше, и я назначил его лидом небольшой команды. Но вместо того, чтобы развивать команду и фокусировать её на достижении результата, он продолжал тушить пожары и писал код за троих. Год я вкладывался в него и растил из него лида, но, кажется, скорее потерял хорошего разработчика и получил плохого руководителя 😢
И таких историй масса, и они случаются на разных уровнях. И чем выше — тем страшнее. В другой компании руководителем разработки сделали бывшего разработчика, который дольше всех работал в компании. И вот его пять команд в 30 человек жили своей жизнью, а он жил своей — писал сложные алгоритмы и решал инциденты в сервисах, о которых знал только он 🫠
Получается, что хороший подчинённый далеко не всегда становится хорошим руководителем. Новая должность, а особенно переход на руководящую должность с линейной — это другой майндсет, другие задачи и обязанности, которым нужно учиться с нуля.
Это как хороший продажник редко становится хорошим директором по продажам — ведь директор по продажам должен уметь нанимать хороших продажников, а не сам продавать лучше всех. И вот мы повышаем успешных сотрудников за прошлые заслуги, даём им должность выше, где нужны уже совсем другие навыки, и тем самым делаем их некомпетентными 😢 И через какое-то время можно наблюдать, как в компании ключевые руководящие посты оказываются заняты людьми, которые топчутся на месте и продолжают делать то, что делали раньше, хотя от них уже ждут другого.
Я в своих наблюдениях не одинок — всё, о чём я тут пишу, было подмечено канадским исследователем Лоуренсом Дж. Питером ещё в 1969 году в книге «The Peter Principle: Why Things Always Go Wrong».
И вот Принцип Питера гласит: «В иерархических организациях сотрудники имеют тенденцию подниматься по служебной лестнице до уровня своей некомпетентности. В итоге каждый стремится занять должность, которую он не способен выполнять».
Что делать, шеф?
❗️Перестать делать то же самое, что ты делал до этого, и рассчитывать на то, что этого достаточно или что это именно то, что от тебя ожидают. Воспринимай новую должность как новую профессию и начинай учиться.
И если ты понимаешь, что это не твоё — не страшно сделать шаг назад, чтобы потом сделать два шага вперёд 😎
2😎26🤔13
Я в ИТ лет 20, 15 из которых ежедневно писал код, 10 из них — на PHP.
Последние лет 5 про PHP я ничего не слышал — в Ситимобил мы ушли на Golang, а в Ситидрайв PHP никогда и не было — JavaScript/TypeScript, переходящий в Golang.
А оказывается, мало того что PHP живее всех живых 🔥, так ещё и в самом расцвете сил!
И даже ребята запускают интересные конференции про PHP, а именно — Пых.конф’25, про которую меня попросил рассказать Пётр Мязин. Из уважения к PHP-сообществу и Петру не могу не рассказать!
С Петром мы знакомы довольно-таки давно, и я даже в 2018 году на его подкасте «Пятиминутка PHP» рассказывал про JWT (рекомендую послушать 🔉).
Так вот, Пых.конф’25!
19 сентября, Москва, Конгресс-центр ЦМТ (+ он-лайн).
👉 Асинхронность и протоколы для неблокирующего I/O
👉 RAG в PHP-бэкендах и круглый стол «Кодим с ИИ»
👉 И... аж олдскулы свело: Yii3, Doctrine, Swoole, WordPress и Битрикс!
Билеты можно купить вот по этой ссылке.
Последние лет 5 про PHP я ничего не слышал — в Ситимобил мы ушли на Golang, а в Ситидрайв PHP никогда и не было — JavaScript/TypeScript, переходящий в Golang.
А оказывается, мало того что PHP живее всех живых 🔥, так ещё и в самом расцвете сил!
И даже ребята запускают интересные конференции про PHP, а именно — Пых.конф’25, про которую меня попросил рассказать Пётр Мязин. Из уважения к PHP-сообществу и Петру не могу не рассказать!
С Петром мы знакомы довольно-таки давно, и я даже в 2018 году на его подкасте «Пятиминутка PHP» рассказывал про JWT (рекомендую послушать 🔉).
Так вот, Пых.конф’25!
19 сентября, Москва, Конгресс-центр ЦМТ (+ он-лайн).
👉 Асинхронность и протоколы для неблокирующего I/O
👉 RAG в PHP-бэкендах и круглый стол «Кодим с ИИ»
👉 И... аж олдскулы свело: Yii3, Doctrine, Swoole, WordPress и Битрикс!
Билеты можно купить вот по этой ссылке.
😎12🤔5
На прошлой неделе мы батлились с Катей Лысенко, задавая друг другу управленческие кейсы. Если тебе не удалось попасть на стрим, то можешь посмотреть его запись на YouTube.
Мы успели рассмотреть с Катей 8 кейсов, и тут я бы хотел детальнее обсудить один из них. Как мне кажется, это один из старых, популярных, на вид простых кейсов, но он полностью раскрывает способность лида действовать структурно и поэтапно, не хватаясь за всё подряд и не решая проблем, которых нет.
Итак, кейс 💼
Что делать, шеф?
Во-первых ☝️, уточни у руководителя, по каким метрикам и критериям он оценивает «низкую» и «высокую» скорость команды
И тут могут быть две развилки:
👉 Субъективное восприятие: руководитель оторван от контекста работы этой команды, не погружён в её детали, и его оценка скорости субъективна — базируется на прошлом опыте, который не релевантен этой команде.
👉 Объективное восприятие: руководитель хорошо понимает команду и её специфику, может быть, даже сам когда-то был выходцем из этой команды и может дать реальную оценку сложности той или иной задачи. Но сейчас что-то сбойнуло, и работа идёт медленнее, чем раньше.
Во-вторых ✌️, выслушай руководителя и возьми время на собственный анализ (около недели). Погрузись в команду и проведи аудит текущего состояния
Тут важно понять:
👉 Есть ли у команды метрики и показатели (velocity, capacity, throughput, cycle time, lead time)?
👉 Как команда оценивает задачи? Насколько точны оценки: не завышены ли, не занижены ли?
В-третьих 🤟, накидай гипотезы улучшений и изменений
👉 Если метрик нет — надо их внедрить
👉 Если у команды постоянное переключение между задачами — переработай систему приоритизации
👉 Если слабое описание задач заставляет команду много коммуницировать — проработай шаблон задач
👉 ... в конце концов, может быть там CI/CD, выполнение которого нужно ждать 2 дня
Все гипотезы надо поделить на 3 категории целей:
👉 Краткосрочные — можно сделать здесь и сейчас с минимальными ресурсами и силами, но при этом сразу получить значимый результат
👉 Среднесрочные — план на пару месяцев: внедрить какой-то процесс, посмотреть на ротацию сотрудников, переработать систему оценки и планирования
👉 Долгосрочные — план на 3+ месяцев: пересмотреть зоны ответственности команд, устранить технический долг, изменить управленческие подходы и культурные практики
В-четвёртых 🖖, презентуй план руководителю
Он что-то добавит, что-то уберёт — главное получить от него ОК на твой план.
Определи с ним, по каким метрикам вы будете трекать успех реализации плана — важно, чтобы у вас было одинаковое понимание «скорости разработки».
Если руководитель всё равно не верит в метрики и считает, что то, что команда делает за 2 недели, можно сделать за час — нужно работать с восприятием руководителя. Прям садиться и «на пальцах» объяснять, почему та или иная задача занимает столько времени. Тут важно построить с ним доверительные отношения, потому что если он раньше не доверял команде, то и тебе самому легко попасть в его недоверие.
В-пятых 🖐, реализуй план в жизнь
Поддерживай регулярную коммуникацию с руководителем, сообщай ему о своих успехах и провалах. Для него должен быть прозрачен прогресс реализации плана и понимание сложностей, с которыми ты сталкиваешься, и того, как ты их преодолеваешь.
Это очень кратко и тезисно — как бы я сам хотел услышать ответ на такой вопрос на собеседовании. А как ответила на него Катя — смотри и слушай в записи.
Мы успели рассмотреть с Катей 8 кейсов, и тут я бы хотел детальнее обсудить один из них. Как мне кажется, это один из старых, популярных, на вид простых кейсов, но он полностью раскрывает способность лида действовать структурно и поэтапно, не хватаясь за всё подряд и не решая проблем, которых нет.
Итак, кейс 💼
Ты вышел на работу лидом команды.
Руководитель разработки говорит, что уволил прошлого лида из-за низкой скорости работы команды, и твоя задача на испытательный срок — разобраться с этой проблемой.
Твои действия?
Что делать, шеф?
Во-первых ☝️, уточни у руководителя, по каким метрикам и критериям он оценивает «низкую» и «высокую» скорость команды
И тут могут быть две развилки:
👉 Субъективное восприятие: руководитель оторван от контекста работы этой команды, не погружён в её детали, и его оценка скорости субъективна — базируется на прошлом опыте, который не релевантен этой команде.
👉 Объективное восприятие: руководитель хорошо понимает команду и её специфику, может быть, даже сам когда-то был выходцем из этой команды и может дать реальную оценку сложности той или иной задачи. Но сейчас что-то сбойнуло, и работа идёт медленнее, чем раньше.
Во-вторых ✌️, выслушай руководителя и возьми время на собственный анализ (около недели). Погрузись в команду и проведи аудит текущего состояния
Тут важно понять:
👉 Есть ли у команды метрики и показатели (velocity, capacity, throughput, cycle time, lead time)?
👉 Как команда оценивает задачи? Насколько точны оценки: не завышены ли, не занижены ли?
В-третьих 🤟, накидай гипотезы улучшений и изменений
👉 Если метрик нет — надо их внедрить
👉 Если у команды постоянное переключение между задачами — переработай систему приоритизации
👉 Если слабое описание задач заставляет команду много коммуницировать — проработай шаблон задач
👉 ... в конце концов, может быть там CI/CD, выполнение которого нужно ждать 2 дня
Все гипотезы надо поделить на 3 категории целей:
👉 Краткосрочные — можно сделать здесь и сейчас с минимальными ресурсами и силами, но при этом сразу получить значимый результат
👉 Среднесрочные — план на пару месяцев: внедрить какой-то процесс, посмотреть на ротацию сотрудников, переработать систему оценки и планирования
👉 Долгосрочные — план на 3+ месяцев: пересмотреть зоны ответственности команд, устранить технический долг, изменить управленческие подходы и культурные практики
В-четвёртых 🖖, презентуй план руководителю
Он что-то добавит, что-то уберёт — главное получить от него ОК на твой план.
Определи с ним, по каким метрикам вы будете трекать успех реализации плана — важно, чтобы у вас было одинаковое понимание «скорости разработки».
Если руководитель всё равно не верит в метрики и считает, что то, что команда делает за 2 недели, можно сделать за час — нужно работать с восприятием руководителя. Прям садиться и «на пальцах» объяснять, почему та или иная задача занимает столько времени. Тут важно построить с ним доверительные отношения, потому что если он раньше не доверял команде, то и тебе самому легко попасть в его недоверие.
В-пятых 🖐, реализуй план в жизнь
Поддерживай регулярную коммуникацию с руководителем, сообщай ему о своих успехах и провалах. Для него должен быть прозрачен прогресс реализации плана и понимание сложностей, с которыми ты сталкиваешься, и того, как ты их преодолеваешь.
Это очень кратко и тезисно — как бы я сам хотел услышать ответ на такой вопрос на собеседовании. А как ответила на него Катя — смотри и слушай в записи.
1😎16🤔2🥴1
Как-то, работая в «Ситимобил», я проходил тренинг по Ситуационному лидерству (SLII®), и вот этот тренинг я до сих пор считаю лучшим, что проходил. Не столько из-за подачи и организации тренинга, хотя и это было на высшем уровне, сколько из-за самой концепции — она тогда соединила разрозненные кусочки знаний о развитии сотрудников и делегировании задач у меня в голове в единую картину и дала готовый инструмент, который можно было применять сразу после тренинга.
Тренинг базировался на модели ситуационного лидерства, которую разработали американские исследователи поведения Paul Hersey и Kenneth Blanchard и описали в своей книге «Management of Organizational Behavior» аж в 1969 году, и сейчас у неё уже десять переизданий!
В чём идея?
Идея в том, что любой человек, который переходит на новую должность, берётся за новый проект или открывает для себя новую область, неминуемо проходит через четыре уровня зрелости (Maturity Levels).
Например, ты поручаешь своему разработчику создать платформу для нагрузочного тестирования сервисов.
☝️ M1: Новичок-энтузиаст (не может, но хочет)
Это задача, о которой он давно мечтал: ресёрч, выбор инструмента, настройка окружения, первые тесты. Всё новое, ничего не понятно, у него горят глаза и полные штаны энтузиазма, он готов вкладываться, но опыта, знаний и компетенций в этой области у него пока нет.
✌️ M2: Разочаровавшийся ученик (не может и не хочет)
Всё оказалось не так увлекательно, как казалось вначале, нормальных инструментов нет, из коробки ничего не работает, надо допиливать, тесты падают, нормального препрод-окружения, чтобы гонять тесты, нет. Энтузиазм угас, горящие глаза затухли.
🤟 M3: Способный, но осторожный исполнитель (может, но не хочет)
Инструмент найден, как-то допилен и интегрирован, окружение как-то работает, и тесты даже запускаются и не падают. Опыт, набитый шишками, уже имеется, но вот большого желания доводить это до совершенства и развивать почему-то нет.
🖖 M4: Самостоятельный профессионал (хочет и может)
Тут он уже эксперт по нагрузочному тестированию на рынке, может собрать стенд для нагрузочного тестирования хоть из консервной банки и шариковой ручки — всё работает идеально и как часы.
И вот эта модель нам говорит, что лидер должен подстраивать свой стиль управления сотрудником в зависимости от уровня зрелости сотрудника в рамках решаемой им задачи.
Каждому уровню зрелости — свой стиль руководства.
☝️ S1 для M1. Указывающий
Ты директивно даёшь чёткие указания о том, как должна выглядеть и функционировать наша платформа: как разворачивать, запускать, эксплуатировать и в каком виде выдавать результат. Внимательно следишь за процессом реализации и проверяешь результат на каждом шаге.
✌️ S2 для M2. Наставнический
Ты объясняешь сотруднику, почему необходимо выбрать именно этот инструмент и начать его допиливать. Слушаешь его идеи и предложения по допиливанию, обсуждаешь их. Свои идеи и предложения не навязываешь, а «продаёшь».
🤟 S3 для M3. Поддерживающий
Ты участвуешь в развитии платформы не как руководитель, а как партнёр — предлагаешь идеи, ставишь цели, но способ их реализации и достижения оставляешь за сотрудником. Поддерживаешь сотрудника при его успехах и неудачах, поощряешь его инициативу и собственные идеи. Работаешь с его мотивацией и строишь доверительные отношения.
🖖 S4 для M4. Делегирующий
Ты сосредоточен на стратегии развитии платформы и подключаешь сотрудника к её реализации. Определяешь сроки, скоуп и точки контроля. Согласовываешь план — дальше он сам решает, как его выполнить. У него есть все права, полномочия и ответственность для реализации.
И вот твоя задача, как руководителя, — быстрее продвигать сотрудника по уровням зрелости вверх, применяя на каждом уровне необходимый стиль руководства.
❗️ Но помни, не все сотрудники могут пройти все четыре уровня — кто-то застрянет на промежуточных.
Тренинг базировался на модели ситуационного лидерства, которую разработали американские исследователи поведения Paul Hersey и Kenneth Blanchard и описали в своей книге «Management of Organizational Behavior» аж в 1969 году, и сейчас у неё уже десять переизданий!
В чём идея?
Идея в том, что любой человек, который переходит на новую должность, берётся за новый проект или открывает для себя новую область, неминуемо проходит через четыре уровня зрелости (Maturity Levels).
Например, ты поручаешь своему разработчику создать платформу для нагрузочного тестирования сервисов.
☝️ M1: Новичок-энтузиаст (не может, но хочет)
Это задача, о которой он давно мечтал: ресёрч, выбор инструмента, настройка окружения, первые тесты. Всё новое, ничего не понятно, у него горят глаза и полные штаны энтузиазма, он готов вкладываться, но опыта, знаний и компетенций в этой области у него пока нет.
✌️ M2: Разочаровавшийся ученик (не может и не хочет)
Всё оказалось не так увлекательно, как казалось вначале, нормальных инструментов нет, из коробки ничего не работает, надо допиливать, тесты падают, нормального препрод-окружения, чтобы гонять тесты, нет. Энтузиазм угас, горящие глаза затухли.
🤟 M3: Способный, но осторожный исполнитель (может, но не хочет)
Инструмент найден, как-то допилен и интегрирован, окружение как-то работает, и тесты даже запускаются и не падают. Опыт, набитый шишками, уже имеется, но вот большого желания доводить это до совершенства и развивать почему-то нет.
🖖 M4: Самостоятельный профессионал (хочет и может)
Тут он уже эксперт по нагрузочному тестированию на рынке, может собрать стенд для нагрузочного тестирования хоть из консервной банки и шариковой ручки — всё работает идеально и как часы.
И вот эта модель нам говорит, что лидер должен подстраивать свой стиль управления сотрудником в зависимости от уровня зрелости сотрудника в рамках решаемой им задачи.
Каждому уровню зрелости — свой стиль руководства.
☝️ S1 для M1. Указывающий
Ты директивно даёшь чёткие указания о том, как должна выглядеть и функционировать наша платформа: как разворачивать, запускать, эксплуатировать и в каком виде выдавать результат. Внимательно следишь за процессом реализации и проверяешь результат на каждом шаге.
✌️ S2 для M2. Наставнический
Ты объясняешь сотруднику, почему необходимо выбрать именно этот инструмент и начать его допиливать. Слушаешь его идеи и предложения по допиливанию, обсуждаешь их. Свои идеи и предложения не навязываешь, а «продаёшь».
🤟 S3 для M3. Поддерживающий
Ты участвуешь в развитии платформы не как руководитель, а как партнёр — предлагаешь идеи, ставишь цели, но способ их реализации и достижения оставляешь за сотрудником. Поддерживаешь сотрудника при его успехах и неудачах, поощряешь его инициативу и собственные идеи. Работаешь с его мотивацией и строишь доверительные отношения.
🖖 S4 для M4. Делегирующий
Ты сосредоточен на стратегии развитии платформы и подключаешь сотрудника к её реализации. Определяешь сроки, скоуп и точки контроля. Согласовываешь план — дальше он сам решает, как его выполнить. У него есть все права, полномочия и ответственность для реализации.
И вот твоя задача, как руководителя, — быстрее продвигать сотрудника по уровням зрелости вверх, применяя на каждом уровне необходимый стиль руководства.
❗️ Но помни, не все сотрудники могут пройти все четыре уровня — кто-то застрянет на промежуточных.
😎19🤔5🥴1
Фаря Рословец позвала меня на стрим 🍿
Будем говорить про масштабирование инженерных команд, выстраивание процессов и развитие инженерной культуры. Я расскажу на примере Citydrive, как за 3 года отмасштабировал ИТ-команду в 5 раз.
Встречаемся 4 сентября (завтра!) в 19:00 по Москве.
👉 Зарегистрироваться на стрим
Будем говорить про масштабирование инженерных команд, выстраивание процессов и развитие инженерной культуры. Я расскажу на примере Citydrive, как за 3 года отмасштабировал ИТ-команду в 5 раз.
Встречаемся 4 сентября (завтра!) в 19:00 по Москве.
👉 Зарегистрироваться на стрим
😎5
Только ленивый ещё не высказал свой прогноз о том, как AI изменит рынок разработки программного обеспечения. Эксперты рынка звучат так же убедительно, как и финансовые эксперты в 2014 году, которые уверяли нас, что рубль укрепляется и не надо покупать доллары… а потом случился «чёрный вторник», и доллар с 30 рублей за штуку взлетел до 80.
Радует одно, ребята, которые выкрикивали на каждом углу, что, мол, «скоро AI полностью заменит разработчиков», разочаровались в волшебности AI и подостыли. И сейчас таких утверждений всё меньше и меньше.
Но всё ещё я слышу другое утверждение — «middle и junior разработчики скоро будут не нужны, останутся только senior’ы». И вот, мне оно тоже кажется неубедительным. Давайте объясню почему.
Понятие senior неоднородно. Того, кого считают супер-крутым senior’ом в условной веб-студии, в большинстве случаев не возьмут даже на позицию junior в FAANG.
Почему? Да потому что наш супер-крутой senior из веб-студии может элементарно не знать, как построить масштабируемую архитектуру для проекта, чтобы выдержать 10k RPS. Он вполне может не суметь спроектировать распределённое файловое хранилище, чтобы сохранить все фотографии из VK, или быстро реализовать алгоритм Дейкстры.
А почему? Да потому что ему это и не нужно! У него нет таких задач. Всё, что требуется, так это быстро «на коленке» наклепать интернет-магазин или сайт-визитку для клиента и выложить это в прод. Ни миллионной аудитории, ни задачи коммивояжёра там не будет.
И вот если мы все перестанем писать код и превратимся в промпт-инженеров, будем лишь валидировать на галлюцинации и корректировать решения от LLM, то со сложностью задач ничего не поменяется. Будут простые задачи — типа, запромтить проект уровня интернет-магазина для продажи носков в Саратове. И будут сложные задачи — типа, запилить децентрализованную систему распределённых транзакций. И вот для этих задач нужны будут промпт-инженеры разного уровня.
Senior Prompt-Engineer’ами не рождаются — ими становятся.
И поэтому будут и senior и даже junior промпт-инженеры в веб-студиях, и junior и middle промпт-инженеры в средних компаниях. Все они будут расти, развиваться, создавая нормальное распределение уровней должностей промпт-инженеров.
Но поживём — увидим 😎
Радует одно, ребята, которые выкрикивали на каждом углу, что, мол, «скоро AI полностью заменит разработчиков», разочаровались в волшебности AI и подостыли. И сейчас таких утверждений всё меньше и меньше.
Но всё ещё я слышу другое утверждение — «middle и junior разработчики скоро будут не нужны, останутся только senior’ы». И вот, мне оно тоже кажется неубедительным. Давайте объясню почему.
Понятие senior неоднородно. Того, кого считают супер-крутым senior’ом в условной веб-студии, в большинстве случаев не возьмут даже на позицию junior в FAANG.
Почему? Да потому что наш супер-крутой senior из веб-студии может элементарно не знать, как построить масштабируемую архитектуру для проекта, чтобы выдержать 10k RPS. Он вполне может не суметь спроектировать распределённое файловое хранилище, чтобы сохранить все фотографии из VK, или быстро реализовать алгоритм Дейкстры.
А почему? Да потому что ему это и не нужно! У него нет таких задач. Всё, что требуется, так это быстро «на коленке» наклепать интернет-магазин или сайт-визитку для клиента и выложить это в прод. Ни миллионной аудитории, ни задачи коммивояжёра там не будет.
И вот если мы все перестанем писать код и превратимся в промпт-инженеров, будем лишь валидировать на галлюцинации и корректировать решения от LLM, то со сложностью задач ничего не поменяется. Будут простые задачи — типа, запромтить проект уровня интернет-магазина для продажи носков в Саратове. И будут сложные задачи — типа, запилить децентрализованную систему распределённых транзакций. И вот для этих задач нужны будут промпт-инженеры разного уровня.
Senior Prompt-Engineer’ами не рождаются — ими становятся.
И поэтому будут и senior и даже junior промпт-инженеры в веб-студиях, и junior и middle промпт-инженеры в средних компаниях. Все они будут расти, развиваться, создавая нормальное распределение уровней должностей промпт-инженеров.
Но поживём — увидим 😎
1😎14🥴2
Как-то один из моих лидов несколько месяцев не мог закрыть позицию в свою команду. И не то чтобы позиция была какая-то особенная — рядовой Golang-разработчик. Да и с рынком тогда всё было нормально — собеседования шли регулярно. Но каждый раз у него было «что-то не то»: то кандидат не до конца знаком с нашим стеком, то глубины знаний Golang не хватало, то где-то по софтам недотянул.
Месяцы шли, задачки копились, а мы всё искали идеального кандидата... 🫠
Как-то я читал про концепцию руководителей типа А и B:
👉 Руководитель типа А — это лидер, который не боится конкуренции и нанимает людей не слабее, а иногда даже сильнее себя
👉 Руководитель типа B — напротив, опасается нелояльных сотрудников, поэтому предпочитает брать людей слабее, чтобы сохранить контроль
Есть даже целая теория о том, что руководитель типа А собирает вокруг себя команду А-игроков, а руководитель типа B — команду С-игроков.
Но у руководителей типа А, особенно начинающих, есть своя ловушка — погоня за идеальным кандидатом. Они пытаются найти человека, который будет соответствовать всем ожиданиям и идеально решать все задачи.
Но идеальных кандидатов (может быть, даже к счастью) не существует. Каждая позиция уникальна, каждая команда со своими особенностями, и всегда найдётся то, чего кандидату будет не хватать для «идеального» соответствия.
Поэтому, чтобы не попасть в такую ловушку, мой совет 💡 — перестань искать идеальных, а сфокусируйся на перспективных.
Вот три вопроса, которые я задаю себе после каждого собеседования:
☝️ Чего именно кандидату не хватает, чтобы быть максимально подходящим для этой позиции?
Это могут быть конкретные технологии, практики и подходы. Или, например, умение обосновывать и отстаивать свою позицию, «продавать» решение команде, справляться с задачами в условиях неопределённости.
✌️ Смогу ли я научить этому кандидата?
Готов ли я инвестировать своё время и силы в его развитие? Будет ли у меня достаточно ресурсов? Смогу ли подключить к этому кого-то из команды?
🤟 Готов ли сам кандидат учиться и расти?
Насколько он открыт к развитию и получению новых знаний? Не будет ли он упираться и цепляться за старые подходы и навыки?
Моя задача за время собеседования собрать ответы на все эти вопросы. И если есть мэтч — даже если кандидат далеко не идеален для позиции — это даёт возможность рискнуть и попробовать взять его в команду.
❗️ Тут важно понимать, что сильные команды рождаются не из идеальных кандидатов, а из умения руководителя видеть потенциал и развивать людей.
Месяцы шли, задачки копились, а мы всё искали идеального кандидата... 🫠
Как-то я читал про концепцию руководителей типа А и B:
👉 Руководитель типа А — это лидер, который не боится конкуренции и нанимает людей не слабее, а иногда даже сильнее себя
👉 Руководитель типа B — напротив, опасается нелояльных сотрудников, поэтому предпочитает брать людей слабее, чтобы сохранить контроль
Есть даже целая теория о том, что руководитель типа А собирает вокруг себя команду А-игроков, а руководитель типа B — команду С-игроков.
Но у руководителей типа А, особенно начинающих, есть своя ловушка — погоня за идеальным кандидатом. Они пытаются найти человека, который будет соответствовать всем ожиданиям и идеально решать все задачи.
Но идеальных кандидатов (может быть, даже к счастью) не существует. Каждая позиция уникальна, каждая команда со своими особенностями, и всегда найдётся то, чего кандидату будет не хватать для «идеального» соответствия.
Поэтому, чтобы не попасть в такую ловушку, мой совет 💡 — перестань искать идеальных, а сфокусируйся на перспективных.
Вот три вопроса, которые я задаю себе после каждого собеседования:
☝️ Чего именно кандидату не хватает, чтобы быть максимально подходящим для этой позиции?
Это могут быть конкретные технологии, практики и подходы. Или, например, умение обосновывать и отстаивать свою позицию, «продавать» решение команде, справляться с задачами в условиях неопределённости.
✌️ Смогу ли я научить этому кандидата?
Готов ли я инвестировать своё время и силы в его развитие? Будет ли у меня достаточно ресурсов? Смогу ли подключить к этому кого-то из команды?
🤟 Готов ли сам кандидат учиться и расти?
Насколько он открыт к развитию и получению новых знаний? Не будет ли он упираться и цепляться за старые подходы и навыки?
Моя задача за время собеседования собрать ответы на все эти вопросы. И если есть мэтч — даже если кандидат далеко не идеален для позиции — это даёт возможность рискнуть и попробовать взять его в команду.
❗️ Тут важно понимать, что сильные команды рождаются не из идеальных кандидатов, а из умения руководителя видеть потенциал и развивать людей.
😎21🤔1
Пару недель назад я рассказывал Фаре Рословец про работу каршеринга. Мы обсудили устройство блоков телеметрии, инциденты с прямыми и косвенными убытками, но больше всего Фарю заинтересовала тема масштабирования команд.
Я пришёл в Ситидрайв в апреле 2022 года. Тогда ИТ-департамент насчитывал около 30 человек, из которых примерно 12 были в одной большой команде NodeJs-разработчиков во главе с лидом.
И вот с перформансом этой команды была большая проблема. Лид не имел опыта управления таким количеством людей и умения фокусировать их на результате. В итоге задачи распределялись хаотично: вчера разработчик писал бэкенд для мобильного приложения, сегодня он получал задачи по обработке телеметрии, а завтра менеджер уже заготовил задачки по внешним интеграциям.
Постоянное переключение контекста мешало ребятам погружаться в доменные области. Каждый раз при возвращении к коду приходилось заново разбираться в изменениях и искать место, куда вставить свои пару строчек. Неудивительно, что такие переключения почти всегда порождали баги и инциденты.
Функциональные команды
Чтобы решить описанные выше проблемы, я решил перестроить бэкенд: выделил ключевые домены, вокруг которых велась активная разработка, и сформировал вокруг них отдельные функциональные команды вместе с лидом.
Каждая команда полностью отвечала за свой домен: выносила бизнес-логику из монолита, сокращала технический долг, внедряла мониторинги и алертинги, дежурила и самостоятельно закрывала инциденты.
Направления разработки
За следующие полгода бизнес-инициатив стало значительно больше, и это привело к росту новых доменов и команд вокруг них.
В меня начали напрямую репортить 10 лидов 🤯 Быть прямым руководителем десяти лидов это крайне непродуктивное занятие — я не успевал глубоко погружаться в их контекст и проблемы и помогать в выборе решений.
И я выделил новый уровень организационной структуры. Сначала сгруппировал команды в функциональные направления (мобильная и серверная разработка), а затем пересобрал их в доменные направления разработки.
Кросс-функциональные команды
В парковом направлении мы почти сразу пришли к кросс-функциональным командам, а в клиентском долгое время сохранялись функциональные.
С ростом количества команд продакт-менеджерам становилось всё тяжелее. Каждую свою фичу они должны были разбить на задачки для разных команд, занести их в планирование каждой команды и потом следить, чтобы ничего не разъехалось.
Этот кавардак нужно было прекращать, и мы пересобрали клиентское направление: сформировали в нём пять кросс-функциональных команд, каждая из которых получила закреплённого продукт-менеджера и технического руководителя.
Такой путь — типичная эволюция для продуктовых команд разработки. Про всё это можно послушать в записи нашей трансляции на YouTube, RuTube и VK видео.
Я пришёл в Ситидрайв в апреле 2022 года. Тогда ИТ-департамент насчитывал около 30 человек, из которых примерно 12 были в одной большой команде NodeJs-разработчиков во главе с лидом.
И вот с перформансом этой команды была большая проблема. Лид не имел опыта управления таким количеством людей и умения фокусировать их на результате. В итоге задачи распределялись хаотично: вчера разработчик писал бэкенд для мобильного приложения, сегодня он получал задачи по обработке телеметрии, а завтра менеджер уже заготовил задачки по внешним интеграциям.
Постоянное переключение контекста мешало ребятам погружаться в доменные области. Каждый раз при возвращении к коду приходилось заново разбираться в изменениях и искать место, куда вставить свои пару строчек. Неудивительно, что такие переключения почти всегда порождали баги и инциденты.
Функциональные команды
Чтобы решить описанные выше проблемы, я решил перестроить бэкенд: выделил ключевые домены, вокруг которых велась активная разработка, и сформировал вокруг них отдельные функциональные команды вместе с лидом.
Так появились команды, отвечающие за:
👉 финансы (эквайринг, биллинг, рейтинги, программы лояльности, бонусы и начисления)
👉 бэкенд для мобильного приложения
👉 телеметрию (интеграция с блоками и обработка данных)
👉 бэк-офис (админки и системы управления парком)
Каждая команда полностью отвечала за свой домен: выносила бизнес-логику из монолита, сокращала технический долг, внедряла мониторинги и алертинги, дежурила и самостоятельно закрывала инциденты.
Направления разработки
За следующие полгода бизнес-инициатив стало значительно больше, и это привело к росту новых доменов и команд вокруг них.
Например:
👉 команда бэк-офиса разделилась на две: одна отвечала за админки и внутренние сервисы, вторая — за системы управления парком
👉 появилась команда по процессингу заказов
👉 выделился домен пользователя (регистрация, рейтинги, риск-профили), вокруг которого мы начали собирать команду из Golang-разработчиков
В меня начали напрямую репортить 10 лидов 🤯 Быть прямым руководителем десяти лидов это крайне непродуктивное занятие — я не успевал глубоко погружаться в их контекст и проблемы и помогать в выборе решений.
И я выделил новый уровень организационной структуры. Сначала сгруппировал команды в функциональные направления (мобильная и серверная разработка), а затем пересобрал их в доменные направления разработки.
В итоге получилось три направления:
👉 клиентское, отвечающее за разработку мобильного приложения и веб-версии
👉 парковое, отвечающее за сбор и обработку телеметрии, системы управления парком и внутренние сервисы
👉 платформенное, отвечающее за общие сервисы и инструменты для разработчиков
Кросс-функциональные команды
В парковом направлении мы почти сразу пришли к кросс-функциональным командам, а в клиентском долгое время сохранялись функциональные.
С ростом количества команд продакт-менеджерам становилось всё тяжелее. Каждую свою фичу они должны были разбить на задачки для разных команд, занести их в планирование каждой команды и потом следить, чтобы ничего не разъехалось.
Этот кавардак нужно было прекращать, и мы пересобрали клиентское направление: сформировали в нём пять кросс-функциональных команд, каждая из которых получила закреплённого продукт-менеджера и технического руководителя.
Команды отвечают за:
👉 маркетинговые инициативы
👉 финансы и оплаты
👉 пользовательский опыт во время аренды
👉 регистрацию клиентов и допуск в сервис
👉 веб-версию
Такой путь — типичная эволюция для продуктовых команд разработки. Про всё это можно послушать в записи нашей трансляции на YouTube, RuTube и VK видео.
😎15🤔1
И вот твоя первая рабочая неделя на позиции лида в новой компании почти подходит к концу — ты познакомился с ребятами из своей новой команды и уже даже успел погрузиться и дать архитектурные комментарии по нескольким запускаемым фичам.
И вдруг — бац 💥! Тебе пишет разработчик: «Привет, я хочу уволиться».
Не проходит и месяца, как на созвоне с другим разработчиком он говорит, что у него оффер, и он тоже хочет уйти из компании.
Прошёл всего месяц, а двое из шести членов команды уже на выходе. У тебя тревога, тебе кажется, что ты не справляешься, и в голове мысли: а что думает мой руководитель? Мол, я пришёл, создал кризис и все разбежались?
На самом деле кризис создал прошлый руководитель команды. Скорее всего, именно из-за этого его и уволили — низкий перформанс команды и его низкая вовлечённость завели команду в тупик, ребята выгорели и уже настроились на выход. Его увольнение лишь заморозило эту ситуацию на некоторое время. Но обычно, если человек решил уйти — он уйдёт. Появление нового руководителя лишь становится идеальным триггером для тех, кто давно собирался уйти.
Что делать, шеф?
☝️ Спрогнозируй риски
Пойми, какие ребята за что отвечают и какой экспертизой обладают. Определи, кто может уйти и какие риски это несёт — какие проекты пострадают и какие знания и компетенции команда может потерять.
Составь план минимизации этих рисков, например это может быть шэринг знаний или перераспределение задач. Постепенно реализуй этот план.
✌️ Дай оттоку оттечь
Не нужно бросаться удерживать выгоревших сотрудников любой ценой. Отток — это прекрасная возможность пересобрать команду. Чем быстрее уйдут те, кто не готов работать дальше, тем быстрее ты перезапустишь команду, и она начнёт приносить пользу бизнесу.
Говори ребятам спасибо за прошлые заслуги и спокойно отпускай их покорять новые горизонты.
🤟 Коммуницируй внутри команды
Тем не менее кризис должен быть контролируемым. Уход людей почти всегда порождает в команде слухи и вопросы. Тут важно ничего не замалчивать, а честно и открыто проговаривать каждую ситуацию ухода и отвечать на все вопросы.
Донеси команде, что увольнения — это естественный процесс обновления, и сейчас ты занят реорганизацией команды и управляешь этим процессом.
🖖 Держи руководителя в курсе
Докладывай о ситуации в команде, проговаривай с ним свой риск-план.
После каждого ухода сотрудника сообщай:
👉 кто именно уходит и почему
👉 какие проекты могут пострадать
👉 как ты организуешь подстраховку и замену
Важно показать руководителю, что ты контролируешь процесс и держишь всё под контролем.
И вдруг — бац 💥! Тебе пишет разработчик: «Привет, я хочу уволиться».
Не проходит и месяца, как на созвоне с другим разработчиком он говорит, что у него оффер, и он тоже хочет уйти из компании.
Прошёл всего месяц, а двое из шести членов команды уже на выходе. У тебя тревога, тебе кажется, что ты не справляешься, и в голове мысли: а что думает мой руководитель? Мол, я пришёл, создал кризис и все разбежались?
На самом деле кризис создал прошлый руководитель команды. Скорее всего, именно из-за этого его и уволили — низкий перформанс команды и его низкая вовлечённость завели команду в тупик, ребята выгорели и уже настроились на выход. Его увольнение лишь заморозило эту ситуацию на некоторое время. Но обычно, если человек решил уйти — он уйдёт. Появление нового руководителя лишь становится идеальным триггером для тех, кто давно собирался уйти.
Что делать, шеф?
☝️ Спрогнозируй риски
Пойми, какие ребята за что отвечают и какой экспертизой обладают. Определи, кто может уйти и какие риски это несёт — какие проекты пострадают и какие знания и компетенции команда может потерять.
Составь план минимизации этих рисков, например это может быть шэринг знаний или перераспределение задач. Постепенно реализуй этот план.
✌️ Дай оттоку оттечь
Не нужно бросаться удерживать выгоревших сотрудников любой ценой. Отток — это прекрасная возможность пересобрать команду. Чем быстрее уйдут те, кто не готов работать дальше, тем быстрее ты перезапустишь команду, и она начнёт приносить пользу бизнесу.
Говори ребятам спасибо за прошлые заслуги и спокойно отпускай их покорять новые горизонты.
🤟 Коммуницируй внутри команды
Тем не менее кризис должен быть контролируемым. Уход людей почти всегда порождает в команде слухи и вопросы. Тут важно ничего не замалчивать, а честно и открыто проговаривать каждую ситуацию ухода и отвечать на все вопросы.
Донеси команде, что увольнения — это естественный процесс обновления, и сейчас ты занят реорганизацией команды и управляешь этим процессом.
🖖 Держи руководителя в курсе
Докладывай о ситуации в команде, проговаривай с ним свой риск-план.
После каждого ухода сотрудника сообщай:
👉 кто именно уходит и почему
👉 какие проекты могут пострадать
👉 как ты организуешь подстраховку и замену
Важно показать руководителю, что ты контролируешь процесс и держишь всё под контролем.
😎10🤔2
«Вот сейчас проведём performance review, вычислим слабых разработчиков и уволим их!» — заявил мне как-то HR.
Всё так, мы коммерческая организация, и если сотрудник не приносит ожидаемого результата, то компании с ним не по пути. Но зачем же ждать — таких разработчиков и так видно.
Вот мой чек-лист, в каком порядке я оцениваю разработчиков.
Efficiency 🚀
Это то, как много задач разработчик закрывает за единицу времени — и больших, и маленьких.
Предсказуем, стабилен и точен относительно оценки задач — всегда в неё попадает, а лучше — опережает. Сохраняет стабильный темп работы на длинной дистанции, не выдыхаясь после интенсивного спринта.
Всё это характеризует высокопроизводительного разработчика — high performer 💪
Есть ещё low performer. Он не закрывает много задач за единицу времени, систематически не попадает в свои же оценки, не автономен — постоянно просит помощи и уточняет детали. Не берёт ответственность, тяжело переключается между контекстами, теряет фокус, зависает и уходит в пустые рассуждения.
💡 Как выявить?
Не нужны burn down chart’ы и скрытые механизмы слежки. Достаточно недельку поработать с человеком, послушать, что и как он говорит на daily, — и всё станет ясно. Разбуди ночью тимлида, и он сразу назовёт своих high и low перформеров.
Руководителю разработки с несколькими командами и десятками разработчиков стоит на 1-2-1 с тимлидами спрашивать, кто у него молодец, а кто нет. Если из раза в раз «немолодцы» одни и те же — вот и список low перформеров.
Опытные руководители разработки делают на коленке простой дашборд по всем своим разработчикам: кто сколько MR-ов влил в master, сколько задач закрыл и сколько деплоев сделал. Периодически заглядывают туда и, заметив отклонения, идут к тимлиду интересоваться.
Reliability 🦾
Если он high performer, закрывает кучу задач, но вместе с этим создаёт кучу багов и инцидентов на продакшене — то это уже не high, а low performer, который не включая голову выкатывает всё на прод и считает свои задачи закрытыми.
А насколько отказоустойчивы его технические решения — или всё падает при первой же нагрузке? Насколько они расширяемы — или каждый раз приходится рефакторить и разгребать спагетти-код, чтобы вставить ещё одну строчку?
Да, конечно, у всех есть error budget, и high performer в абсолютных значениях может ошибаться чаще, чем low performer, но зависимость между количеством закрытых задач и числом проблем на продакшене не должна быть линейной.
💡 Как выявить?
Стоит пару недель походить на инциденты — и всё станет ясно. Падает одно и то же, фиксы не устраняют корневую причину, новые правки рождают новые инциденты. Если «на арене цирка раз за разом те же клоуны» — значит, актёрский состав разработчиков, создающих проблемы, уже сформирован.
Или сервис только пару недель как запустили в прод, а разработчик уже закладывает рефакторинг в оценку новых фич. Не проходит и двух месяцев, как он заявляет, что неплохо бы вообще-то переписать сервис с нуля.
Loyalty 💎
High performer, который редко ошибается, — но как он работает в команде?
Моментально ли подключается к инцидентам и оперативно катит фикс? Или закрывает ноутбук в 18:00 — и гори оно всё синим пламенем?
Проявляет ли инициативу, предлагает ли улучшения процессов и подходов, делая свою и работу команды эффективнее? Или пассивен, безучастен, сидит на митингах с выключенной камерой и молчит?
Команде и смежникам комфортно с ним работать? Или это токсичный сгусток желчи, разлагающий коллектив?
💡 Как выявить?
Этих героев все знают в лицо, о них даже слагают легенды. Нужно быть совсем отстранённым от жизни команды, чтобы не замечать слона под ковром.
Вот тут и может помочь perf review и оценка 360°, если, например, разработчик был десантирован на внешний проект и фидбэк к тебе не доходил. Но чудес ждать не стоит — лучше сам иногда заходи к смежникам и спрашивай — всё ли ОК?
Как видишь, не нужно строить хитрые системы слежки и оценки перформанса сотрудников. Достаточно создать культуру требовательности — и команды сами начнут отторгать слабых разработчиков.
Всё так, мы коммерческая организация, и если сотрудник не приносит ожидаемого результата, то компании с ним не по пути. Но зачем же ждать — таких разработчиков и так видно.
Вот мой чек-лист, в каком порядке я оцениваю разработчиков.
Efficiency 🚀
Это то, как много задач разработчик закрывает за единицу времени — и больших, и маленьких.
Предсказуем, стабилен и точен относительно оценки задач — всегда в неё попадает, а лучше — опережает. Сохраняет стабильный темп работы на длинной дистанции, не выдыхаясь после интенсивного спринта.
Всё это характеризует высокопроизводительного разработчика — high performer 💪
Есть ещё low performer. Он не закрывает много задач за единицу времени, систематически не попадает в свои же оценки, не автономен — постоянно просит помощи и уточняет детали. Не берёт ответственность, тяжело переключается между контекстами, теряет фокус, зависает и уходит в пустые рассуждения.
💡 Как выявить?
Не нужны burn down chart’ы и скрытые механизмы слежки. Достаточно недельку поработать с человеком, послушать, что и как он говорит на daily, — и всё станет ясно. Разбуди ночью тимлида, и он сразу назовёт своих high и low перформеров.
Руководителю разработки с несколькими командами и десятками разработчиков стоит на 1-2-1 с тимлидами спрашивать, кто у него молодец, а кто нет. Если из раза в раз «немолодцы» одни и те же — вот и список low перформеров.
Опытные руководители разработки делают на коленке простой дашборд по всем своим разработчикам: кто сколько MR-ов влил в master, сколько задач закрыл и сколько деплоев сделал. Периодически заглядывают туда и, заметив отклонения, идут к тимлиду интересоваться.
Reliability 🦾
Если он high performer, закрывает кучу задач, но вместе с этим создаёт кучу багов и инцидентов на продакшене — то это уже не high, а low performer, который не включая голову выкатывает всё на прод и считает свои задачи закрытыми.
А насколько отказоустойчивы его технические решения — или всё падает при первой же нагрузке? Насколько они расширяемы — или каждый раз приходится рефакторить и разгребать спагетти-код, чтобы вставить ещё одну строчку?
Да, конечно, у всех есть error budget, и high performer в абсолютных значениях может ошибаться чаще, чем low performer, но зависимость между количеством закрытых задач и числом проблем на продакшене не должна быть линейной.
💡 Как выявить?
Стоит пару недель походить на инциденты — и всё станет ясно. Падает одно и то же, фиксы не устраняют корневую причину, новые правки рождают новые инциденты. Если «на арене цирка раз за разом те же клоуны» — значит, актёрский состав разработчиков, создающих проблемы, уже сформирован.
Или сервис только пару недель как запустили в прод, а разработчик уже закладывает рефакторинг в оценку новых фич. Не проходит и двух месяцев, как он заявляет, что неплохо бы вообще-то переписать сервис с нуля.
Loyalty 💎
High performer, который редко ошибается, — но как он работает в команде?
Моментально ли подключается к инцидентам и оперативно катит фикс? Или закрывает ноутбук в 18:00 — и гори оно всё синим пламенем?
Проявляет ли инициативу, предлагает ли улучшения процессов и подходов, делая свою и работу команды эффективнее? Или пассивен, безучастен, сидит на митингах с выключенной камерой и молчит?
Команде и смежникам комфортно с ним работать? Или это токсичный сгусток желчи, разлагающий коллектив?
💡 Как выявить?
Этих героев все знают в лицо, о них даже слагают легенды. Нужно быть совсем отстранённым от жизни команды, чтобы не замечать слона под ковром.
Вот тут и может помочь perf review и оценка 360°, если, например, разработчик был десантирован на внешний проект и фидбэк к тебе не доходил. Но чудес ждать не стоит — лучше сам иногда заходи к смежникам и спрашивай — всё ли ОК?
Как видишь, не нужно строить хитрые системы слежки и оценки перформанса сотрудников. Достаточно создать культуру требовательности — и команды сами начнут отторгать слабых разработчиков.
🥴17😎4🤨3
В жизни каждого руководителя наступает такой момент, когда нужно продать свою идею своему руководителю — будь то инициатива по внедрению новой технологии или изменению процесса.
И вот здесь важно понимать, что успех этой «продажи» зависит не столько от самой идеи, сколько от того, кому ты эту идею продаёшь и как ты это делаешь. Ведь по типу управленческого мышления все руководители разные, и то, что вдохновит одного, может вызвать неприязнь и раздражение у другого 😡
Существует множество разных практик того, как можно «упаковать» идею и какую лидерскую технику коммуникации выбрать для чтобы её «продать».
В этой заметке я хочу рассказать про модель Адизеса. Точнее, этой заметкой я открываю серию из пяти публикаций про эту модель и её типы руководителей.
Ицхак Кальдерон Адизес — писатель и бизнес-консультант, сформулировал концепцию, согласно которой любой руководитель в любой компании выполняет четыре функции:
👉 приносит результат, выступая производителем (Producer)
👉 строит порядок и процессы, выступая администратором (Administrator)
👉 генерирует идеи и указывает направление развития, выступая предпринимателем (Entrepreneur)
👉 соединяет людей и создаёт систему ценностей, выступая интегратором (Integrator)
Адизес утверждает, что только идеальный менеджер, у которого одновременно прокачаны все четыре функции, может привести компанию к успеху. Правда, Адизес ещё отмечает, что таких идеальных менеджеров не существует, потому что невозможно одновременно владеть всеми четырьмя функциями на высоком уровне. Чего уж говорить — по этой модели даже три функции выполнять успешно параллельно видится мне крайне затруднительным.
Поэтому хороший менеджер — это тот, кто выполняет две функции на отлично, а остальные две на хорошо.
И получается, что у нас есть руководители, у которых какая-то функция развита, а какая-то — нет. Адизес предложил систему кодирования руководителей по четырём буквам PAEI:
👉 если функция у руководителя развита сильно — она пишется с большой буквы,
👉 если слабо — с маленькой,
👉 если отсутствует — ставится прочерк.
Например:
👉 руководитель, у которого идеально развита только организационная работа (Administrator), будет кодироваться как pAei
👉 руководитель, который силён в генерации идей и производстве результата, но слабее в других функциях — PaEi
👉 руководитель, способный только лишь генерировать идеи — --E-
Адизес пошёл дальше и описал жизненный цикл организации — от зарождения до гибели. Он показал, что на разных этапах развития компании нужны разные лидеры с разным набором прокачанных функций.
А ещё бывают руководители, которые выгорели и потеряли смысл, — у них потухли все четыре функции:
👉 ничего не производит (P↓),
👉 не управляет процессами (A↓),
👉 не генерирует идей (E↓),
👉 не поддерживает людей (I↓).
Это управленец, который формально занимает позицию, но не создаёт никакой ценности — ни для команды, ни для компании. Для такого руководителя даже придумали специальный термин — «мёртвый пень». Он кодируется отсутствием всех функций как ----.
В следующих заметках я детально раскрою каждый тип руководителя и расскажу, как можно продать ему свою идею.
А пока можешь поставить лайк этой заметке и пройти тест, чтобы определить свой тип по Адизесу. Меня, например, этот опросник оценил как PAei, что соответствует правде 😎
И вот здесь важно понимать, что успех этой «продажи» зависит не столько от самой идеи, сколько от того, кому ты эту идею продаёшь и как ты это делаешь. Ведь по типу управленческого мышления все руководители разные, и то, что вдохновит одного, может вызвать неприязнь и раздражение у другого 😡
Существует множество разных практик того, как можно «упаковать» идею и какую лидерскую технику коммуникации выбрать для чтобы её «продать».
В этой заметке я хочу рассказать про модель Адизеса. Точнее, этой заметкой я открываю серию из пяти публикаций про эту модель и её типы руководителей.
Ицхак Кальдерон Адизес — писатель и бизнес-консультант, сформулировал концепцию, согласно которой любой руководитель в любой компании выполняет четыре функции:
👉 приносит результат, выступая производителем (Producer)
👉 строит порядок и процессы, выступая администратором (Administrator)
👉 генерирует идеи и указывает направление развития, выступая предпринимателем (Entrepreneur)
👉 соединяет людей и создаёт систему ценностей, выступая интегратором (Integrator)
Адизес утверждает, что только идеальный менеджер, у которого одновременно прокачаны все четыре функции, может привести компанию к успеху. Правда, Адизес ещё отмечает, что таких идеальных менеджеров не существует, потому что невозможно одновременно владеть всеми четырьмя функциями на высоком уровне. Чего уж говорить — по этой модели даже три функции выполнять успешно параллельно видится мне крайне затруднительным.
Поэтому хороший менеджер — это тот, кто выполняет две функции на отлично, а остальные две на хорошо.
И получается, что у нас есть руководители, у которых какая-то функция развита, а какая-то — нет. Адизес предложил систему кодирования руководителей по четырём буквам PAEI:
👉 если функция у руководителя развита сильно — она пишется с большой буквы,
👉 если слабо — с маленькой,
👉 если отсутствует — ставится прочерк.
Например:
👉 руководитель, у которого идеально развита только организационная работа (Administrator), будет кодироваться как pAei
👉 руководитель, который силён в генерации идей и производстве результата, но слабее в других функциях — PaEi
👉 руководитель, способный только лишь генерировать идеи — --E-
Адизес пошёл дальше и описал жизненный цикл организации — от зарождения до гибели. Он показал, что на разных этапах развития компании нужны разные лидеры с разным набором прокачанных функций.
А ещё бывают руководители, которые выгорели и потеряли смысл, — у них потухли все четыре функции:
👉 ничего не производит (P↓),
👉 не управляет процессами (A↓),
👉 не генерирует идей (E↓),
👉 не поддерживает людей (I↓).
Это управленец, который формально занимает позицию, но не создаёт никакой ценности — ни для команды, ни для компании. Для такого руководителя даже придумали специальный термин — «мёртвый пень». Он кодируется отсутствием всех функций как ----.
В следующих заметках я детально раскрою каждый тип руководителя и расскажу, как можно продать ему свою идею.
А пока можешь поставить лайк этой заметке и пройти тест, чтобы определить свой тип по Адизесу. Меня, например, этот опросник оценил как PAei, что соответствует правде 😎
😎24🤔2
Ты же заметил, что на позапрошлых двух неделях я выпал и ничего не публиковал? 😢
Расслабился и обленился, подумал ты? А вот и нет! Я вписался в парочку подкастов, и на днях вышел один из них — хочу поделиться 🔥
Мы встретились с Олей и за час поразмышляли о том, кто такой СТО, стоит ли вообще идти по этой карьерной дорожке и почему роль технического директора бывает такой одинокой.
Можно слушать, смотреть — или делать всё сразу. Осталось только выбрать платформу:
📺 YouTube
📺 VK Видео
🎙 Аудио подкаст
🎵 Яндекс подкаст
📺 Rutube
Все больше втягиваюсь в тему подкастов — сидишь, разговариваешь о чём-то интересном, это записывают, монтируют, выкладывают, обсуждают 😎
Если ты хостишь подкаст — приглашай меня обязательно, буду рад составить компанию в выпуске.
Расслабился и обленился, подумал ты? А вот и нет! Я вписался в парочку подкастов, и на днях вышел один из них — хочу поделиться 🔥
Мы встретились с Олей и за час поразмышляли о том, кто такой СТО, стоит ли вообще идти по этой карьерной дорожке и почему роль технического директора бывает такой одинокой.
Можно слушать, смотреть — или делать всё сразу. Осталось только выбрать платформу:
Все больше втягиваюсь в тему подкастов — сидишь, разговариваешь о чём-то интересном, это записывают, монтируют, выкладывают, обсуждают 😎
Если ты хостишь подкаст — приглашай меня обязательно, буду рад составить компанию в выпуске.
Please open Telegram to view this post
VIEW IN TELEGRAM
😎7🤔1
Мы с тобой обсудили модель менеджеров по Адизесу, а теперь начнём обсуждать каждый тип по отдельности. Начнём с Производителя (Producer, буковка P).
Производитель — это менеджер, который знает, как всё устроено, глубоко понимает специфику своего дела и умеет, используя эти знания и возможности, быстро решать любые задачи и приносить максимальный результат здесь и сейчас.
Производителю нужна чёткая и измеримая цель, и тогда он будет мотивирован на её достижение. Если нет конкретных показателей успеха, то Производитель теряет интерес и демотивируется — он не понимает, что именно нужно достичь и как это влияет на успех компании. Он не любит обсуждений и советов, предпочитает единолично и быстро принимать решения, считая свои мотивы понятными и очевидными, а при несогласии с ним — настойчиво и авторитарно продавливает своё мнение. Раздражается и теряет мотивацию, когда кто-то вмешивается в его работу, пытается контролировать или тормозит.
Производитель не мыслит стратегически, а его решения краткосрочны. Он привык использовать знакомые инструменты и не склонен к внедрению инноваций или созданию чего-то нового.
Задача, выполненная собственными силами, приносит Производителю наибольшее удовлетворение, а отсутствие признания его заслуг демотивирует.
В своей крайней форме (P---) Производитель превращается в Героя-одиночку 🦸
Герой-одиночка — это трудоголик, который берёт всю работу на себя. Он решает самые сложные, важные и срочные задачи, а его подчинённые — наблюдатели на подхвате. Когда Герой осознаёт, что не справляется, он, так уж и быть, в последний момент сбрасывает часть горящих задач на подчинённых. В остальное время они без дела слоняются по коридорам, потому что у Героя-одиночки нет ни времени, ни интереса заниматься административными вопросами.
Как работать с руководителем-производителем❓
👉 Будь кратким и конкретным: оперируй фактами и цифрами, начинай с сути, а не с контекста
👉 Не начинай с проблем — начни с решения. Сначала расскажи, что предлагаешь, а потом — как ты к этому пришёл, не перегружая деталями
👉 Будь морально готов к авралу: твой руководитель рано или поздно подкинет тебе горящую задачу, с которой сам не успевает справиться
Он мыслит категориями «что, когда, сколько и какой эффект». Поэтому, продвигая идею, нужно оперировать полученной выгодой и результатом. И ни в коем случае не пытайся «продать» идею через философию, эмоции, вдохновение или лозунги — только разозлишь.
Что делать, если руководитель-производитель — это ты❓
👉 Не принимай решения молниеносно и не беги реализовывать. Остынь, переспи и дай себе время на размышления — а нужно ли вообще это делать, есть ли в этом польза?
👉 Не отвергай мнения тиммейтов, поощряй их инициативу и участие, прислушивайся к ним, учитывай их в принятии решений
👉 Не доводи задачи до кризисных ситуаций — делегируй их на более ранних этапах. А лучше выпиши то, что можешь делать только ты, — остальное отдай команде
👉 Мысли стратегически: жёстко выделяй время в календаре для размышлений — о целях, рисках и направлениях развития. Принимая решение, задавай себе вопрос: «Как это решение будет работать через 3–6 месяцев?»
Производитель — это менеджер, который знает, как всё устроено, глубоко понимает специфику своего дела и умеет, используя эти знания и возможности, быстро решать любые задачи и приносить максимальный результат здесь и сейчас.
Производителю нужна чёткая и измеримая цель, и тогда он будет мотивирован на её достижение. Если нет конкретных показателей успеха, то Производитель теряет интерес и демотивируется — он не понимает, что именно нужно достичь и как это влияет на успех компании. Он не любит обсуждений и советов, предпочитает единолично и быстро принимать решения, считая свои мотивы понятными и очевидными, а при несогласии с ним — настойчиво и авторитарно продавливает своё мнение. Раздражается и теряет мотивацию, когда кто-то вмешивается в его работу, пытается контролировать или тормозит.
Производитель не мыслит стратегически, а его решения краткосрочны. Он привык использовать знакомые инструменты и не склонен к внедрению инноваций или созданию чего-то нового.
Задача, выполненная собственными силами, приносит Производителю наибольшее удовлетворение, а отсутствие признания его заслуг демотивирует.
В своей крайней форме (P---) Производитель превращается в Героя-одиночку 🦸
Герой-одиночка — это трудоголик, который берёт всю работу на себя. Он решает самые сложные, важные и срочные задачи, а его подчинённые — наблюдатели на подхвате. Когда Герой осознаёт, что не справляется, он, так уж и быть, в последний момент сбрасывает часть горящих задач на подчинённых. В остальное время они без дела слоняются по коридорам, потому что у Героя-одиночки нет ни времени, ни интереса заниматься административными вопросами.
Как работать с руководителем-производителем❓
👉 Будь кратким и конкретным: оперируй фактами и цифрами, начинай с сути, а не с контекста
👉 Не начинай с проблем — начни с решения. Сначала расскажи, что предлагаешь, а потом — как ты к этому пришёл, не перегружая деталями
👉 Будь морально готов к авралу: твой руководитель рано или поздно подкинет тебе горящую задачу, с которой сам не успевает справиться
Он мыслит категориями «что, когда, сколько и какой эффект». Поэтому, продвигая идею, нужно оперировать полученной выгодой и результатом. И ни в коем случае не пытайся «продать» идею через философию, эмоции, вдохновение или лозунги — только разозлишь.
Что делать, если руководитель-производитель — это ты❓
👉 Не принимай решения молниеносно и не беги реализовывать. Остынь, переспи и дай себе время на размышления — а нужно ли вообще это делать, есть ли в этом польза?
👉 Не отвергай мнения тиммейтов, поощряй их инициативу и участие, прислушивайся к ним, учитывай их в принятии решений
👉 Не доводи задачи до кризисных ситуаций — делегируй их на более ранних этапах. А лучше выпиши то, что можешь делать только ты, — остальное отдай команде
👉 Мысли стратегически: жёстко выделяй время в календаре для размышлений — о целях, рисках и направлениях развития. Принимая решение, задавай себе вопрос: «Как это решение будет работать через 3–6 месяцев?»
😎16🤔2
А знаешь ли ты, как происходит запись подкаста?
Вот если очень утрированно, то путь таков. Выбирается тема подкаста, интервьюер составляет список вопросов согласно этой теме, и мы согласовываем их с PR. Потом я накидываю тезисы ответов и тоже согласовываю с PR. Встречаемся, записываемся. Первая редактура интервьюера — он там что-то вырезает, потом согласовываем с PR, и они тоже что-то просят вырезать. И, о счастье, если мы отклоняемся от списка вопросов и поговорим о чём-то отвлечённом, и это тоже не будет вырезано 😢
Как ты понял, это мероприятие по большей части требует предварительной подготовки. Что было совсем не так на подкасте, про который я вам тут хочу рассказать. Я уже тизернул вам, что вписался в два подкаста — про один уже рассказал. Теперь про второй 😎
Иван Чернов и Иван Елфимов, разработчики из «Ostrovok! Tech», делают подкаст «Два Ивана (название обсуждается)», в котором мне удалось поучаствовать.
Я бы, конечно, хотел сказать, что тема подкаста была про инциденты в ИТ и как мы в Ситидрайв построили процесс работы с технологическими инцидентами, но ребятам удалось создать невероятно ламповую обстановку, что я даже первый куплет гимна Узбекистана по памяти пропел.
В общем, очень необычный и новый для меня опыт такого рода подкастов, а послушать, что получилось, можно на:
💬 Mave в Telegram
🎙 Mave
🎵 Яндекс Музыка
📺 YouTube
📺 VK
P.S. На фотографии — мы с Иванами на записи этого подкаста в студии в Москве.
Вот если очень утрированно, то путь таков. Выбирается тема подкаста, интервьюер составляет список вопросов согласно этой теме, и мы согласовываем их с PR. Потом я накидываю тезисы ответов и тоже согласовываю с PR. Встречаемся, записываемся. Первая редактура интервьюера — он там что-то вырезает, потом согласовываем с PR, и они тоже что-то просят вырезать. И, о счастье, если мы отклоняемся от списка вопросов и поговорим о чём-то отвлечённом, и это тоже не будет вырезано 😢
Как ты понял, это мероприятие по большей части требует предварительной подготовки. Что было совсем не так на подкасте, про который я вам тут хочу рассказать. Я уже тизернул вам, что вписался в два подкаста — про один уже рассказал. Теперь про второй 😎
Иван Чернов и Иван Елфимов, разработчики из «Ostrovok! Tech», делают подкаст «Два Ивана (название обсуждается)», в котором мне удалось поучаствовать.
Я бы, конечно, хотел сказать, что тема подкаста была про инциденты в ИТ и как мы в Ситидрайв построили процесс работы с технологическими инцидентами, но ребятам удалось создать невероятно ламповую обстановку, что я даже первый куплет гимна Узбекистана по памяти пропел.
В общем, очень необычный и новый для меня опыт такого рода подкастов, а послушать, что получилось, можно на:
P.S. На фотографии — мы с Иванами на записи этого подкаста в студии в Москве.
Please open Telegram to view this post
VIEW IN TELEGRAM
😎7
Недавно у меня был перелёт со стыковочным рейсом. У меня был целый час, и я решил взять кофе в аэропорту. С баристой у нас возникли небольшие трудности перевода, но в итоге он понял, что я хочу латте большого размера с единственным шотом эспрессо.
Когда я вернулся за кофе, бариста радостно протянул мне кружку, но вместо латте в ней был обычный американо. Я ещё раз взглянул на чек — в нём было пробито именно латте. Указав на несоответствие, бариста удивился, извинился и пошёл переделывать напиток. Вернувшись через пару минут, он снова извинился, протянул мне кружку с латте, и я ушёл ждать посадку и наслаждаясь кофе. Кстати, кофе он сделал действительно неплохой.
Казалось бы, ну допустил ошибку и допустил. Но интересно, сколько таких ошибок он делает за день. Вместо того чтобы приготовить сто порций кофе, он же может сделать и сто тридцать. А где он возьмёт время на дополнительные тридцать кружек? Будет перерабатывать, уставать, выгорать и/или выполнять другие свои функции хуже 😢
На самом деле, всё это ложится и на наши команды, в которых разработчики говорят, что приходится заниматься только продуктовыми задачками и продакт-менеджеры не оставляют времени на рефакторинг и технический долг.
Ровно с такой же риторикой я столкнулся, когда пришёл в Ситидрайв. Команда из десяти backend-разработчиков с лидом, все как один, заявили мне, что им никто не выделяет время на рефакторинг.
Наверное, можно было бы сразу занять такую же позицию, побежать и начать ругаться с продуктами, договариваться о квоте на технические задачи или пытаться увеличивать штат. Но я взял небольшую паузу, чтобы посмотреть, что ребята вообще делают и как они это делают.
Вот примеры того, что я заметил:
👉 У меня был разработчик, который регулярно получал от команды саппорта задачи по начислению различного рода компенсаций пользователям. Он открывал базу и вручную делал селекты и апдейты.
👉 Второй разработчик вручную запускал скрипт миграции карт со старого эквайринга на новый. Если какие-то карты мигрировались неверно, он пробегался по ним и пытался вручную их смигрировать.
👉 А ещё у нас был плавающий баг в системе расчёта рейтинга пользователя, и при даунтаймах рейтинг пересчитывался неверно у некоторых пользователей. Лежали мы тогда часто, поэтому после каждого такого инцидента разработчик бежал и вручную пересчитывал этот рейтинг для пострадавших пользователей.
По сути, то время, которое разработчики могли бы потратить на исправление технического долга и на рефакторинг, они тратили на эти ручные операции. Я пару недель анализировал работу десяти разработчиков и выписал порядка трёх десятков таких кейсов, которые точно можно и нужно было автоматизировать.
Вместо того чтобы бегать и исправлять рассинхронизацию рейтинга, нужно было просто поправить баг с race condition в самом сервисе. Вместо того чтобы вручную править данные в базе, нужно было просто сделать кнопку в админке, чтобы команда операторов сама могла начислять нужные компенсации пользователям.
Все эти кейсы я технически и продуктово проработал и нарезал задач в трекере разработчикам. И о чудо — по мере реализации каждой задачи каждая следующая стала делаться быстрее, потому что начало высвобождаться время от ручных операций. За месяц с небольшим ребята закрыли все мои задачки и уже начали сами приносить свои — с идеями, где что нужно поменять или переписать, чтобы дальше бежать быстрее. Так мне удалось без дополнительного найма сделать команду более производительной и более продуктивной.
Возвращаясь к баристе из кафе ☕️
Конечно можно придумать и внедрить способ двойной валидации заказа перед приготовлением напитков. Но часто проблема скрывается и в самих людях, которые не готовы перепроверять за собой и просто склонны систематически ошибаться. И здесь, к сожалению, никакой процесс не спасёт. Скорее всего, с такими людьми вам просто не по пути.
Когда я вернулся за кофе, бариста радостно протянул мне кружку, но вместо латте в ней был обычный американо. Я ещё раз взглянул на чек — в нём было пробито именно латте. Указав на несоответствие, бариста удивился, извинился и пошёл переделывать напиток. Вернувшись через пару минут, он снова извинился, протянул мне кружку с латте, и я ушёл ждать посадку и наслаждаясь кофе. Кстати, кофе он сделал действительно неплохой.
Казалось бы, ну допустил ошибку и допустил. Но интересно, сколько таких ошибок он делает за день. Вместо того чтобы приготовить сто порций кофе, он же может сделать и сто тридцать. А где он возьмёт время на дополнительные тридцать кружек? Будет перерабатывать, уставать, выгорать и/или выполнять другие свои функции хуже 😢
На самом деле, всё это ложится и на наши команды, в которых разработчики говорят, что приходится заниматься только продуктовыми задачками и продакт-менеджеры не оставляют времени на рефакторинг и технический долг.
Ровно с такой же риторикой я столкнулся, когда пришёл в Ситидрайв. Команда из десяти backend-разработчиков с лидом, все как один, заявили мне, что им никто не выделяет время на рефакторинг.
Наверное, можно было бы сразу занять такую же позицию, побежать и начать ругаться с продуктами, договариваться о квоте на технические задачи или пытаться увеличивать штат. Но я взял небольшую паузу, чтобы посмотреть, что ребята вообще делают и как они это делают.
Вот примеры того, что я заметил:
👉 У меня был разработчик, который регулярно получал от команды саппорта задачи по начислению различного рода компенсаций пользователям. Он открывал базу и вручную делал селекты и апдейты.
👉 Второй разработчик вручную запускал скрипт миграции карт со старого эквайринга на новый. Если какие-то карты мигрировались неверно, он пробегался по ним и пытался вручную их смигрировать.
👉 А ещё у нас был плавающий баг в системе расчёта рейтинга пользователя, и при даунтаймах рейтинг пересчитывался неверно у некоторых пользователей. Лежали мы тогда часто, поэтому после каждого такого инцидента разработчик бежал и вручную пересчитывал этот рейтинг для пострадавших пользователей.
По сути, то время, которое разработчики могли бы потратить на исправление технического долга и на рефакторинг, они тратили на эти ручные операции. Я пару недель анализировал работу десяти разработчиков и выписал порядка трёх десятков таких кейсов, которые точно можно и нужно было автоматизировать.
Вместо того чтобы бегать и исправлять рассинхронизацию рейтинга, нужно было просто поправить баг с race condition в самом сервисе. Вместо того чтобы вручную править данные в базе, нужно было просто сделать кнопку в админке, чтобы команда операторов сама могла начислять нужные компенсации пользователям.
Все эти кейсы я технически и продуктово проработал и нарезал задач в трекере разработчикам. И о чудо — по мере реализации каждой задачи каждая следующая стала делаться быстрее, потому что начало высвобождаться время от ручных операций. За месяц с небольшим ребята закрыли все мои задачки и уже начали сами приносить свои — с идеями, где что нужно поменять или переписать, чтобы дальше бежать быстрее. Так мне удалось без дополнительного найма сделать команду более производительной и более продуктивной.
Возвращаясь к баристе из кафе ☕️
Конечно можно придумать и внедрить способ двойной валидации заказа перед приготовлением напитков. Но часто проблема скрывается и в самих людях, которые не готовы перепроверять за собой и просто склонны систематически ошибаться. И здесь, к сожалению, никакой процесс не спасёт. Скорее всего, с такими людьми вам просто не по пути.
😎16🥴3
Уверен, в твоей компании есть такой человек — или ты точно встречал его за время своей карьеры.
Упал прод и никто не знает, что делать? Звонят ему. Критический баг в пятницу, и чинить некому? Ну как некому — мы знаем, кто поможет. Он никогда не говорит «нет», всегда спешит на помощь, доступен в любое время дня и ночи и даже в отпуске (а ходит ли он вообще в отпуск?).
Он всегда приходит на помощь, тушит любой пожар и всех спасает.
Таких людей мы называем «героями» 🦸 и слагаем о них оды. Чего говорить, даже у Бориса Гребенщикова был универсальный рецепт на любой кризис — «Немедля звони человеку из Кемерова».
Как-то один, знавший жизнь, системный администратор сказал мне фразу, которую, как мне кажется, я запомнил на всю жизнь — «Героизм одних — это про*б других».
И вот так часто бывает, что в случае наших героев тот, кто проявил героизм, и тот, кто допустил про*б, — один и тот же человек.
Так, ведь и вправду.
👉 Герой не даёт команде расти
Абсолютно не доверяет другим, считает, что сам всё сделает быстрее и лучше. Это сопровождается публичным обесцениванием членов команды, мол, «бездарности, приходится всё править за вас». Не делится знаниями, потому что боится потерять статус «незаменимого».
В такой токсичной обстановке остальные члены команды чувствуют себя второстепенными и теряют мотивацию.
👉 Герой создаёт хаос
Постоянно нарушает процессы во имя результата. Код-ревью? Не, буду пушить напрямую в мастер! Тестирование и отладка кода в дев-среде? Это лишняя бюрократия! Автотесты? Документация? Ну ты понял... 😅
Постоянная работа в авральном режиме, хот-фиксы, правки — всё это неизбежно ведёт к техническому долгу и багам.
💡 Тут важно понимать, что герой лечит последствия, а не причины.
Он не работает на упреждение проблем, а сражается и «спасает» всех в последний момент, когда уже совсем всё плохо. Так оно и понятно: когда система работает устойчиво и стабильно — герои никому не нужны, а вот когда «всё сломалось, и он за ночь всё починил» — это повод для гордости и место «подвигу».
И институт геройства — это не причина, а следствие проблем. «Герои» своими усилиями скрывают фундаментальные проблемы в процессах и архитектуре, которые иначе были бы очевидны и требовали бы решения. И стоит убрать героев, как всё рассыплется, как карточный домик.
Что делать, шеф?
☝️ Убери топливо для героизма
Перестань хвалить героя, а начни хвалить команду. Поощряй не факт подвига с устранением проблемы, а внедрение системы или процесса, которые позволят не допустить такую проблему в будущем. Мотивируй команду на постоянное создание и внедрение процессов и систем.
✌️ Создай ротацию
Снижай зависимость от отдельных экспертов, вовлекая всех во все этапы производственных процессов, ротируй сотрудников между проектами. Знания и навыки сами начнут равномерно распределяться по команде, кто-то даже начнёт писать документацию для себя, которой сможет поделиться с другими.
🤟 Почини планирование
У задач должны быть реалистичные сроки выполнения, они должны учитывать риски и системные проблемы. Вы должны уметь гибко переприоритезировать ваш бэклог, если кто-то неожиданно заболеет или уйдёт в day off. Любая задача из бэклога должна иметь возможность быть выполненной другим членом команды. Перестань выводить сотрудников на работу в выходные дни и во внерабочее время.
🖖 Регламентируй и автоматизируй
У любой части производственного процесса должен быть регламент, он должен быть описан, и с ним должна быть ознакомлена вся команда, и он должен быть ей понятен. Если регламент подразумевает ручные действия и их можно автоматизировать — это надо обязательно сделать.
Герои нужны в кино❗️там есть завязка и кульминация сюжета, а в сложных сервисах, которые работают 24/7, нужны системность, отказоустойчивость и стабильность.
А если в твоей компании успешные релизы всегда сопровождаются историями о чьих-то героических усилиях, то я тебя поздравляю — у вас культура героизма.
Упал прод и никто не знает, что делать? Звонят ему. Критический баг в пятницу, и чинить некому? Ну как некому — мы знаем, кто поможет. Он никогда не говорит «нет», всегда спешит на помощь, доступен в любое время дня и ночи и даже в отпуске (а ходит ли он вообще в отпуск?).
Он всегда приходит на помощь, тушит любой пожар и всех спасает.
Таких людей мы называем «героями» 🦸 и слагаем о них оды. Чего говорить, даже у Бориса Гребенщикова был универсальный рецепт на любой кризис — «Немедля звони человеку из Кемерова».
Как-то один, знавший жизнь, системный администратор сказал мне фразу, которую, как мне кажется, я запомнил на всю жизнь — «Героизм одних — это про*б других».
И вот так часто бывает, что в случае наших героев тот, кто проявил героизм, и тот, кто допустил про*б, — один и тот же человек.
Так, ведь и вправду.
👉 Герой не даёт команде расти
Абсолютно не доверяет другим, считает, что сам всё сделает быстрее и лучше. Это сопровождается публичным обесцениванием членов команды, мол, «бездарности, приходится всё править за вас». Не делится знаниями, потому что боится потерять статус «незаменимого».
В такой токсичной обстановке остальные члены команды чувствуют себя второстепенными и теряют мотивацию.
👉 Герой создаёт хаос
Постоянно нарушает процессы во имя результата. Код-ревью? Не, буду пушить напрямую в мастер! Тестирование и отладка кода в дев-среде? Это лишняя бюрократия! Автотесты? Документация? Ну ты понял... 😅
Постоянная работа в авральном режиме, хот-фиксы, правки — всё это неизбежно ведёт к техническому долгу и багам.
💡 Тут важно понимать, что герой лечит последствия, а не причины.
Он не работает на упреждение проблем, а сражается и «спасает» всех в последний момент, когда уже совсем всё плохо. Так оно и понятно: когда система работает устойчиво и стабильно — герои никому не нужны, а вот когда «всё сломалось, и он за ночь всё починил» — это повод для гордости и место «подвигу».
И институт геройства — это не причина, а следствие проблем. «Герои» своими усилиями скрывают фундаментальные проблемы в процессах и архитектуре, которые иначе были бы очевидны и требовали бы решения. И стоит убрать героев, как всё рассыплется, как карточный домик.
Что делать, шеф?
☝️ Убери топливо для героизма
Перестань хвалить героя, а начни хвалить команду. Поощряй не факт подвига с устранением проблемы, а внедрение системы или процесса, которые позволят не допустить такую проблему в будущем. Мотивируй команду на постоянное создание и внедрение процессов и систем.
✌️ Создай ротацию
Снижай зависимость от отдельных экспертов, вовлекая всех во все этапы производственных процессов, ротируй сотрудников между проектами. Знания и навыки сами начнут равномерно распределяться по команде, кто-то даже начнёт писать документацию для себя, которой сможет поделиться с другими.
🤟 Почини планирование
У задач должны быть реалистичные сроки выполнения, они должны учитывать риски и системные проблемы. Вы должны уметь гибко переприоритезировать ваш бэклог, если кто-то неожиданно заболеет или уйдёт в day off. Любая задача из бэклога должна иметь возможность быть выполненной другим членом команды. Перестань выводить сотрудников на работу в выходные дни и во внерабочее время.
🖖 Регламентируй и автоматизируй
У любой части производственного процесса должен быть регламент, он должен быть описан, и с ним должна быть ознакомлена вся команда, и он должен быть ей понятен. Если регламент подразумевает ручные действия и их можно автоматизировать — это надо обязательно сделать.
Герои нужны в кино❗️там есть завязка и кульминация сюжета, а в сложных сервисах, которые работают 24/7, нужны системность, отказоустойчивость и стабильность.
А если в твоей компании успешные релизы всегда сопровождаются историями о чьих-то героических усилиях, то я тебя поздравляю — у вас культура героизма.
1😎17
Ну что ж, сегодня был мой последний рабочий день в Ситидрайв 💪
Это были невероятно драйвовые и продуктивные почти 4 года, но пора двигаться дальше!
Когда я пришёл в Ситидрайв на позицию СТО в марте 2022 года, я и не мог представить, сколько всего нужно будет сделать и сколько в итоге будет сделано. А сделать удалось действительно многое 😎
👉 2022 год. Подняли стабильность сервиса в 50 раз! Мы снизили потери от технологических инцидентов с 1,5% GMV в месяц до 0,03%. Это позволило сократить отток аудитории, и мы смогли подняться с третьего места на рынке каршеринга на второе.
👉 2023 год. Рост бизнеса и запуск новых бизнес-инициатив. Инженерная команда выросла в 2 раза — с 50 до 100 человек, попутно автоматизировав всё, что можно, максимально ускорив путь кода до продакшена.
👉 2024 год. Фокус на качестве после бешеного роста. Запустили направление сопровождения сервисов — быстрее реагируем на проблемы клиентов и решаем их. Повысили качество инженерных решений — запустили архитектурный комитет и технологические учения.
👉 2025 год. Мы полностью переосмыслили идею каршеринга и превратили её в платформу для автолюбителей, запустив новые направления бизнеса «Надолго» и «Rent-a-car». Инженерная команда выросла до 150 человек, и мы начали реализацию новой технологической платформы, которая позволяет быстро запускать и валидировать бизнес-инициативы.
Главное достижение, которым поистине горжусь за эти 4 года — это команда, которую удалось собрать и вырастить. Команда, где каждый инженер силён, уникален и является экспертом в своей области.
И сейчас, когда IT-стратегия на 3 года защищена, а бюджет на 2026 год утверждён, самое время передать управление команде и двигаться дальше — к новым вызовам и возможностям 🚀
И пользуясь моментом, хочу поздравить всех с наступающим Новым годом — увидимся уже в новом году! 🎄✨
Это были невероятно драйвовые и продуктивные почти 4 года, но пора двигаться дальше!
Когда я пришёл в Ситидрайв на позицию СТО в марте 2022 года, я и не мог представить, сколько всего нужно будет сделать и сколько в итоге будет сделано. А сделать удалось действительно многое 😎
👉 2022 год. Подняли стабильность сервиса в 50 раз! Мы снизили потери от технологических инцидентов с 1,5% GMV в месяц до 0,03%. Это позволило сократить отток аудитории, и мы смогли подняться с третьего места на рынке каршеринга на второе.
👉 2023 год. Рост бизнеса и запуск новых бизнес-инициатив. Инженерная команда выросла в 2 раза — с 50 до 100 человек, попутно автоматизировав всё, что можно, максимально ускорив путь кода до продакшена.
👉 2024 год. Фокус на качестве после бешеного роста. Запустили направление сопровождения сервисов — быстрее реагируем на проблемы клиентов и решаем их. Повысили качество инженерных решений — запустили архитектурный комитет и технологические учения.
👉 2025 год. Мы полностью переосмыслили идею каршеринга и превратили её в платформу для автолюбителей, запустив новые направления бизнеса «Надолго» и «Rent-a-car». Инженерная команда выросла до 150 человек, и мы начали реализацию новой технологической платформы, которая позволяет быстро запускать и валидировать бизнес-инициативы.
Главное достижение, которым поистине горжусь за эти 4 года — это команда, которую удалось собрать и вырастить. Команда, где каждый инженер силён, уникален и является экспертом в своей области.
И сейчас, когда IT-стратегия на 3 года защищена, а бюджет на 2026 год утверждён, самое время передать управление команде и двигаться дальше — к новым вызовам и возможностям 🚀
И пользуясь моментом, хочу поздравить всех с наступающим Новым годом — увидимся уже в новом году! 🎄✨
3🎄48😎16🤔5🥴1