Интересы тимлида и рекрутера не совпадают
На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:
👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.
Рекрутеру в среднем важно не то, насколько подходящего человека вы наймете на открытую позицию, и точно не то, сколько лет он потом проработает в вашей команде. Сама система мотивации оптимизирует его эффективность по шкале, которая не просто не имеет ничего общего с качеством найма, но скорее противоположна ему.
Именно поэтому я всегда говорю о том, что главным заинтересованным в процессе найма должен быть тимлид, и его ни в коем случае нельзя полностью делегировать в HR.
На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:
👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.
Рекрутеру в среднем важно не то, насколько подходящего человека вы наймете на открытую позицию, и точно не то, сколько лет он потом проработает в вашей команде. Сама система мотивации оптимизирует его эффективность по шкале, которая не просто не имеет ничего общего с качеством найма, но скорее противоположна ему.
Именно поэтому я всегда говорю о том, что главным заинтересованным в процессе найма должен быть тимлид, и его ни в коем случае нельзя полностью делегировать в HR.
Хабр
Сколько зарабатывают IT-рекрутеры, и кому готовы платить больше
Мы на Хабр Карьере регулярно исследуем рынок зарплат в IT, и чаще всего — зарплаты разработчиков. Сегодня мы решили посмотреть, а сколько зарабатывают те, кто их ищет и нанимает — рекрутеры и...
Как общаться прямо, но не быть грубым
👉Не используйте слова, которые могут показаться собеседнику эмоционально заряженными, оценочными или хоть как-то направленными на личность.
👉Перед тем, как выражать свое сильное мнение, выслушайте вторую сторону и попробуйте их понять. Как вариант – встраивайте открытые вопросы, так любую обратную связь проще принять.
👉Прямую обратную связь стоит подкреплять очень четкими фактами и объяснять логику за вашими размышлениями.
👉Говорите уверенно, но при этом сохраняя вежливость.
👉Старайтесь не использовать в коммуникации факт своей сеньорности, большего опыта или должности.
👉Не используйте слова, которые могут показаться собеседнику эмоционально заряженными, оценочными или хоть как-то направленными на личность.
👉Перед тем, как выражать свое сильное мнение, выслушайте вторую сторону и попробуйте их понять. Как вариант – встраивайте открытые вопросы, так любую обратную связь проще принять.
👉Прямую обратную связь стоит подкреплять очень четкими фактами и объяснять логику за вашими размышлениями.
👉Говорите уверенно, но при этом сохраняя вежливость.
👉Старайтесь не использовать в коммуникации факт своей сеньорности, большего опыта или должности.
TechTello
How to be Direct Without Being Rude - TechTello
When trying to be direct do you often come across as too strong? Are you being called pushy, rude, insensitive or assigned other such labels? You may like to say things as they are because beating around the bush is not your style. But an honest and direct…
Про эффект Линди
Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет.
Немного переформулировав, эффект Линди можно применить и к росту продуктов – насколько большими бы вы не были, скорее всего вы сможете вырасти еще в два раза, просто продолжая делать все то же самое, что вы уже делали для роста раньше. В статье эта идея раскручивается в обратную сторону – если вы растете линейно, то шансов, что вы покажете 10х рост, практически нет, если вы не измените полностью что-то значительное.
Еще одна область, где эффект Линди вполне применим – рост команды. Скорее всего, вы сможете вырастить команду в два раза, не сильно перестраивая культуру, процессы и оргструктуру, но вот вырасти на порядок так уже не получится.
Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет.
Немного переформулировав, эффект Линди можно применить и к росту продуктов – насколько большими бы вы не были, скорее всего вы сможете вырасти еще в два раза, просто продолжая делать все то же самое, что вы уже делали для роста раньше. В статье эта идея раскручивается в обратную сторону – если вы растете линейно, то шансов, что вы покажете 10х рост, практически нет, если вы не измените полностью что-то значительное.
Еще одна область, где эффект Линди вполне применим – рост команды. Скорее всего, вы сможете вырастить команду в два раза, не сильно перестраивая культуру, процессы и оргструктуру, но вот вырасти на порядок так уже не получится.
A Smart Bear
The Lindy Effect on startup potential
On average, you're halfway to your final destination. How, then, do we not only double from here, but 10x?
Метрики в работе технической поддержки
Если есть команды, в которых сбор метрик операционной эффективности чаще всего осмысленен и не вреден, то это разные виды технического саппорта. В статье рассказывают про отличный пример покрытия метриками команды, находящейся на первой линии разбора вопросов, связанных с безопасностью. Для привлечения внимания некоторые из аспектов работы команды, покрытые метриками:
👉Время реакции на запросы и процент разобранных обращений
👉Корректность разбора алертов
👉Загруженность саппорта
Рекомендую почитать в том числе тем, кто занимается поддержкой внутренней инфраструктуры или платформенных продуктов – я сам применял похожие практики, например, для оценки SLA обращений за помощью в Slack.
Если есть команды, в которых сбор метрик операционной эффективности чаще всего осмысленен и не вреден, то это разные виды технического саппорта. В статье рассказывают про отличный пример покрытия метриками команды, находящейся на первой линии разбора вопросов, связанных с безопасностью. Для привлечения внимания некоторые из аспектов работы команды, покрытые метриками:
👉Время реакции на запросы и процент разобранных обращений
👉Корректность разбора алертов
👉Загруженность саппорта
Рекомендую почитать в том числе тем, кто занимается поддержкой внутренней инфраструктуры или платформенных продуктов – я сам применял похожие практики, например, для оценки SLA обращений за помощью в Slack.
Принцип "No Known Bugs", он же "Zero Bug Policy"
В чем суть принципа – исправление любого бага по умолчанию приоритизируется выше, чем разработка любой новой фичи. С таким подходом, при условии отсутствия предыдущего бэклога из тысячи нерешенных проблем, и при разработке короткими итерациями, вы сможете повысить скорость решения багов до нескольких дней.
У такого подхода, конечно, есть и недостатки. Один из ключевых – команде в среднем гораздо интереснее заниматься разработкой новых штук, а не прерываться постоянно на то, чтобы передвинуть кнопочку чуть левее, или задебажить неуловимое некорректное поведение системы. Справиться с этим помогает несколько вещей:
👉Дисциплина. Как только вы начинаете отдавать приоритет вообще всем багам, даже в том случае, когда появляются споры, баг ли это или фича, приходится тратить меньше когнитивных усилий на принятие решения о приоритизации.
👉Нужно держать перед глазами конечную цель. Она не в скорости закрытия багов, а в том, чтобы система, за которую вы отвечаете, была качественной, и вы могли бы строить поверх нее новые фичи с уверенностью.
👉Рефрейминг – относиться к багам как к незапланированным продуктовым улучшениям. Ведь любой баг – это отклонение системы от идеального поведения, а значит его исправление – приближение ее к этому поведению, следовательно улучшение. Таким образом приоритизация между багами и фичами превращается в то, что в приоритизированный заранее бэклог продуктовых улучшений периодически прилетают незапланированные, которые по умолчанию оказываются сверху списка. Такая вот ментальная бухгалтерия.
Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.
В чем суть принципа – исправление любого бага по умолчанию приоритизируется выше, чем разработка любой новой фичи. С таким подходом, при условии отсутствия предыдущего бэклога из тысячи нерешенных проблем, и при разработке короткими итерациями, вы сможете повысить скорость решения багов до нескольких дней.
У такого подхода, конечно, есть и недостатки. Один из ключевых – команде в среднем гораздо интереснее заниматься разработкой новых штук, а не прерываться постоянно на то, чтобы передвинуть кнопочку чуть левее, или задебажить неуловимое некорректное поведение системы. Справиться с этим помогает несколько вещей:
👉Дисциплина. Как только вы начинаете отдавать приоритет вообще всем багам, даже в том случае, когда появляются споры, баг ли это или фича, приходится тратить меньше когнитивных усилий на принятие решения о приоритизации.
👉Нужно держать перед глазами конечную цель. Она не в скорости закрытия багов, а в том, чтобы система, за которую вы отвечаете, была качественной, и вы могли бы строить поверх нее новые фичи с уверенностью.
👉Рефрейминг – относиться к багам как к незапланированным продуктовым улучшениям. Ведь любой баг – это отклонение системы от идеального поведения, а значит его исправление – приближение ее к этому поведению, следовательно улучшение. Таким образом приоритизация между багами и фичами превращается в то, что в приоритизированный заранее бэклог продуктовых улучшений периодически прилетают незапланированные, которые по умолчанию оказываются сверху списка. Такая вот ментальная бухгалтерия.
Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.
Gshutler
No known bugs
How the principle of "no known bugs" works in practice
Подробный гайд про то, как работают опционы
Чем выше уровень руководителя, тем сильнее растет переменная часть его зарплаты. А если вы работаете в стартапе, то чаще всего она будет состоять не из премии, а из опционов. Я никогда не вдавался в глубокие детали того, как они работают, и механика казалась довольно очевидной – приходишь в компанию, тебе дают пачку акций, спустя несколько лет ты можешь ее продать, а на вырученные деньги покупаешь домик с видом на море и новый порш.
Но, как и всегда, все работает сильно сложнее:
👉Чтобы получить акции, опцион надо исполнить, заплатив деньги из своего кармана. И часто нужно много денег, при этом последующая конвертация акций в выручку не всегда гарантирована.
👉На стоимость и полезность опционов может повлиять много разных сценариев, начиная от банкротства компании или ее продажей, заканчивая истечением срока опционов.
👉Опционы покрываются сразу двумя видами налогов – подоходным на исполнение и налогом на прирост капитала на их продажу.
👉На стоимость опционов может повлиять еще и размытие акций – постепенный выпуск новых бумаг, тут надо внимательно читать правила конкретной компании.
Короче, в статье разобрано огромное количество таких аспектов. Но еще интереснее – статистика!
📈СЕО обычно получает 5-10% акций, VP 1-2%, директор 0.4-1.25%, сеньор 0.33-1%, менеджер или мидл 0.2-0.33%.
📈Выход планировать стоит на через 10 лет, и быть готовым к 15 годам. При этом надеяться можно и на 5, но это очень оптимистично.
📉Присоединяясь к стартапу seed стадии с долей 1% ваш шанс заработать хотя бы $1М – всего 3.2%. Детальные расчеты есть в англоязычной версии статьи.
Чем выше уровень руководителя, тем сильнее растет переменная часть его зарплаты. А если вы работаете в стартапе, то чаще всего она будет состоять не из премии, а из опционов. Я никогда не вдавался в глубокие детали того, как они работают, и механика казалась довольно очевидной – приходишь в компанию, тебе дают пачку акций, спустя несколько лет ты можешь ее продать, а на вырученные деньги покупаешь домик с видом на море и новый порш.
Но, как и всегда, все работает сильно сложнее:
👉Чтобы получить акции, опцион надо исполнить, заплатив деньги из своего кармана. И часто нужно много денег, при этом последующая конвертация акций в выручку не всегда гарантирована.
👉На стоимость и полезность опционов может повлиять много разных сценариев, начиная от банкротства компании или ее продажей, заканчивая истечением срока опционов.
👉Опционы покрываются сразу двумя видами налогов – подоходным на исполнение и налогом на прирост капитала на их продажу.
👉На стоимость опционов может повлиять еще и размытие акций – постепенный выпуск новых бумаг, тут надо внимательно читать правила конкретной компании.
Короче, в статье разобрано огромное количество таких аспектов. Но еще интереснее – статистика!
📈СЕО обычно получает 5-10% акций, VP 1-2%, директор 0.4-1.25%, сеньор 0.33-1%, менеджер или мидл 0.2-0.33%.
📈Выход планировать стоит на через 10 лет, и быть готовым к 15 годам. При этом надеяться можно и на 5, но это очень оптимистично.
📉Присоединяясь к стартапу seed стадии с долей 1% ваш шанс заработать хотя бы $1М – всего 3.2%. Детальные расчеты есть в англоязычной версии статьи.
vas3k.club
Гайд для сотрудников: опционы в стартапах — Вастрик.Клуб 🤘✖️👩💻
Всё интересное происходит за закрытыми дверями
Где у руководителей точки роста
Неплохая модель для того, чтобы порефлексировать о том, на развитии каких ключевых поведений вам стоит сфокусироваться как руководителю.
Под фокусом здесь подразумевается влияние на бизнесовые цели компании, под автономией – то, насколько в среднем велико влияние других людей и прочих вводных на ваши решения.
1️⃣Low Focus, Low Autonomy
- Вы нечасто думаете про цели компании.
- У вас нет понимания, как конкретные проекты связаны с общей стратегией.
- Вы в последнее время не инициировали никаких стратегических проектов.
- Чаще всего вы делаете то, что вам говорят другие.
- Как технический лид вы идете по пути наименьшего сопротивления, выбирая безопасные и абстрактные цели вроде "уменьшаем техдолг" или "рефакторим легаси".
2️⃣Low Focus, High Autonomy
- Вы постоянно начинаете какие-то инициативы, бизнесовая польза которых неочевидна.
- Вы отвечаете за разработку технической стратегии, не понимая стратегии компании.
3️⃣High Focus, Low Autonomy
- Вы нацелены на получение бизнесового результата, но отвечаете за экзекьюшн, а не постановку целей.
- Все, что вы делаете, определяется не вашими решениями, а внешними факторами.
- Вы редко сопротивляетесь каким-то решениям или предлагаете альтернативы им.
4️⃣High Focus, High Autonomy
- Вы активный участник встреч про стратегию бизнеса.
- Вы спокойно объясняете командам смысл работы над любыми проектами.
- Вы легко можете выделить свой личный импакт на результаты компании.
Вот такая классификация. Здесь нет объективно плохих квадрантов – все зависит от текущей роли, в которой вы находитесь. При этом понимание того, лежат ли ваши основные точки роста в шкале фокуса или в шкале автономности может помочь в планировании собственной карьеры.
Неплохая модель для того, чтобы порефлексировать о том, на развитии каких ключевых поведений вам стоит сфокусироваться как руководителю.
Под фокусом здесь подразумевается влияние на бизнесовые цели компании, под автономией – то, насколько в среднем велико влияние других людей и прочих вводных на ваши решения.
1️⃣Low Focus, Low Autonomy
- Вы нечасто думаете про цели компании.
- У вас нет понимания, как конкретные проекты связаны с общей стратегией.
- Вы в последнее время не инициировали никаких стратегических проектов.
- Чаще всего вы делаете то, что вам говорят другие.
- Как технический лид вы идете по пути наименьшего сопротивления, выбирая безопасные и абстрактные цели вроде "уменьшаем техдолг" или "рефакторим легаси".
2️⃣Low Focus, High Autonomy
- Вы постоянно начинаете какие-то инициативы, бизнесовая польза которых неочевидна.
- Вы отвечаете за разработку технической стратегии, не понимая стратегии компании.
3️⃣High Focus, Low Autonomy
- Вы нацелены на получение бизнесового результата, но отвечаете за экзекьюшн, а не постановку целей.
- Все, что вы делаете, определяется не вашими решениями, а внешними факторами.
- Вы редко сопротивляетесь каким-то решениям или предлагаете альтернативы им.
4️⃣High Focus, High Autonomy
- Вы активный участник встреч про стратегию бизнеса.
- Вы спокойно объясняете командам смысл работы над любыми проектами.
- Вы легко можете выделить свой личный импакт на результаты компании.
Вот такая классификация. Здесь нет объективно плохих квадрантов – все зависит от текущей роли, в которой вы находитесь. При этом понимание того, лежат ли ваши основные точки роста в шкале фокуса или в шкале автономности может помочь в планировании собственной карьеры.
Aviv Ben-Yosef
Tech Executive Alignment
In another effort to open the kimono, here is another key part of effective executive coaching. Many tech leaders find it hard to decide what behaviors they should be working on personally. One dia…
Про ошибку планирования
Ошибка планирования – когнитивное искажение, в результате которого мы систематически недооцениваем время, сложность и риски, связанные с выполнением задачи. Именно отсюда растут ноги у всех историй о проектах, на выполнение которых закладывался месяц, а по факту завершили их через три года.
Почему мы склонны постоянно совершать эту ошибку:
👉Мы гораздо лучше запоминаем хорошие события, чем плохие. Это накладывается на то, что мы в целом склонны переоценивать свои собственные способности. Отсюда гораздо больший вес уделяется возможному позитивному исходу, чем негативному.
👉Мы слишком привязываемся к изначальному плану и изначальным вводным, и систематически недооцениваем новую поступающую информацию.
👉Даже в тех случаях, когда мы обращаем внимание на внешние сигналы, мы склонны пессимизировать те, которые не соответствуют нашей текущей картине мира.
👉Если речь идет про рабочие задачи, то включается еще и элемент социального давления.
Ошибка планирования – когнитивное искажение, в результате которого мы систематически недооцениваем время, сложность и риски, связанные с выполнением задачи. Именно отсюда растут ноги у всех историй о проектах, на выполнение которых закладывался месяц, а по факту завершили их через три года.
Почему мы склонны постоянно совершать эту ошибку:
👉Мы гораздо лучше запоминаем хорошие события, чем плохие. Это накладывается на то, что мы в целом склонны переоценивать свои собственные способности. Отсюда гораздо больший вес уделяется возможному позитивному исходу, чем негативному.
👉Мы слишком привязываемся к изначальному плану и изначальным вводным, и систематически недооцениваем новую поступающую информацию.
👉Даже в тех случаях, когда мы обращаем внимание на внешние сигналы, мы склонны пессимизировать те, которые не соответствуют нашей текущей картине мира.
👉Если речь идет про рабочие задачи, то включается еще и элемент социального давления.
The Decision Lab
Planning fallacy - The Decision Lab
Planning Fallacy is the tendency to be too optimistic about one's estimates. As a result, the time needed to get something done is underestimated.
Как измерять качество
Когда команда решает всерьез заняться качеством своего продукта, чаще всего первым шагом становится определение набора метрик, которым это самое качество определяется, вторым – постановка целей вокруг их улучшения, а третьим – изменение процессов таким образом, чтобы метрики действительно подросли. Все круто, все довольны, тимлид получает премию, а сеньоры – оценки "выше ожиданий" на перфоманс ревью.
Как всегда рациональный Виталий Шароватов напоминает, что качество – субъективно, а, значит, любые метрики могут использоваться только как сигналы о том, что, возможно, качество меняется. При этом объективно измерить его невозможно. Вместо этого он предлагает следующий алгоритм:
👉Выберите набор метрик, которые, по вашему опыту, коррелируют с важными аспектами внешнего или внутреннего качества.
👉Следите за метриками с помощью карт Шухарта, которые помогают отличать незначительные флуктуации метрик от существенных отклонений.
👉При появлении пиков или провалов в метриках анализируйте их причины, и исправляйте их.
👉Регулярно пересматривайте свой набор метрик и ставьте под сомнение их корреляцию с качеством.
Когда команда решает всерьез заняться качеством своего продукта, чаще всего первым шагом становится определение набора метрик, которым это самое качество определяется, вторым – постановка целей вокруг их улучшения, а третьим – изменение процессов таким образом, чтобы метрики действительно подросли. Все круто, все довольны, тимлид получает премию, а сеньоры – оценки "выше ожиданий" на перфоманс ревью.
Как всегда рациональный Виталий Шароватов напоминает, что качество – субъективно, а, значит, любые метрики могут использоваться только как сигналы о том, что, возможно, качество меняется. При этом объективно измерить его невозможно. Вместо этого он предлагает следующий алгоритм:
👉Выберите набор метрик, которые, по вашему опыту, коррелируют с важными аспектами внешнего или внутреннего качества.
👉Следите за метриками с помощью карт Шухарта, которые помогают отличать незначительные флуктуации метрик от существенных отклонений.
👉При появлении пиков или провалов в метриках анализируйте их причины, и исправляйте их.
👉Регулярно пересматривайте свой набор метрик и ставьте под сомнение их корреляцию с качеством.
Как проводить осмысленные карьерные разговоры
Одна из моих любимых частей книги Radical Candor – фреймворк карьерных разговоров. Основная идея простая – обсуждая со своими сотрудниками карьерное развитие, нужно в первую очередь руководствоваться тем, кем они видят себя в идеальном будущем, даже если оно вообще никак не связано с вашей компанией. Статья по ссылке раскручивает эту идею чуть подробнее, объясняя ее пользу не только для сотрудника, но и для компании.
В чем суть – если при планировании карьеры руководствоваться только четко описанной матрицей компетенций, и фокусироваться только на следующем шаге, вы рискуете свалиться в локальную оптимизацию. Вместо того, чтобы думать о реальном улучшении навыков и о приносимом импакте, вы мотивируете людей искать пути побыстрее получить следующую лычку, закрыв синтетические галочки из документа с описанной карьерной лесенкой.
Вместо этого попробуйте сместить фокус на то, чтобы выбирать следующие шаги развития, оптимизируя их под то самое видение идеального будущего, тем самым переключившись на глобальные оптимизации. Вот какие вопросы могут помочь это видение определить:
👉Представь себе точку своей карьеры, в которой ты занимаешься чем-то макимально классным, не хочешь ничего менять, чувствуешь полное удовлетворение от работы. Из чего в таком случае состоит твоя ежедневная рутина?
👉Какие конкретно навыки помогают тебе ощущать себя успешным в этой точке?
👉Решением каких проблем ты занимаешься в этой точке карьеры?
Автор предлагает еще одну простую модель, которая помогает в таких разговорах – обсуждать два измерения роста, скоуп и импакт.
👉Скоуп показывает широту вашей зоны ответственности, размер вашей песочницы. Это количество людей, которым вы можете управлять, бюджет, которым можете распоряжаться.
👉Импакт – глубина вашей зоны ответственности. Он покрывает результаты вашей собственной работы, вашей команды, и эффективность принятых вами решений.
Эта моделька скоуп/импакт удобна для того, чтобы добавить деталей каждому следующему карьерному шагу, который вы прорабатываете вместе с сотрудником.
Одна из моих любимых частей книги Radical Candor – фреймворк карьерных разговоров. Основная идея простая – обсуждая со своими сотрудниками карьерное развитие, нужно в первую очередь руководствоваться тем, кем они видят себя в идеальном будущем, даже если оно вообще никак не связано с вашей компанией. Статья по ссылке раскручивает эту идею чуть подробнее, объясняя ее пользу не только для сотрудника, но и для компании.
В чем суть – если при планировании карьеры руководствоваться только четко описанной матрицей компетенций, и фокусироваться только на следующем шаге, вы рискуете свалиться в локальную оптимизацию. Вместо того, чтобы думать о реальном улучшении навыков и о приносимом импакте, вы мотивируете людей искать пути побыстрее получить следующую лычку, закрыв синтетические галочки из документа с описанной карьерной лесенкой.
Вместо этого попробуйте сместить фокус на то, чтобы выбирать следующие шаги развития, оптимизируя их под то самое видение идеального будущего, тем самым переключившись на глобальные оптимизации. Вот какие вопросы могут помочь это видение определить:
👉Представь себе точку своей карьеры, в которой ты занимаешься чем-то макимально классным, не хочешь ничего менять, чувствуешь полное удовлетворение от работы. Из чего в таком случае состоит твоя ежедневная рутина?
👉Какие конкретно навыки помогают тебе ощущать себя успешным в этой точке?
👉Решением каких проблем ты занимаешься в этой точке карьеры?
Автор предлагает еще одну простую модель, которая помогает в таких разговорах – обсуждать два измерения роста, скоуп и импакт.
👉Скоуп показывает широту вашей зоны ответственности, размер вашей песочницы. Это количество людей, которым вы можете управлять, бюджет, которым можете распоряжаться.
👉Импакт – глубина вашей зоны ответственности. Он покрывает результаты вашей собственной работы, вашей команды, и эффективность принятых вами решений.
Эта моделька скоуп/импакт удобна для того, чтобы добавить деталей каждому следующему карьерному шагу, который вы прорабатываете вместе с сотрудником.
Как читать бизнес-книги
Типичная критика любой бизнес-литературы – две страницы конкретных советов и идей на двести страниц воды и мотивационных речей. Но что, если просто подходить к этим книгам с другим алгоритмом:
👉Перед тем, как начать чтение, пообещайте себе по итогам поменять три какие-то вещи в вашей работе.
👉Относитесь к чтению как к поиску и выбору этих трех вещей для изменения.
👉Выписывайте или выделяйте только те мысли, по мотивам которых вы планируете предпринять реальные действия. На все остальное не тратьте время.
👉Делитесь тем, что вы узнали из книги, со своими коллегами в любой форме. Опять же, с целью получить в результате желаемые изменения.
Типичная критика любой бизнес-литературы – две страницы конкретных советов и идей на двести страниц воды и мотивационных речей. Но что, если просто подходить к этим книгам с другим алгоритмом:
👉Перед тем, как начать чтение, пообещайте себе по итогам поменять три какие-то вещи в вашей работе.
👉Относитесь к чтению как к поиску и выбору этих трех вещей для изменения.
👉Выписывайте или выделяйте только те мысли, по мотивам которых вы планируете предпринять реальные действия. На все остальное не тратьте время.
👉Делитесь тем, что вы узнали из книги, со своими коллегами в любой форме. Опять же, с целью получить в результате желаемые изменения.
4 года холакратии
Владелец консалтинговой компании на ~30 человек делится опытом перехода от иерархической структуры к холакратии. С его точки зрения опыт максимально позитивный – прибыль выросла, он смог отойти от операционных задач, людям работать в кайф, компания спокойно прошла через ряд внешних проблем.
Статья, хоть и позитивная, но смотрит на холакратию довольно реалистично. Подойдет точно не всем, с быстрым ростом не совместима, переход должен драйвиться сильной волей собственника, продолбать весь процесс перехода можно очень легко. Помимо самой статьи рекомендую почитать комментарии, там много интересных деталей.
Владелец консалтинговой компании на ~30 человек делится опытом перехода от иерархической структуры к холакратии. С его точки зрения опыт максимально позитивный – прибыль выросла, он смог отойти от операционных задач, людям работать в кайф, компания спокойно прошла через ряд внешних проблем.
Статья, хоть и позитивная, но смотрит на холакратию довольно реалистично. Подойдет точно не всем, с быстрым ростом не совместима, переход должен драйвиться сильной волей собственника, продолбать весь процесс перехода можно очень легко. Помимо самой статьи рекомендую почитать комментарии, там много интересных деталей.
Хабр
4 года холакратии — честный отзыв о работе без руководителей
В этой статье я постарался честно и вдумчиво проанализировать опыт перехода из вертикальной структуры в горизонтальную. Как мы к этому пришли? Как проходил переход? Что с зарплатами? Куда делись...
Метод, методология и методика
Я постоянно путаю эти три термина, и меня не раз ругали за это. Недавняя статья на Хабре хорошо укладывает все три определения в понятную стстему:
👉Метод – это путь достижения выбранной цели.
👉Методология – это алгоритм применения конкретных методов, которые следует применять для решения некоторого класса задач.
👉Методика – это практическое воплощение одной или нескольких методологий, которые мы будем применять для решения конкретной задачи.
Одна и та же сущность в зависимости от контекста может быть и методом, и методологией, и методикой. Например, Scrum. Руководство по нему описывает методологию. На практике используются конкретные Scrum-методики, основанные на общей методологии. А в контексте более широкой методологии SAFe, Scrum – это просто метод, вместо которого могут использоваться и другие.
Я постоянно путаю эти три термина, и меня не раз ругали за это. Недавняя статья на Хабре хорошо укладывает все три определения в понятную стстему:
👉Метод – это путь достижения выбранной цели.
👉Методология – это алгоритм применения конкретных методов, которые следует применять для решения некоторого класса задач.
👉Методика – это практическое воплощение одной или нескольких методологий, которые мы будем применять для решения конкретной задачи.
Одна и та же сущность в зависимости от контекста может быть и методом, и методологией, и методикой. Например, Scrum. Руководство по нему описывает методологию. На практике используются конкретные Scrum-методики, основанные на общей методологии. А в контексте более широкой методологии SAFe, Scrum – это просто метод, вместо которого могут использоваться и другие.
Хабр
Методики, Методологии, Методы, Фреймворки – Что к чему
В последнее время много обсуждаются разные новомодные методики управления проектами, Agile-методики, методики разработки продукта… Или не «методики», а «методологии»?.. Или «методы»?.. Как...
Еще раз про то, насколько тяжело сейчас будет джунам
Пару недель назад я делился статьей про то, что из-за рассвета генеративных моделей спрос на джунов будет довольно быстро падать – и ничего хорошего от этого ждать не стоит. Держите еще одно эссе на эту тему, которое интересно тем, что смотрит на проблему шире – возможности найти работу уже лишаются начинающие юристы, редакторы и другие подобные профессии.
По мнению автора для того, чтобы быть ценным оператором LLM, нужно очень хорошо понимать, что вы хотите в итоге получить, и уметь видеть, когда в ответ вы получили какую-то фигню. Из этого следует, что начинающим разработчикам важнее всего:
👉Повышать насмотренность на реальный код, занимаясь пет-проектами и опенсорсом.
👉Разбираться в том, как все устроено на самом деле. Относиться к любой компьютерной системе не как к черному ящику, а погружаясь в детали ее устройства.
👉Больше внимания уделять базе, а не конкретным языкам и фреймворкам – алгоритмам, проектированию систем, устройству компиляторов, баз данных, операционок.
👉Разбираться в operations: работе с облачными сервисами, SRE, GitOps.
Короче, ничего нового – те же самые советы джунам давали и до AI. Отличие только в том, что раньше найти работу можно было и просто научившись работать с API пары фреймворков, а теперь этого будет совсем недостаточно.
Пару недель назад я делился статьей про то, что из-за рассвета генеративных моделей спрос на джунов будет довольно быстро падать – и ничего хорошего от этого ждать не стоит. Держите еще одно эссе на эту тему, которое интересно тем, что смотрит на проблему шире – возможности найти работу уже лишаются начинающие юристы, редакторы и другие подобные профессии.
По мнению автора для того, чтобы быть ценным оператором LLM, нужно очень хорошо понимать, что вы хотите в итоге получить, и уметь видеть, когда в ответ вы получили какую-то фигню. Из этого следует, что начинающим разработчикам важнее всего:
👉Повышать насмотренность на реальный код, занимаясь пет-проектами и опенсорсом.
👉Разбираться в том, как все устроено на самом деле. Относиться к любой компьютерной системе не как к черному ящику, а погружаясь в детали ее устройства.
👉Больше внимания уделять базе, а не конкретным языкам и фреймворкам – алгоритмам, проектированию систем, устройству компиляторов, баз данных, операционок.
👉Разбираться в operations: работе с облачными сервисами, SRE, GitOps.
Короче, ничего нового – те же самые советы джунам давали и до AI. Отличие только в том, что раньше найти работу можно было и просто научившись работать с API пары фреймворков, а теперь этого будет совсем недостаточно.
Sourcegraph
The Death of the Junior Developer
LLMs are putting pressure on junior tech jobs. Learn how to stay ahead.
Please open Telegram to view this post
VIEW IN TELEGRAM
Антипаттерны в работе со сложными системами
Несколько когнитивных искажений, которым подвержены люди, занимающиеся анализом сложных систем. К таким системам можно отнести и код, и организацию.
👉Преждевременное заключение. Первый подходящий вывод считается правильным, и дальнейшие поиски решения прекращаются.
👉Навешивание ярлыков. Когда мы вешаем знакомый ярлык на что-то новое и непонятное, мы с одной стороны упрощаем себе работу с ним, а с другой – рискуем таким образом пропустить какие-то важные различия.
👉Узкий фокус. Вместо анализа всей системы, мы смотрим только на ее отдельные компоненты и не видим общей картины.
👉Неосознанная фильтрация данных, которые противоречат нашим изначальным предпосылкам.
Несколько когнитивных искажений, которым подвержены люди, занимающиеся анализом сложных систем. К таким системам можно отнести и код, и организацию.
👉Преждевременное заключение. Первый подходящий вывод считается правильным, и дальнейшие поиски решения прекращаются.
👉Навешивание ярлыков. Когда мы вешаем знакомый ярлык на что-то новое и непонятное, мы с одной стороны упрощаем себе работу с ним, а с другой – рискуем таким образом пропустить какие-то важные различия.
👉Узкий фокус. Вместо анализа всей системы, мы смотрим только на ее отдельные компоненты и не видим общей картины.
👉Неосознанная фильтрация данных, которые противоречат нашим изначальным предпосылкам.
Alex Martynov Blog
Complexity Anti-Patterns - Alex Martynov Blog
Photo by Ming Sun on Pexels In this blog, I want to offer an overview of the themes distilled from different literature that can be considered anti-patterns when we deal with complexity. This is intended as part one of a two-blog series. In the second one…
Новые выпуски тимлидских подкастов
Нерегулярная рубрика на канале – "Какие подкасты про тимлидство послушать". Погнали:
👉Бреслав и Ложечкин про собеседования: нанимать ди универсальных программистов, нужно ли знать математику, как нанимать студентов и что не нужно проверять на входе.
👉Три тимлида заходят в бар про тайм-менеджмент: борьба с прокрастинацией, заметки на встречах, техники пустого инбокса и чеклисты.
👉Подлодка про чистый код: Кирилл Мокевнин разбирает, насколько еще актуальны советы из легендарной книги.
Нерегулярная рубрика на канале – "Какие подкасты про тимлидство послушать". Погнали:
👉Бреслав и Ложечкин про собеседования: нанимать ди универсальных программистов, нужно ли знать математику, как нанимать студентов и что не нужно проверять на входе.
👉Три тимлида заходят в бар про тайм-менеджмент: борьба с прокрастинацией, заметки на встречах, техники пустого инбокса и чеклисты.
👉Подлодка про чистый код: Кирилл Мокевнин разбирает, насколько еще актуальны советы из легендарной книги.
Как нанять СЕО
Как нанимать разработчиков и менеджеров мы все примерно представляем. И вакансии обычно примерно типовые, и роли, которые надо будет выполнять, довольно понятные. Но вот найм СЕО – какая-то абсолютно отдельная история. Для общего развития перед выходными держите статью про то, как выглядит рекомендуемый процесс найма СЕО в стартап:
👉Вместо подготовки профиля позиции, отберите 10-15 резюме кандидатов, которых вы бы наняли, и выделите их сильные и слабые стороны, важные для вас.
👉Выберите правильную рекрутинговую компанию. Чаще всего, чем меньше агентство, тем больше его нетворк заточен под кандидатов с предпринимательскими скиллами в стартапы и небольшие компании.
👉Неочевидный совет – для стартапа лучше не выбирать кандидата с огромным опытом именно в вашем домене. Иначе велик риск того, что вместо инноваций он будет придерживаться своих привычных путей.
👉Приоритизируйте найм того, кто умеет собирать сильные команды, вместо того, кто может прийти и зарешать проблему самостоятельно.
👉Доменный опыт проигрывает и еще одному качеству – умению адаптироваться к меняющемуся окружению.
👉Важно умение управлять ожиданиями стейкхолдеров, выравнивать их и синтезировать большое количество информации.
👉Ну и, напоследок, уметь приоритизировать, причем во многом на уровне интуиции.
Как нанимать разработчиков и менеджеров мы все примерно представляем. И вакансии обычно примерно типовые, и роли, которые надо будет выполнять, довольно понятные. Но вот найм СЕО – какая-то абсолютно отдельная история. Для общего развития перед выходными держите статью про то, как выглядит рекомендуемый процесс найма СЕО в стартап:
👉Вместо подготовки профиля позиции, отберите 10-15 резюме кандидатов, которых вы бы наняли, и выделите их сильные и слабые стороны, важные для вас.
👉Выберите правильную рекрутинговую компанию. Чаще всего, чем меньше агентство, тем больше его нетворк заточен под кандидатов с предпринимательскими скиллами в стартапы и небольшие компании.
👉Неочевидный совет – для стартапа лучше не выбирать кандидата с огромным опытом именно в вашем домене. Иначе велик риск того, что вместо инноваций он будет придерживаться своих привычных путей.
👉Приоритизируйте найм того, кто умеет собирать сильные команды, вместо того, кто может прийти и зарешать проблему самостоятельно.
👉Доменный опыт проигрывает и еще одному качеству – умению адаптироваться к меняющемуся окружению.
👉Важно умение управлять ожиданиями стейкхолдеров, выравнивать их и синтезировать большое количество информации.
👉Ну и, напоследок, уметь приоритизировать, причем во многом на уровне интуиции.
Medium
How to Hire a CEO
I often find boards of startups taking — what I consider to be — less-than-perfect approaches to hiring a CEO. The focus is often on…
Исследование руководителей разработки
Недавно я собирал с вас вопросы для большого исследования тимлидов, которое проводят ребята из DevCrowd. Так вот, они наконец-то запустили сам опрос про условия работы, зарплату, важные навыки и сообщество.
Результаты появятся в сентябре, а пока проходите опрос и скидывайте его коллегам! Если что, результаты прошлого года можно посмотреть тут.
Недавно я собирал с вас вопросы для большого исследования тимлидов, которое проводят ребята из DevCrowd. Так вот, они наконец-то запустили сам опрос про условия работы, зарплату, важные навыки и сообщество.
Результаты появятся в сентябре, а пока проходите опрос и скидывайте его коллегам! Если что, результаты прошлого года можно посмотреть тут.
survey.alchemer.eu
Исследование рынка руководителей разработки, 2024
Исследование рынка руководителей разработки, 2024.
Про аллокацию ресурсов на задачи
Приходилось ли вам когда-нибудь распределять приоритеты работы, управляя процентом выделяемых ресурсов на несколько направлений? Например, 20% времени планировать тратить на техдолг, 50% – на новые фичи, а еще 30% – на поддержку существующей функциональности. Если да, то у меня новости – такой подход работает не очень оптимально.
👉Такой подход прячет за собой реальное определение приоритетов. Мы тратим на техдолг 20%, потому что это наименее важное для нас направление, или потому что нужно обслуживать более срочные задачи?
👉Помимо приоритетов, он прячет и наши ожидания от вложенных ресурсов. Что именно мы ожидаем от вложения 20% ресурсов в техдолг? Точно ли этого достаточно? Как вообще определяется достаточность?
Альтернативный подход требует немного переключить модель мышления. Распределение ресурсов должно быть следствием выбранной вами стратегии, а не самой стратегией. Один из вариантов научиться думать в такой модели – продвинутая матрица Эйзенхауэра с пятью типами работы. Попробуйте сначала определить, чего вы хотите добиться в каждом из них, а уже из этого понимания сформулируйте гипотезу о том, сколько ресурсов на каждое направление надо выделить для достижения успеха.
Приходилось ли вам когда-нибудь распределять приоритеты работы, управляя процентом выделяемых ресурсов на несколько направлений? Например, 20% времени планировать тратить на техдолг, 50% – на новые фичи, а еще 30% – на поддержку существующей функциональности. Если да, то у меня новости – такой подход работает не очень оптимально.
👉Такой подход прячет за собой реальное определение приоритетов. Мы тратим на техдолг 20%, потому что это наименее важное для нас направление, или потому что нужно обслуживать более срочные задачи?
👉Помимо приоритетов, он прячет и наши ожидания от вложенных ресурсов. Что именно мы ожидаем от вложения 20% ресурсов в техдолг? Точно ли этого достаточно? Как вообще определяется достаточность?
Альтернативный подход требует немного переключить модель мышления. Распределение ресурсов должно быть следствием выбранной вами стратегии, а не самой стратегией. Один из вариантов научиться думать в такой модели – продвинутая матрица Эйзенхауэра с пятью типами работы. Попробуйте сначала определить, чего вы хотите добиться в каждом из них, а уже из этого понимания сформулируйте гипотезу о том, сколько ресурсов на каждое направление надо выделить для достижения успеха.