Фактор сениорности
Недавно я вернулся в найм, активно просматриваю резюме и провожу собеседования. За последние месяцы я выработал для себя один конкретный критерий, которым хочу поделиться, и которым я почти безошибочно отличаю сениора от мидла. Это то как кандидат формулирует опыт в резюме.
Когда человек претендует на сениорную позицию, я ожидаю увидеть в его резюме не просто описание мест работы, ролей и его обязанностей, а совершённые действия с измеримым эффектом.
🔸 Мидл: Проектировал архитектуру приложения
— окей, участвовал. Это описание процесса, но не результата.
🔸 Мидл+: Спроектировал архитектуру приложения
— уже лучше, завершённое действие, но без оценки влияния.
🔸 Сениор: Спроектировал архитектуру, которая выдерживает 4-кратную нагрузку на тех же мощностях, уменьшил кодовую базу на 25% и число серверов на треть. Итого: сэкономил компании ~5 млн рублей в год, а так же уменьшил TTM на 20% (средняя задача теперь делается не 5 дней, а 4).
— это то, что нужно. Видно и техническое решение, и его результат.
То есть сениор — это не тот, кто делал, а тот, кто сделал, и может объяснить зачем, как и что это дало бизнесу. Резюме — это первый фильтр и уже оно должно демонстрировать не активность, а эффективность.
Есть такое мнение, что чем больше умных слов вы напишите в резюме, и лет в разных крупных компаниях припишете — тем выше шансы на рассмотрение. Но вот именно опыт эффективности ваших решений практически невозможно симулировать, как бы того не советовали разные блоггеры, прочитавшие в жизни одну книгу по алгоритмам. Вас скорее всего раскусят, и хорошо если в черный список не добавят.
Когда на собеседовании человек не может ответить, зачем что-то было сделано, почему именно так и какой эффект это дало, — то сразу понятно, что он либо не ведущую роль играл в проекте, либо вообще «причастен по касательной».
Если у вас в опыте есть цифры, метрики, влияние на продукт или бизнес — обязательно указывайте их. Это ваша главная валюта. И иммунитет от сомнений со стороны HR и нанимающих менеджеров.
© Фото из канала «Рекрутинг и жизнь»
Недавно я вернулся в найм, активно просматриваю резюме и провожу собеседования. За последние месяцы я выработал для себя один конкретный критерий, которым хочу поделиться, и которым я почти безошибочно отличаю сениора от мидла. Это то как кандидат формулирует опыт в резюме.
Когда человек претендует на сениорную позицию, я ожидаю увидеть в его резюме не просто описание мест работы, ролей и его обязанностей, а совершённые действия с измеримым эффектом.
🔸 Мидл: Проектировал архитектуру приложения
— окей, участвовал. Это описание процесса, но не результата.
🔸 Мидл+: Спроектировал архитектуру приложения
— уже лучше, завершённое действие, но без оценки влияния.
🔸 Сениор: Спроектировал архитектуру, которая выдерживает 4-кратную нагрузку на тех же мощностях, уменьшил кодовую базу на 25% и число серверов на треть. Итого: сэкономил компании ~5 млн рублей в год, а так же уменьшил TTM на 20% (средняя задача теперь делается не 5 дней, а 4).
— это то, что нужно. Видно и техническое решение, и его результат.
То есть сениор — это не тот, кто делал, а тот, кто сделал, и может объяснить зачем, как и что это дало бизнесу. Резюме — это первый фильтр и уже оно должно демонстрировать не активность, а эффективность.
Есть такое мнение, что чем больше умных слов вы напишите в резюме, и лет в разных крупных компаниях припишете — тем выше шансы на рассмотрение. Но вот именно опыт эффективности ваших решений практически невозможно симулировать, как бы того не советовали разные блоггеры, прочитавшие в жизни одну книгу по алгоритмам. Вас скорее всего раскусят, и хорошо если в черный список не добавят.
Когда на собеседовании человек не может ответить, зачем что-то было сделано, почему именно так и какой эффект это дало, — то сразу понятно, что он либо не ведущую роль играл в проекте, либо вообще «причастен по касательной».
Если у вас в опыте есть цифры, метрики, влияние на продукт или бизнес — обязательно указывайте их. Это ваша главная валюта. И иммунитет от сомнений со стороны HR и нанимающих менеджеров.
© Фото из канала «Рекрутинг и жизнь»
❤22🔥10😁8🤔4💯2
Кто все эти люди?
Middle, Senior, Техлид, Архитектор
Этот пост я решил написать после коммента к прошлому посту:
К сожалению автор комментария после ответа ей в её же стиле решила уйти из канала, поэтому дискуссии не случилось, однако хочется разобраться в чём же разница?
Middle Developer
Работает автономно. Берёт задачу, делает, сдаёт. Пока больше про «как», чем про «зачем». Если не знает «как», то идёт к старшим товарищам. Иногда усложняет решения, но учится на этом. Большая часть сениорных обязанностей предваряется словом «может»
Senior Developer
Пишет надёжно. Думает о последствиях решений. Видит потенциальные проблемы заранее. Отвечает за качество, помогает другим.
То есть это специалист, который с одной стороны понимает свою систему. А с другой при решении задач уже ожидается, что он думает не только про то «как сделать», но и про «зачем», и «какие последствия».
Здесь я вернусь к комменту выше и его части «сеньоры обычно решают задачи, поставленные кем-то выше». На мой взгляд «отвечать за качество» === самому себе или команде ставить задачи на удержание этого качества; инициировать беседы о больших изменениях; и в целом быть владельцем «качества» технической стороны продукта. То есть я не согласен с утверждением что «сениоры решают задачи, поставленные кем-то выше».
Техлид
Управляет технической частью команды. Не обязательно самый скилловый в написании кода, но точно — самый внимательный в связке: код, люди, процессы.
Так же бывает ситуация, когда кодовая часть полностью на сениоре и есть роль «тимлид», где это с одной стороны человек про людей, а с другой про связанность с бизнесом.
Архитектор
Смотрит на систему целиком. Чаще всего выделенная роль отдельная от команды разработки. Отвечает за несколько проектов, и их масштабируемость, стабильность и развитие. Редко пишет код — чаще говорит как нужно делать или почему так нельзя.
Поэтому я считаю что не путаю сениоров и тимлидов/архитекторов.
Эти роли могут совмещаться. В небольшой команде один человек может быть и сениором, и техлидом, и архитектором (увы «и мидлом» тут опции нет). Но по мере роста потребность в разных людях и ролях точно появится — иначе, когда всё держится на одном человеке, то он будет тормозить команду.
💬 Но все же, может я не прав и у вас в компании иначе? Расскажите, кто у вас за что отвечает и как это устроено?
Middle, Senior, Техлид, Архитектор
Этот пост я решил написать после коммента к прошлому посту:
Вы не путаете сеньоров с архитекторами/тим лидами? Сеньоры обычно решают задачи, поставленные кем-то свыше по моему опыту
К сожалению автор комментария после ответа ей в её же стиле решила уйти из канала, поэтому дискуссии не случилось, однако хочется разобраться в чём же разница?
Middle Developer
Работает автономно. Берёт задачу, делает, сдаёт. Пока больше про «как», чем про «зачем». Если не знает «как», то идёт к старшим товарищам. Иногда усложняет решения, но учится на этом. Большая часть сениорных обязанностей предваряется словом «может»
Senior Developer
Пишет надёжно. Думает о последствиях решений. Видит потенциальные проблемы заранее. Отвечает за качество, помогает другим.
То есть это специалист, который с одной стороны понимает свою систему. А с другой при решении задач уже ожидается, что он думает не только про то «как сделать», но и про «зачем», и «какие последствия».
Здесь я вернусь к комменту выше и его части «сеньоры обычно решают задачи, поставленные кем-то выше». На мой взгляд «отвечать за качество» === самому себе или команде ставить задачи на удержание этого качества; инициировать беседы о больших изменениях; и в целом быть владельцем «качества» технической стороны продукта. То есть я не согласен с утверждением что «сениоры решают задачи, поставленные кем-то выше».
Техлид
Управляет технической частью команды. Не обязательно самый скилловый в написании кода, но точно — самый внимательный в связке: код, люди, процессы.
Так же бывает ситуация, когда кодовая часть полностью на сениоре и есть роль «тимлид», где это с одной стороны человек про людей, а с другой про связанность с бизнесом.
Архитектор
Смотрит на систему целиком. Чаще всего выделенная роль отдельная от команды разработки. Отвечает за несколько проектов, и их масштабируемость, стабильность и развитие. Редко пишет код — чаще говорит как нужно делать или почему так нельзя.
Поэтому я считаю что не путаю сениоров и тимлидов/архитекторов.
Эти роли могут совмещаться. В небольшой команде один человек может быть и сениором, и техлидом, и архитектором (увы «и мидлом» тут опции нет). Но по мере роста потребность в разных людях и ролях точно появится — иначе, когда всё держится на одном человеке, то он будет тормозить команду.
💬 Но все же, может я не прав и у вас в компании иначе? Расскажите, кто у вас за что отвечает и как это устроено?
❤16👌2🎉1🐳1
Тренды фронтенда и не только
Вчера во время лекции в ИТМО (фото с неё, кстати) моя студентка напомнила мне, что я ей обещал выступить на их вечерней сходке, где они делятся разным. Пришлось держать обещание, и быстро готовиться. Я спросил что интересно, на что получил ответ: расскажи про тренды во фронтенде (ха-ха, где я и где фронтенд, спрашивается). Но ок, порыл интернет, вспомнил с чем к нам сейчас приходят на FrontendConf, собрал презентацию... и знаете, на встрече было от силы 2 фронтендера. Хорошо потренировал навыки адаптации и импровизации, в общем.
Но, так как я брал не только технические тренды из статей на медиуме и хабре, то упомянул темы выгорания, work-life b и T-Shape. И в итоге 15-ти минутное выступление превратилось в часовой мастер-класс вопросов и ответов про карьеру, выгорание и как вообще расти по карьерной лестнице. Если вам интересно, то могу написать свой опыт, ставьте смайлик ⚡️, чтобы я оценил запрос.
Выкладываю вчерашнюю презентацию первым комментарием (она все же больше про тренды, ну и строго не судите, я готовил её вчера за два часа), а заодно хочу вам сказать что завтра последний день приёма заявок к нам на FrontendConf, успевайте податься.
Вчера во время лекции в ИТМО (фото с неё, кстати) моя студентка напомнила мне, что я ей обещал выступить на их вечерней сходке, где они делятся разным. Пришлось держать обещание, и быстро готовиться. Я спросил что интересно, на что получил ответ: расскажи про тренды во фронтенде (ха-ха, где я и где фронтенд, спрашивается). Но ок, порыл интернет, вспомнил с чем к нам сейчас приходят на FrontendConf, собрал презентацию... и знаете, на встрече было от силы 2 фронтендера. Хорошо потренировал навыки адаптации и импровизации, в общем.
Но, так как я брал не только технические тренды из статей на медиуме и хабре, то упомянул темы выгорания, work-life b и T-Shape. И в итоге 15-ти минутное выступление превратилось в часовой мастер-класс вопросов и ответов про карьеру, выгорание и как вообще расти по карьерной лестнице. Если вам интересно, то могу написать свой опыт, ставьте смайлик ⚡️, чтобы я оценил запрос.
Выкладываю вчерашнюю презентацию первым комментарием (она все же больше про тренды, ну и строго не судите, я готовил её вчера за два часа), а заодно хочу вам сказать что завтра последний день приёма заявок к нам на FrontendConf, успевайте податься.
⚡66❤4❤🔥4🔥4
Ситуационное лидерство
На конференции PeopleSense в понедельник прослушал доклад, где уже по названию «Лидер как коуч» и спикеру (коуч ICF) можно было предсказать контент. Но я решил дать шанс.
Автор доклада попыталась зайти на тему, когда коучингом не получится решить проблему сотрудника? У неё даже был слайд с двумя шляпами — ментора и коуча — как метафора двух ролей руководителя. Я даже почти удивился — неужели адекватная рефлексия на тему когда коучингом проблему не решить? Но, увы, дальше доклад все же скатился в разбор кейсов и коучинговые способы их решения. ШТОШ. Раз уж на конференциях хотя бы вскользь это не упоминается, то расскажу вам базу.
На сцену врывается модель Херси и Бланшард (Situational Leadership). 4 стиля управления в зависимости от уровня знаний и уровня мотивации у сотрудника в решаемой задаче/проблеме: указывающий, наставнический, поддерживающий и делегирующий.
Два года назад я был на тренинге, где мне в буквальном смысле открыли глаза на кейсы, когда первые два уровня этой модели необходимо применять. Я же ведь весь такой руководитель про людей и про доверие к ним. А тут мне явно показали через простой пример, когда приказывать нужно: обучение горным лыжам — и всё встало на места.
▫ . Вы решили научиться горным лыжам, а до этого ими не занимались вообще. Чтобы им научиться вам будет нужен тренер, модель поведения которого будет указывающая. Делай так, так не делай, тут верно, тут не верно.
Вы дали задачу в проекте, в котором у человека нет ни опыта ни знаний. Тут вы объясняете пошагово: «Надо собрать данные, затем сверить с шаблоном. Когда сделаешь — покажи, проверим». Фокус — на контроле и ясных инструкциях.
Такой стиль управления называется указывающий (Directing) — когда у сотрудника низкая компетентность и плавающая мотивация.
▫ . У человека получается уже ехать и не падать на каждом склоне. Теперь важно не сбить настрой. Ты молодец, получается отлично, вот тут ногу только вот так надо.
Человек принес первый результат, он полное г.. не то в общем. Но видно что старался. Вы говорите: «Начало хорошее. Смотри, вот тут можно улучшить. Посмотри этот пример — он поможет». Поддержка сочетается с направлением.
Это наставнический стиль (Coaching) — некоторая компетентность, высокая или никакая мотивация. Я не случайно написал именно противопоставление, на тренинге мы разбирали что именно в этой точке у части людей напрочь отпадает желание заниматься дальше этим делом/задачей.
Смешно что этот стиль называется на английском Coaching, хотя имхо здесь уместнее гибрид коучинга и менторинга.
▫ . Идёт 5-я тренировка, человек уже скатывается без падений и даже умеет кантоваться. Главное не останавливаться. Хвалим и поддерживаем. Уже не учим, и слегка челленджим: а что если попробовать быстрее скатиться? Именно здесь коучинг уместнее всего.
Это поддерживающий стиль (Supporting) — высокая компетентность, переменная мотивация.
▫ . Человек достиг мастерства, сам может тренировать. Теперь его можно пустить в свободное плавание. Вы просто отдаёте задачу: «Цель такая, сроки такие. Остальное на твоё усмотрение. Если нужно — я на связи». Коучинг здесь возможен — но по запросу.
Этот стиль делегирующий (Delegating) — высокая компетентность, высокая мотивация.
Чем больше я руководил, тем чаще прибегал к стилям 3 и 4, абсолютно не думая про 1 и 2. В целом, это рабочая модель управления. Метод «выкинуть в озеро и пусть сам учится плавать». Но если вы ищете подходы к разным людям и хотите их действительно растить, то вам точно стоит всегда держать в голове всю систему ситуационного лидерства.
Я не хотел бы от автора доклада чтобы она рассказывала всё это, но странно что она совсем не упомянула про эту модель. Коучинг — это не серебряная пуля.
Про ситуационное лидерство есть куча статей в интернете (например) и даже тренингов, если захотите попрактиковаться.
This post in English.
На конференции PeopleSense в понедельник прослушал доклад, где уже по названию «Лидер как коуч» и спикеру (коуч ICF) можно было предсказать контент. Но я решил дать шанс.
Автор доклада попыталась зайти на тему, когда коучингом не получится решить проблему сотрудника? У неё даже был слайд с двумя шляпами — ментора и коуча — как метафора двух ролей руководителя. Я даже почти удивился — неужели адекватная рефлексия на тему когда коучингом проблему не решить? Но, увы, дальше доклад все же скатился в разбор кейсов и коучинговые способы их решения. ШТОШ. Раз уж на конференциях хотя бы вскользь это не упоминается, то расскажу вам базу.
На сцену врывается модель Херси и Бланшард (Situational Leadership). 4 стиля управления в зависимости от уровня знаний и уровня мотивации у сотрудника в решаемой задаче/проблеме: указывающий, наставнический, поддерживающий и делегирующий.
Два года назад я был на тренинге, где мне в буквальном смысле открыли глаза на кейсы, когда первые два уровня этой модели необходимо применять. Я же ведь весь такой руководитель про людей и про доверие к ним. А тут мне явно показали через простой пример, когда приказывать нужно: обучение горным лыжам — и всё встало на места.
Вы дали задачу в проекте, в котором у человека нет ни опыта ни знаний. Тут вы объясняете пошагово: «Надо собрать данные, затем сверить с шаблоном. Когда сделаешь — покажи, проверим». Фокус — на контроле и ясных инструкциях.
Такой стиль управления называется указывающий (Directing) — когда у сотрудника низкая компетентность и плавающая мотивация.
Человек принес первый результат, он полное г.. не то в общем. Но видно что старался. Вы говорите: «Начало хорошее. Смотри, вот тут можно улучшить. Посмотри этот пример — он поможет». Поддержка сочетается с направлением.
Это наставнический стиль (Coaching) — некоторая компетентность, высокая или никакая мотивация. Я не случайно написал именно противопоставление, на тренинге мы разбирали что именно в этой точке у части людей напрочь отпадает желание заниматься дальше этим делом/задачей.
Смешно что этот стиль называется на английском Coaching, хотя имхо здесь уместнее гибрид коучинга и менторинга.
Это поддерживающий стиль (Supporting) — высокая компетентность, переменная мотивация.
Этот стиль делегирующий (Delegating) — высокая компетентность, высокая мотивация.
Чем больше я руководил, тем чаще прибегал к стилям 3 и 4, абсолютно не думая про 1 и 2. В целом, это рабочая модель управления. Метод «выкинуть в озеро и пусть сам учится плавать». Но если вы ищете подходы к разным людям и хотите их действительно растить, то вам точно стоит всегда держать в голове всю систему ситуационного лидерства.
Я не хотел бы от автора доклада чтобы она рассказывала всё это, но странно что она совсем не упомянула про эту модель. Коучинг — это не серебряная пуля.
Про ситуационное лидерство есть куча статей в интернете (например) и даже тренингов, если захотите попрактиковаться.
This post in English.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28🔥13❤10👏4
Какое у тебя хобби?
Это один из моих любимых вопросов на финальных собеседованиях. А после того, как в недавнем посте вы поставили мне кучу ⚡️, я был обязан вам рассказать про то как борюсь с выгоранием. И, как показывают исследования, способ про который я расскажу может и вам подойти.
Одним из инструментов, которые помогают мне не сгореть, является хобби. Понятно, что при моей работе и с двумя детьми — заниматься чем-то для души требует определённой самодисциплины. Но забывать то, что по-настоящему любишь, — одна из самых распространённых и опасных ошибок, особенно в периоды повышенной нагрузки: будь то работа, рождение детей или просто жизненные обстоятельства.
Одно из моих хобби — болеть за «Зенит».
Это началось в 1997 году. Я гостил у бабушки, и мы с двоюродным братом решили посмотреть футбол по телевизору. Это был матч Спартак — Зенит. В 90-е Спартак — безоговорочный лидер, народная команда, девять чемпионств за десять лет. А Зенит тогда только вернулся в высшую лигу, был середняком, да и до этого взял всего один чемпионский титул в советское время.
Я собирался болеть за Спартак, но брат меня опередил:
— Я буду болеть за Спартак.
— Тогда я за Зенит! — сказал я на эмоциях.
Так и началась моя любовь к клубу — почти случайно, но навсегда.
За 28 лет я видел разный Зенит:
— яркий, бегущий вперёд Зенит Петржелы,
— эпоху Кержакова и Аршавина,
— победу в Кубке и Суперкубке УЕФА,
— время Халка и Витселя,
— а уж сколько камбеков, валидольных матчей или историй когда по сопернику проезжали катком... ух... 😉
Когда меня спрашивают, почему я переехал в Петербург, я иногда в шутку отвечаю:
— Чтобы ходить на матчи Зенита.
И в этой шутке, как водится, доля правды.
Я часто зову друзей на стадион. Даже моим четырёхлетним детям уже довелось побывать на матчах — дважды.
Футбол и Зенит — это мой способ справляться с хандрой и депрессией. Это то, к чему я возвращаюсь, когда хорошо. И особенно — когда плохо.
Вчера «Зенит» впервые за несколько лет не стал чемпионом.
А сегодня «Зениту» исполняется 100 лет. Я искренне поздравляю клуб с юбилеем. Не важно, что происходит вокруг — болеть за «Зенит» для меня больше, чем просто увлечение. Это часть жизни.
Это хобби можно описать словами из гимна болельщиков:
Мы с тобой, Зенит, мы с тобой всегда.
Ты не будешь один никогда.
А можно фотографией, которую я поставил в начале (это фото из моего архива). Я часто встречаю на матчах людей, которые преданно болеют за Зенит всю свою жизнь. Это их хобби, и может быть именно благодаря ему они дожили до своих лет.
Это один из моих любимых вопросов на финальных собеседованиях. А после того, как в недавнем посте вы поставили мне кучу ⚡️, я был обязан вам рассказать про то как борюсь с выгоранием. И, как показывают исследования, способ про который я расскажу может и вам подойти.
Одним из инструментов, которые помогают мне не сгореть, является хобби. Понятно, что при моей работе и с двумя детьми — заниматься чем-то для души требует определённой самодисциплины. Но забывать то, что по-настоящему любишь, — одна из самых распространённых и опасных ошибок, особенно в периоды повышенной нагрузки: будь то работа, рождение детей или просто жизненные обстоятельства.
Одно из моих хобби — болеть за «Зенит».
Это началось в 1997 году. Я гостил у бабушки, и мы с двоюродным братом решили посмотреть футбол по телевизору. Это был матч Спартак — Зенит. В 90-е Спартак — безоговорочный лидер, народная команда, девять чемпионств за десять лет. А Зенит тогда только вернулся в высшую лигу, был середняком, да и до этого взял всего один чемпионский титул в советское время.
Я собирался болеть за Спартак, но брат меня опередил:
— Я буду болеть за Спартак.
— Тогда я за Зенит! — сказал я на эмоциях.
Так и началась моя любовь к клубу — почти случайно, но навсегда.
За 28 лет я видел разный Зенит:
— яркий, бегущий вперёд Зенит Петржелы,
— эпоху Кержакова и Аршавина,
— победу в Кубке и Суперкубке УЕФА,
— время Халка и Витселя,
— а уж сколько камбеков, валидольных матчей или историй когда по сопернику проезжали катком... ух... 😉
Когда меня спрашивают, почему я переехал в Петербург, я иногда в шутку отвечаю:
— Чтобы ходить на матчи Зенита.
И в этой шутке, как водится, доля правды.
Я часто зову друзей на стадион. Даже моим четырёхлетним детям уже довелось побывать на матчах — дважды.
Футбол и Зенит — это мой способ справляться с хандрой и депрессией. Это то, к чему я возвращаюсь, когда хорошо. И особенно — когда плохо.
Вчера «Зенит» впервые за несколько лет не стал чемпионом.
А сегодня «Зениту» исполняется 100 лет. Я искренне поздравляю клуб с юбилеем. Не важно, что происходит вокруг — болеть за «Зенит» для меня больше, чем просто увлечение. Это часть жизни.
Это хобби можно описать словами из гимна болельщиков:
Мы с тобой, Зенит, мы с тобой всегда.
Ты не будешь один никогда.
А можно фотографией, которую я поставил в начале (это фото из моего архива). Я часто встречаю на матчах людей, которые преданно болеют за Зенит всю свою жизнь. Это их хобби, и может быть именно благодаря ему они дожили до своих лет.
🔥27❤13😢3👏2
Мохов Олег Львович.pdf
415.5 KB
Чёрные полосы — белые полосы
Жизнь — такая штука: иногда ты прыгаешь выше головы. Иногда — даже несколько раз подряд. А потом вдруг останавливаешься и думаешь, может твоё место где-то пониже...
Не будет долгих прелюдий — всё просто: я ищу работу.
Что я хочу?
Наверное, впервые в жизни — не статус, не громкий титул, не строку в резюме про «бигтех» (хотя, признаюсь, в Яндексе мне нравилось). Я хочу понятную работу. Ту, которую можно делать с пониманием зачем.
Что я умею:
— работать руками. Я не забыл фронтенд, хотя свежие фреймворки придётся немного подтянуть.
— руководить технической командой: нанимать, онбордить, ставить цели, достигать их.
— вести проекты как проджект: следить за delivery, трекать задачи, наводить порядок в процессах.
— управлять продуктом, особенно если понимаю его суть. А если не понимаю то сам кастдеваю, ux-ю, достаю аналитику, и потом строю гипотезы. Последние 5 лет я делал продукты в HR, в основном про найм.
Могу делать всё сразу, могу что-то одно. Я легко адаптируюсь и бросаюсь туда где болит.
Я открыт к разным вариантам. И к понижению — тоже. Просто хочу делать дело.
Жизнь — такая штука: иногда ты прыгаешь выше головы. Иногда — даже несколько раз подряд. А потом вдруг останавливаешься и думаешь, может твоё место где-то пониже...
Не будет долгих прелюдий — всё просто: я ищу работу.
Что я хочу?
Наверное, впервые в жизни — не статус, не громкий титул, не строку в резюме про «бигтех» (хотя, признаюсь, в Яндексе мне нравилось). Я хочу понятную работу. Ту, которую можно делать с пониманием зачем.
Что я умею:
— работать руками. Я не забыл фронтенд, хотя свежие фреймворки придётся немного подтянуть.
— руководить технической командой: нанимать, онбордить, ставить цели, достигать их.
— вести проекты как проджект: следить за delivery, трекать задачи, наводить порядок в процессах.
— управлять продуктом, особенно если понимаю его суть. А если не понимаю то сам кастдеваю, ux-ю, достаю аналитику, и потом строю гипотезы. Последние 5 лет я делал продукты в HR, в основном про найм.
Могу делать всё сразу, могу что-то одно. Я легко адаптируюсь и бросаюсь туда где болит.
Я открыт к разным вариантам. И к понижению — тоже. Просто хочу делать дело.
❤42💔15😢7🕊3😱1
3 месяца CPO
Глупо не написать о том, что случилось. В пятницу, когда я ехал из аэропорта на CodeFest, то познакомился с Русланом и, узнав чем он занимается, вдоволь позадавал вопросов почему мне трудно входить в новую компанию.
Руслан ещё тогда сказал, что это стык разных культур, продуктовой и операционной. Он часто приводит вторую к первой, часто видит дикое сопротивление организаций и очень часто это приводит к большим переменам и уходам. Сказал не сдаваться и do my best.
Итак, я пришёл в HR продукты без команды разработки, без структуры, с максимумом неопределённости. На старте мне дали двух продактов, и очень поверхностные цели, в итоге можно было считать что это — высокая автономия, ожидание рывка и понятный вектор: «Сделать».
Что я сделал:
🔹 Запустил процесс работы над MVP приложения для сотрудников — с идеи до первого релиза (но ещё не MVP)
🔹 Придумал концепцию продукта, презентовать не успел
🔹 Нанял команду разработчиков этого продукта, начал выстраивать процессы
🔹 Ввёл OKR-планирование и ежемесячные статусы на топов
🔹 Проинициировал оргдизайн: роли, зоны ответственности, кластеры
🔹 Фасилитировал синки, ретро, отчёты, продуктовые обсуждения
🔹 Сам писал тикеты, документы, помогал другим менеджерам готовиться к планёркам
Работал не в должности — а руками и головой, погружался через кросс-функциональность. Где нужно — подключал процессы. Где не было ничего — создавал.
🛑 В итоге мы с компанией разошлись в ожиданиях от роли CPO. Потому что и де-юре (должность моя называлась ИТ БП), и де-факто компания хотела не того, что обычно делают продакты.
Мой подход — про автономию, быстрый трек, product-first. Ожидания оказались ближе к структуре, отчётности и системному управлению.
Это нормально — иногда вы просто не совпадаете.
Глупо не написать о том, что случилось. В пятницу, когда я ехал из аэропорта на CodeFest, то познакомился с Русланом и, узнав чем он занимается, вдоволь позадавал вопросов почему мне трудно входить в новую компанию.
Руслан ещё тогда сказал, что это стык разных культур, продуктовой и операционной. Он часто приводит вторую к первой, часто видит дикое сопротивление организаций и очень часто это приводит к большим переменам и уходам. Сказал не сдаваться и do my best.
Итак, я пришёл в HR продукты без команды разработки, без структуры, с максимумом неопределённости. На старте мне дали двух продактов, и очень поверхностные цели, в итоге можно было считать что это — высокая автономия, ожидание рывка и понятный вектор: «Сделать».
Что я сделал:
🔹 Запустил процесс работы над MVP приложения для сотрудников — с идеи до первого релиза (но ещё не MVP)
🔹 Придумал концепцию продукта, презентовать не успел
🔹 Нанял команду разработчиков этого продукта, начал выстраивать процессы
🔹 Ввёл OKR-планирование и ежемесячные статусы на топов
🔹 Проинициировал оргдизайн: роли, зоны ответственности, кластеры
🔹 Фасилитировал синки, ретро, отчёты, продуктовые обсуждения
🔹 Сам писал тикеты, документы, помогал другим менеджерам готовиться к планёркам
Работал не в должности — а руками и головой, погружался через кросс-функциональность. Где нужно — подключал процессы. Где не было ничего — создавал.
🛑 В итоге мы с компанией разошлись в ожиданиях от роли CPO. Потому что и де-юре (должность моя называлась ИТ БП), и де-факто компания хотела не того, что обычно делают продакты.
Мой подход — про автономию, быстрый трек, product-first. Ожидания оказались ближе к структуре, отчётности и системному управлению.
Это нормально — иногда вы просто не совпадаете.
Telegram
Руслан Остропольский: ИТ, процессы, люди, конференции Channel
Управленческий менеджмент в ИТ и около🧑💻| Спикер 🗣 | Строю системность и процессы 🧑🚀 | Помогаю компаниям трансформиваться 🚀
@Ostropolsky | Facebook - https://www.facebook.com/rusostropolsky | Youtube - https://www.youtube.com/c/RuslanOstropolsky
@Ostropolsky | Facebook - https://www.facebook.com/rusostropolsky | Youtube - https://www.youtube.com/c/RuslanOstropolsky
1❤16👍6😁4💯2
Матрица RACI — кто за что отвечает?
Одна из самых неприятных ситуаций — когда два человека считают, что отвечают за одно и то же. И каждый делает по-своему, с лучшими намерениями. А на выходе — недопонимание, конфликты и потерянное время.
Один договаривается с маркетингом про анонсы, второй — параллельно готовит свои материалы и злится, что его не позвали. Итог — двойная работа, недовольство с двух сторон и вопрос «а кто вообще должен был решать?»
Такие конфликты редко случаются «в вакууме». Обычно это не про конкретный проект, а про размытые зоны ответственности.
У меня была подобная ситуация, когда с заказчиком мы вообще не могли работать, потому что он влезал параллельно буквально во всё.
Я иду обсуждать с дизайнерами вайрфреймы — параллельно он даёт задачи из следующего квартала. Я обсуждаю с маркетином тексты на лэндосе — параллельно он договаривается с разработкой что эти тексты надо убрать с лэндоса. И так далее.
Кто у нас отвечает за согласование с дизайнерами?
А кто идёт разговаривать с маркетингом?
А кто может финально сказать «да»?
И вот тут помогает матрица RACI.
— Responsible — кто делает
— Accountable — кто несёт ответственность и принимает решение,
— Consulted — с кем надо посоветоваться,
— Informed — кого надо держать в курсе.
Особенно важна буква A. Accountable всегда один.
Матрица не обязана быть в табличке. Она может жить просто в договорённости: «если что — по дизайну решает Аня, по маркетингу — Лёша». Всё. Уже легче жить.
Если вы регулярно не можете понять, кто за что, — сядьте и проговорите роли. Можно без формальностей. Главное — хотя бы определить, кто принимает финальные решения.
RACI работает не только на коммуникацию тет-а-тет, но и на распределение ролей в проекте и их взаимосвязи. Короче, классное упражнение чтобы визуализировать кто за что.
Имхо, когда у вас нормальная здоровая доверительная команда и система это поддерживает, то RACI — это избыточный контроль. Но иногда такое упражнение нужно проделать, чтобы явно зафиксировать зоны ответственности и чтобы каждый понимал свою роль и не влезал в чужую, даже по доброй воле.
Повторю самое важное на мой взгляд. Можно скипнуть буквы RCI, но обязательно нужно договориться кто A, и что он один (на самом деле остальные в этот момент становятся C или I).
И ещё: такие договорённости не вечные. Люди уходят, меняются, вырастают. Поэтому RACI — это не документ. Это привычка раз в какое-то время уточнять роли.
Одна из самых неприятных ситуаций — когда два человека считают, что отвечают за одно и то же. И каждый делает по-своему, с лучшими намерениями. А на выходе — недопонимание, конфликты и потерянное время.
Один договаривается с маркетингом про анонсы, второй — параллельно готовит свои материалы и злится, что его не позвали. Итог — двойная работа, недовольство с двух сторон и вопрос «а кто вообще должен был решать?»
Такие конфликты редко случаются «в вакууме». Обычно это не про конкретный проект, а про размытые зоны ответственности.
У меня была подобная ситуация, когда с заказчиком мы вообще не могли работать, потому что он влезал параллельно буквально во всё.
Я иду обсуждать с дизайнерами вайрфреймы — параллельно он даёт задачи из следующего квартала. Я обсуждаю с маркетином тексты на лэндосе — параллельно он договаривается с разработкой что эти тексты надо убрать с лэндоса. И так далее.
Кто у нас отвечает за согласование с дизайнерами?
А кто идёт разговаривать с маркетингом?
А кто может финально сказать «да»?
И вот тут помогает матрица RACI.
— Responsible — кто делает
— Accountable — кто несёт ответственность и принимает решение,
— Consulted — с кем надо посоветоваться,
— Informed — кого надо держать в курсе.
Особенно важна буква A. Accountable всегда один.
Матрица не обязана быть в табличке. Она может жить просто в договорённости: «если что — по дизайну решает Аня, по маркетингу — Лёша». Всё. Уже легче жить.
Если вы регулярно не можете понять, кто за что, — сядьте и проговорите роли. Можно без формальностей. Главное — хотя бы определить, кто принимает финальные решения.
RACI работает не только на коммуникацию тет-а-тет, но и на распределение ролей в проекте и их взаимосвязи. Короче, классное упражнение чтобы визуализировать кто за что.
Имхо, когда у вас нормальная здоровая доверительная команда и система это поддерживает, то RACI — это избыточный контроль. Но иногда такое упражнение нужно проделать, чтобы явно зафиксировать зоны ответственности и чтобы каждый понимал свою роль и не влезал в чужую, даже по доброй воле.
Повторю самое важное на мой взгляд. Можно скипнуть буквы RCI, но обязательно нужно договориться кто A, и что он один (на самом деле остальные в этот момент становятся C или I).
И ещё: такие договорённости не вечные. Люди уходят, меняются, вырастают. Поэтому RACI — это не документ. Это привычка раз в какое-то время уточнять роли.
❤13👍10🔥3🤔1
PARIS, RASIQ, RAPID и куча других матриц
Когда я готовил пост про RACI, то в статье на википедии обнаружил кучу других фреймворков суть которых примерно та же: расписать матрицу ответственности.
Но у меня созрел вопрос к вам, а вы когда-нибудь в работе пользовались чем-то отличным от RACI? Если да, то расскажите чем, плиз.
Когда я готовил пост про RACI, то в статье на википедии обнаружил кучу других фреймворков суть которых примерно та же: расписать матрицу ответственности.
Но у меня созрел вопрос к вам, а вы когда-нибудь в работе пользовались чем-то отличным от RACI? Если да, то расскажите чем, плиз.
❤4🔥3🐳1💯1
Ресурсы и инструменты для развития тимлида: приоритеты, баланс, «помощь зала» / Наталья Борисенко
Это доклад-рефлексия на тему того как тимлиду развиваться и прокачивать себя.
Наташа начинает с того, что поднимает проблему нехватки денег для поездок на конференции и приводит это в качестве примера причины, по которой она начала выступать. Не универсальный совет, конечно, так как на конференции 1000+ участников, а докладчиков меньше 100, но кому-то зайдет. Я лично по той же причине пошел в ПК.
Далее приводятся 5 инструментов роста руководителя:
— конференции
— люди (эксперты/менторы/менти)
— книги, исследования, статьи
— курсы
— подкасты.
В целом на этом можно сказать всё тема доклада раскрыта 😃, но далее идёт рефлексия на тему как и с чем лучше работать.
Ограниченные ресурсы — это реальность, поэтому любые каналы, курсы и книги стоит фильтровать. Наташа предлагает формулу:
много источников + строгий фильтр = качественные знания.
Наташа даёт совет: если материал не зацепил за 10 минут — лучше не мучиться дальше. Это единственный момент, с которым я категорически не согласен. Лично у меня были случаи, когда «невкусный» на первый взгляд материал оказывался ценным, а книгу, которую я мог мучать месяцами в конце оказывалась бриллиантом. Даже этот доклад я досмотрел только со второй попытки — в первый раз был слишком перегружен, и информация не легла.
Затем Наташа делится личным опытом поиска менторов. Сначала — интересный автор, потом этап «конфетно-букетного периода», когда вы просто читаете его материалы. Если откликается — можно попробовать выйти на контакт. В частности, она рассказывает историю знакомства с Торри Подмажерски и про свой запрос: как найти баланс между ролями IC и Team Lead, как не наломать дров в росте и где искать поддержку.
В докладе также упоминается модель Gain – Grind – Grow:
— Gain — выделение времени на получение знаний
— Grind — практика и применение
— Grow — превращаем навыки в достижения целей (подробнее например здесь)
В конце Наташа немного рассказывает про пользу нетворкинга и проф.сообществ на примере сообщества техписов. А так же делает ремарку на тему того, что все иногда могут перегореть и важно следить не только за интенсивностью работы, но и за своими личными ощущениями.
Неплохой доклад, особенно если вы недавно стали тимлидом и не знаете с чего начать. Я же лично в очередной раз рекомендую книгу Джеймса Стэньера, даже если вы не SEM многое из описанного в ней вам будет полезно.
Все обзоры по тегу #докладобзор@teamleading
Это доклад-рефлексия на тему того как тимлиду развиваться и прокачивать себя.
Наташа начинает с того, что поднимает проблему нехватки денег для поездок на конференции и приводит это в качестве примера причины, по которой она начала выступать. Не универсальный совет, конечно, так как на конференции 1000+ участников, а докладчиков меньше 100, но кому-то зайдет. Я лично по той же причине пошел в ПК.
Далее приводятся 5 инструментов роста руководителя:
— конференции
— люди (эксперты/менторы/менти)
— книги, исследования, статьи
— курсы
— подкасты.
В целом на этом можно сказать всё тема доклада раскрыта 😃, но далее идёт рефлексия на тему как и с чем лучше работать.
Ограниченные ресурсы — это реальность, поэтому любые каналы, курсы и книги стоит фильтровать. Наташа предлагает формулу:
много источников + строгий фильтр = качественные знания.
Наташа даёт совет: если материал не зацепил за 10 минут — лучше не мучиться дальше. Это единственный момент, с которым я категорически не согласен. Лично у меня были случаи, когда «невкусный» на первый взгляд материал оказывался ценным, а книгу, которую я мог мучать месяцами в конце оказывалась бриллиантом. Даже этот доклад я досмотрел только со второй попытки — в первый раз был слишком перегружен, и информация не легла.
Затем Наташа делится личным опытом поиска менторов. Сначала — интересный автор, потом этап «конфетно-букетного периода», когда вы просто читаете его материалы. Если откликается — можно попробовать выйти на контакт. В частности, она рассказывает историю знакомства с Торри Подмажерски и про свой запрос: как найти баланс между ролями IC и Team Lead, как не наломать дров в росте и где искать поддержку.
В докладе также упоминается модель Gain – Grind – Grow:
— Gain — выделение времени на получение знаний
— Grind — практика и применение
— Grow — превращаем навыки в достижения целей (подробнее например здесь)
В конце Наташа немного рассказывает про пользу нетворкинга и проф.сообществ на примере сообщества техписов. А так же делает ремарку на тему того, что все иногда могут перегореть и важно следить не только за интенсивностью работы, но и за своими личными ощущениями.
Неплохой доклад, особенно если вы недавно стали тимлидом и не знаете с чего начать. Я же лично в очередной раз рекомендую книгу Джеймса Стэньера, даже если вы не SEM многое из описанного в ней вам будет полезно.
Все обзоры по тегу #докладобзор@teamleading
YouTube
Ресурсы и инструменты для развития тимлида: приоритеты, баланс, «помощь зала» / Наталья Борисенко
Приглашаем на самую крупную мультиформатную конференцию для тимлидов и руководителей не только из IT — TeamLead Conf 2025, которая пройдет 10 и 11 ноября 2025 в Москве.
Подробнее о конференции: https://clck.ru/3NUaBv
________
Единственная профессиональная…
Подробнее о конференции: https://clck.ru/3NUaBv
________
Единственная профессиональная…
👍7❤5🤔2
Глобальный Undo
Один из самых странно решённых и невероятно долгоживущих сценариев на мобильных устройствах — это Undo, а точнее его отсутствие.
На десктопах всё давно просто и понятно: Ctrl+Z работает почти везде. А на мобилках? Когда только появился iPhone, Стив Джобс придумал, что для отмены действия можно… потрясти телефон. Да-да. Потрясти. Телефон. В ответ появится модалка: «Отменить ввод текста?». Но, как можно догадаться, это (потрясти + подтвердить) не прижилось. В смысле оно работает, но проще переписать. Да и работает только в текстовых полях. На этом всё и закончилось.
На первый взгляд, вроде и проблемы-то нет. Даже исследования говорят, что пользователи редко вспоминают про Undo на мобильных интерфейсах (например, вот статья из ACM Digital Library). Но только до тех пор, пока сам не промажешь пальцем — и не потеряешь точку невозврата.
Продакты, внимание! Дарю вам фичу.
Вы смотрите видео. Концентрируетесь. И тут — случайный тап по экрану: попали пальцем не туда и видео перескочило на 20 минут вперёд. Или свайпнули чуть не так, и всё улетело на начало. Всё — нужный момент потерян. И даже не знаешь, где был до этого. Возвращаться приходится наугад. Иногда — просто бросаешь смотреть. Бесит!
Добавить Undo — это может быть пара строчек. А пользователь сэкономит время, и (что намного важнее) нервы.
Один из главных признаков, когда вам стоит предусмотреть путь назад: если у вас в интерфейсе есть действие, после которого пользователь может сказать «ой».
Один из самых странно решённых и невероятно долгоживущих сценариев на мобильных устройствах — это Undo, а точнее его отсутствие.
На десктопах всё давно просто и понятно: Ctrl+Z работает почти везде. А на мобилках? Когда только появился iPhone, Стив Джобс придумал, что для отмены действия можно… потрясти телефон. Да-да. Потрясти. Телефон. В ответ появится модалка: «Отменить ввод текста?». Но, как можно догадаться, это (потрясти + подтвердить) не прижилось. В смысле оно работает, но проще переписать. Да и работает только в текстовых полях. На этом всё и закончилось.
На первый взгляд, вроде и проблемы-то нет. Даже исследования говорят, что пользователи редко вспоминают про Undo на мобильных интерфейсах (например, вот статья из ACM Digital Library). Но только до тех пор, пока сам не промажешь пальцем — и не потеряешь точку невозврата.
Продакты, внимание! Дарю вам фичу.
Вы смотрите видео. Концентрируетесь. И тут — случайный тап по экрану: попали пальцем не туда и видео перескочило на 20 минут вперёд. Или свайпнули чуть не так, и всё улетело на начало. Всё — нужный момент потерян. И даже не знаешь, где был до этого. Возвращаться приходится наугад. Иногда — просто бросаешь смотреть. Бесит!
Добавить Undo — это может быть пара строчек. А пользователь сэкономит время, и (что намного важнее) нервы.
Один из главных признаков, когда вам стоит предусмотреть путь назад: если у вас в интерфейсе есть действие, после которого пользователь может сказать «ой».
1👍27🔥6❤5
FrontendConf — мы почти готовы. А вы?
В прошлом году я вошел в программный комитет FrontendConf, и когда в ноябре я пришёл на первый созвон ПК, то подумал: «Зачем так рано? Впереди же почти год». А потом кааааак понял...
Осенью прошлого года я был на FrontendConf. Это стало возможно благодаря Никите Дубко (на фото и кстати, у него теперь есть канал, где он делится опытом перехода в продакт-менеджмент). Я просто ходил, смотрел, а потом половину вечера рассказывал одному из членов ПК, что бы я сделал иначе. Так я оказался в программном комитете.
С тех пор — больше полугода еженедельных созвонов. Интервью с претендентами, обсуждения внутри ПК, просмотры чужих интервью. Споры, обсуждения, критика, Глеб Михеев 😃. И вот вчера мы зафиналили спикеров.
Я смотрю и горжусь тем, что у нас получилось. Программа будет живой: актуальная, интересная, в меру хардкорная, в меру софтовая. Мы почти расставили доклады по сетке — и честно признаюсь, мне будет сложно выбрать куда пойти в некоторых слотах.
Да, я понимаю, что FrontendConf стоит недёшево. Но помимо докладов, которые вы сможете послушать вживую, будет море нетворкинга. А ещё останется доступ ко всем записям. Поэтому мой совет вам такой — пройдитесь по программе, отметьте доклады, которые хочется услышать. Если получилось больше десяти — идите к своему руководителю и упрашивайте купить билет.
От себя внесу небольшую лепту для моих читателей, вот вам промик на небольшую скидку в 5% — fc25_teamleading.
И надеюсь увидеться на FrontendConf 2025.
В прошлом году я вошел в программный комитет FrontendConf, и когда в ноябре я пришёл на первый созвон ПК, то подумал: «Зачем так рано? Впереди же почти год». А потом кааааак понял...
Осенью прошлого года я был на FrontendConf. Это стало возможно благодаря Никите Дубко (на фото и кстати, у него теперь есть канал, где он делится опытом перехода в продакт-менеджмент). Я просто ходил, смотрел, а потом половину вечера рассказывал одному из членов ПК, что бы я сделал иначе. Так я оказался в программном комитете.
С тех пор — больше полугода еженедельных созвонов. Интервью с претендентами, обсуждения внутри ПК, просмотры чужих интервью. Споры, обсуждения, критика, Глеб Михеев 😃. И вот вчера мы зафиналили спикеров.
Я смотрю и горжусь тем, что у нас получилось. Программа будет живой: актуальная, интересная, в меру хардкорная, в меру софтовая. Мы почти расставили доклады по сетке — и честно признаюсь, мне будет сложно выбрать куда пойти в некоторых слотах.
Да, я понимаю, что FrontendConf стоит недёшево. Но помимо докладов, которые вы сможете послушать вживую, будет море нетворкинга. А ещё останется доступ ко всем записям. Поэтому мой совет вам такой — пройдитесь по программе, отметьте доклады, которые хочется услышать. Если получилось больше десяти — идите к своему руководителю и упрашивайте купить билет.
От себя внесу небольшую лепту для моих читателей, вот вам промик на небольшую скидку в 5% — fc25_teamleading.
И надеюсь увидеться на FrontendConf 2025.
1🔥12❤6👍6
К сожалению, сейчас мы не готовы пригласить вас на следующий этап.
Это фраза, которая будто создана, чтобы раздражать.
Сегодня будет аж три поста про найм. С недавних пор я снова в поиске работы и хочу поделиться несколькими наблюдениями.
Во-первых, давайте уже перестанем говорить:
Нет, не легко. Это миф.
Я ушёл из Яндекса почти год назад. С тех пор у меня была череда откликов, собеседований и «смотрели, но не выбрали». За это время я понял вот что: если кто-то и находит работу быстро, то это точно не я. И я общаюсь со многими друзьями по несчастью и у них та же ситуация.
Возможно легко находят работу мидлы. На рынке много вакансий, понятные требования, стандартные процессы, вилки ± одинаковые. Там всё довольно прозрачно. Может там «легко»?
Но вот по данным Time / LinkedIn Economic Graph, в 2023 году медиана закрытия вакансий была 44 дня. Не ну это было давно и не у нас, а у нас что? А в России показатели закрытия вакансий тоже растут. А значит мы снова вернулись к тому, что найм — это рынок работодателя.
Сеньорам, руководителям, C-level’ам объективно сложнее искать работу. Таких позиций меньше, ожидания размытые, критерии успеха меняются от компании к компании. Да и чаще тебя ищут, чем ты находишь.
В остальное время ты просто ждёшь, что хотя бы один отклик не закончится шаблоном:
И в ХХ эта аналитика на виду: просмотр в 16:10 — отказ в 16:10. Отказали быстрее минуты, получается
Я не прошу развёрнутый фидбек на полстраницы. Хочется просто одного предложения:
– Где не совпали?
– Что показалось слабым?
– Почему решили не звать?
Чтобы не совсем уехать кукухой я спрашиваю у ChatGPT — что не так? Он не уходит в глухую оборону, не прячется за HR-бренд и может помочь понять, где можно подкрутить. Почему компании не могут сделать так же? Где пресловутая AI-трансформация рекрутмента?
Но, честно, хочется, чтобы и компании чуть взрослее относились к процессу.
«Вы нам подходите, но нам кажется, что вы немного overqualified? Вам ок такое?» Или «Сейчас мы общаемся с другими кандидатами, но если вакансия не закроется в ближайшие пару недель, мы вернёмся к вам. Если вы готовы подождать — дайте знать».
Это уважительно.
Если вы сейчас тоже в поиске — держитесь.
Это тяжёлый, иногда очень выматывающий процесс, особенно если не вписываешься в «типовую» позицию. Но вы не одни.
Если нужно — скидывайте свои резюме, с удовольствием посмотрю и дам обратную связь. Сейчас у меня есть на это время.
Это фраза, которая будто создана, чтобы раздражать.
Сегодня будет аж три поста про найм. С недавних пор я снова в поиске работы и хочу поделиться несколькими наблюдениями.
Во-первых, давайте уже перестанем говорить:
«С твоим опытом ты легко найдёшь работу!»
Нет, не легко. Это миф.
Я ушёл из Яндекса почти год назад. С тех пор у меня была череда откликов, собеседований и «смотрели, но не выбрали». За это время я понял вот что: если кто-то и находит работу быстро, то это точно не я. И я общаюсь со многими друзьями по несчастью и у них та же ситуация.
Возможно легко находят работу мидлы. На рынке много вакансий, понятные требования, стандартные процессы, вилки ± одинаковые. Там всё довольно прозрачно. Может там «легко»?
Но вот по данным Time / LinkedIn Economic Graph, в 2023 году медиана закрытия вакансий была 44 дня. Не ну это было давно и не у нас, а у нас что? А в России показатели закрытия вакансий тоже растут. А значит мы снова вернулись к тому, что найм — это рынок работодателя.
Сеньорам, руководителям, C-level’ам объективно сложнее искать работу. Таких позиций меньше, ожидания размытые, критерии успеха меняются от компании к компании. Да и чаще тебя ищут, чем ты находишь.
В остальное время ты просто ждёшь, что хотя бы один отклик не закончится шаблоном:
«Спасибо за интерес, но мы пока не готовы двигаться дальше…»
И в ХХ эта аналитика на виду: просмотр в 16:10 — отказ в 16:10. Отказали быстрее минуты, получается
Я не прошу развёрнутый фидбек на полстраницы. Хочется просто одного предложения:
– Где не совпали?
– Что показалось слабым?
– Почему решили не звать?
Чтобы не совсем уехать кукухой я спрашиваю у ChatGPT — что не так? Он не уходит в глухую оборону, не прячется за HR-бренд и может помочь понять, где можно подкрутить. Почему компании не могут сделать так же? Где пресловутая AI-трансформация рекрутмента?
Но, честно, хочется, чтобы и компании чуть взрослее относились к процессу.
«Вы нам подходите, но нам кажется, что вы немного overqualified? Вам ок такое?» Или «Сейчас мы общаемся с другими кандидатами, но если вакансия не закроется в ближайшие пару недель, мы вернёмся к вам. Если вы готовы подождать — дайте знать».
Это уважительно.
Если вы сейчас тоже в поиске — держитесь.
Это тяжёлый, иногда очень выматывающий процесс, особенно если не вписываешься в «типовую» позицию. Но вы не одни.
Если нужно — скидывайте свои резюме, с удовольствием посмотрю и дам обратную связь. Сейчас у меня есть на это время.
❤34💔24💯11
Telegram
··• Серёжа печатает
Я тут решил собрать немного годноты для проджектов и продактов.
Когда я начал искать работу спустя 10 лет, оказалось, что все научились делать 10 этапов собеседований и проводить их определённым образом. А значит, к этому надо готовиться.
К счастью, к этому…
Когда я начал искать работу спустя 10 лет, оказалось, что все научились делать 10 этапов собеседований и проводить их определённым образом. А значит, к этому надо готовиться.
К счастью, к этому…
А ещё хочу поделиться полезной рекомендацией для тех, кто сейчас готовится к собеседованиям.
Мой друг (и, по несчастью, коллега по рынку труда) Серёжа собрал отличную борду для подготовки к интервью на позиции проджектов и продактов. Там структурировано, чётко и по делу — без воды, с примерами и разбором типовых вопросов.
Серёжа умеет раскладывать сложное на простое и писать внятно. Поэтому рекомендую не только борду, но и его Telegram-канал — он пишет полезно и без лишнего шума.
https://t.me/seryozha_typing/365
Мой друг (и, по несчастью, коллега по рынку труда) Серёжа собрал отличную борду для подготовки к интервью на позиции проджектов и продактов. Там структурировано, чётко и по делу — без воды, с примерами и разбором типовых вопросов.
Серёжа умеет раскладывать сложное на простое и писать внятно. Поэтому рекомендую не только борду, но и его Telegram-канал — он пишет полезно и без лишнего шума.
https://t.me/seryozha_typing/365
👍15🔥6❤4
И ещё давайте посмотрим на найм с другой стороны.
Сергей Озеранский недавно написал у себя в канале о своём опыте собеседований с инженерами.
Найм давно стал шаблонным. За каждым собеседованием — одно и то же: опросники, задачи. В лучшем случае архитектурная секция. Благодаря благотелям вырос целый слой «хакающих систему» джунов, которые натаскиваются на такие интервью. И сениоров, которые не проходят дальше первой секции, потому что у них нет времени готовиться и зубрить учебники.
При этом то, что предлагает Сергей, требует высокой подготовки. Он пишет о навыке вести живой разговор, быть в моменте, уметь задавать вопросы по ходу — не по бумажке, а по голове. К слову, в Яндексе у нас тоже были такие секции: когда ты общался не по скрипту, а по сути. Но, справедливости ради, это требует опыта, внутренней уверенности в знаниях, а так же умения слушать и импровизировать. К такому виду собеседований надо быть готовым.
Я лично поддерживаю этот подход. Он медленнее, сложнее и менее «масштабируем», но он гораздо точнее. Потому что люди не равны задачкам на доске. И хорошее интервью — это разговор. Не тест.
Сергей Озеранский недавно написал у себя в канале о своём опыте собеседований с инженерами.
Найм давно стал шаблонным. За каждым собеседованием — одно и то же: опросники, задачи. В лучшем случае архитектурная секция. Благодаря благотелям вырос целый слой «хакающих систему» джунов, которые натаскиваются на такие интервью. И сениоров, которые не проходят дальше первой секции, потому что у них нет времени готовиться и зубрить учебники.
При этом то, что предлагает Сергей, требует высокой подготовки. Он пишет о навыке вести живой разговор, быть в моменте, уметь задавать вопросы по ходу — не по бумажке, а по голове. К слову, в Яндексе у нас тоже были такие секции: когда ты общался не по скрипту, а по сути. Но, справедливости ради, это требует опыта, внутренней уверенности в знаниях, а так же умения слушать и импровизировать. К такому виду собеседований надо быть готовым.
Я лично поддерживаю этот подход. Он медленнее, сложнее и менее «масштабируем», но он гораздо точнее. Потому что люди не равны задачкам на доске. И хорошее интервью — это разговор. Не тест.
👍27💯14🔥3
YouTube
Уволить нельзя оставить: баланс между эффективностью и эмпатией Татьяна Сеземина (Холдинг Т1)
Приглашаем на самую крупную мультиформатную конференцию для тимлидов и руководителей не только из IT — TeamLead Conf 2025, которая пройдет 10 и 11 ноября 2025 в Москве.
Подробнее о конференции: https://clck.ru/3NUaBv
________
Единственная профессиональная…
Подробнее о конференции: https://clck.ru/3NUaBv
________
Единственная профессиональная…
Это доклад о том, как увольнять людей и расставаться с ними максимально эффективно.
В докладе рассмотрены три темы.
▫ Какие есть риски увольнения. Тут Татьяна выделяет следующие риски: долгий и дорогой поиск замены, утечка знаний и информации, переживание и деморализация команды, перетягивание команды и суды.
Я много раз наблюдал даже громкие увольнения — и «деморализация» сходила на нет через пару недель. А «перетягивание команды» — это не столько риск, сколько индикатор: что происходит в компании, если люди готовы уйти за одним человеком?
▫ Когда увольнения можно избежать и когда нельзя:
Можно: если проблемы с Hard-Skills или есть проблемы взаимодействия с контрагентами.
Нельзя: завершение проекта / закрытие направления, токсичные проявления в команде, открытый саботаж.
▫️ Семь шагов при увольнении
1. Дать второй шанс: обозначить проблему, дать конкретный срок на исправление.
2. Оценить срок подбора замены
3. Прямо поговорить с человеком.
4. Проработать увольнение с теми кто может быть против.
Этот пункт на мой взгляд самый не очевидный и потому полезный. Принимая решение об увольнении нужно понимать что конкретно и с кем делал человек? Татьяна, зачем-то, говорит про кумовство, хотя я бы говорил про элементарную защиту цепочки поставки. Когда вероятно могут быть люди, плотно взаимодействующие с человеком и удовлетворенные результатом работы.
5. Уточнить правовой аспект (например, не относится ли увольняемый к защищенным ТК РФ категориям)
6. Саморефлекция
7. Скоммуницировать команде.
Несмотря на неплохие тезисы доклад оставил у меня двоякое впечатление. Есть хорошие тезисы, например, что уволить человека, даже когда он откровенно просаживает задачи и это подтверждено цифрами — сложно. Но тут же Татьяна себе противоречит, ведь если так, то как уволить за открытый саботаж?
Татьяна не погружается глубоко в вопрос «почему людей иногда нужно увольнять». Из доклада складывается ощущение что увольнять надо тех с кем не удобно работать. Татьяна, например, приводит кейс с аналитиком, который на каждом дейли говорил что у них ничего не получится. Но совсем не раскрывает вопрос: а при этом делал ли он свою работу? Может это была его защитная реакция — завести себя в состояние цейтнота, чтобы делать работу на максималках? Может команду это так же подстёгивало? Хочется больше контекста.
Расскажу пример из своей практики, был у меня разработчик, допустим Иван Иваныч. И вот он был редкостный... человек. Мат-перемат и уши в трубочку заворачивались от каждого диалога. Он доставлял кучу проблем, мог не приходить на работу, коллеги от него стрелялись, и были даже инциденты закончившиеся больницей. И я тоже хотел бы его уволить, но.... Иваныч был просто гениальным фронтендером. Я дал ему отдельный проект с небольшой командой и возможность проявлять себя в нём, и оказалось что помимо офигенных скиллов во фронтенде он обладает ещё и очень неплохими навыками motion-дизайна. Его интерфейсы были очень вкусными и привлекательными. И так мы прожили достаточно долго, а потом Иваныч сам ушел из компании, но при этом у меня остались тёплые (и веселые) воспоминания о нём.
Если вы смотрели сериал «Доктор Хаус», то понимаете что я получил такого же доктора Хауса. Если вы нанимаете команду винтиков, то нужно следовать рекомендациям Татьяны (посмотрите доклад), если вы хотите собрать сильную и смелую команду, то доклад надо посмотреть критически и задавать себе вопросы: а точно ли это так? а согласен ли я с этим? Вот именно в такой компоновке я готов порекомендовать этот доклад.
А увольнять надо тех, кто не работает.
Все обзоры докладов по тегу #докладобзор@teamleading
В докладе рассмотрены три темы.
Я много раз наблюдал даже громкие увольнения — и «деморализация» сходила на нет через пару недель. А «перетягивание команды» — это не столько риск, сколько индикатор: что происходит в компании, если люди готовы уйти за одним человеком?
Можно: если проблемы с Hard-Skills или есть проблемы взаимодействия с контрагентами.
Нельзя: завершение проекта / закрытие направления, токсичные проявления в команде, открытый саботаж.
1. Дать второй шанс: обозначить проблему, дать конкретный срок на исправление.
2. Оценить срок подбора замены
3. Прямо поговорить с человеком.
4. Проработать увольнение с теми кто может быть против.
Этот пункт на мой взгляд самый не очевидный и потому полезный. Принимая решение об увольнении нужно понимать что конкретно и с кем делал человек? Татьяна, зачем-то, говорит про кумовство, хотя я бы говорил про элементарную защиту цепочки поставки. Когда вероятно могут быть люди, плотно взаимодействующие с человеком и удовлетворенные результатом работы.
5. Уточнить правовой аспект (например, не относится ли увольняемый к защищенным ТК РФ категориям)
6. Саморефлекция
7. Скоммуницировать команде.
Несмотря на неплохие тезисы доклад оставил у меня двоякое впечатление. Есть хорошие тезисы, например, что уволить человека, даже когда он откровенно просаживает задачи и это подтверждено цифрами — сложно. Но тут же Татьяна себе противоречит, ведь если так, то как уволить за открытый саботаж?
Татьяна не погружается глубоко в вопрос «почему людей иногда нужно увольнять». Из доклада складывается ощущение что увольнять надо тех с кем не удобно работать. Татьяна, например, приводит кейс с аналитиком, который на каждом дейли говорил что у них ничего не получится. Но совсем не раскрывает вопрос: а при этом делал ли он свою работу? Может это была его защитная реакция — завести себя в состояние цейтнота, чтобы делать работу на максималках? Может команду это так же подстёгивало? Хочется больше контекста.
Расскажу пример из своей практики, был у меня разработчик, допустим Иван Иваныч. И вот он был редкостный... человек. Мат-перемат и уши в трубочку заворачивались от каждого диалога. Он доставлял кучу проблем, мог не приходить на работу, коллеги от него стрелялись, и были даже инциденты закончившиеся больницей. И я тоже хотел бы его уволить, но.... Иваныч был просто гениальным фронтендером. Я дал ему отдельный проект с небольшой командой и возможность проявлять себя в нём, и оказалось что помимо офигенных скиллов во фронтенде он обладает ещё и очень неплохими навыками motion-дизайна. Его интерфейсы были очень вкусными и привлекательными. И так мы прожили достаточно долго, а потом Иваныч сам ушел из компании, но при этом у меня остались тёплые (и веселые) воспоминания о нём.
Если вы смотрели сериал «Доктор Хаус», то понимаете что я получил такого же доктора Хауса. Если вы нанимаете команду винтиков, то нужно следовать рекомендациям Татьяны (посмотрите доклад), если вы хотите собрать сильную и смелую команду, то доклад надо посмотреть критически и задавать себе вопросы: а точно ли это так? а согласен ли я с этим? Вот именно в такой компоновке я готов порекомендовать этот доклад.
А увольнять надо тех, кто не работает.
Все обзоры докладов по тегу #докладобзор@teamleading
Please open Telegram to view this post
VIEW IN TELEGRAM
👍24❤4🎉1
Кстати, уже завтра будет Saint TeamLead Conf и я там тоже буду. Подходите знакомиться и обниматься 😊
1❤8🥰3🔥2
Telegram
ULYANOV.LIFE
«В мире животных» или немного о «волках»
Есть такая секта в IT-сообществе, которая своих членов называет волками, а главным лозунгом провозглашает: «Работать нужно за деньги, а не за спасибо». Казалось бы — что тут не так, и почему секта? Волк вроде как…
Есть такая секта в IT-сообществе, которая своих членов называет волками, а главным лозунгом провозглашает: «Работать нужно за деньги, а не за спасибо». Казалось бы — что тут не так, и почему секта? Волк вроде как…
Идеология одиночек
Макс Ульянов написал пару постов про «волков» — первый, второй. Глеб Михеев подхватил. Не могу не откликнуться и не высказать своё имхо — но сначала лучше прочитать их.
Волки — это не герои-одиночки. Это читеры, для которых важнее пройти, чем понять. И, увы, такая установка встречается всё чаще — во многом потому, что сама система это поощряет. Современные собеседования всё чаще напоминают не экзамен на знания, а экзамен на знание формата. Кто умеет угадывать или знает вопросы или может нагуглить правильные ответы, побеждает.
Я это видел давно. В универе у нас был курс по сетям Cisco — обязательный и скучный. Преподавание слабое, интереса ноль, но каждую неделю — тест. И всё свелось к гонке шпаргалок. Интернет? Отрубили. Флешки? Запретили. CD-диски, дискеты? Поставили мониторинг экранов. Я дошёл до того, что печатал шифрованные шпоры на бумажках размером с ладонь. Иногда это работало, иногда нет — но в итоге ничему полезному меня этот курс не научил. Потому что никто не объяснил, зачем всё это, и не создал условий для настоящего понимания.
Собеседования — не просто фильтр. Это предиктор будущей работы. Человек потом с этими знаниями будет писать код, общаться с командой, принимать решения. Если он проходит «по шпоре» — то что будет потом?
Мышление «просочиться» — токсично. И если собеседования сейчас устроены так, что выгодно именно оно, — значит, надо менять формат. Практические интервью, приближённые к реальной работе, лучше вскрывают суть: кто умеет решать — решит. Кто зубрил — сдуется. Проблема в том, что такие собеседования дорогие (я об этом писал).
Нет, я не идеалист. Я понимаю, почему бигтех (а за ним и другие компании) выбирает формат экзамена. Он масштабируемый. Это позволяет работать с сотнями кандидатов, не тратя по 4 часа на каждого. Но это не делает формат хорошим — только удобным.
Есть классический треугольник: дёшево, быстро, качественно — выбери любые два. Сейчас рынок требует дешево и быстро. Поэтому у нас — собеседования-экзамены. Возможно, пока это наилучшее из плохого. Но точно не то, чем стоит гордиться.
И вот тут возвращаемся к «волкам». Если бы они только сливали собесы и выкладывали разборы — это было бы похоже на форму протеста. Не идеальную, но понятную.
Идеология волков звучит так: «Работать нужно только за деньги, а не за спасибо». Это не позиция профессионала — это логика читера. Того, кто делает только то, за что платят прямо сейчас. Как таксист, который ради 50 рублей проезжает на красный. На короткой дистанции это может сработать. Но ни одна команда, ни один продукт на этом далеко не уедет.
Нет ничего страшного, если вы воспользовались IDDQD, чтобы посмотреть как надо было и что же там дальше. Плохо, когда вы живете исключительно на IDDQD. Именно поэтому идеология волков — не про справедливость, а про халяву. Не про улучшение системы, а про то как её обходить. Это читерство и оно всегда вскрывается. Иногда — через месяц. Иногда — через 35 лет. Но вскроется обязательно.
Макс Ульянов написал пару постов про «волков» — первый, второй. Глеб Михеев подхватил. Не могу не откликнуться и не высказать своё имхо — но сначала лучше прочитать их.
Волки — это не герои-одиночки. Это читеры, для которых важнее пройти, чем понять. И, увы, такая установка встречается всё чаще — во многом потому, что сама система это поощряет. Современные собеседования всё чаще напоминают не экзамен на знания, а экзамен на знание формата. Кто умеет угадывать или знает вопросы или может нагуглить правильные ответы, побеждает.
Я это видел давно. В универе у нас был курс по сетям Cisco — обязательный и скучный. Преподавание слабое, интереса ноль, но каждую неделю — тест. И всё свелось к гонке шпаргалок. Интернет? Отрубили. Флешки? Запретили. CD-диски, дискеты? Поставили мониторинг экранов. Я дошёл до того, что печатал шифрованные шпоры на бумажках размером с ладонь. Иногда это работало, иногда нет — но в итоге ничему полезному меня этот курс не научил. Потому что никто не объяснил, зачем всё это, и не создал условий для настоящего понимания.
Собеседования — не просто фильтр. Это предиктор будущей работы. Человек потом с этими знаниями будет писать код, общаться с командой, принимать решения. Если он проходит «по шпоре» — то что будет потом?
Мышление «просочиться» — токсично. И если собеседования сейчас устроены так, что выгодно именно оно, — значит, надо менять формат. Практические интервью, приближённые к реальной работе, лучше вскрывают суть: кто умеет решать — решит. Кто зубрил — сдуется. Проблема в том, что такие собеседования дорогие (я об этом писал).
Нет, я не идеалист. Я понимаю, почему бигтех (а за ним и другие компании) выбирает формат экзамена. Он масштабируемый. Это позволяет работать с сотнями кандидатов, не тратя по 4 часа на каждого. Но это не делает формат хорошим — только удобным.
Есть классический треугольник: дёшево, быстро, качественно — выбери любые два. Сейчас рынок требует дешево и быстро. Поэтому у нас — собеседования-экзамены. Возможно, пока это наилучшее из плохого. Но точно не то, чем стоит гордиться.
И вот тут возвращаемся к «волкам». Если бы они только сливали собесы и выкладывали разборы — это было бы похоже на форму протеста. Не идеальную, но понятную.
Идеология волков звучит так: «Работать нужно только за деньги, а не за спасибо». Это не позиция профессионала — это логика читера. Того, кто делает только то, за что платят прямо сейчас. Как таксист, который ради 50 рублей проезжает на красный. На короткой дистанции это может сработать. Но ни одна команда, ни один продукт на этом далеко не уедет.
Нет ничего страшного, если вы воспользовались IDDQD, чтобы посмотреть как надо было и что же там дальше. Плохо, когда вы живете исключительно на IDDQD. Именно поэтому идеология волков — не про справедливость, а про халяву. Не про улучшение системы, а про то как её обходить. Это читерство и оно всегда вскрывается. Иногда — через месяц. Иногда — через 35 лет. Но вскроется обязательно.
18🔥26❤17😁8🕊3💯3❤🔥1😢1🙏1🐳1
Вау! 3 тысячи, спасибо каждому кто читает этот канал, пишет в комментарии и репостит. Так как здесь много новых людей, то настало время сделать навигационный пост, чтобы не пропустить самое интересное.
❤16👍10❤🔥6🥰2
Привет, меня зовут Олег.
Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level).
Здесь я пишу свои мысли на разные темы. Вот некоторые важные посты, разбитые на тематики.
Мой манифест работе — понедельник начинается в субботу.
Подходы к управлению
— Ситуационное лидерство
— Всегда действовать в интересах команды
— Минимальный жизнеспособный сотрудник и правила работы со мной
— Про одну из ролей продактов и закон Йеркеса-Додсона
— Про нагрузку на команду и формулу Кингмана
Командные встречи и 1х1
— Как часть нужно общаться командой?
— Как давать корректирующий фидбек (Алгоритм Хорстмана)
— Метод 5П для встреч один на один
— Метод ORID
— Обратные ретроспективы
Саморазвитие
— Сколько часов надо работать в неделю?
— Учиться — быть самоучкой?
— Мыслетопливо и как я его сохраняю
Про найм и увольнения
— Факторы сениорности
— Как нанимать лучших
— Почему я люблю вопрос «Какое у тебя хобби» и почему он про выгорание.
— Как увольнять, сохраняя достоинство
— Что делать если вас уволили?
— Про то почему волки — читеры
— Сломан ли найм и как его начать чинить
Про Performance Review
— Как давать фидбек друг на друга. В трёх частях: первая, вторая и третья.
— Как калибровать людей
— Зачем калибровать людей. Часть один и два.
— Про слепые калибровки
А также просто мысли о разном.
— Как я начал читать и мой рейтинг книг, прочитанных в 2024 году.
— Про икигай и смысл жизни
— Как я научился Power Nap'ам.
А ещё я делаю обзоры на книги и доклады. Их можно найти по тегам — #книгобзор@teamleading и #докладобзор@teamleading.
Я почти 20 лет работаю в ИТ, из них 15 работал в российском бигтехе и вырос из верстальщика до руководителя отдела (C-level).
Здесь я пишу свои мысли на разные темы. Вот некоторые важные посты, разбитые на тематики.
Мой манифест работе — понедельник начинается в субботу.
Подходы к управлению
— Ситуационное лидерство
— Всегда действовать в интересах команды
— Минимальный жизнеспособный сотрудник и правила работы со мной
— Про одну из ролей продактов и закон Йеркеса-Додсона
— Про нагрузку на команду и формулу Кингмана
Командные встречи и 1х1
— Как часть нужно общаться командой?
— Как давать корректирующий фидбек (Алгоритм Хорстмана)
— Метод 5П для встреч один на один
— Метод ORID
— Обратные ретроспективы
Саморазвитие
— Сколько часов надо работать в неделю?
— Учиться — быть самоучкой?
— Мыслетопливо и как я его сохраняю
Про найм и увольнения
— Факторы сениорности
— Как нанимать лучших
— Почему я люблю вопрос «Какое у тебя хобби» и почему он про выгорание.
— Как увольнять, сохраняя достоинство
— Что делать если вас уволили?
— Про то почему волки — читеры
— Сломан ли найм и как его начать чинить
Про Performance Review
— Как давать фидбек друг на друга. В трёх частях: первая, вторая и третья.
— Как калибровать людей
— Зачем калибровать людей. Часть один и два.
— Про слепые калибровки
А также просто мысли о разном.
— Как я начал читать и мой рейтинг книг, прочитанных в 2024 году.
— Про икигай и смысл жизни
— Как я научился Power Nap'ам.
А ещё я делаю обзоры на книги и доклады. Их можно найти по тегам — #книгобзор@teamleading и #докладобзор@teamleading.
Telegram
Про руководство разработкой и продуктом | Олег Мохов
Понедельник начинается в субботу
Эта книга одна из моих любимых. Процитирую один фрагмент (прочитайте вдумчиво):
Трудовое законодательство нарушалось злостно, и я почувствовал, что у меня исчезло всякое желание бороться с этими нарушениями, потому что сюда…
Эта книга одна из моих любимых. Процитирую один фрагмент (прочитайте вдумчиво):
Трудовое законодательство нарушалось злостно, и я почувствовал, что у меня исчезло всякое желание бороться с этими нарушениями, потому что сюда…
2❤30👍19👏5🙏2🥰1🕊1