Продолжение прошлого поста, истории про "что такое плохо"
4️⃣ "В Ставрополе за эти деньги..."
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
5️⃣ "Как правильно или как лучше?"
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Еще давно, на первой работе я был стажером в аутсорсинговой разработке. Там классно был организован конвейер по отбору, обучению и онбордингу высококлассных стажеров. Но после окончания стажировки люди переходили на сдельную зарплату и перспективы были довольно плачевные. Все стажеры в "курилке" обсуждали свои сомнительные перспективы в компании, когда они перейдут из стажеров в специалисты. Некоторые даже специально оттягивали этот момент, хотя зарплата стажера была больше похожа на стипендию.
И вот, встреча с руководством компании, где можно открыто поговорить и задать вопросы. Я освещаю выше описанную ситуацию и предложение пересмотреть условия, на которых люди начинают работать как специалисты, гендиректор триггерится на фразу про стипендию, со словами "да в в Ставрополе люди за эти деньги" рады работать и так далее. Всё, далее уже никакие рациональные аргументы не имеют смысла. Больше я в этой компании руководству ничего не предлагал. Пара человек при мне ушли на х2 зп в другие компании. Потом и я ушел.
Это очень частая ситуация, когда человек воспринимает ситуацию, требующую менеджерского решения, не рационально, а эмоционально, причем эмоции часто основаны на воспринимаемом близко к сердцу личном (опыте или переживании).
Мораль:
➖Решая ситуацию как менеджер, нельзя полагаться на эмоции, на свою личную жизнь и опыт, прошлую карьеру. Только на объективный анализ текущей ситуации
➖"Мне/кому-то было тяжело, теперь вам должно быть тяжело" - это токсичная, неэффективная, а потому еще и глупая установка
В этой истории я уже достаточно опытный разработчик с навыками аналитика, решающий весь цикл задачи от общения с пользователем до реализации и тестирования. Наша команда занимается разработкой биллинга и различных внутренних продуктов, которыми пользуется бухгалтерия и т.п.
Возникает типовая задача - из-за рассинхрона финансовых данных между разными сервисами нужен какой-то механизм сверок. Есть несколько частей системы, за каждую отвечают разные отделы. И вот есть заказчик - главный бухгалтер, и есть менеджер, принимающий решение - директор по разработке.
У нас возникли разногласия - я предлагал сделать сверку на стороне моей команды, потому что тогда это будет сделано быстро и качественно. Директор предлагал сделать в на стороне команды, которая отвечает за данные (DWH), потому что это "правильно", и по правильному сверки должны быть на их стороне. Технически сделать можно было и так и так - в обеих системах были все возможности.
В общем мы немного поспорили, потому что я понимал, что если это отдать им - это либо вообще не будет сделано, либо будет сделано через несколько месяцев против наших 1-2 недель. Но Head of Dev твердо остался на своем.
Это типичный выбор между "как правильно" (теоретически) и "как лучше" (в реальности). И это довольно типичная ошибка людей с майндсетом разработчика.
Я на тот момент еще достаточно горячо, скажем так, воспринимал такие ситуации, поэтому на этом я не остановился, и решил слегка поинтриговать, чтобы было таки выбрано мое решение. Я отдельно встретился и обсудил ситуацию с заказчиком (главным бухгалтером) и описал просто - "либо мы делаем как хочет Стас, либо это будет нормально и быстро сделано". Она всё поняла, не знаю что там было сделано за кулисами, но через пару дней нам отдали эту задачу )
Мораль:
➖Реальные условия на земле всегда важнее "теоретически правильного" решения
➖При оценке ситуации надо учитывать качество и надежность кадров, а не только технологии и организационную структуру
➖Порой можно добиться своего решения, даже если ты разработчик, а оппонент - директор по разработке. Если уметь и хотеть. Другой вопрос - нужно ли вам это?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8🔥4❤2
#рекомендации
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
В перерывах между историями хочу поделиться рассказом Ивана Селиховкина "Черная книга скрам". Это тот чел, набором статей про проектный менеджмент которого я делился в одном из постов.
Вообще я не знаю, что он за человек и чем занимается, но он пишет очень умно и с глубоким знанием вопроса.
По сути, здесь он в форме рассказа иронически пересматривает очень распространенную не критичную точку зрения на Agile в форме карго-культа. Я бы даже сказал, что прочитать рассказ и тщательно его обдумать - это хорошее упражнение, чтобы подняться на ступеньку выше как менеджер, умеющий выбирать правильные организационные инструменты.
Ссылка: https://pmjournal.ru/articles/keysy/chernaya-kniga-skram/
👍3🔥2🤔1
Продолжаем истории "что такое плохо".
6️⃣ "Удали, пожалуйста, свое сообщение"
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Я тогда работал разрабом, где-то 2,5 года опыта примерно было. 50%+ моей работы это была поддержка, в основном колл-центра, оформления заказов, логистики и т.п. в приложении. Короче, много общался с пользователями и консультировал их, так как часто какие-то проблемы были из недопонимания и решались на словах. А если надо было кодить - то либо решал сам, либо передавал другим разрабам по зонам ответственности. И я был, соответственно, единой точкой входа в команду разработки по любым проблемам.
При этом у нас были трое парней на саппорте, которые по сути просто перенаправляли запросы ко мне, даже с типовыми вопросами. У меня закономерно возникла идея реорганизовать саппорт по нормальному, чтобы консультационные вопросы по работе приложения решались поддержкой, а не разрабами, типовые так точно.
Я придумал и предложил руководителю департамента улучшенную схему работы саппорта, предложил сделать внутреннюю базу знаний по решению типовых кейсов поддержкой и т.п., с обоснованием, в том числе экономическим (саппорт в несколько раз дешевле разрабов).
На это предложение отреагировали положительно, но с классической оговоркой - что организация, внедрение и обучение полностью на мне.
И вот, ближе к концу обсуждения этой идеи, идет переписка на корпоративном портале в комментах между мной, руководителем нашего департамента разработки, и техническим директором, который руководит этими чувачками на саппорте. У меня возникает резонный вопрос - а какая мотивация у этих ребят браться за это и усложнять себе работу - сейчас они с отключенным мозгом могут просто раскидывать тикеты, а в этой схеме они должны стать специалистами как минимум 2 линии. И там же спрашиваю, будет ли у них какое-то повышение зарплаты или какой у них мотив этим заниматься. В общем веду себя как нормальный человек, который конструктивно решает рабочую проблему.
Через несколько минут мне звонит техдир, их руководитель, и говорит "Удали, пожалуйста, свое сообщение". Я, помню, даже опешил от такого прикола. Говорю: "эээ, хорошо, а какая-все таки у них будет мотивация этим заниматься?". И он отвечает: "то что их не уволят" %)) В общем молодо-зелено, сообщение я удалил (сегодняшний я бы не удалил), но сразу сделал вывод, что, во-первых, техдир идиот, и во-вторых, что шансов у этого проекта примерно 0%.
При этом проект уже был повешен на меня. Я потратил какое-то время, пытаясь понять, можно ли с него съехать, и когда понял, что нельзя - просто договорился со своим руководителем, что мы попробуем, может получится, а может нет (я знал, что точно нет), и не стал особо вкладывать усилия в это, отработал чисто формально (естественно, у чуваков не было никакой мотивации), и всё это потихоньку сошло на нет за несколько месяцев и тихо было прикопано без каких-то дальнейших обсуждений.
Мораль:
➖Если вы имеете дело с каким-то среднего уровня менеджментом (а средний уровень - слабый), то скорее всего ваши предложения по улучшению работы, требующие чего-то от кого-то кроме вас - не взлетят. Бывает сложно оценить уровень менеджера, особенно по неопытности, но просто знать об этом уже неплохо.
➖Переход на принципиально более сложную и ответственную работу всегда должен сопровождаться промоушеном (повышением с изменением роли и зарплаты). Он может быть отложенным (по достижению результата), но из этого правила нет исключений. Альтернатива - почти гарантированно отсутствие мотивации этим заниматься.
➖Если на человека вешают невыполнимую или крайне неприятную задачу - отказываться и ругаться это не всегда единственная выход, который у него есть. Тихий и неприметный слив - это вторая опция. Это знает любой опытный менеджер как применительно к себе, так и к членам своей команды )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤4🔥3
Предпоследняя история про плохой менеджмент.
7️⃣ "вам самим-то не надоело в говне сидеть?"
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Эта история из восьми - моя любимая. Сама ситуация очень короткая, но чтобы была понятна вся ее глубина - придется рассказать предысторию.
Мы работали с другом в одной компании, оба программистами. У него были амбиции тимлида, и он нашел подходящую вакансию. Позвал меня с собой - поставил там условие, что ему нужен свой аналитик-прогер.
Это была финтех компания, в ней долгое время не могли найти руководителя в одну из команд разработки. Всё, начиная от процессов и заканчивая состоянием системы, было в относительно плачевном состоянии (было вообще в ужасном, но часть уже успели наладить при предыдущем тимлиде, который ушел за несколько месяцев до этого).
Онбординг был из серии "вот держите доступы". При трудоустройстве я общался с Head of HR и CTO, когда я через месяц пришел на работу - оба они уже уволились. По некоторым конкретным вопросам мог проконсультировать бывший тимлид (с ним был контракт на поддержку), но в целом он не сильно горел желанием сотрудничать и это было заметно.
Так что по большому счету нас просто закинули туда и предоставили самим себе. На доске в Jira - все как обычно, какие-то задачи зависшие на много месяцев в in development, непонятно что на самом деле в работе, задачи с описанием в две строки или вообще без описания и куча проблем в системе. И с командой тоже не все гладко - например, там был чувак, который вообще ничего не делал и его пришлось сразу уволить.
По сути у нас не было никакого руководителя, никто нам не ставил никакие цели, был какой-то поток бизнесовых задач, но в целом мы были просто предоставлены сами себе. Друг занялся больше технической частью и командой, я занялся процессами, ходил вместо него на часть совещаний с руководителями других отделов и заказчиками, реверс-инжинирингом проанализировал имеющийся API и описал его, ну и так далее. Я разобрался в Jira, стал ее админить, сделал новую нормальную доску, сделал рабочий процесс, внедрил его. Ну и при этом мы оба еще параллельно прогали задачи, которые влетали к нам - на разработку или какую-то аналитику собрать.
Так прошло первых несколько месяцев. Наняли нам нового руководителя - техдира. Чувак из тех, про которых сразу мелькает мысль, что физиогномика работает. Мы познакомились, он там начал какой-то свой онбординг проходить, вникать в дела.
(мы подошли к самой ситуации категории "что такое плохо") И вот, где-то пару недель наверно он работает, подходит он к нам с моим другом в опенспейсе с каким-то очередным вопросом о том, как всё устроено, и говорит: "слушайте, вам самим-то не надоело в говне сидеть?"
Вот так вот. %)
Мораль:
➖Ну, во-первых это очень смешно )
➖ Недостаток эмпатии и эгоцентричность для менеджера - это очень большая проблема, исключающая возможность наладить доверительные отношения с сотрудниками (если это не какие-то попадающие в зависимость жертвы)
➖Надо думать, что говоришь. Можно ляпнуть какую-то глупость при знакомстве с людьми, и потом исправить это впечатление будет крайне тяжело или невозможно
➖Другие люди - это не NPC, они тоже что-то делают осмысленное. Придя на новую работу - стоит начать с интервью членов команды и сбора информации о том, что происходило до тебя
➖Ситуацию в менеджменте надо всегда понимать не в статике, а в динамике - "было/стало", отдельные факты имеют малое значение. И лишь на таком уровне стоит давать какую-то оценку работе других людей.
➖И если эта оценка плохая - порой лучше промолчать и подумать еще.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤5🔥4
Человек для роли или роль для человека?
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
Пару раз у меня стояла задача составить или применять "матрицу грейдов" для команды разработки. У думающих людей эти матрицы всегда вызывают процесс критического осмысления содержимого.
❓Действительно ли мы это используем в работе?
❓Правда ли мы именно так определяем рост на следующий грейд?
❓Действительно ли те, кого мы нанимаем и кто у нас уже работают - одинаково соответствуют описанным характеристикам?
❓Действительно ли мы именно на эти вещи смотрим, когда оцениваем сотрудников?
Ну и так далее. Обычно ответ на все или часть этих вопросов - нет.
Другой вопрос - дело ли в конкретной матрице (плохая матрица) или вообще под вопросом целесообразность ее наличия.
Хорошая сторона этой затеи - людям действительно порой не хватает ориентиров по каким критериям им можно улучшить свою работу и как двинуться дальше. Но это в принципе можно решать личным карьерным треком, сделанным на пару с менеджером.
Такие "хорошие" стороны как формализация причин отказа в повышении или принижения чьих-то заслуг я не рассматриваю как хорошие ) Стандартизацию с натяжкой можно отнести к положительным, но стандартизация не имеет самоценности и не может быть целью самой себя.
Плохих сторон, как мне видится, гораздо больше.
Они проистекают из идеи, что люди разные, и у всех разные сильные и слабые стороны. Есть такое выражение - "прокрустово ложе". Строгое и последовательное соблюдение стандартов грейдов, на мой взгляд, имеет именно этот эффект.
Во-первых, кто-то круче, а кто-то слабее. Стандарт подгонять под слабых или под сильных? Если его сделать средним - одни не будут до него дотягивать, другие будут заведомо его превышать. Придется лукавить.
Во-вторых, всегда (почти) это сводится к "на бумаге так, а на практике мы наши субъективные оценки работы человека подгоняем под шаблон". То есть, если нам чья-то работа нравится - мы склонны таким образом зафреймить его работу, чтобы она подходила под предлагаемые компетенции. А если нет - то всегда без труда можно найти в списке отсутствующие или слабые пункты.
То есть фактически это не алгоритмизируется и не автоматизируется, поэтому поверх субъективного мнения менеджера мы просто накладываем формальный слой, который добавляет издержки поверх субъективного решения. То есть решение будет ровно то же самое, просто потребуется дополнительный труд для его принятия.
Но вообще пост не про матрицу компетенций и грейды. Пост про то, вокруг чего строить команду - вокруг сильных сторон или вокруг слабостей. Это не такой очевидный вопрос, и хоть я в такой формулировке его не слышал от других менеджеров, а только в книгах, но по факту люди этот выбор совершают.
Когда мы говорим, что для определенной роли нужен такой-то минимальный набор компетенций, фактически мы легитимизируем фокусировку на слабых сторонах. То есть надо каждую свою компетенцию довести до какого-то приемлемого уровня.
В реальности мы часто имеем команду, в которой люди очень разные, причем чем команда сильнее - тем она более разнообразна и вариативна. В такой команде один будет энтузиастом, другой надежным и ему можно доверить ответственные вещи делать в соло, третий хаотичным и забывчивым, но решающим намного более сложные задачи, четвертый - очень трудоспособным, но с проблемами когда надо делать что-то сложное, а пятый - добряком, с которым всем приятно работать и из-за этого в команде отличная атмосфера.
Представьте, что для этих людей нужно сделать единый стандарт. Это я упомянул (в очень утрированном поверхностном виде) только про личные качества. А еще есть зоны ответственности, которые тоже распределены совершенно неравномерно. Кто-то только делает задачи, а кто-то еще их создает. Кто-то делает деплой. Кто-то следит за ошибками в логах, а кто-то нет.
Надо ли, чтобы все делали весь перечень работ? Сколько-то пунктов из этого списка? А что, если кто-то будет очень хорошо и стабильно делать сложные задачи, но ничего дополнительно на себя не берет?
Здесь есть над чем подумать, и, пожалуй, тема стоит еще одного поста, раскрывающего мою точку зрения на то, "как надо".
👍8🔥5
Мысли о рекрутинге.
В последнее время все больше стал об этом думать. Хочу поделиться с вами.
Для начала, что меня наводило на размышления:
1️⃣ Когда начинаешь работать менеджером, начинаешь видеть насколько сложно найти хотя бы просто нормально работающих людей. Это совершенно непонятно, когда сам куда-то устраиваешься, или просто работаешь с норм коллегами, часть которых еще и круче тебя намного. Это было 5 лет назад, тогда я просто обратил внимание на это, но не придал особо значения.
2️⃣ Я сделал наблюдение, что практически все топовые ребята в команде - это либо пришедшие по стажерской программе, либо по рефералкам. За редким исключением те, кто просто приходил по холодному найму из рынка - исполняли работу при прочих равных на грейд ниже остальных, и чаще всего это была работа в формате исполнения базовых функций. Ну, или наоборот - рефералы и бывшие стажеры выполняли работу на один грейд выше, чем те, кого наняли с рынка.
3️⃣ Потом я начал в подробностях смотреть как изнутри выглядит найм. Например, как разработчик, проводящий собесы, предлагает фильтр по 5 годам опыта. Или как проходит собес чел, который в итоге не умеет делать практически ничего из того, что обсуждалось на собеседовании. Или как приходит чел с хорошими хардами и по рефералке, а в итоге ничего не делает.
4️⃣ Я смотрел одно из видео с Антоном Гладковым, где он рассказал, как нанимает людей. Во-первых, критерии отбора были там гораздо более серьезными. Во-вторых, сроки найма там были порядка недели ("3 дня") вместо возни по несколько месяцев как у всех. То есть в 10+ раз меньше срок при более высоком качестве.
На тот момент я сделал вывод, что холодный найм это крайне унылое и бесперспективное занятие, и наверно по хорошему проще вложить аналогичное количество средств и усилий в формирование способов поиска теплых или горячих кандидатов, чем строить эти конвейеры холодного найма. По крайней мере если речь идет про средний бизнес без HR-бренда с потребностями в единицах людей, ну максимум 1-2 десятках.
5️⃣ Как и все остальные, я наслышан о форматах собеседований в бигтехе. Например, когда мидлом устроиться на порядок проще, чем стажером. Про все эти академические вопросы. Рисования кода на доске. Алгоритмические секции, в том числе для QA. Тесты кубернетеса и кафки для джуна QA. Запрет на использование ИИ ассистента во время собеса. Когда сначала не проходит собес человек, которого потом в этой же компании отрывают в руками и он работает топ-перформером. И ровно обратные ситуации.
6️⃣ Когда я сам питчил работу в моей команде людям, я начал понимать, что рекрутеры не могут так же, по крайней мере если не сформируют тщательно уникальное предложение, скрупулезно изучив особенности команды и компании, куда нанимают. Я рассказывал про типовые задачи, реально важные фичи типа что нет дейликов и кучи дебильных встреч и можно просто работать, и прочие вещи. Отталкиваясь от своего понимания, что у нас особенно по кайфу, если поставить себя на место разработчика. А у всех по дефолту печеньки, интересный коллектив и дружный проект. А, еще продукт, который 10 или 20 лет на рынке! Это как продавать машину, уникальное предложение которой сводится к тому, что она ездит.
7️⃣ Ну и наконец, одно из последних наблюдений, как проходят технические собесы кандидаты, в которых я заведомо знаю, что они отлично работают и являются топ-перформерами. По обоим был фидбек что-то типа 5-6 из 10 и отрицательный вердикт - "не подходит". В основном потому, что не имел опыта работы с конкретными инструментами, технологиями и ситуациями )
То есть я выяснил, что мало того, что есть проблема, что берут тех, кто потом не работает (или не увольняют таких), так еще и режут тех, кто потом бы работал отлично.
(не влезло в 1 пост, продолжение вторым постом ниже)
В последнее время все больше стал об этом думать. Хочу поделиться с вами.
Для начала, что меня наводило на размышления:
На тот момент я сделал вывод, что холодный найм это крайне унылое и бесперспективное занятие, и наверно по хорошему проще вложить аналогичное количество средств и усилий в формирование способов поиска теплых или горячих кандидатов, чем строить эти конвейеры холодного найма. По крайней мере если речь идет про средний бизнес без HR-бренда с потребностями в единицах людей, ну максимум 1-2 десятках.
То есть я выяснил, что мало того, что есть проблема, что берут тех, кто потом не работает (или не увольняют таких), так еще и режут тех, кто потом бы работал отлично.
(не влезло в 1 пост, продолжение вторым постом ниже)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍8
Итого, у нас складывается довольно интересная картина:
➖Поле холодного найма очень слабое, найти даже просто норм работающих людей очень сложно
➖На вакухи летят тысячи отзывов, в том числе большинство нерелевантных, копаться в них без фильтрации уже никто не может. Начинаются какие-то взаимные войны автоматизаций
➖Холодный найм перестает работать - все больше найма сводится к другим способам (например, через прямые приглашения)
➖Есть куча вакансий, которые месяцами не могут закрыть
➖При этом есть топовые люди, которые не могут найти либо вообще ничего толкового, либо достойное их место для раскрытия своего потенциала
➖Есть просто "программисты из подвала", которые работают за 0,5 ценника от вакансий тех, кто не может месяцами найти никого толкового. Они не участвуют в рынке по ряду причин, включая выше озвученные
➖Есть собесы, которые плохо сделаны и их отвратительно проходить
➖Навык прохождения собеседований всё меньше коррелирует с реальным выхлопом от работы
➖Уволить после неудачного найма очень сложно
➖При этом для сотрудников практически отсутствует институт репутации (про компании еще хоть что-то можно узнать из открытых источников) - то есть всякие токсики, отморозки и паразиты просто дрейфуют по разным компаниям, еще больше ухудшая выборку холодного найма
➖Ценник рекрутинга айтишника через агентства достигает 20-25% его годовой зарплаты
➖При этом даже в результате относительно неплохо сделанных собесов бывают ложноположительные и ложноотрицательные заключения
Список неполный.
Выглядит так, как будто здесь закопаны какие-то новые еще не реализованные возможности )
➖Поле холодного найма очень слабое, найти даже просто норм работающих людей очень сложно
➖На вакухи летят тысячи отзывов, в том числе большинство нерелевантных, копаться в них без фильтрации уже никто не может. Начинаются какие-то взаимные войны автоматизаций
➖Холодный найм перестает работать - все больше найма сводится к другим способам (например, через прямые приглашения)
➖Есть куча вакансий, которые месяцами не могут закрыть
➖При этом есть топовые люди, которые не могут найти либо вообще ничего толкового, либо достойное их место для раскрытия своего потенциала
➖Есть просто "программисты из подвала", которые работают за 0,5 ценника от вакансий тех, кто не может месяцами найти никого толкового. Они не участвуют в рынке по ряду причин, включая выше озвученные
➖Есть собесы, которые плохо сделаны и их отвратительно проходить
➖Навык прохождения собеседований всё меньше коррелирует с реальным выхлопом от работы
➖Уволить после неудачного найма очень сложно
➖При этом для сотрудников практически отсутствует институт репутации (про компании еще хоть что-то можно узнать из открытых источников) - то есть всякие токсики, отморозки и паразиты просто дрейфуют по разным компаниям, еще больше ухудшая выборку холодного найма
➖Ценник рекрутинга айтишника через агентства достигает 20-25% его годовой зарплаты
➖При этом даже в результате относительно неплохо сделанных собесов бывают ложноположительные и ложноотрицательные заключения
Список неполный.
Выглядит так, как будто здесь закопаны какие-то новые еще не реализованные возможности )
👍16❤6
image_2025-11-07_21-13-35.png
62.4 KB
Индивидуальная ответственность или коллективная?
Я наткнулся на эту картинку, которую рисовал полтора года назад, чтобы пояснить коллеге, почему нельзя применять подход коллективной ответственности за результат, пока у тебя нет индивидуальной.
В принципе, наверно это была культурная дискуссия (в смысле, что о культуре).
Его посыл, как я его понял, был такой, что не нужно (и даже плохо) обсуждать кто и что конкретно должен делать или плохо делает, а важно, чтобы все (включая людей из разных структурных единиц, например, разработчиков и продактов) работали вместе и добивались результата.
Мой посыл был такой, что есть уровни зрелости, набросал схему как я это понимаю, и что нельзя "перепрыгнуть", а нужно последовательно по ним идти. А если попытаться применить сразу последнюю модель - то будет контрпродуктивно.
То есть:
1️⃣ Сначала нужно добиться/убедиться, что каждый член команды хорошо понимает и делает свою работу. Индивидуально.
2️⃣ Потом нужно убедиться, что команда умеет действовать сообща и интересуется результатом своей работы.
3️⃣ Потом необходимо создать прозрачную систему, через которую принимается работа и транслируется результат этой слаженной команды.
4️⃣ И лишь потом можно говорить о том, чтобы эффективно объединять разные команды для успешной совместной работы, где нет ничего "чужого".
То есть: индивидуальная работа -> тимбилдинг -> прозрачность и системность -> коллективный результат
Почему так?
Потому что если у вас есть проблемы с предыдущими этапами, а вы используете более продвинутую модель - у вас все незакрытые издержки будут вынесены на системный уровень.
Например:
➖у вас есть несколько людей, которые не делают что от них требуется? Другие будут работать за них, потому что "нам важен только командный результат". Со временем люди начнут раздражаться - почему они должны выполнять больше работы за других. Раздражение проявится по разному - кто-то уйдет, кто-то снизит производительность.
Или так:
➖вы не создали прозрачную систему, в которой понятен результат конкретной команды - и вот есть проект, который делают несколько команд. Все вокруг общее, все вокруг ничье. Зоны ответственности и результаты перемешаны. Система не позволяет качественно на большом масштабе распределить работу и так же прозрачно получить результат. Понять, кто справляется, а кто нет. Типичный итог - слабые команды заваливают проект, который пытаются потом судорожно пытаются вытянуть более сильные команды.
Люди (по крайней мере люди моей и близких западных культур) хотят хорошо работать, если результат их работы ассоциируется с их индивидуальностью и личными качествами. Когда они могут себя проявить. И не хотят хорошо работать, если плохая работа не порицается и не устраняется, а издержки от нее просто ложатся на тех, кто лучше работает.
Я наткнулся на эту картинку, которую рисовал полтора года назад, чтобы пояснить коллеге, почему нельзя применять подход коллективной ответственности за результат, пока у тебя нет индивидуальной.
В принципе, наверно это была культурная дискуссия (в смысле, что о культуре).
Его посыл, как я его понял, был такой, что не нужно (и даже плохо) обсуждать кто и что конкретно должен делать или плохо делает, а важно, чтобы все (включая людей из разных структурных единиц, например, разработчиков и продактов) работали вместе и добивались результата.
Мой посыл был такой, что есть уровни зрелости, набросал схему как я это понимаю, и что нельзя "перепрыгнуть", а нужно последовательно по ним идти. А если попытаться применить сразу последнюю модель - то будет контрпродуктивно.
То есть:
То есть: индивидуальная работа -> тимбилдинг -> прозрачность и системность -> коллективный результат
Почему так?
Потому что если у вас есть проблемы с предыдущими этапами, а вы используете более продвинутую модель - у вас все незакрытые издержки будут вынесены на системный уровень.
Например:
➖у вас есть несколько людей, которые не делают что от них требуется? Другие будут работать за них, потому что "нам важен только командный результат". Со временем люди начнут раздражаться - почему они должны выполнять больше работы за других. Раздражение проявится по разному - кто-то уйдет, кто-то снизит производительность.
Или так:
➖вы не создали прозрачную систему, в которой понятен результат конкретной команды - и вот есть проект, который делают несколько команд. Все вокруг общее, все вокруг ничье. Зоны ответственности и результаты перемешаны. Система не позволяет качественно на большом масштабе распределить работу и так же прозрачно получить результат. Понять, кто справляется, а кто нет. Типичный итог - слабые команды заваливают проект, который пытаются потом судорожно пытаются вытянуть более сильные команды.
Люди (по крайней мере люди моей и близких западных культур) хотят хорошо работать, если результат их работы ассоциируется с их индивидуальностью и личными качествами. Когда они могут себя проявить. И не хотят хорошо работать, если плохая работа не порицается и не устраняется, а издержки от нее просто ложатся на тех, кто лучше работает.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6💯3👍1
Наконец, последняя из 8 историй про плохой менеджмент.
8️⃣ Кидалово обыкновенное
Действующие лица: снова тот же чел, техдир из прошлой истории + тимлид и сеньор разраб из его команды.
Ситуация - канун нового года, это было еще в России - поэтому длинные праздники впереди. Если что-то навернется - никого не будет на работе. Обсуждаются дежурства - быть на подхвате, если что-то сломается - быстро подключиться и разрулить.
Техдир договаривается с тимлидом, что тот с еще одним опытным разрабом, чередуясь, подежурят на январские праздники. Техдир недавно пришел, поэтому он не особо в теме, как это делалось раньше, просто спрашивает как было раньше.
Тимлид совершает неточность, не проговорив до конца условия дежурства (компенсацию), потому что предполагает, что условия будут полностью те же, что и в прошлый раз.
Проходят январские праздники, люди отдежурили, но ничего не сломалось. И когда поднимается вопрос компенсации - это были то ли отгулы, то ли небольшая премия - техдир такой: а ничего же не сломалось, за что?
Я эту историю поставил последней, потому что эта ошибка в менеджменте - самая грубая: жадность и экономия на мелочах - проигрыш по крупному. Абсолютно никакой мотивации, кроме скверного характера, за таким решением стоять не может.
В чем проигрыш? Естественно, люди это запомнили. Тимлид и самый опытный разработчик. И в любой последующей ситуации взаимодействия с этим техдиром - перешли исключительно к транзакционному взаимодействию (я даю что-то тебе только после того, как ты даешь что-то мне) и урезали очень много своей добровольной инициативы, причем незаметно для этого руководителя.
Мораль:
➖личная порядочность имеет большое значение. Ее стоит брать в расчет, когда нанимаешь руководителя. Если человек чмо - для менеджера это вылезет быстрее и повлияет намного сильнее
➖глупо жадничать в мелочах - больше потеряешь по крупному
➖обычно стоит сохранять позитивные традиции. Если было принято поощрять людей за что-то определенным образом ранее - лучше сделать так же, если нет каких-то серьезных оснований сделать по другому
Итого, у нас есть 8 историй:
Плюрализм споткнулся о размер столов
Ну это, конечно, неправда
Ты подрываешь мой авторитет
В Ставрополе за эти деньги...
Как правильно или как лучше?
Удали, пожалуйста, свое сообщение
Вам самим-то не надоело в говне сидеть?
И сегодняшняя, Кидалово обыкновенное
Что из них можно почерпнуть? Думаю, каждый найдет что-то свое. Я думаю примерно следующее:
➖Все ошибаются, на любой позиции, причем достаточно часто. Не всегда "руководству виднее" (довольно популярный стереотип). Отрицать это глупо. Другой вопрос - как часто, насколько критично, как себя в этом случае ведут и учатся ли на своих ошибках
➖Можно учиться на чужих ошибках. Если Вы - человек наблюдательный и анализирующий, то работая на соло позиции и планируя стать менеджером, можно смотреть по сторонам, находить ошибки, и думать, как было бы можно сделать лучше. А еще лучше обсуждать или анализировать вместе с кем-то
➖Часто мы действуем интуитивно, когда ошибаемся. Это значит, что поглощая информацию о разных ситуациях, оптимальных или плохих решениях, впитывая такой опыт (для этого, в моем понимании, и полезны такие истории), мы прокачиваем нашу внутреннюю "нейросетку", проживая ситуации во внутреннем симуляторе, и это позволяет в будущем поступить правильнее. Чего я вам и желаю )
Действующие лица: снова тот же чел, техдир из прошлой истории + тимлид и сеньор разраб из его команды.
Ситуация - канун нового года, это было еще в России - поэтому длинные праздники впереди. Если что-то навернется - никого не будет на работе. Обсуждаются дежурства - быть на подхвате, если что-то сломается - быстро подключиться и разрулить.
Техдир договаривается с тимлидом, что тот с еще одним опытным разрабом, чередуясь, подежурят на январские праздники. Техдир недавно пришел, поэтому он не особо в теме, как это делалось раньше, просто спрашивает как было раньше.
Тимлид совершает неточность, не проговорив до конца условия дежурства (компенсацию), потому что предполагает, что условия будут полностью те же, что и в прошлый раз.
Проходят январские праздники, люди отдежурили, но ничего не сломалось. И когда поднимается вопрос компенсации - это были то ли отгулы, то ли небольшая премия - техдир такой: а ничего же не сломалось, за что?
Я эту историю поставил последней, потому что эта ошибка в менеджменте - самая грубая: жадность и экономия на мелочах - проигрыш по крупному. Абсолютно никакой мотивации, кроме скверного характера, за таким решением стоять не может.
В чем проигрыш? Естественно, люди это запомнили. Тимлид и самый опытный разработчик. И в любой последующей ситуации взаимодействия с этим техдиром - перешли исключительно к транзакционному взаимодействию (я даю что-то тебе только после того, как ты даешь что-то мне) и урезали очень много своей добровольной инициативы, причем незаметно для этого руководителя.
Мораль:
➖личная порядочность имеет большое значение. Ее стоит брать в расчет, когда нанимаешь руководителя. Если человек чмо - для менеджера это вылезет быстрее и повлияет намного сильнее
➖глупо жадничать в мелочах - больше потеряешь по крупному
➖обычно стоит сохранять позитивные традиции. Если было принято поощрять людей за что-то определенным образом ранее - лучше сделать так же, если нет каких-то серьезных оснований сделать по другому
Итого, у нас есть 8 историй:
Плюрализм споткнулся о размер столов
Ну это, конечно, неправда
Ты подрываешь мой авторитет
В Ставрополе за эти деньги...
Как правильно или как лучше?
Удали, пожалуйста, свое сообщение
Вам самим-то не надоело в говне сидеть?
И сегодняшняя, Кидалово обыкновенное
Что из них можно почерпнуть? Думаю, каждый найдет что-то свое. Я думаю примерно следующее:
➖Все ошибаются, на любой позиции, причем достаточно часто. Не всегда "руководству виднее" (довольно популярный стереотип). Отрицать это глупо. Другой вопрос - как часто, насколько критично, как себя в этом случае ведут и учатся ли на своих ошибках
➖Можно учиться на чужих ошибках. Если Вы - человек наблюдательный и анализирующий, то работая на соло позиции и планируя стать менеджером, можно смотреть по сторонам, находить ошибки, и думать, как было бы можно сделать лучше. А еще лучше обсуждать или анализировать вместе с кем-то
➖Часто мы действуем интуитивно, когда ошибаемся. Это значит, что поглощая информацию о разных ситуациях, оптимальных или плохих решениях, впитывая такой опыт (для этого, в моем понимании, и полезны такие истории), мы прокачиваем нашу внутреннюю "нейросетку", проживая ситуации во внутреннем симуляторе, и это позволяет в будущем поступить правильнее. Чего я вам и желаю )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥6❤2
Как увеличить свою удачу?
Для менеджеров в некотором смысле важнее задумываться о карьере, так как их движение на желаемую позицию занимает несколько шагов. Недостаточно просто получать опыт и дождаться, пока ты начнешь считаться сеньором.
У кого-то это особенно актуально для первой менеджерской позиции. Кто-то задумывается - вот я разработчик, как стать тимлидом? Или: я тимлид, как вырасти до engineering manager или CTO?
Успех данного мероприятия складывается из двух частей - личных усилий и удачи.
По всевозможным исследованиям, люди склонны недооценивать удачу (внешние обстоятельства, которые привели к положительным или отрицательным результатам) и склонны приписывать успехи своим личным качествам. У вас есть возможность не быть как все )
Возникает закономерный вопрос: если удача - это внешние обстоятельства, то как на нее можно повлиять?
Представим, что Вы разработчик и хотите занять позицию тимлида. Для упрощения представим, что устроиться с улицы на эту позицию нельзя. Предположим, по личным качествам Вы - достойный кандидат. Вы работаете в какой-то команде разработки. Возьмем шанс, что среди всех команд тимлидов не хватает в 30%.
Базово, это означает, что с вероятностью 30% Вы станете тимлидом, просто продолжая работать в своей компании. В таком упрощенном варианте - с нулевой вероятностью, если Вы оказались не там, где надо, и с 100% если там, где надо.
Так вот, если Вы поработаете в 4 разных компаниях, такой шанс уже вырастает до 76%.
Это значит, что надо никогда не забывать, что если вы что-то делаете, и у Вас не получается - возможно вы просто делаете это не в том месте, и не в то время.
Во всех компаниях, начиная с первой, я предлагал различные вполне разумные улучшения. Только в третьей это кому-то действительно понадобилось, и только в четвертой это реально принесло пользу мне и компании.
Короче, удачу можно увеличить просто чаще перебирая варианты.
Конкретно касательно менеджмента - это в первую очередь смена компании и развитие нетворка. Если Вы - классный, то чем больше людей Вас будет оценивать, тем большая вероятность, что Вы кому-то приглянетесь на желаемой позиции.
Усилить этот эффект можно, если перебирать не случайно, а анализируя. Хорошие руководители чаще нужны, например, в компаниях, которые недавно переросли из одной управленческой структуры в другую (например, из стартапа в средний бизнес. Или из среднего бизнеса в корпорацию), потому что при масштабировании нужно организовывать работу по новому. И гораздо реже они нужны там, где ничего не меняется. Даже в компании, где все отвратительно организовано - у вас будет гораздо больше шансов, чем в той, где все стабильно, все позиции уже заняты и нет текучки.
В одних компаниях любой ответственный достойный кандидат почти автоматически будет приглашен на руководящую позицию. В других - сидят люди, которые бы хотели, но им не предоставляется шанса. Всем будет лучше, если подружить эти две потребности )
Для менеджеров в некотором смысле важнее задумываться о карьере, так как их движение на желаемую позицию занимает несколько шагов. Недостаточно просто получать опыт и дождаться, пока ты начнешь считаться сеньором.
У кого-то это особенно актуально для первой менеджерской позиции. Кто-то задумывается - вот я разработчик, как стать тимлидом? Или: я тимлид, как вырасти до engineering manager или CTO?
Успех данного мероприятия складывается из двух частей - личных усилий и удачи.
По всевозможным исследованиям, люди склонны недооценивать удачу (внешние обстоятельства, которые привели к положительным или отрицательным результатам) и склонны приписывать успехи своим личным качествам. У вас есть возможность не быть как все )
Возникает закономерный вопрос: если удача - это внешние обстоятельства, то как на нее можно повлиять?
Представим, что Вы разработчик и хотите занять позицию тимлида. Для упрощения представим, что устроиться с улицы на эту позицию нельзя. Предположим, по личным качествам Вы - достойный кандидат. Вы работаете в какой-то команде разработки. Возьмем шанс, что среди всех команд тимлидов не хватает в 30%.
Базово, это означает, что с вероятностью 30% Вы станете тимлидом, просто продолжая работать в своей компании. В таком упрощенном варианте - с нулевой вероятностью, если Вы оказались не там, где надо, и с 100% если там, где надо.
Так вот, если Вы поработаете в 4 разных компаниях, такой шанс уже вырастает до 76%.
Это значит, что надо никогда не забывать, что если вы что-то делаете, и у Вас не получается - возможно вы просто делаете это не в том месте, и не в то время.
Во всех компаниях, начиная с первой, я предлагал различные вполне разумные улучшения. Только в третьей это кому-то действительно понадобилось, и только в четвертой это реально принесло пользу мне и компании.
Короче, удачу можно увеличить просто чаще перебирая варианты.
Конкретно касательно менеджмента - это в первую очередь смена компании и развитие нетворка. Если Вы - классный, то чем больше людей Вас будет оценивать, тем большая вероятность, что Вы кому-то приглянетесь на желаемой позиции.
Усилить этот эффект можно, если перебирать не случайно, а анализируя. Хорошие руководители чаще нужны, например, в компаниях, которые недавно переросли из одной управленческой структуры в другую (например, из стартапа в средний бизнес. Или из среднего бизнеса в корпорацию), потому что при масштабировании нужно организовывать работу по новому. И гораздо реже они нужны там, где ничего не меняется. Даже в компании, где все отвратительно организовано - у вас будет гораздо больше шансов, чем в той, где все стабильно, все позиции уже заняты и нет текучки.
В одних компаниях любой ответственный достойный кандидат почти автоматически будет приглашен на руководящую позицию. В других - сидят люди, которые бы хотели, но им не предоставляется шанса. Всем будет лучше, если подружить эти две потребности )
👍10🔥5
Личные интересы vs. интересы компании
Мне однажды (а может такое было и пару раз) попался рабочий документ, где фигурировал тезис типа "если личные интересы противоречат интересам компании, то". Ну и, конечно, то нужно действовать в интересах компании и/или сообщить менеджеру об этом ) Что-то в этом духе.
Это показывает всю сюрреалистичность образа мыслей некоторых корпоративных служащих.
Нет никаких интересов, кроме личных интересов разных людей. Ну и уж конечно, никто не предпочитает чужие интересы своим. В силу лицемерия или отсутствия понимания, как работает этика, люди могут утверждать иное.
Но тот факт, что все действуют в своих интересах, осознаваемых или нет, не отменяет того, что люди могут что-то совершать для общего дела, помощи другим или развития чужого бизнеса. Это происходит, когда люди считают, что это в их интересах.
Исходя из этого есть несколько основных стратегий, которые используются в разных компаниях, в какой-то пропорции:
1️⃣ Обращение в фанатиков/болельщиков/сектантов - убеждать сотрудников, что в их интересах действовать в чужих интересах. Работает примерно как гос. пропаганда - надо слушаться, быть благодарным, преследовать шкурные интересы стыдно, пиетет к символике и т.д.
2️⃣ Контроль и надзор - создание системы, в которой становится слишком невыгодно и/или неприятно не делать то, что от тебя требуют. Сюда входит сдельная работа, KPI, регулярные отчеты о сделанной/планируемой работе.
3️⃣ Обмен - скрытый или открытый, "ты-мне, я-тебе".
Тут важно уточнить - речь не идет о обмене типа "ты работаешь, тебе платят". В разработке (как и во многих других вещах) этого не достаточно. Всегда есть десятки ситуаций, когда человек принимает решения наедине с самим собой, основываясь на своем отношении к делу - закрыть ли глаза на проблему, сделать как попросили или как правильно, постараться или просто тянуть лямку.
В зависимости от настроя, разница в производительности и приносимой пользе может легко составлять несколько раз. При этом объективное измерение разработки - задача не имеющая на сегодняшний день эффективного решения. Поэтому о таких вещах и думают.
Следующим постом раскрою тему чуть глубже, добавлю примеров и расскажу о своем подходе к этому.
Мне однажды (а может такое было и пару раз) попался рабочий документ, где фигурировал тезис типа "если личные интересы противоречат интересам компании, то". Ну и, конечно, то нужно действовать в интересах компании и/или сообщить менеджеру об этом ) Что-то в этом духе.
Это показывает всю сюрреалистичность образа мыслей некоторых корпоративных служащих.
Нет никаких интересов, кроме личных интересов разных людей. Ну и уж конечно, никто не предпочитает чужие интересы своим. В силу лицемерия или отсутствия понимания, как работает этика, люди могут утверждать иное.
Но тот факт, что все действуют в своих интересах, осознаваемых или нет, не отменяет того, что люди могут что-то совершать для общего дела, помощи другим или развития чужого бизнеса. Это происходит, когда люди считают, что это в их интересах.
Исходя из этого есть несколько основных стратегий, которые используются в разных компаниях, в какой-то пропорции:
Тут важно уточнить - речь не идет о обмене типа "ты работаешь, тебе платят". В разработке (как и во многих других вещах) этого не достаточно. Всегда есть десятки ситуаций, когда человек принимает решения наедине с самим собой, основываясь на своем отношении к делу - закрыть ли глаза на проблему, сделать как попросили или как правильно, постараться или просто тянуть лямку.
В зависимости от настроя, разница в производительности и приносимой пользе может легко составлять несколько раз. При этом объективное измерение разработки - задача не имеющая на сегодняшний день эффективного решения. Поэтому о таких вещах и думают.
Следующим постом раскрою тему чуть глубже, добавлю примеров и расскажу о своем подходе к этому.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥6
Предположение о чужой тупости
Я еще давно подметил одну очень любопытную штуку, которая меня вообще очень поразила, когда я ее обнаружил.
Есть два типа людей (нормальные и те, которые делят людей на два типа):
1. Одни, когда что-то идет не так, как бы предполагают в другом тупость по умолчанию
2. Другие исходят из презумпции разума, что другой человек наверно подумал, когда что-то делал, пока не доказано иного
Наверно звучит не очень понятно, поэтому объясню на метафорическом примере:
Человек видит, как другой вышел из туалета с мокрыми штанами.
Первый вариант - он скажет (неиронично): "даю фидбек: когда идешь в туалет, надо снимать штаны"
Второй вариант - он задаст вопрос: "что случилось?", предполагая множество вариантов, например, что это вода и не было полотенца и т.п.
То есть в целом, первый вариант - это по умолчанию предположение в действиях других (но не в своих) худшего возможного сценария, который предполагает, что мозг не включался при выполнении задачи, причем неиронично, без цели задеть и вообще без каких-то задних мыслей.
Я сталкивался с такой логикой очень много раз, и, если честно, у меня нет нормального объяснения, почему у некоторых таким образом работает мышление. Первые разы мне это казалось нелепым и оскорбительным, потом я понял - это просто какая-то психологическая особенность. Ни в каких источниках ранее мне не попадалось описание этого явления.
Тем не менее, в целом это достаточно деструктивное поведение и оно мешает работать/создает неприятную атмосферу.
Самый лучший, проверенный способ действовать, если вы видите что-то, похожее на неправильно/плохо сделанную работу - это не делать никаких предвзятых умозаключений, а просто задать вопрос: почему так получилось/почему так было сделано, и потом выяснить все обстоятельства.
Рабочие примеры:
1. Видишь, задача несколько дней лежит в ревью
➖(плохо) нужно обращать внимание на задачи и не забывать делать ревью
➖(нормально) я смотрю задача на ревью застряла, почему так?
2. Видишь задачу закрыли какую-то непонятно почему
➖(плохо) почему задачу не сделали и закрыли?
➖(нормально) тут есть задача закрытая непонятно почему, а что там было?
Окей, даже если вы знаете что другой принял неверное решение - все равно лучшим решением может быть расспросить его, вместо того, чтобы начинать с негативных заключений. Лишь если человек по мере обсуждения в упор продолжает не видеть проблему в своих действиях - тогда ему уже стоит прямо на нее указать.
Может показаться мелочь, но из таких нюансов коммуникаций формируется (или не формируется) здоровая комфортная атмосфера работы в команде.
P.S. после написания, решил проверить как прокомментирует наблюдение grok: https://grok.com/share/c2hhcmQtMg_7a9a6754-681d-4dfb-a3d0-b9e873a7b096
Я еще давно подметил одну очень любопытную штуку, которая меня вообще очень поразила, когда я ее обнаружил.
Есть два типа людей (нормальные и те, которые делят людей на два типа):
1. Одни, когда что-то идет не так, как бы предполагают в другом тупость по умолчанию
2. Другие исходят из презумпции разума, что другой человек наверно подумал, когда что-то делал, пока не доказано иного
Наверно звучит не очень понятно, поэтому объясню на метафорическом примере:
Человек видит, как другой вышел из туалета с мокрыми штанами.
Первый вариант - он скажет (неиронично): "даю фидбек: когда идешь в туалет, надо снимать штаны"
Второй вариант - он задаст вопрос: "что случилось?", предполагая множество вариантов, например, что это вода и не было полотенца и т.п.
То есть в целом, первый вариант - это по умолчанию предположение в действиях других (но не в своих) худшего возможного сценария, который предполагает, что мозг не включался при выполнении задачи, причем неиронично, без цели задеть и вообще без каких-то задних мыслей.
Я сталкивался с такой логикой очень много раз, и, если честно, у меня нет нормального объяснения, почему у некоторых таким образом работает мышление. Первые разы мне это казалось нелепым и оскорбительным, потом я понял - это просто какая-то психологическая особенность. Ни в каких источниках ранее мне не попадалось описание этого явления.
Тем не менее, в целом это достаточно деструктивное поведение и оно мешает работать/создает неприятную атмосферу.
Самый лучший, проверенный способ действовать, если вы видите что-то, похожее на неправильно/плохо сделанную работу - это не делать никаких предвзятых умозаключений, а просто задать вопрос: почему так получилось/почему так было сделано, и потом выяснить все обстоятельства.
Рабочие примеры:
1. Видишь, задача несколько дней лежит в ревью
➖(плохо) нужно обращать внимание на задачи и не забывать делать ревью
➖(нормально) я смотрю задача на ревью застряла, почему так?
2. Видишь задачу закрыли какую-то непонятно почему
➖(плохо) почему задачу не сделали и закрыли?
➖(нормально) тут есть задача закрытая непонятно почему, а что там было?
Окей, даже если вы знаете что другой принял неверное решение - все равно лучшим решением может быть расспросить его, вместо того, чтобы начинать с негативных заключений. Лишь если человек по мере обсуждения в упор продолжает не видеть проблему в своих действиях - тогда ему уже стоит прямо на нее указать.
Может показаться мелочь, но из таких нюансов коммуникаций формируется (или не формируется) здоровая комфортная атмосфера работы в команде.
P.S. после написания, решил проверить как прокомментирует наблюдение grok: https://grok.com/share/c2hhcmQtMg_7a9a6754-681d-4dfb-a3d0-b9e873a7b096
Grok
Презумпция глупости vs разумности | Shared Grok Conversation
а ты можешь пояснить или дать ссылку на пояснение что это такое и почему так происходит? "Я еще давн
👍14🔥5❤3
Новогоднее настроение
Атмосфера под конец года на работе часто немного другая. Декабрь в B2B SaaS - обычно более расслабленный, потому что основной объем переговоров по сделкам активно идет в октябре-ноябре, а под конец года, особенно ближе к рождеству - это скорее время B2C ажиотажа.
И это хорошо. Можно привести дела в порядок, люди могут морально перезагрузиться от смены обстановки на некоторый период. А с другой стороны - какое-то особенное настроение тоже можно использовать с пользой, совместив ее с удовольствием.
Короче, захотелось поделиться, что в этом году придумали у нас.
1️⃣ Внутри команды в последних числах декабря проводим внутреннюю конфу по применению AI в разработке. Это уже вторая такая, прошлая была летом, прошла классно, к сожалению не могу поделиться записью, так как это внутренняя между группой компаний тусовка была. Было 4 спикера - сеньор разработчик, архитектор, head of dev и vp of engineering, каждый рассказал что-то со своей перспективы. Было много интересных хайлайтов, например, что кодинг с AI больше похож на работу тимлида, чем на программирование.
2️⃣ Решили попробовать устроить внутренний хакатон, тоже с прицелом на AI тулы. Даже с кое-какими призами для большего фана ) Не знаю что из этого получится, но сидеть вместе с head of product и marketing lead и придумывать как всё должно быть организовано было местами довольно весело
3️⃣ Ну и третье, мб не такое веселое, но тоже важное - я решил забрать на себя и переделать систему performance ревью, который будет в начале следующего года. Те, в которых я участвовал, не удовлетворяли моему чувству вкуса, и даже местами просто соображениям рациональности ) поэтому захотелось переделать, а не просто оставить это дело HR'ам. Были давно в голове мысли, как это должно быть сделано по организации и содержимому, частично на основании анализа ошибок, частично на основании нетворкинга и понимания, как это сделано в некоторых других местах, что людям нравится, а что нет. Наверно, размышления о перформанс ревью стоят отдельного поста.
Знаю, что в разных компаниях есть какие-то специальные активности за рамками ежедневной работы, кто-то устраивает code freeze, кто-то - неделю креатива и инициатив от разработки, может быть и у вас есть что-то особенное? )
Атмосфера под конец года на работе часто немного другая. Декабрь в B2B SaaS - обычно более расслабленный, потому что основной объем переговоров по сделкам активно идет в октябре-ноябре, а под конец года, особенно ближе к рождеству - это скорее время B2C ажиотажа.
И это хорошо. Можно привести дела в порядок, люди могут морально перезагрузиться от смены обстановки на некоторый период. А с другой стороны - какое-то особенное настроение тоже можно использовать с пользой, совместив ее с удовольствием.
Короче, захотелось поделиться, что в этом году придумали у нас.
Знаю, что в разных компаниях есть какие-то специальные активности за рамками ежедневной работы, кто-то устраивает code freeze, кто-то - неделю креатива и инициатив от разработки, может быть и у вас есть что-то особенное? )
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤1🎉1
Решение хуже проблемы
Иногда (или часто) решение - хуже, чем проблема.
Очень часто сложные и неудобные в эксплуатации организационные системы возникают по следующему правилу - решается каждая возникающая проблема.
Именно так и получается чудовище Франкенштейна, где все обмазано дополнительными выматывающими механизмами и предохранителями, такими как ежедневные планерки, еженедельные или двухнедельные планирования, ретроспективы, бесконечные отчеты и "встречи по синхронизации", куда утекает львиная доля производственных мощностей. В итоге часто и на работу времени и/или желания особо не остается.
Каждое решение, исправляющее какую-то проблему (например, забытую на несколько дней в ревью задачу) - идет со своей ценой. Цена решения может быть выше цены решаемой проблемы. Цена решения опускается под соусом "ну надо же что-то делать с этим".
Тут надо понимать, что с точки зрения менеджера - это страшно, не решать какую-то возникшую проблему. Решение - это способ защиты (в том числе психологической) от вопросов "а что мы с этим делаем"? Страшно ответить "ничего". Так что тут может потребоваться некоторый уровень смелости или пофигизма.
Вот примерная логика, которой я следую, встречая проблему, фидбек, критику и проч.:
1️⃣ Объективно ли существует описанная проблема, или автору это только кажется?
(Если да, то)
2️⃣ Эта проблема имеет системный характер (не является частным случаем)?
(Если да, то)
3️⃣ Есть ли у нее решение, доступное с текущими возможностями?
(Если да, то)
4️⃣ Если взвесить на весах все издержки от этого решения - с одной стороны, и пользу от устранения проблемы - с другой, перевесит ли польза?
(Если да, то) - делаем.
Если ответ "нет" на любой из пунктов - не делаем.
Если ответ "не знаю" - не делаем, но можно потратить дополнительное время на анализ/наблюдение, которые позволят углубить понимание проблемы (есть ли она и какой имеет характер, цену).
Поэтому есть один из принципов, которого я придерживаюсь (и рекомендую) - организация работы должна быть настолько простой, что возникающие издержки от этой простоты не перевешивают стоимости дальнейшего усложнения. И эта сложность должна соответствовать уровню требований от системы.
Всегда можно сделать что-то лучше и сложнее. Почти всегда что-то одновременно станет хуже. Почти всегда переоценивают первое и недооценивают второе.
Иногда (или часто) решение - хуже, чем проблема.
Очень часто сложные и неудобные в эксплуатации организационные системы возникают по следующему правилу - решается каждая возникающая проблема.
Именно так и получается чудовище Франкенштейна, где все обмазано дополнительными выматывающими механизмами и предохранителями, такими как ежедневные планерки, еженедельные или двухнедельные планирования, ретроспективы, бесконечные отчеты и "встречи по синхронизации", куда утекает львиная доля производственных мощностей. В итоге часто и на работу времени и/или желания особо не остается.
Каждое решение, исправляющее какую-то проблему (например, забытую на несколько дней в ревью задачу) - идет со своей ценой. Цена решения может быть выше цены решаемой проблемы. Цена решения опускается под соусом "ну надо же что-то делать с этим".
Тут надо понимать, что с точки зрения менеджера - это страшно, не решать какую-то возникшую проблему. Решение - это способ защиты (в том числе психологической) от вопросов "а что мы с этим делаем"? Страшно ответить "ничего". Так что тут может потребоваться некоторый уровень смелости или пофигизма.
Вот примерная логика, которой я следую, встречая проблему, фидбек, критику и проч.:
(Если да, то)
(Если да, то)
(Если да, то)
(Если да, то) - делаем.
Если ответ "нет" на любой из пунктов - не делаем.
Если ответ "не знаю" - не делаем, но можно потратить дополнительное время на анализ/наблюдение, которые позволят углубить понимание проблемы (есть ли она и какой имеет характер, цену).
Поэтому есть один из принципов, которого я придерживаюсь (и рекомендую) - организация работы должна быть настолько простой, что возникающие издержки от этой простоты не перевешивают стоимости дальнейшего усложнения. И эта сложность должна соответствовать уровню требований от системы.
Всегда можно сделать что-то лучше и сложнее. Почти всегда что-то одновременно станет хуже. Почти всегда переоценивают первое и недооценивают второе.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤1
Решать задачи как менеджер, а не разработчик
Однажды, это было 4-5 лет назад, коллега рассказал мне историю, что в компании, где он когда-то работал, назначали фронтэндера тимлидом команды бэкендеров и наоборот - бэкендера лидом команды фронтов. На первый взгляд звучит как забавная байка, но это хорошо демонстрирует один принцип: решать задачи как менеджер - это совсем не то, а зачастую - ровно противоположное тому, как нужно решать задачи в роли разработчика. Если ты не можешь сделать сам - ты вынужден опираться на других и на командную работу.
Помню, когда сам только перешел на позицию delivery manager, и ко мне подходили с вопросами типа посмотреть какую-то статистику по клиентам, первым желанием было всегда - написать за 5 минут запрос в БД и скопировать отчет коллеге. В каждой отдельной ситуации быстрее сделать самому, а не формулировать задачу другому, или тем более выстраивать какую-то систему постановки и приемки задач.
Так обычно и формируется типовая ситуация - перегруженный тимлид, который занимается всем, даже при том, что команде может не хватать задач (потому что обеспечить задачи - тоже на тимлиде). Потом человек доходит до ситуации, когда он просто не может перестать. Причем в этот момент уже никому не лучше от того, что человек взял на себя слишком много - ни компании (не выстроена работа команды), ни человеку (он зашивается и утомляется), ни команде (медленное развитие, часто твоя работа блокируется недоступным тимлидом). Я несколько раз решал подобную проблему перегрузки для людей, которые не могли из нее выбраться сами. Делается это примерно так, сначала выполняется упражнение:
1. Надо составить список всего, что ты делаешь (типы работы) - консультации, фикс багов, релизы, код ревью, декомпозиция задач, 1-1 и т.п.
2. В этом списке выбрать всё, что ты можешь делать не сам.
3. Перестать это делать. Принципиально. Даже если очень хочется. Даже если кажется, что результат будет намного хуже.
4. Прикинуть, кому это можно отдать и распределить по команде.
После выполнения этого упражнения, вероятно, понадобится еще 1-2 итерации, пока оно не будет по настоящему выполнено - как правило люди с первого раза просто психологически не способны его сделать, так как не могут отпустить какие-то вещи из-за гиперответственности, тревожности, и/или перфекционизма. В силу этих причин кажется, что почти ничего нельзя доверить другим.
Лишь если получится добиться того, что действительно это начало ощущаться как "всё сделано, нечего делать" - тогда можно забирать какие-то функции обратно в поисках правильного баланса, но уже с другой стороны. Но это будет уже делать проще, потому что при наличии пространства для маневра есть время нормально подумать и организовать работу.
Любая организация работы - это долгосрочная инвестиция. Чтобы ее совершить, надо накопить свободное время. Чтобы было свободное время - надо не быть перегруженным операционной, текущей работой. Если менеджер перегружен - всегда будет страдать общий результат.
Однажды, это было 4-5 лет назад, коллега рассказал мне историю, что в компании, где он когда-то работал, назначали фронтэндера тимлидом команды бэкендеров и наоборот - бэкендера лидом команды фронтов. На первый взгляд звучит как забавная байка, но это хорошо демонстрирует один принцип: решать задачи как менеджер - это совсем не то, а зачастую - ровно противоположное тому, как нужно решать задачи в роли разработчика. Если ты не можешь сделать сам - ты вынужден опираться на других и на командную работу.
Помню, когда сам только перешел на позицию delivery manager, и ко мне подходили с вопросами типа посмотреть какую-то статистику по клиентам, первым желанием было всегда - написать за 5 минут запрос в БД и скопировать отчет коллеге. В каждой отдельной ситуации быстрее сделать самому, а не формулировать задачу другому, или тем более выстраивать какую-то систему постановки и приемки задач.
Так обычно и формируется типовая ситуация - перегруженный тимлид, который занимается всем, даже при том, что команде может не хватать задач (потому что обеспечить задачи - тоже на тимлиде). Потом человек доходит до ситуации, когда он просто не может перестать. Причем в этот момент уже никому не лучше от того, что человек взял на себя слишком много - ни компании (не выстроена работа команды), ни человеку (он зашивается и утомляется), ни команде (медленное развитие, часто твоя работа блокируется недоступным тимлидом). Я несколько раз решал подобную проблему перегрузки для людей, которые не могли из нее выбраться сами. Делается это примерно так, сначала выполняется упражнение:
1. Надо составить список всего, что ты делаешь (типы работы) - консультации, фикс багов, релизы, код ревью, декомпозиция задач, 1-1 и т.п.
2. В этом списке выбрать всё, что ты можешь делать не сам.
3. Перестать это делать. Принципиально. Даже если очень хочется. Даже если кажется, что результат будет намного хуже.
4. Прикинуть, кому это можно отдать и распределить по команде.
После выполнения этого упражнения, вероятно, понадобится еще 1-2 итерации, пока оно не будет по настоящему выполнено - как правило люди с первого раза просто психологически не способны его сделать, так как не могут отпустить какие-то вещи из-за гиперответственности, тревожности, и/или перфекционизма. В силу этих причин кажется, что почти ничего нельзя доверить другим.
Лишь если получится добиться того, что действительно это начало ощущаться как "всё сделано, нечего делать" - тогда можно забирать какие-то функции обратно в поисках правильного баланса, но уже с другой стороны. Но это будет уже делать проще, потому что при наличии пространства для маневра есть время нормально подумать и организовать работу.
Любая организация работы - это долгосрочная инвестиция. Чтобы ее совершить, надо накопить свободное время. Чтобы было свободное время - надо не быть перегруженным операционной, текущей работой. Если менеджер перегружен - всегда будет страдать общий результат.
👍8🔥6🎄2
Вот и наступил новый год, с чем всех поздравляю)🎄
Каналу уже год (он запущен в декабре 2024), каждую неделю здесь выходил пост. 52 недели в году, пока полет нормальный. Продолжаем)
Личные интересы vs. интересы компании ч.2
В продолжение вот этого поста
Люди действительно очень разные в том, чего они хотят от работы, и от своей экономической деятельности вообще. Очень наивно, на мой взгляд, предполагать, что главная цель любого бизнеса - это прибыль, а любого наемного работника - максимизация заработка и минимизация усилий. Это могло бы быть так, если бы не существовало человеческой психологии.
Гордость, самоуважение, желание понравиться другим, безопасность, спокойствие, любопытство, желание выделиться, ощутить себя частью группы, или же наоборот независимым - люди часто будут готовы предпочесть многие вещи увеличению дохода.
Некоторые из этих чувств хорошо эксплуатируются корпоративной пропагандой - люди могут радоваться тому, что ходят строем, надевают одежду с корпоративной символикой и чувствуют себя частью чего-то большого и важного, и порой будут готовы отодвигать в сторону другие свои предпочтения.
Другие механики хорошо ложатся на инструмент "объективных показателей", который создает как будто бы логичные и справедливые объяснения для карьерного роста. И на этот случай есть история с первой моей айтишной работы.
Это был аутсорс со сдельной зарплатой, и там была полностью прозрачная система, любой мог зайти и посмотреть часовую ставку, премии и выработку каждого другого программиста в отделе из 100 человек, а соответственно, узнать зарплату. При этом для увеличения часовой ставки нужно было повышать квалификацию - сдавать внутренние экзамены, получать внешние сертификаты.
И когда твой карьерный рост абсолютно предсказуемый и понятный, ты видишь других людей, которые объективно круче - ты понимаешь, что, с одной стороны - абсолютно логично, что ты зарабатываешь меньше, а с другой - понимаешь, что тебе надо делать, чтобы расти. И это создает ощущение справедливости, понятности и предсказуемости.
Проблема только в одном: если цель - это развитие в профессии и карьерный рост, то тебе не нужно тратить время на сдачу экзаменов, приобретение сертификатов и выполнение критериев, нужных для этой компании - надо просто научиться работать и сменить работу на более высокооплачиваемую. Но так не кажется, пока ты смотришь изнутри системы "сделай вот это - и получишь больше", она становится психологическим якорем. В итоге там было полно людей, которые могли бы легчайшим образом уйти на х2 в другие компании, а вместо этого они старательно выполняли карьерные планы внутри нее. Это вопрос рамки, в которой мыслит человек.
Вне зависимости от того, как вы хотите это использовать, будучи менеджером вам нужно разбираться (или хотя бы пробовать разобраться), что хотят люди. Лично мне никогда не были особо интересны выше описанные манипуляции, ни "вдохновлять людей" на якобы высокие цели, ни заставлять их что-то выполнять, что они не хотят, и стоять с палкой над душой. Если бы я писал "миссию компании", вместо высокопарных тейков там бы было написано: "наша цель - зарабатывать деньги и хорошо проводить время".
Возможно, мне это всё не нравится, потому что у меня это плохо получается - стоять над душой или убеждать людей поверить в то, чего нет. Но так или иначе, мой подход - это выяснить, что нужно руководству компании, выяснить, что нужно членам команды (имеющимся, или потенциальным, если речь про найм), найти пересечения - и организовать работу так, чтобы и те и другие могли получить максимум того, что из этого пересечения получается. Если пересечений нет - проще расстаться, чем переделывать людей.
Таким образом задача для меня сводится к:
1. поиску людей, которым что-то нужно, что они могут получить, принося пользу компании (в лице ее руководителей, которые задают цели и направление, тут тоже никаких абстракций)
2. и далее - организации для них лучших возможных ролей, которые им подходят, и рабочих процессов, в которых они могут раскрыть свои лучшие качества.
Каналу уже год (он запущен в декабре 2024), каждую неделю здесь выходил пост. 52 недели в году, пока полет нормальный. Продолжаем)
Личные интересы vs. интересы компании ч.2
В продолжение вот этого поста
Люди действительно очень разные в том, чего они хотят от работы, и от своей экономической деятельности вообще. Очень наивно, на мой взгляд, предполагать, что главная цель любого бизнеса - это прибыль, а любого наемного работника - максимизация заработка и минимизация усилий. Это могло бы быть так, если бы не существовало человеческой психологии.
Гордость, самоуважение, желание понравиться другим, безопасность, спокойствие, любопытство, желание выделиться, ощутить себя частью группы, или же наоборот независимым - люди часто будут готовы предпочесть многие вещи увеличению дохода.
Некоторые из этих чувств хорошо эксплуатируются корпоративной пропагандой - люди могут радоваться тому, что ходят строем, надевают одежду с корпоративной символикой и чувствуют себя частью чего-то большого и важного, и порой будут готовы отодвигать в сторону другие свои предпочтения.
Другие механики хорошо ложатся на инструмент "объективных показателей", который создает как будто бы логичные и справедливые объяснения для карьерного роста. И на этот случай есть история с первой моей айтишной работы.
Это был аутсорс со сдельной зарплатой, и там была полностью прозрачная система, любой мог зайти и посмотреть часовую ставку, премии и выработку каждого другого программиста в отделе из 100 человек, а соответственно, узнать зарплату. При этом для увеличения часовой ставки нужно было повышать квалификацию - сдавать внутренние экзамены, получать внешние сертификаты.
И когда твой карьерный рост абсолютно предсказуемый и понятный, ты видишь других людей, которые объективно круче - ты понимаешь, что, с одной стороны - абсолютно логично, что ты зарабатываешь меньше, а с другой - понимаешь, что тебе надо делать, чтобы расти. И это создает ощущение справедливости, понятности и предсказуемости.
Проблема только в одном: если цель - это развитие в профессии и карьерный рост, то тебе не нужно тратить время на сдачу экзаменов, приобретение сертификатов и выполнение критериев, нужных для этой компании - надо просто научиться работать и сменить работу на более высокооплачиваемую. Но так не кажется, пока ты смотришь изнутри системы "сделай вот это - и получишь больше", она становится психологическим якорем. В итоге там было полно людей, которые могли бы легчайшим образом уйти на х2 в другие компании, а вместо этого они старательно выполняли карьерные планы внутри нее. Это вопрос рамки, в которой мыслит человек.
Вне зависимости от того, как вы хотите это использовать, будучи менеджером вам нужно разбираться (или хотя бы пробовать разобраться), что хотят люди. Лично мне никогда не были особо интересны выше описанные манипуляции, ни "вдохновлять людей" на якобы высокие цели, ни заставлять их что-то выполнять, что они не хотят, и стоять с палкой над душой. Если бы я писал "миссию компании", вместо высокопарных тейков там бы было написано: "наша цель - зарабатывать деньги и хорошо проводить время".
Возможно, мне это всё не нравится, потому что у меня это плохо получается - стоять над душой или убеждать людей поверить в то, чего нет. Но так или иначе, мой подход - это выяснить, что нужно руководству компании, выяснить, что нужно членам команды (имеющимся, или потенциальным, если речь про найм), найти пересечения - и организовать работу так, чтобы и те и другие могли получить максимум того, что из этого пересечения получается. Если пересечений нет - проще расстаться, чем переделывать людей.
Таким образом задача для меня сводится к:
1. поиску людей, которым что-то нужно, что они могут получить, принося пользу компании (в лице ее руководителей, которые задают цели и направление, тут тоже никаких абстракций)
2. и далее - организации для них лучших возможных ролей, которые им подходят, и рабочих процессов, в которых они могут раскрыть свои лучшие качества.
👍12❤5🎄5
Как попасть на нелюбимую работу?
На днях посмотрел видос, как HR из гугла объясняет, что на самом деле HR хочет услышать на скрининге/собесе, и как правильно соврать. https://youtu.be/T__1QViXUxk
В первую очередь при просмотре у меня возник вопрос - если ты понимаешь, что это все чушь собачья, почему ты продолжаешь это требовать? Это все превращается в какую-то дурацкую игру, где обе стороны становятся заложниками и не получают, да и не хотят получать истинную информацию.
Но потом возникла другая мысль, и она, кажется, поинтереснее. В целом сейчас очень много народу увлечено тем, как сфальсифицировать что-то - определенный опыт, культурные паттерны, «правильные» ответы, которых могут ожидать те, кто работают по «методичке», вот как на этом видосе, и т.п. - лишь бы их взяли на работу. Давайте в качестве умственного эксперимента доведем это до абсурда, чтобы посмотреть на ситуацию с другого угла: если завтра людей будут заставлять прыгать на скакалке, проходить детектор лжи и танцевать перед веб-камерой - нужно ли учиться хорошо это делать, чтобы попасть на такую работу, где это требуют?
То есть, а нужно ли вам попасть на работу, где от вас хотят того, что вы считаете бредом, например? И что с вами будут работать за люди, которые придумали такое собеседование?
Есть довольно существенная корреляция, которую многие замечают в моем окружении - в самых классных компаниях и коллективах обычно самые приятные и чилловые собесы, которые похожи на обычный разговор и по атмосфере, и по содержимому. В моем понимании человек, который с целью найти себе хорошего коллегу будет гонять по академическим вопросам, заставлять писать код на бумажке или на доске - ну как минимум странный. Скорее всего - неприятный.
Понятно, что если у человека стоит цель попасть на ЛЮБУЮ работу, то выбор может быть между прыгать на скакалке или курить бамбук.
Но есть у меня такое подозрение, что ситуация, когда чем больше ты подстраиваешься, тем с меньшей вероятностью ты найдешь хорошую приятную работу с норм людьми - довольно контр-интуитивная. То есть буквально - стараясь больше, повышая эффективность и конверсию, ты можешь оказаться в худшей ситуации. И здесь есть довольно прямая аналогия с психологией отношений, которая думаю будет гораздо более интуитивно понятна - если вы из кожи вон лезете чтобы хоть как-то понравиться, вероятность хороших отношений резко падает.
Есть люди, которым глубоко не нравится их работа. Для кого-то вообще не важно, будет «дружный коллектив» или нет. Будут ли там токсики. Если для тебя любая работа - это страдание, и ты в любом случае тянешь лямку - наверно с этой перспективы не так важно. Если у тебя 3 работы и для тебя это просто взаимодействие с какими-то NPC, а не с настоящими людьми - наверно, тоже, избирательность если и важна, то в другом смысле.
Но довольно многим людям, особенно которые еще не перегорели, вообще-то довольно важно находиться в приятной атмосфере на работе. Им нужны и «интересные задачи», и «дружный коллектив», как бы пошло и заезжено это сегодня ни звучало. Да просто - быть окруженными людьми, которые смотрят на вещи похожим образом. Для многих людей необходимость лицемерить давит на психику и существенно снижает их качество жизни.
Что с этим можно сделать? Думаю, что полезно хотя бы иногда задуматься: есть ли у меня выбор? И если есть, почему бы не попробовать быть собой? Вдруг из этого что-то выйдет? Вдруг я уже крутой и кому-то нужен такой, какой я есть? В качестве гипотезы. Если она подтвердится - конверсия будет в несколько раз ниже, но итоговый результат - намного лучше.
На днях посмотрел видос, как HR из гугла объясняет, что на самом деле HR хочет услышать на скрининге/собесе, и как правильно соврать. https://youtu.be/T__1QViXUxk
В первую очередь при просмотре у меня возник вопрос - если ты понимаешь, что это все чушь собачья, почему ты продолжаешь это требовать? Это все превращается в какую-то дурацкую игру, где обе стороны становятся заложниками и не получают, да и не хотят получать истинную информацию.
Но потом возникла другая мысль, и она, кажется, поинтереснее. В целом сейчас очень много народу увлечено тем, как сфальсифицировать что-то - определенный опыт, культурные паттерны, «правильные» ответы, которых могут ожидать те, кто работают по «методичке», вот как на этом видосе, и т.п. - лишь бы их взяли на работу. Давайте в качестве умственного эксперимента доведем это до абсурда, чтобы посмотреть на ситуацию с другого угла: если завтра людей будут заставлять прыгать на скакалке, проходить детектор лжи и танцевать перед веб-камерой - нужно ли учиться хорошо это делать, чтобы попасть на такую работу, где это требуют?
То есть, а нужно ли вам попасть на работу, где от вас хотят того, что вы считаете бредом, например? И что с вами будут работать за люди, которые придумали такое собеседование?
Есть довольно существенная корреляция, которую многие замечают в моем окружении - в самых классных компаниях и коллективах обычно самые приятные и чилловые собесы, которые похожи на обычный разговор и по атмосфере, и по содержимому. В моем понимании человек, который с целью найти себе хорошего коллегу будет гонять по академическим вопросам, заставлять писать код на бумажке или на доске - ну как минимум странный. Скорее всего - неприятный.
Понятно, что если у человека стоит цель попасть на ЛЮБУЮ работу, то выбор может быть между прыгать на скакалке или курить бамбук.
Но есть у меня такое подозрение, что ситуация, когда чем больше ты подстраиваешься, тем с меньшей вероятностью ты найдешь хорошую приятную работу с норм людьми - довольно контр-интуитивная. То есть буквально - стараясь больше, повышая эффективность и конверсию, ты можешь оказаться в худшей ситуации. И здесь есть довольно прямая аналогия с психологией отношений, которая думаю будет гораздо более интуитивно понятна - если вы из кожи вон лезете чтобы хоть как-то понравиться, вероятность хороших отношений резко падает.
Есть люди, которым глубоко не нравится их работа. Для кого-то вообще не важно, будет «дружный коллектив» или нет. Будут ли там токсики. Если для тебя любая работа - это страдание, и ты в любом случае тянешь лямку - наверно с этой перспективы не так важно. Если у тебя 3 работы и для тебя это просто взаимодействие с какими-то NPC, а не с настоящими людьми - наверно, тоже, избирательность если и важна, то в другом смысле.
Но довольно многим людям, особенно которые еще не перегорели, вообще-то довольно важно находиться в приятной атмосфере на работе. Им нужны и «интересные задачи», и «дружный коллектив», как бы пошло и заезжено это сегодня ни звучало. Да просто - быть окруженными людьми, которые смотрят на вещи похожим образом. Для многих людей необходимость лицемерить давит на психику и существенно снижает их качество жизни.
Что с этим можно сделать? Думаю, что полезно хотя бы иногда задуматься: есть ли у меня выбор? И если есть, почему бы не попробовать быть собой? Вдруг из этого что-то выйдет? Вдруг я уже крутой и кому-то нужен такой, какой я есть? В качестве гипотезы. Если она подтвердится - конверсия будет в несколько раз ниже, но итоговый результат - намного лучше.
YouTube
Ex-Google Recruiter Explains Why "Lying" Gets You Hired
🔥 Get my Job Seekers Toolkit: https://stan.store/farahsharghi/p/get-my-job-seekers-toolkit-now
🔥 Book a 1:1: https://stan.store/farahsharghi/p/book-a-1hour-career-coaching-session-with-me-eq3bs
As an Ex-Google recruiter, I've watched qualified candidates…
🔥 Book a 1:1: https://stan.store/farahsharghi/p/book-a-1hour-career-coaching-session-with-me-eq3bs
As an Ex-Google recruiter, I've watched qualified candidates…
❤🔥9👍7💯3
Взгляд за кулисы - неудачный найм
Решил попробовать еще один формат - поделиться какими-то реальными рабочими документами, которые я составлял. Они могут быть простые и неформальные, или же какие-то более серьезно подготовленные доки топ-менеджмента. У каждого документа - история, которая за ним стоит.
Первый такой док - памятка тимлиду по онбордингу нового члена команды. Ноги у нее выросли из пары неудачных наймов. Дело было во второй половине 2024 года, искали middle/senior frontend на гибрид в Алматы. Я тогда только несколько месяцев работал в команде, процесс был уже отлажен, и воспользовались тем, что уже есть и отработано. Стандартный процесс - нанимающий менеджер предлагает описание вакансии и требуемые фильтры, HR рекрутер ищет и собирает кандидатов, заносит в систему, передает резюме на ревью, делает скрининг, запрашивает рекомендации с предыдущих работ и т.п. Дальше два собеса - поведенческий и технический.
На каждом этапе, соответственно, был какой-то отсев. Ключевым и определяющим элементом системы было успешное прохождение технического собеса, на остальных этапах достаточно было просто не облажаться.
Забегая вперед - было два фейла с наймом на эту позицию. Потом я ее просто закрыл (но это уже другая история).
Первый фейл - взяли чела (мидла), и сразу выяснилось, что он не умеет работать. В принципе это, скорее, даже не в полной мере фейл, потому что быстрый отсев на испыталке это нормальная ситуация, хотя и не особо желательная. Хорошо отработал фронтэндер, который был с ним в команде, через 2 недели работы выдал гигантский список несоответствий по скиллам, которые по резюме и собеседованию у человека как бы есть.
Некоторый дополнительный ресерч дал инфу, что он год назад проходил какие-то базовые курсы на фронтэндера, в общем сделали вывод, что чел накрутил и по факту он джун, который пытается вкатиться, ну и, видимо, наловчился проходить собесы. Лида, который проводил собес, это заставило задуматься о формате.
В общем, запустили процесс увольнения (это стандартная процедура, которая занимает несколько итераций-разговоров с лидом, это не так что просто сразу "пошел нахер", потому что если человек откажется - процедура радикально усложняется), парень упираться не стал, ну и суммарно через месяц где-то его не стало.
Ну, подумали, что надо лучше проверять хард скиллы - хорошо ) Второй фейл был более неприятный. Чел (в отличие от первого, который, может, и неплохой парень) пришел по рефералке от дизайнера, на позицию сеньора, и с хард скиллами у него было всё хорошо. Проблема заключалась в том, что у него не было никакого желания их применять, скорее наоборот - с первых недель начал очень сильно затягивать выполнение задач, потом это усугубилось враньем тимлиду о статусе работы (типа "сейчас-сейчас"), и в итоге перешло просто в отсутствие ответов в мессенджере. Был еще забавный момент, когда лид команды написал ему что-то типа "окей, не нужно заканчивать задачу, давай просто расстанемся" - чел сразу вышел на связь и пришел подписать документы.
Не очень понятно, в чем заключался план. Просто полутать денег за 1-2 месяца работы, пока не уволят? Вряд ли, есть способы эффективнее - например, устроиться на фулл удаленку или несколько.
Меня на самом деле довольно сильно удивляют люди, которые даже не пытаются прикидываться, что нормально работают. То ли это какая-то интеллектуальная ограниченность, то ли психические особенности, я для себя так и не нашел ответ, потому что действуя из рациональных соображений, человек потратит минимальные усилия, чтобы соответствовать признакам нормальной работы.
Из второй ситуации, помимо прочего, я сделал вывод, что такую ситуацию можно было бы отработать быстрее, если сделать простой гайд для лида с чек-листом - на что стоит обратить внимание. В моменте это бывает сложно.
Следующим постом будет сам док и немного пояснений к нему.
Решил попробовать еще один формат - поделиться какими-то реальными рабочими документами, которые я составлял. Они могут быть простые и неформальные, или же какие-то более серьезно подготовленные доки топ-менеджмента. У каждого документа - история, которая за ним стоит.
Первый такой док - памятка тимлиду по онбордингу нового члена команды. Ноги у нее выросли из пары неудачных наймов. Дело было во второй половине 2024 года, искали middle/senior frontend на гибрид в Алматы. Я тогда только несколько месяцев работал в команде, процесс был уже отлажен, и воспользовались тем, что уже есть и отработано. Стандартный процесс - нанимающий менеджер предлагает описание вакансии и требуемые фильтры, HR рекрутер ищет и собирает кандидатов, заносит в систему, передает резюме на ревью, делает скрининг, запрашивает рекомендации с предыдущих работ и т.п. Дальше два собеса - поведенческий и технический.
На каждом этапе, соответственно, был какой-то отсев. Ключевым и определяющим элементом системы было успешное прохождение технического собеса, на остальных этапах достаточно было просто не облажаться.
Забегая вперед - было два фейла с наймом на эту позицию. Потом я ее просто закрыл (но это уже другая история).
Первый фейл - взяли чела (мидла), и сразу выяснилось, что он не умеет работать. В принципе это, скорее, даже не в полной мере фейл, потому что быстрый отсев на испыталке это нормальная ситуация, хотя и не особо желательная. Хорошо отработал фронтэндер, который был с ним в команде, через 2 недели работы выдал гигантский список несоответствий по скиллам, которые по резюме и собеседованию у человека как бы есть.
Некоторый дополнительный ресерч дал инфу, что он год назад проходил какие-то базовые курсы на фронтэндера, в общем сделали вывод, что чел накрутил и по факту он джун, который пытается вкатиться, ну и, видимо, наловчился проходить собесы. Лида, который проводил собес, это заставило задуматься о формате.
В общем, запустили процесс увольнения (это стандартная процедура, которая занимает несколько итераций-разговоров с лидом, это не так что просто сразу "пошел нахер", потому что если человек откажется - процедура радикально усложняется), парень упираться не стал, ну и суммарно через месяц где-то его не стало.
Ну, подумали, что надо лучше проверять хард скиллы - хорошо ) Второй фейл был более неприятный. Чел (в отличие от первого, который, может, и неплохой парень) пришел по рефералке от дизайнера, на позицию сеньора, и с хард скиллами у него было всё хорошо. Проблема заключалась в том, что у него не было никакого желания их применять, скорее наоборот - с первых недель начал очень сильно затягивать выполнение задач, потом это усугубилось враньем тимлиду о статусе работы (типа "сейчас-сейчас"), и в итоге перешло просто в отсутствие ответов в мессенджере. Был еще забавный момент, когда лид команды написал ему что-то типа "окей, не нужно заканчивать задачу, давай просто расстанемся" - чел сразу вышел на связь и пришел подписать документы.
Не очень понятно, в чем заключался план. Просто полутать денег за 1-2 месяца работы, пока не уволят? Вряд ли, есть способы эффективнее - например, устроиться на фулл удаленку или несколько.
Меня на самом деле довольно сильно удивляют люди, которые даже не пытаются прикидываться, что нормально работают. То ли это какая-то интеллектуальная ограниченность, то ли психические особенности, я для себя так и не нашел ответ, потому что действуя из рациональных соображений, человек потратит минимальные усилия, чтобы соответствовать признакам нормальной работы.
Из второй ситуации, помимо прочего, я сделал вывод, что такую ситуацию можно было бы отработать быстрее, если сделать простой гайд для лида с чек-листом - на что стоит обратить внимание. В моменте это бывает сложно.
Следующим постом будет сам док и немного пояснений к нему.
👍7🔥2
Как мы узнаем, что кто-то херово работает? (памятка нанимающему менеджеру про онбординг)
Таким был оригинальный заголовок памятки, которой я поделился с тимлидами. Вот ссылка на итоговый текст на английском, который пошел в базу знаний. Там немного более отполированные формулировки.
А ниже привожу оригинал.
Мы рассматриваем некоторые шаблоны поведения, которые являются красными флагами.
Применительно к онбордингу - это означает, что как только мы видим красные флаги - нужно приложить дополнительные усилия чтобы проанализировать ситуацию подробнее.
1. Время реакции в удаленной коммуникации (естественно, речь про рабочее время).
Норм: отвечает сразу или в течение минут, изредка через полчаса-час
Не норм: несколько раз отвечал с большой задержкой (полчаса, несколько часов)
Не норм №2: всегда отвечает с существенной задержкой (10-20 минут)
2. Посещение офиса в случае гибридного формата работы
Норм: ходит в офис столько дней, сколько договаривались. Проводит там большую часть рабочего дня (типа 7+ часов). В случае отклонений - предварительно спрашивает менеджера
Не норм: не ходит в офис обговоренное количество дней, хотя в договоре гибрид, без каких-либо объяснений или вопросов
Не норм №2: проводит в офисе несколько часов и уходит, без каких-либо объяснений
Короче, любое не обсужденное отклонение от обговоренного формата работы.
3. Регулярность коммитов в гит
Норм: коммиты несколько раз в неделю, в идеале каждый день
Не норм: коммит раз в неделю или тем более отсутствие коммитов в течение недели+
4. Реакция на отсутствие работы
Норм: сообщает, что закончил, интересуется что еще можно сделать
Норм №2: сообщает, что закончил + ищет сам что еще можно сделать (напр. сам выбирает задачу из бэклога)
Не норм: тихо сидит и ничего не делает, ждет, пока к нему сам обратится менеджер
5. Работа со своими задачами на доске (при условии, что информирован, что нужно самостоятельно работать со своими задачами на доске):
Норм: на доске задачи находятся большую часть времени в актуальных статусах, редкие (реже 1 раза в неделю) случаи, когда задача на несколько дней зависла. Актуализирует статусы сразу или каждые 1-2 дня
Не норм: забивает на актуализацию статусов
Не норм №2: ведет свои задачи, но постоянно "забывает", и исправляет только после указания менеджера
6. Работа с блокерами:
Норм: если его задача застряла, прилагает явные усилия, чтобы ее завершить - общается с другими людьми, уведомляет менеджера, задает вопросы, пытается разобраться
Не норм: встретив блокер, бросает задачу либо сразу, либо после 1 неудачной попытки что-то выяснить
Не норм №2%: никогда не возвращается к заблокированным на другой стороне задачам
7. Повторение ошибок:
Норм: сделав ошибку и получив объяснение, в следующий раз учитывает это и не повторяет аналогичную ошибку
Не норм: несколько (2+) раз повторяется ситуация, когда после объяснения снова и снова повторяет одни и те же ошибки
8. Оценка сроков
Норм: иногда ошибается, иногда угадывает, в целом видно что ответственно относится к договоренностям и пытается в них попадать, в случае отклонения - сообщает
Норм №2: берет адекватный запас и почти всегда попадает в оценку
Не норм: большинство раз (50%+) не попадает в свои оценки, никак не эволюционирует в этом со временем
Не норм №2: выйдя за срок - молчит, ничего не сообщает
Не норм №3: выйдя за срок, назначает новый срок, который тоже пропускает
Не норм №4: очевидно, что всегда во много раз (3+) завышает сроки
9. Вопросы:
Норм: задает вопросы, когда сталкивается с трудностями. Вопросы соответствуют уровню компетенции
Не норм: не задает вопросы или задает слишком мало, тратит время на безуспешные попытки разобраться самому
Не норм №2: задает слишком много вопросов (в том числе то, что легко найти самому), или вопросы, не соответствующие уровню компетенции (то что и так должен знать по своему резюме)
10. Первое впечатление
Норм: видно, что старается произвести хорошее впечатление на старте работы
Не норм: сразу забивает болт и даже не пытается как-то себя проявить на старте
(часть не влезла в пост, следующим сообщением)
Таким был оригинальный заголовок памятки, которой я поделился с тимлидами. Вот ссылка на итоговый текст на английском, который пошел в базу знаний. Там немного более отполированные формулировки.
А ниже привожу оригинал.
Мы рассматриваем некоторые шаблоны поведения, которые являются красными флагами.
Применительно к онбордингу - это означает, что как только мы видим красные флаги - нужно приложить дополнительные усилия чтобы проанализировать ситуацию подробнее.
1. Время реакции в удаленной коммуникации (естественно, речь про рабочее время).
Норм: отвечает сразу или в течение минут, изредка через полчаса-час
Не норм: несколько раз отвечал с большой задержкой (полчаса, несколько часов)
Не норм №2: всегда отвечает с существенной задержкой (10-20 минут)
2. Посещение офиса в случае гибридного формата работы
Норм: ходит в офис столько дней, сколько договаривались. Проводит там большую часть рабочего дня (типа 7+ часов). В случае отклонений - предварительно спрашивает менеджера
Не норм: не ходит в офис обговоренное количество дней, хотя в договоре гибрид, без каких-либо объяснений или вопросов
Не норм №2: проводит в офисе несколько часов и уходит, без каких-либо объяснений
Короче, любое не обсужденное отклонение от обговоренного формата работы.
3. Регулярность коммитов в гит
Норм: коммиты несколько раз в неделю, в идеале каждый день
Не норм: коммит раз в неделю или тем более отсутствие коммитов в течение недели+
4. Реакция на отсутствие работы
Норм: сообщает, что закончил, интересуется что еще можно сделать
Норм №2: сообщает, что закончил + ищет сам что еще можно сделать (напр. сам выбирает задачу из бэклога)
Не норм: тихо сидит и ничего не делает, ждет, пока к нему сам обратится менеджер
5. Работа со своими задачами на доске (при условии, что информирован, что нужно самостоятельно работать со своими задачами на доске):
Норм: на доске задачи находятся большую часть времени в актуальных статусах, редкие (реже 1 раза в неделю) случаи, когда задача на несколько дней зависла. Актуализирует статусы сразу или каждые 1-2 дня
Не норм: забивает на актуализацию статусов
Не норм №2: ведет свои задачи, но постоянно "забывает", и исправляет только после указания менеджера
6. Работа с блокерами:
Норм: если его задача застряла, прилагает явные усилия, чтобы ее завершить - общается с другими людьми, уведомляет менеджера, задает вопросы, пытается разобраться
Не норм: встретив блокер, бросает задачу либо сразу, либо после 1 неудачной попытки что-то выяснить
Не норм №2%: никогда не возвращается к заблокированным на другой стороне задачам
7. Повторение ошибок:
Норм: сделав ошибку и получив объяснение, в следующий раз учитывает это и не повторяет аналогичную ошибку
Не норм: несколько (2+) раз повторяется ситуация, когда после объяснения снова и снова повторяет одни и те же ошибки
8. Оценка сроков
Норм: иногда ошибается, иногда угадывает, в целом видно что ответственно относится к договоренностям и пытается в них попадать, в случае отклонения - сообщает
Норм №2: берет адекватный запас и почти всегда попадает в оценку
Не норм: большинство раз (50%+) не попадает в свои оценки, никак не эволюционирует в этом со временем
Не норм №2: выйдя за срок - молчит, ничего не сообщает
Не норм №3: выйдя за срок, назначает новый срок, который тоже пропускает
Не норм №4: очевидно, что всегда во много раз (3+) завышает сроки
9. Вопросы:
Норм: задает вопросы, когда сталкивается с трудностями. Вопросы соответствуют уровню компетенции
Не норм: не задает вопросы или задает слишком мало, тратит время на безуспешные попытки разобраться самому
Не норм №2: задает слишком много вопросов (в том числе то, что легко найти самому), или вопросы, не соответствующие уровню компетенции (то что и так должен знать по своему резюме)
10. Первое впечатление
Норм: видно, что старается произвести хорошее впечатление на старте работы
Не норм: сразу забивает болт и даже не пытается как-то себя проявить на старте
(часть не влезла в пост, следующим сообщением)
👍7🔥5❤2
(продолжение документа)
Как проходит онбординг разраба в общем случае?
Онбординг проходит примерно следующие стандартные этапы (можно использовать как чеклист):
1. Подготовка к работе (до нескольких дней) - получить доступы, развернуть проект, и т.п.
2. Ознакомпление с проектом (1-3 дня) - познакомиться с командой, почитать конфлюенс, посмотреть доску в Jira, посмотреть репозитории и т.п.
3. Выполнение нескольких простых задач, чтобы втянуться в процессы
4. Выполнение задач, соответствующих компетенции - соло, чтобы проверить скиллы
5. Выполнение задач со сроками - чтобы проверить навыки оценки сроков
6. Выполнение задач в команде (напр. на эпике) - чтобы проверить навыки командной работы
7. Получить фидбек от нового сотрудника - на свежий взгляд, что стоило бы улучшить в проекте
На определенном этапе (срок выбирается по ситуации), нужно выбрать время и проанализировать объем сделанной работы за период (например, за 2 недели), соответствует ли он заявленной по резюме компетенции. Повторить 2-3 раза, пока не станет ясно, что всё ок.
P.S. был глюк, что посты местами поменялись ) поправил
Как проходит онбординг разраба в общем случае?
Онбординг проходит примерно следующие стандартные этапы (можно использовать как чеклист):
1. Подготовка к работе (до нескольких дней) - получить доступы, развернуть проект, и т.п.
2. Ознакомпление с проектом (1-3 дня) - познакомиться с командой, почитать конфлюенс, посмотреть доску в Jira, посмотреть репозитории и т.п.
3. Выполнение нескольких простых задач, чтобы втянуться в процессы
4. Выполнение задач, соответствующих компетенции - соло, чтобы проверить скиллы
5. Выполнение задач со сроками - чтобы проверить навыки оценки сроков
6. Выполнение задач в команде (напр. на эпике) - чтобы проверить навыки командной работы
7. Получить фидбек от нового сотрудника - на свежий взгляд, что стоило бы улучшить в проекте
На определенном этапе (срок выбирается по ситуации), нужно выбрать время и проанализировать объем сделанной работы за период (например, за 2 недели), соответствует ли он заявленной по резюме компетенции. Повторить 2-3 раза, пока не станет ясно, что всё ок.
P.S. был глюк, что посты местами поменялись ) поправил
🔥9👍4
Тут довольно интересный эпизод произошел, и я впервые отредактировал свой пост. Событие нетривиальное, считаю такое надо пояснять. Да и это навело на некоторые мысли, которыми тоже хотелось бы поделиться.
Со мной связались и попросили удалить из поста имя челика, который не приходил в офис, врал что работает над задачей и т.п., вторая история из поста. Было довольно логичное объяснение, которое находится в юридической сфере. Я не был в курсе такой особенности.
После еще одной истории документа (которая будет в следующих постах), я собирался поподробнее остановиться на теме, почему я позволяю себе выносить суждения о том, что такое хорошо и что такое плохо, и более того, почему это полезно и почему этим стоит заниматься другим. Ведь есть расхожее мнение, что "не судите" и всё такое.
Еще когда работал разрабом, я задумывался - неужели людям не стремно просто не работать месяцами, или отвратительно вести себя с коллегами, или еще что-то такое делать, что повредит их репутации, даже если вынести за скобки совесть. Тогда еще ходили байки про "черные списки", в которые можно попасть, если будешь создавать проблемы. А ответ был простой )
Нет никаких черных списков. Нет никакой ответственности, что бы человек ни сделал на работе (если никого не зарезал). Да в общем-то и по статье сейчас практически никогда не увольняют, даже если человек просто на работу ходить не будет, но не откажется написать заявление по собственному желанию. Институт репутации фактически законодательно запрещен для частных лиц, он может применяться только для публичных и юридических лиц, публичных высказываний.
В этом есть и плюс - ты можешь начать с чистого листа, если у тебя был плохой период в жизни. Но есть и минус - люди, которые вредят другим - будут продолжать это делать.
Если система поощряет негативное поведение - негативного поведения будет становиться больше. Есть люди, которые буквально считают, что неэтично указывать на то, что кто-то сделал гадость. Это потихоньку подтачивает ветку относительно высокой производительности труда, на которой мы все сидим. Все пока держится на том, что большинство людей ведут себя культурно, не мучают друг друга и более или менее стараются делать то, за что им заплатили.
Мы живем в довольно странном мире, в котором люди все меньше и меньше убеждены, что хорошее поведение должно поощряться, а плохое - принижаться. Причем первого не может существовать без второго, так как если все всех хвалят - стирается граница, что есть хорошо. Это задачка, которую людям еще предстоит решить )
Со мной связались и попросили удалить из поста имя челика, который не приходил в офис, врал что работает над задачей и т.п., вторая история из поста. Было довольно логичное объяснение, которое находится в юридической сфере. Я не был в курсе такой особенности.
После еще одной истории документа (которая будет в следующих постах), я собирался поподробнее остановиться на теме, почему я позволяю себе выносить суждения о том, что такое хорошо и что такое плохо, и более того, почему это полезно и почему этим стоит заниматься другим. Ведь есть расхожее мнение, что "не судите" и всё такое.
Еще когда работал разрабом, я задумывался - неужели людям не стремно просто не работать месяцами, или отвратительно вести себя с коллегами, или еще что-то такое делать, что повредит их репутации, даже если вынести за скобки совесть. Тогда еще ходили байки про "черные списки", в которые можно попасть, если будешь создавать проблемы. А ответ был простой )
Нет никаких черных списков. Нет никакой ответственности, что бы человек ни сделал на работе (если никого не зарезал). Да в общем-то и по статье сейчас практически никогда не увольняют, даже если человек просто на работу ходить не будет, но не откажется написать заявление по собственному желанию. Институт репутации фактически законодательно запрещен для частных лиц, он может применяться только для публичных и юридических лиц, публичных высказываний.
В этом есть и плюс - ты можешь начать с чистого листа, если у тебя был плохой период в жизни. Но есть и минус - люди, которые вредят другим - будут продолжать это делать.
Если система поощряет негативное поведение - негативного поведения будет становиться больше. Есть люди, которые буквально считают, что неэтично указывать на то, что кто-то сделал гадость. Это потихоньку подтачивает ветку относительно высокой производительности труда, на которой мы все сидим. Все пока держится на том, что большинство людей ведут себя культурно, не мучают друг друга и более или менее стараются делать то, за что им заплатили.
Мы живем в довольно странном мире, в котором люди все меньше и меньше убеждены, что хорошее поведение должно поощряться, а плохое - принижаться. Причем первого не может существовать без второго, так как если все всех хвалят - стирается граница, что есть хорошо. Это задачка, которую людям еще предстоит решить )
👍9🔥3❤2🤔2