Про фидбэк луп

Одна из главных причин фрустрации при переходе из индивидуального контрибьютора в лиды в резком увеличении длины цикла обратной связи о том, что ты молодец, и предпринятые тобой действия влияют на итоговый результат. Когда ты разработчик все сравнительно просто. Фидбэк лупов много, и все они довольно короткие:

🔄Написал код – скомпилировал – увидел результат
🔄Доделал таску – отправил PR на ревью – получил комментарии
🔄Смерджил ветку в мастер – дождался релиза – потрогал новую фичу руками и показал своей маме

А вот с тимлидами все намного сложнее. Вроде бы ты помог команде начать работать чуть эффективнее, убрав что-то, что ей мешало, но как сказались именно твои действия на итоговом результате – черт его знает. Из-за этого многие тимлиды и пытаются заменить сложное простым, вводя различные дурацкие метрики, и пытаясь на них повлиять.

Я знаю только один нормальный способ с этим жить, и в заметке по ссылке предлагают его же. Во-первых, смиритесь с тем, что цикл обратной связи о результатах руководителя – долгий и довольно неявный. Это, к сожалению, не изменить. Во-вторых, старайтесь сами декомпозировать свою работу на маленькие кусочки и вести дневник своих маленьких побед. Например, иногда достаточно просто быстро опросить команду на тему того, насколько им стало лучше жить после какого-то изменения в процессах, чтобы понять, что свою работу вы сделали не зря.

Как проджекту и продакту получить бриллиантовый оффер

Почти 80% проджектов и продактов не могут найти себе нормальную работу с отличной зарплатой и адекватным начальником. А всё потому что не умеют правильно оценивать свой опыт, проходить собеседования и чётко формулировать зарплатные ожидания.

Из этого рождаются абьюзивные отношения с говнокомпаниями, которые не хуже Марата Башарова бьют под дых и роняют всё профессиональное либидо.

Бывает ли по-другому?
Карьерный Цех доказывает, что ДА.
Ребята уже давно закрывают вакансии в ТОПовых компаниях России и точно знают, каким должен быть сотрудник, чтобы ему выкатили идеальный оффер.

Карьерный Цех берёт проджекта за руку, учит правильно искать работу и приводит к вакансии мечты.
Эксперты сопровождения научат правильно проходить собеседования, укажут на пробелы в hard- и soft-skills и приведут за руку в тусовку, где каждый найдёт крутой нетворк.
Знания о поиске работы, которые даёт Карьерный Цех, будут работать и через 5, и через 10, и даже 20 лет.

Как познакомиться с проектом поближе:
Переходите на сайт и записывайтесь на бесплатную консультацию. После консультации вы получите индивидуальный план поиска работы, который поможет получить бриллиантовый оффер.

Реклама. ИП Федоров Е.П.
ИНН 532008901966

Культурный контракт с сотрудником

Я большой фанат прописывания явных ожидания между менеджером и сотрудником. Лично у меня с каждым человеком заведен общий документ в Notion, в котором описаны базовые ожидания от его роли, кастомные ожидания, зависящие от конкретной области ответственности, и личные цели на какой-то промежуток времени. Формат может немного различаться для разных людей в зависимости от их уровня зрелости и автономности, но я всегда стараюсь фиксировать их письменно.

Мои ожидания крутятся вокруг того, что именно человек должен делать, и как его работа будет оцениваться. Но сегодняшняя статья явно подсветила недостаток моей системы ожиданий – она ничего не говорит про то, КАК именно человек должен подходить к работе. Короче говоря, ничего не говорит про культурный код и принципы. Для старичков это не особо осмысленное вложение времени, а вот для людей, которые только пришли в компанию, выравниваться на уровне принципов поведения – супер-важно для их успеха.

Вот некоторые из пунктов, которые в такой культурный контракт включает автор статьи:

👉Не бойтесь говорить правду руководителю
👉Сначала научитесь играть по правилам, потом придумывайте свои
👉Сначала решать сложную ситуацию, а потом разбираться, кто в виноват в ее возникновении
👉Прояснять ожидания и соблюдать договоренности
👉Каждый сам отвечает за свой выбор

Звучат принципы, конечно, как за все хорошее против всего плохого. Чтобы такая система завелась, помимо бумажки с их списком каждый принцип нужно разбирать на реальных примерах, и, самое главное, регулярно самому их демонстрировать.

