Meetily – локальный генератор заметок со встреч

Я давно уже хотел настроить себе пайплайн записи встреч, их расшифровки, суммаризации и складывания куда-то в Obsidian. Все это, конечно, только на локальных моделях, чтобы данные никуда не утекали. Так вот, только я сел настраивать пайплайн, как наткнулся на готовый опенсорсный проект – Meetily. Что он уже умеет:

👉Подключаться к аудиосессии и захватывать ее
👉Транскрибировать встречи с помощью whisper.cpp, причем сразу с разметкой спикеров
👉Использовать разные локальные модели для суммаризации

Забираю себе потестировать, вы тоже потом расскажите! Демку можно посмотреть вот тут.

Про переработки

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

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

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

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

DEI – хорошая идея, плохая реализация

👉Хороший менеджер оценивает людей не только по их текущим результатам, но и по потенциалу. Компания – это система, которая может как раскрывать этот потенциал, так и убивать его.
👉Задача компании – зарабатывать деньги. Этому помогают ценности и культура. DEI (diversity, equity, inclusion) – инструмент, который может помочь с реализацией некоторых ценностей, но он не должен подменять ни их, ни цель существования бизнеса.
👉Инклюзивная культура помогает строить хай-перфоманс команды за счет того, что расширяет как воронку кандидатов в целом, так и воронку тех, кому окружение не мешает добиваться крутых результатов. А чем больше перформящих людей, тем выше планочка поднимается для всех.
👉Пример того, почему это важно – после скандала в Uber процент женщин в SRE команде упал с 25% до 3%. А это означает кучу упущенных возможностей получить крутых сотрудников.
👉Разумные DEI инициативы направлены на то, чтобы уменьшить когнитивные искажения, которые мешают какой-то группе людей нормально работать и расти в компании.
👉При этом на самом деле большинство DEI кампаний бессмысленные – вместо того, чтобы объяснять, чем бизнесу важна инклюзивность, и решать конкретные точечные проблемы, они навязывают карго-культы и заворачивают их в обертку пустых ценностей.

Открытое собеседование на СТО

Роль СТО сильно зависит от размера, структуры и культуры компании. Собеседования тоже довольно сильно отличаются от компании к компании, но при этом общее ядро выделить точно можно.

Ведущие подкаста "Бреслав и Ложечкин" уже завтра проводят открытое собеседование СТО – Саша будет собеседовать Андрея. Помимо самого собеседования будет детальный анализ всех вопросов и ответов вместе с экспертом, который отвечает за Executive Search.

Короче говоря, если вы посматриваете на роль СТО как на возможный майлстоун в вашей карьере, обязательно подключайтесь! Собес пройдет в Телеграм-канале по ссылке в заголовке.

Capable и capability

Capable - can already do the “work”
Capability - has potential to be capable to do the “work”

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

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

Новые выпуски менеджерских подкастов

👉"Три тимлида заходят в бар" про техлидов – как и зачем искать техническое лидерство, и должен ли техлид быть инженером, разбирающимся во всех технических нюансах проекта.
👉"Бреслав и Ложечкин" продолжают говорить про дайверсити – в этот раз про стереотипы, предвзятость, и то, как с ней бороться.
👉"Frontend Weekend" с Евгением Россинским, СТО Иви, про то, как не выгореть, работая техническим директором 15 лет в одной компании.

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

Принципы Principal инженеров Amazon

Случайно наткнулся на страницу со списком культурных и инженерных установок, которых придерживаются Principal инженеры в Amazon:

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

Треугольник принятия решений

Я периодически делюсь статьями про разные практики документирования принимаемых в команде решений. Классический пример – Architecture Decision Records, документы, которые сохраняют весь контекст когда-то принятых решений про дизайн проекта. Так вот, вне зависимости, какое именно решение вы документируете, у него можно выделить три ключевых компонента:

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

Если использовать эти компоненты как вершины треугольника, мы получаем отличную ментальную модель, в которой его стороны становятся дополнительными аспектами принятия решения:

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

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

Как прорабатывать свой performance review

Если вы смотрите новый сезон Severance, то там есть восхитительный момент с типичнейшим performance review. Герой справляется с его проработкой так себе, а вот вам в похожей ситуации поможет простой гайд:

👉Постарайтесь воспринимать performance review как ценный фидбэк, который поможет вам стать лучше. В реальности в значимом проценте компаний performance review – карго-культ, который приносит больше вреда, чем пользы. Но в любом случае вам стоит выжать из него максимум для себя, иначе зачем это все.
👉Если какой-то фидбэк вы не готовы принять, не надо сразу же спорить с ним. Возьмите время на то, чтобы подумать над уточняющими вопросами и вернуться к менеджеру или тому, кто этот фидбэк дал.
👉Определите для себя, с каким фидбэком вы по итогу согласны, а с каким нет. Вам точно не нужно пытаться исправлять все, о чем вам нафидбэчили другие люди. У всех есть свои предрассудки, да и вообще, вы не обязаны нравиться каждому.
👉Используйте ту часть обратной связи, с которой согласны, чтобы выработать план действий. Не нужно бросаться на все пункты одновременно, выберите самый импактящий на вашей текущей роли, и начните с него.

Способы принятия решений в команде

Если в понедельник мы обсуждали довольно абстрактную модель принятия решений, то теперь держите максимально прикладные методы:

👉Голосование точками. Тут все стандартно, помогает быстро выбрать один ответ из множества, и при этом учесть мнение каждого.
👉Степень поддержки. Каждый участник оценивает решение по x-балльной шкале. Решение принято, только если средний уровннь поддержки больше нужного уровня.
👉Метод NUF. Взвешенная оценка – новизна (new), полезность (useful), осуществимость (feasible). Решение можно принимать как по общей оценке, так и выбрав один или несколько приоритетных критериев.
👉Игра в покер. Похоже на предыдущие методы, но проводится в закрытую. Все так же, как в planning poker – все выкладывают карты, вскрываются, затем владельцы минимальной и максимальной оценок спорят.
👉Метод парных сравнений. Выбираются критерии, каждое решение сравнивается с каждым, победитель получает +1 балл. Наилучшим становится тот вариант, который победил во всех парах.

А вообще, я наконец-то в отпуске, так что на этой и следующей неделе ежедневных статей не обещаю!

AI фейки на собеседованиях

Буквально недавно к нам собеседовался русскоязычный продакт, который в начале разговора подключил к звонку Otter.ai (это такой сервис автоматической расшифровки звонков). Он очень бодро отвечал на все behavioral вопросы, а порой даже слишком бодро, подкрепляя свои истории кейсами других людей (а вы знаете, что с такой же проблемой сталкивался и Джобс...). Явно прокололся он в тот момент, когда пытался выговорить незнакомые ему сложные слова на английском языке. Короче говоря, наша гипотеза в том, что он автоматически расшифровывал наши вопросы, отправлял их LLM вместе с кастомными промптами, и весело зачитывал ответы.

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

Как техническому менеджеру не терять свои навыки

1️⃣Периодически проходитесь и по всем этапам пользовательского пути, и по этапам стандартного процесса разработки в вашей команде, выписываете все проблемы, составляете friction log.
2️⃣Почти во всех командах львиная доля времени уходит на различную операционку – закрытие мелких багов, инфраструктурные задачи, решение инцидентов. Регулярный глубокий анализ всего, что происходит в этих областях, и поиск возможностей их оптимизировать – как помогут команде, так и дадут менеджеру больше контекста о происходящем.
3️⃣Участвуйте в той же ротации дежурных по инцидентам, что и вся команда. Вы сможете буквально на кончиках пальцев понимать, где в вашей системе самые проблемные места, насколько хорошо все документировано, и чем весь процесс можно сделать лучше.
4️⃣Возьмите на себя подготовку различных документов – и техдокументации, и пострмортемов, и ADR.
5️⃣Попробуйте периодически брать "engineerication" (engineer+vacation) – несколько дней или недель непрерывного времени, когда вы занимаетесь только инженерными задачами. Это особенно хорошо работает, когда нужно быстро погрузиться в новый домен.

Интервью на СТО

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

Важность – Решаемость – Запущенность

Чаще всего, выбирая точки приложения усилий, менеджеры сортируют возможные задачи по степени их срочности. Иногда вмешивается матрица Эйзенхауэра, и, помимо срочности, появляется компонент важности. Держите чуть более глубокий фреймворк, который помогает ответить на вопрос "Будет ли мое участие как менеджера полезным?"

👉Решаемость (tractability) – насколько вообще выбранную проблему можно решить в разумное время.
👉Запущенность (neglectedness) – насколько уровень выделяемых ресурсов на проблему соответствует тому, который нужен, чтобы реально ее решить.
👉Важность (importance) – ну тут все по классике.

Так вот, при оценке всех проблем по этим критериям, вы можете увидеть довольно важные вещи. Самыми интересными выглядят вот эти два кластера:

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