Бреслав и Ложечкин про собеседования и найм

Подкастная пятница уже становится традицией канала! Сегодня принес вам релиз нового выпуска подкаста "Бреслав и Ложечкин", в котором подробно разбирается и то, как можно нанимать людей в стартапы, и то, в чем состоят минусы и плюсы сложного процесса, который сейчас работает в Амазоне.

Закидывайте в список прослушивания на выходные, делитесь фидбэком тут в комментариях или прямо в канале подкаста. А еще мы с недавних пор стали монтировать и видео, так что на Сашу и Андрея теперь можно еще и смотреть!

Про документацию

Кент Бек в своей рассылке наваливает базы про документацию. Суть идеи в том, что сама по себе документация никому не нужна. Что нужно – наличие ответов на конкретные вопросы, знание того, как работает система, и как ее изменять чтобы она не поломалась. И решение о том, нужна ли документация в конкретном месте или нет, это всегда трейдофф.

Факторы, говорящие о том, что документация нужна:

👉Большая потенциальная аудитория читателей. Условно говоря, документация для публичного фреймворка имеет намного больше смысла, чем внутреннего класса, который за все время увидит только три человека.
👉Стабильность. Чем меньше меняется система, и чем более она стабильна, тем меньше костов на поддержание актуальной документации, тем больше в ней смысла.
👉Низкая цена затрат на документацию. Если для того, чтобы написать доки, вы откладываете какие-то важные продуктовые задачи, приносящие ценность бизнесу – скорее всего, вы делаете что-то не так.

Вместо траты время на документацию, можно рассматореть альтернативные способы добиться того же результата:

👉Упрощать систему. Простому коду и архитектуре не нужна документация.
👉Живые коммуникации: парное программирование, рассказы про устройство системы, разговоры за обедом.
👉Тесты. Тут все понятно – при изменении системы приходится менять и тесты, поэтому они легко сохраняют свою релевантность.

Про проблемы рабочей эмиграции

Я стараюсь периодически разваливать популярный миф о том, что тимлиду с бэкграундом работы в российских компаниях невозможно найти работу инжиниринг менеджером где-то в Европе. Я сам получал несколько таких офферов, и многие друзья таким же образом релоцировались в Европу, причем даже в последние годы, несмотря на общий кризис в IT.

Так вот, я обычно покрываю вопрос релокации сугубо с карьерной стороны, выкладывая материалы про прохождения собеседований, анализ текущего рынка вакансий и зарплат, и другие похожие материалы. Но переезд – это не только получение оффера, но и просто гигантское количество сложностей и стресса, связанного с обустройством на новом месте, адаптацией к новой культуре, поиску своей собственной идентичности. И сегодня я хочу посоветовать канал Кирилла Куликова, серийного предпринимателя и эмигранта с огромным стажем. Его канал – супер-ценный источник историй о том, как выбрать страну для переезда и пережить релокацию. Вот некоторые из постов:

👉Разбор актуальной статистике Евростата про жизнь в Европе: безопасность, доходы, уровень счастья и отказы во въезде.
👉Что не так с Нидерландами: тут база, с которой я в целом согласен.
👉Про обладание несколькими ВНЖ: почему это легально, зачем это нужно, и откуда их взять.

Все остальные посты про эмиграцию можно найти не только в канале, но и в базе знаний в Notion. Даже задумался, чтобы себе такую же завести! А вообще, подписывайтесь на канал – помимо эмигрантских заметок там еще много хорошего про стартапы и предпринимательство.

Джунов нельзя заменять на AI

Шикарное эссе про то, почему даже с повышением качества и предсказуемости работы AI вам нужно нанимать джунов.

Основная ценность сеньорного инженера – уметь строить надежные, поддерживаемые и понятные системы из меньших блоков. Умение управлять сложной социотехнической системой приходит только с опытом работы в индустрии, методом проб и ошибок и обучения у старших товарищей. Написание простого кода действительно с рядом оговорок можно отдать AI, но вы теряете кучу других важных преимуществ от наличия джунов в команде, включая здоровую групповую динамику, культуру наставничества, да и вообще воронку появления новых сеньоров.

Основной боттлнек индустрии – не развитие джунов, а их найм. Компании не хотят инвестировать в неопытных инженеров, ценность наличия которых в команде сложнее переводится в деньги, чем сеньоров. Именно отсюда и берется постепенное повышение планки найма и невозможность начинающему специалисту найти работу. Повлиять на это могут только сами нанимающие менеджеры, убеждая свое руководство в необходимости найма джунов. Если этого не делать, то, особенно с учетом появления генеративного AI, поток новых специалистов совсем остановится, и через пять лет с проблемами разбираться придется, опять же, нам самим.

Обязательно прочитайте и полную статью, я пропустил много важных идей и тезисов.

Почему data-driven подход неоптимален

👉Данные собираются с тех пользователей, которые есть у вашего продукта сегодня. Если вы расширяете рынок, эти данные могут начать вводить в заблуждение, а не помогать, так как ранние пользователи всегда более лояльны.
👉Получение надежных данных – сложная и долгая задача, замедляющая процесс принятия решений и приводящая к параличу выбора.
👉Когда вы собираете данные с большого количества пользователей, вам приходится их сегментировать тем или иным образом. Сегментация ведет к усреднению пользователей внутри сегмента, а это – к потере важного контекста. Например, внутри большого сегмента может быть скрыт гораздо более ценный сегмент меньшего размера, который вы пропустили, и в итоге не будете оптимизироваться под его нужды.
👉A/B тесты хороши на чувствительных метриках. Из-за этого зачастую более важные метрики, но на которые гораздо сложнее повлиять, вроде долгосрочного ретеншна, обделяются вниманием. Еще хуже обстоит с важными, но трудноизмеряемыми метриками, вроде влияние на бренд.

Вывод из всего этого простой – нужно учиться держать баланс между тем, чтобы полагаться на данные, и тем, чтобы полагаться на собственную интуицию, обученную на общении с пользователями и понимании рынка. Причем чем сильнее конкуренция и чем слабее ваша позиция в ней, тем больше надо полагаться на интуицию, так как она помогает принимать решения гораздо быстрее.

Что почитать тимлиду

Пятница – отличный момент, чтобы выбрать себе новую книгу на выходные. Держите неплохую подборку менеджерских книг, которая выгодно отличается от других тем, что содержит не только самые очевидные рекомендации, например:

👉Dr. James Stanier «Become an Effective Engineering Manager»
👉David Marquet. «Turn the Ship Around»
👉Ю. Гиппенрейтер. «Большая книга общения с ребенком»

Обеспечение качества зависит от контекста

У качества может быть много разных определений. То, которое использую я, очень близко к автору статьи. Качество – поведение программы, соответствующее ожиданиям пользователя и нефункциональным требованиям. Но несмотря на то, что это определение общее и для высоконагруженных интернет-сервисов, и для небольших мобильных приложений, и для супер-сложной системы вроде компилятора, подходы к обеспечению качества будут совсем разными.

Вся статья посвящена тому, чтобы показать, что методы обеспечения качества зависят от вашего контекста, и вводит модель, которая помогает рассуждать об этом контексте. Вот на какие параметры предлагается смотреть:

👉Essential domain complexity – неотъемлимая сложность предметной области, в которой работает программа. У интернет-магазина диванов она не очень высокая. У HFT системы, скорее всего, наоборот.
👉Scalability complexity – сложность, создаваемая большим количеством пользователей системы
👉Team maturity – уровень навыков команды и знания предметного контекста

В зависимости от того, попадает ли ваш продукт в ситуацию "low essential domain complexity, high scalability complexity, low team maturity" или "high essential domain complexoty, low scalability complexity, high team maturity", подходы к тому, как обеспечивать качество, будут очень сильно отличаться. Поэтому слепо копировать успешные кейсы других компаний, не понимая, чем их ситуация отличалась от вашей, нельзя.

Помимо этой золотой мысли, в статье выстраивается ментальная модель фидбэк лупов создания продукта с хорошими рассуждениями о том, на каких из них фокусироваться в зависимости от перечисленных выше параметров.

Очень рекомендую статью для тех, кто хочет уложить в понятную модель свои мысли про то, как обеспечивать качество.

Сбор тем и вопросов для большого исследования тимлидов

В прошлом году мы проводили большое исследование тимлидов, где, среди прочего, разбирались с основными навыками руководителей команд, проблемами, с которыми они сталкиваются, способами получения новых знаний и кучей других вещей.

В этом году я вышел из команды проекта, но ребята продолжают делать исследования. Давайте поможем им, и накидаем в комментарии к этому посту вопросы и темы, которые вам было бы интересно разобрать в исследовании. Например:

👉Сколько зарабатывают тимлиды в зависимости от размера команды
👉Что замотивировало тимлидов уйти из разработки в менеджмент
👉Средний срок жизни сотрудника в команде

Интересы тимлида и рекрутера не совпадают

На Хабре выложили аналитику по зарплатам рекрутеров. И все бы ничего, но есть там несколько интересных моментов:

👉Зарплаты линейных рекрутеров почти всегда зависят от KPI, которым выступает количество закрытых вакансий
👉24% опрошенных считают, что для повышения зарплаты им надо закрывать больше вакансий. Только 12% – что нужно улучшать сорсинг кандидатов.

Рекрутеру в среднем важно не то, насколько подходящего человека вы наймете на открытую позицию, и точно не то, сколько лет он потом проработает в вашей команде. Сама система мотивации оптимизирует его эффективность по шкале, которая не просто не имеет ничего общего с качеством найма, но скорее противоположна ему.

Именно поэтому я всегда говорю о том, что главным заинтересованным в процессе найма должен быть тимлид, и его ни в коем случае нельзя полностью делегировать в HR.

Как общаться прямо, но не быть грубым

👉Не используйте слова, которые могут показаться собеседнику эмоционально заряженными, оценочными или хоть как-то направленными на личность.
👉Перед тем, как выражать свое сильное мнение, выслушайте вторую сторону и попробуйте их понять. Как вариант – встраивайте открытые вопросы, так любую обратную связь проще принять.
👉Прямую обратную связь стоит подкреплять очень четкими фактами и объяснять логику за вашими размышлениями.
👉Говорите уверенно, но при этом сохраняя вежливость.
👉Старайтесь не использовать в коммуникации факт своей сеньорности, большего опыта или должности.

Про эффект Линди

Эффект Линди говорит о том, что чем дольше что-то существует, тем больше вероятность, что это что-то будет существовать и дальше. Например, если какой-5 фреймворк был популярен 5 лет, то он, скорее всего, будет популярен и следующие 5 лет.

Немного переформулировав, эффект Линди можно применить и к росту продуктов – насколько большими бы вы не были, скорее всего вы сможете вырасти еще в два раза, просто продолжая делать все то же самое, что вы уже делали для роста раньше. В статье эта идея раскручивается в обратную сторону – если вы растете линейно, то шансов, что вы покажете 10х рост, практически нет, если вы не измените полностью что-то значительное.

Еще одна область, где эффект Линди вполне применим – рост команды. Скорее всего, вы сможете вырастить команду в два раза, не сильно перестраивая культуру, процессы и оргструктуру, но вот вырасти на порядок так уже не получится.

Метрики в работе технической поддержки

Если есть команды, в которых сбор метрик операционной эффективности чаще всего осмысленен и не вреден, то это разные виды технического саппорта. В статье рассказывают про отличный пример покрытия метриками команды, находящейся на первой линии разбора вопросов, связанных с безопасностью. Для привлечения внимания некоторые из аспектов работы команды, покрытые метриками:

👉Время реакции на запросы и процент разобранных обращений
👉Корректность разбора алертов
👉Загруженность саппорта

Рекомендую почитать в том числе тем, кто занимается поддержкой внутренней инфраструктуры или платформенных продуктов – я сам применял похожие практики, например, для оценки SLA обращений за помощью в Slack.

Принцип "No Known Bugs", он же "Zero Bug Policy"

В чем суть принципа – исправление любого бага по умолчанию приоритизируется выше, чем разработка любой новой фичи. С таким подходом, при условии отсутствия предыдущего бэклога из тысячи нерешенных проблем, и при разработке короткими итерациями, вы сможете повысить скорость решения багов до нескольких дней.

У такого подхода, конечно, есть и недостатки. Один из ключевых – команде в среднем гораздо интереснее заниматься разработкой новых штук, а не прерываться постоянно на то, чтобы передвинуть кнопочку чуть левее, или задебажить неуловимое некорректное поведение системы. Справиться с этим помогает несколько вещей:

👉Дисциплина. Как только вы начинаете отдавать приоритет вообще всем багам, даже в том случае, когда появляются споры, баг ли это или фича, приходится тратить меньше когнитивных усилий на принятие решения о приоритизации.
👉Нужно держать перед глазами конечную цель. Она не в скорости закрытия багов, а в том, чтобы система, за которую вы отвечаете, была качественной, и вы могли бы строить поверх нее новые фичи с уверенностью.
👉Рефрейминг – относиться к багам как к незапланированным продуктовым улучшениям. Ведь любой баг – это отклонение системы от идеального поведения, а значит его исправление – приближение ее к этому поведению, следовательно улучшение. Таким образом приоритизация между багами и фичами превращается в то, что в приоритизированный заранее бэклог продуктовых улучшений периодически прилетают незапланированные, которые по умолчанию оказываются сверху списка. Такая вот ментальная бухгалтерия.

Один из главных плюсов такого подхода – повышение мотивации команды инвестировать в практики, ведущие к повышению качества: лучшее понимание пользователя, автоматизация, architecture decision records, грамотная декомпозиция.

Подробный гайд про то, как работают опционы

Чем выше уровень руководителя, тем сильнее растет переменная часть его зарплаты. А если вы работаете в стартапе, то чаще всего она будет состоять не из премии, а из опционов. Я никогда не вдавался в глубокие детали того, как они работают, и механика казалась довольно очевидной – приходишь в компанию, тебе дают пачку акций, спустя несколько лет ты можешь ее продать, а на вырученные деньги покупаешь домик с видом на море и новый порш.

Но, как и всегда, все работает сильно сложнее:

👉Чтобы получить акции, опцион надо исполнить, заплатив деньги из своего кармана. И часто нужно много денег, при этом последующая конвертация акций в выручку не всегда гарантирована.
👉На стоимость и полезность опционов может повлиять много разных сценариев, начиная от банкротства компании или ее продажей, заканчивая истечением срока опционов.
👉Опционы покрываются сразу двумя видами налогов – подоходным на исполнение и налогом на прирост капитала на их продажу.
👉На стоимость опционов может повлиять еще и размытие акций – постепенный выпуск новых бумаг, тут надо внимательно читать правила конкретной компании.

Короче, в статье разобрано огромное количество таких аспектов. Но еще интереснее – статистика!

📈СЕО обычно получает 5-10% акций, VP 1-2%, директор 0.4-1.25%, сеньор 0.33-1%, менеджер или мидл 0.2-0.33%.
📈Выход планировать стоит на через 10 лет, и быть готовым к 15 годам. При этом надеяться можно и на 5, но это очень оптимистично.
📉Присоединяясь к стартапу seed стадии с долей 1% ваш шанс заработать хотя бы $1М – всего 3.2%. Детальные расчеты есть в англоязычной версии статьи.

Где у руководителей точки роста

Неплохая модель для того, чтобы порефлексировать о том, на развитии каких ключевых поведений вам стоит сфокусироваться как руководителю.

Под фокусом здесь подразумевается влияние на бизнесовые цели компании, под автономией – то, насколько в среднем велико влияние других людей и прочих вводных на ваши решения.

1️⃣Low Focus, Low Autonomy

- Вы нечасто думаете про цели компании.
- У вас нет понимания, как конкретные проекты связаны с общей стратегией.
- Вы в последнее время не инициировали никаких стратегических проектов.
- Чаще всего вы делаете то, что вам говорят другие.
- Как технический лид вы идете по пути наименьшего сопротивления, выбирая безопасные и абстрактные цели вроде "уменьшаем техдолг" или "рефакторим легаси".

2️⃣Low Focus, High Autonomy

- Вы постоянно начинаете какие-то инициативы, бизнесовая польза которых неочевидна.
- Вы отвечаете за разработку технической стратегии, не понимая стратегии компании.

3️⃣High Focus, Low Autonomy

- Вы нацелены на получение бизнесового результата, но отвечаете за экзекьюшн, а не постановку целей.
- Все, что вы делаете, определяется не вашими решениями, а внешними факторами.
- Вы редко сопротивляетесь каким-то решениям или предлагаете альтернативы им.

4️⃣High Focus, High Autonomy

- Вы активный участник встреч про стратегию бизнеса.
- Вы спокойно объясняете командам смысл работы над любыми проектами.
- Вы легко можете выделить свой личный импакт на результаты компании.

Вот такая классификация. Здесь нет объективно плохих квадрантов – все зависит от текущей роли, в которой вы находитесь. При этом понимание того, лежат ли ваши основные точки роста в шкале фокуса или в шкале автономности может помочь в планировании собственной карьеры.