Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами. Размещение рекламы: @tanyasanovna Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Про беседы при увольнении
Памятка про то, как правильно увольнять людей, когда других выходов не остается. Согласен почти со всеми пунктами.
👉Увольнение не должно быть сюрпризом, обратную связь про неудовлетворительные результаты работы надо давать сильно заранее, как и возможность исправиться.
👉Решение об увольнении ваше, так что и увольнять надо вам.
👉Подготовьте железные аргументы, и используйте их вместо сожалений.
👉Предложите помощь в дальнейшем трудоустройстве.
👉Детально и точно расскажите обо всех выходных бонусах, проконсультировавшись заранее с HR.
👉Осознайте, что не стоит требовать 100% вовлеченности в работу в последние недели после увольнения.
👉Не игнорируйте сотрудника после увольнения.
Я не согласен вот с этим пунктом:
Не начинайте разговор со слов: «Ты уволен». Немного «сыграйте в мяч». Спросите у вашего коллеги: «Как ты оцениваешь свою работу в компании?».
В жизни любого руководителя и директора случаются черные полосы и ошибки, которые уж точно никто и никогда не собирался совершать. Эти ошибки сжигают кучу нервов, портят отношения с людьми, а иногда ставят на кон всю карьеру или бизнес. Про такие фэйлы не пишут в книгах, про них не предупреждают перед переходом на позицию или при прохождении интервью. На такие грабли нужно самому наступить или послушать, как на них наступали другие руководители
11 мая Школа «Стратоплан» проводит бесплатную однодневную конференцию Failconf: лучше учиться на чужих ошибках. Там мы хотим открыто и без стеснения поговорить про несколько реальных факапов наших тренеров-руководителей, которые в свое время стоили им кучи нервов, бессонных ночей, потерянных денег, проектов и сотрудников.
4 спикера, 4 истории плюс сессия вопросов и ответов для разбора ваших ситуаций в работе.
11 мая — день признания собственных фейлов. Регистрируйтесь и приходите послушать, какие проблемы могут возникать даже тогда, когда «все учтено и продумано»: Failconf: лучше учиться на чужих ошибках.
Про когнитивную нагрузку
Максимальная когнитивная нагрузка – один из важных лимитов, который надо учитывать при дизайне команд. Подробно об этом рассказывается в книге Team Topologies, которую я как-то уже рекомендовал в этом канале.
Автор предлагает смотреть на когнитивную нагрузку с помощью следующей ментальной модели:cognitive_capacity = individual_cognitive_strength - (environment_cognitive_friction + task_cognitive_weight
👉Cognitive strength – количество ментальной энергии, которое конкретный человек или команда могут выделить на работу в конкретный день.
👉Cognitive friction – влияние рабочего окружения на ментальную нагрузку. Коимат в команде, качество кода, комфорт рабочего места, автоматизация рутины.
👉Cognitive weight – сложность конкретной решаемой задачи, как неотъемлимая, так и порождаемая плохой декомпозицией.
Podlodka Crew про софт-скиллы
Через неделю стартует новый сезон конференции Podlodka Soft Skills Crew про то, как правильно применять софты на собеседованиях. Вот несколько топовых сессий:
👉Воркшоп про то, как сделать свой LinkedIn таким, чтобы им заинтересовались зарубежные работодатели
👉Воркшоп по самопрезентации, на котором научат правильно рассказывать про кейсы из своего опыта
👉Публичное собеседование в обратную сторону, после которого вы научитесь выяснять действительно важные детали про вашего будущего работодателя
👉Воркшоп по переговорам об оффере, с тактиками повышения итоговой компенсации
Среди спикеров такие классные ребята как Женя Антонов, Алексей Шаграев, Вероника Ильина и Валерий Бабушкин.
📆Дата: 13-17 мая, две сессии в день
👉Регистрация
Как экономия на зарплате вредит бизнесу
Эту статью я намеренно публикую перед выходными – на прочтение всего лонгрида у вас уйдет около часа. Но оно того стоит, несмотря на то, что автор периодически скатывается в избирательную выборку фактов, подтверждающих его гипотезы.
Оптимизация зарплат вредит бизнесу:
👉Компетентные люди увольняются, средний уровень квалификации падает.
👉Падает качество, растет уровень брака.
👉Возникают проблемы в контроле качества.
👉Компания перестает слышать сигналы о проблемах от тех людей, кому еще не пофигу.
👉Линейный менеджмент перестает принимать решения и передавать информацию наверх, вместо работы занимается политикой.
👉Риски для компании постепенно растут, а барьеры обнуляются.
👉Шансы банкротства компании с каждым годом все выше.
Собственно, а какие психологические факторы влияют на эту цепочку:
👉Руководство склонно недооценивать имеющиеся в компании компетенции. Некоторые знания и их важность вообще неочевидны, пока их не потеряешь.
👉Существование некоторых компетенций – случайность. Потеряв какого-то человека вообще не факт, что вы сможете нанять полноценную замену.
👉Сотрудник, которому не доплачивают, в целом начинает хуже работать.
На эту грустную картину влияют еще два фактора. Во-первых, экономия на зарплатах – это не только их умышленное снижение, но и неспособность успевать за средним ростом по индустрии. Во-вторых, квалифицированных профессионалов вроде как в целом становится меньше, и, как следствие, они становятся еще дороже.
Основной вывод из всего этого:
Сперва нанимаете лучших сотрудников и платите высокую зарплату, организуете процессы, продолжаете нанимать и инвестируете в людей - потом ожидаете рост результатов.Читать полностью…
I’ve never seen a CTO get fired for not being technical enough but I’ve seen a lot get fired because they can’t speak to the business.
Серия постов Шароватова про планирование
Виталий Шароватов начал серию клевых заметок про планирование, в которых с помощью цепочки рассуждений объясняет несколько важных идей:
👉Планирование без понятной цели не имеет никакого смысла.
👉Улучшения, получаемые от планирования, должны быть выше, чем цена планирования.
👉Дополнительные исследования для уменьшения неопределенности всегда стоят денег, поэтому нужно всегда прикидывать ценность этого самого уменьшения.
Как и в других статьях и выступлениях Виталика мне нравится, что он ведет все свои рассуждения от базовых принципов, поэтому спорить с ними довольно бессмысленно, даже если вам кажется, что именно ваша ситуация – вот точно совсем-совсем ДРУГАЯ. Короче, он там явно в своих заметках только разгоняется, поэтому посматривайте в канал!
Новые выпуски тимлидских подкастов
Тут вышло сразу два интересных выпуска, которые не стоит пропускать:
👉"Бреслав и Ложечкин" про карьерный рост руководителя: в чем отличия ролей линейного руководителя и менеджера менеджеров, как подготовиться к переходу между ними, какие бывают типичные ошибки и ловушки.
👉"Три тимлида заходят в бар", новый подкаст от Насти Абрашитовой, Жени Антонова и Виктора Корейши. Первый выпуск – про сложные разговоры с подчиненными. Как сказать человеку, что от него попахивает, надо ли помогать бороться с зависимостями и как побеждать в кондиционерных войнах.
Что делать, когда сотрудник не воспринимает обратную связь
Представьте, что у вас есть сотрудник, на которого вам принесли обратную связь. Она довольно негативная. Люди жалуются, что ваш сотрудник пассивно-агрессивный и ведет себя снисходительно. Когда вы пытаетесь донести эту обратную связь, сотрудник отказывается ее признавать и встает в защитную позицию.
Вот, что советуют в таких ситуациях:
👉Вообще говоря, такой фидбэк выглядит довольно абстрактным. Перед тем, как приходить с ним к сотруднику, нужно собрать конкретные кейсы того, где и что пошло не так. Хороший менеджер закапываетсы в детали, а не просто передает жалобы.
👉Давая такой фидбэк, постарайтесь деперсонализировать его. Не называйте человека пассивно-агрессивным. Вместо этого лучше сказать что-то вроде "твои действия в этой ситуации были восприняты как пассивно-агрессивные".
👉Проявите эмпатию, и попробуйте покопать, какие конкретно эмоции в человеке вызывает эта обратная связь, и откуда именно эти эмоции берутся.
В комментах к треду на Реддите, конечно, какие-то очень кровожадные люди собрались. Каждый второй комментарий про то, что человеку надо написать PIP, а потом уволить. Как страшно жить то, а.
Признаки того, что менеджер все продолбает
За последние шесть лет среднее количество прямых сотрудников у менеджера выросло почти в три раза. Это привело сразу к нескольким неприятным последствиям:
👉Менеджеры считают, что они отвечают за где-то на 50% больше вещей, чем им позволяет загруженность.
👉Все та же половина менеджеров сильно страдает от стресса и вымотанности, и не может уделять достаточно внимания персонализированной работе со своей командой.
👉У сотрудников таких менеджеров шансов стать топ-перформерами в два раза меньше, чем у других. А шанс того, что они уволятся, наоборот, в три раза выше.
В статье выделяют четыре признака того, что менеджер будет склонен к тому, чтобы зафейлить свою команду:
👉Менеджер не понимает своих сильных и слабых сторон. Это проявляется в оборонительной позиции при получении конструктивного фидбэка, отказе от делегирования, постоянном поиске поддержки от руководства в решениях, которые должны приниматься самостоятельно.
👉Команда не проявляет эмпатию к менеджеру. Это проявляется в их недоверии к его навыкам, нежеланию приспосабливаться к его стилю менеджмента и попытках переложить всю ответственность за результат на его плечи.
👉Сотрудники не получают видимой пользы от взаимодействий со своим менеджером.
👉Работа членов команды не выровнена с целями. Это проявляется в несоответствии амбициозности задач и уровня конкретных сотрудников, большом проценте времени, который уходит на неявные цели, и слишком частое изменение направления работы.
Как писать статус-репорты
Когда вы отвечаете за какой-то важный и долгий проект, хорошим способом держать всех заинтересованных в курсе того, что происходит – писать регулярные сообщения о его прогрессе куда-то в видимый всем канал. Это даже не столько инструмент вовлечения стейкхолдеров, потому что с действительно важными разумнее общаться лично, а политический инструмент, который уменьшает вероятность того, что про ваш проект начнут разговаривать как про непрозрачный бесполезный долгострой.
Автор статьи рассказывает про набор советов, которыми он руководствуется при написании таких отчетов. Некоторые мне кажутся странненькими, но вот те, которые точно утащу себе:
👉Регулярность переоценена. Вместо того, чтобы публиковать отчет по строгому расписанию, лучше делать перерывы разной продолжительности – иногда неделю, иногда три. Так будет создаваться ощущение, что у вас действительно появилась новая и интересная информация, и вероятность прочтения отчета повышается.
👉Если для вас такой режим подходит, то попробуйте headline driven development. Заранее запланируйте, когда будете писать следующий отчет, и к этому моменту постарайтесь сделать что-то весомое в проекте.
👉Всегда любой отчет начинайте с TL;DR в одно предложение и с короткого напоминания целей проекта. Во-первых, список читателей мог поменяться. Во-вторых, это для вас ваш проект – центр мира, а остальные люди его могут не держать в голове. В-третьих, любые новости проще воспринимать в общем контексте.
👉Все любят приятные сюрпризы. Можете заранее прикинуть, что может быть таким сюрпризом, и целенаправленно подготовить его для включения в отчет.
👉Если в проекте произошли какие-то изменения, особенно те, которые противоречат опубликованным вами ранее отчетам, обязательно в явном виде про них напишите. Неявные изменения могут легко привести к поломанным ожиданиям, а те к политическим проблемам.
👉Держите в голове три основных вопроса, которые могут быть у вашей аудитории, и постарайтесь на них ответить.
👉Если в проекте случились какие-то проблемы или появились новые риски – о них тоже стоит ясно рассказать. При этом обязательно упомяните, что вы будете с ними делать.
Подборка книг для менеджеров
Чтение книг – самый доступный для менеджера способ получения новых знаний. Помимо, конечно, регулярного утреннего чтения этого канала. Если ваши списки к прочтению пустые, посмотрите на подборку книг в посте, она, в целом, достаточно неплохая.
👉Turn the Ship Around: про выстраивание команды, которая не будет зависеть от вас
👉No Rules Rules: про инженерную культуру Netflix с отсутствием бюрократии
👉Extreme Ownership: про то, что вы представляете свою компанию, и в любых проблемах, кроме вас, винить некого
👉High Output Management: как менеджеру выбирать точку приложения усилий
👉From Worst to First: как делать себя и команду более бизнес-ориентированными
👉The Making of a Manager: про то, как стать менеджером
👉The Manager's Path: про путь от инженера до VP
👉5 Dysfunctions of a Team: как превращать сломанные команды в рабочие
👉The Ride of a Lifetime: про длиннющий путь СЕО Disney
👉Dare to Lead: как лидеру не бояться быть открытым и уязвимым
Кстати, я в свое время тоже регулярно писал отчеты о прочитанных книгах, среди которых было и много менеджерских. Если хотите прям заполнить свой бэклог на максимум, то можете вот тут эти обзоры почитать!
Инструмент для BYOD от Касперского
BYOD, Bring Your Own Device, это кодовое название политики организации, суть которой в том, что сотрудникам разрешается использовать для работы свое собственное оборудование вместо того, чтобы обязывать их пользоваться корпоративным. Основной плюс в том, что вы можете иметь доступ к корпоративной почте и мессенджерам со своего любимого айфона, вместо того, чтобы использовать отдельный залоченный девайс.
BYOD приходит с определенным набором проблем. Главный, конечно – дополнительные риски безопасности. Если сотрудники могут подключиться к закрытому контуру с личных девайсов, то любой вирус может повлечь за собой серьезные утечки. Чтобы бороться с этим, Касперский предлагает решение Kaspersky Security Mobility Management. В него входит:
👉Управление каталогом девайсов и списком доверенных приложений
👉Отзыв доступов к корпоративным ресурсам
👉Выборочная или полная очистка устройств
👉Загрузка всех нужных сертификатов, политик безопасности и приложений
👉Отслеживание всяких рисков для безопасности
Короче говоря, если вы хотите внедрять BYOD у себя, посмотрите на Касперского – решение выглядит прямо очень мощным.
Реклама: АО "Лаборатория Касперского", ИНН 7713140469
Что делать, когда в техподдержке – экстремальная ситуация?
И как разбираться с последствиями?
Об этом мы поговорим на открытом вебинаре «Завал в техподдержке: что делать?»
Онлайн-встреча состоится сегодня, 17 апреля, в 19:00 МСК
И если вы руководитель или сотрудник службы поддержки, операционный руководитель или комьюнити-менеджер, то это событие – для вас.
▫️Руководители службы поддержки смогут разобраться в причинах и последствия экстремальной ситуации, поймут, как грамотно действовать при инциденте
▫️Операционные руководители поймут, чего ожидать от службы поддержки в экстремальной ситуации
▫️Комьюнити-менеджеры узнают, как инцидент в поддержке влияет на каналы обслуживания
Вебинар проведёт Константин Кафтан, руководитель проектного менеджмента в VK
Бонус! Всем участникам вебинара – скидка 5% на любой курс OTUS
📝 Записаться на событиеРеклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
erid:2SDnjeHhYhw
X5 Tech проводит митап для технических писателей
🗓 Когда?
18 апреля 19:00–22:00
📍Где?
Москва, ProsvetHall + онлайн
Практики из X5 Tech, Озон, Just AI и ВКонтакте поделятся опытом:
🙋🏼♀️ Как техническому писателю найти подходящее место в команде и какие процессы в ней происходят?
🫵🏻 Какие трудности может испытывать новичок в роли технического писателя, почему они возникают и как можно их преодолеть?
🤖 Как использовать ChatGPT в своей работе?
Регистрация на Techdoc Meetup #4 здесь
* Полезно не только техническим писателям
Реклама. ООО "Корпоративный центр ИКС 5", ИНН 7728632689
erid:2SDnjewiKjF
Как писать дизайн-доки
Один из важных элементов инженерной культуры Google – практика написания дизайн-документов на любую сколько-то серьезную фичу. Они содержат высокоуровневый план реализации фичи, описывают ключевые дизайновые решения и принятые компромиссы.
В статье по ссылке дается довольно подробный гайд по тому, как структурировать такой документ, и на какие вопросы стоит ответить. А если вы хотите получше понять плюсы и минусы такой практики, могу посоветовать послушать недавний выпуск Подлодки про инженерную культуру в Бигтехе, где мы в том числе похоливарили про необходимость написания бесконечного количества документов вместо программирования.
Гайд по внутренним коммуникациям
37signals написали классный гайд про организацию коммуникаций внутри компании. Общая философия – уводить все общение в асинхронный режим, все важное фиксировать в долгоживущих документах, а митинги проводить, только когда нет другого выбора. А детали сформулированы в виде 30 принципов. Вот некоторые из них:
👉Разговор помогает только тем, кто в этот момент находится в комнате. Документы помогают всем, в том числе тем, кто придет в компанию через несколько лет.
👉Чтобы раскрыться, значимый разговор должен настояться значимое время. Слишком быстрое суждение, либо требование быстрого ответа повышает шансы непродуманных решений.
👉Если вы выражаете свою мысль неоднозначно, люди воспримут ее в самом плохом возможном смысле.
👉Всегда собирайте обратную связь про то, насколько ваши документы понятны, какие вопросы были пропущены, и все ли ожидания закрыты. С течением времени стоимость пропущенной информации будет только расти.
Помимо принципов, гайд содержит несколько конкретных практик, которые поощряют людей делиться информацией. Вот две, которые мне понравились больше всего:
👉Автоматические сообщения вроде "Какую книгу вы сейчас читаете?" или "Встречали ли вы в последнее время примеры классного дизайна?". Такие опциональные вопросы дают людям дополнительную возможность завязать разговор и сблизиться, что особенно важно удаленным командам.
👉Heartbeats: 6-недельные статус репорты команды, департамента или конкретного человека. Они содержат обзор самых важных ачивок, подчеркивают важность работы и рассказывают про интересные мелочи. Цель – рефлексия о текущем прогрессе и предоставление сводки тем, кто в ней заинтересован.
Не бросайтесь сразу же исправлять все проблемы
Когда вы оказываетесь в новом контексте, будь то новая компания, проект или роль, вы практически сразу начинаете замечать какие-то проблемы. Например, команда прямо сейчас занимается планированием на следующий квартал, и вы точно видите, что при таком процессе декомпозиции и оценки точно ничего не получится.
Автор дает два, на мой взгляд, очень ценных совета для таких ситуаций.
1️⃣Начинайте исправлять проблему, только когда столкнетесь с ней во второй раз. Во-первых, скорее всего, от вас никто не ожидает решения пожаров прямо сейчас. Скорее вас нанимают, чтобы обеспечить успех команды в долгосроке. Во-вторых, посмотрев, как организация реагирует на проблемы и провалы, вы можете узнать много полезного для себя в будущем. В-третьих, вообще-то, вы можете ошибаться. Какой-то неоптимальный с вашей точки зрения процесс может на самом деле работать в текущем контексте. Попытавшись что-то поменять, не разобравшись, вы можете сделать только хуже.
2️⃣Фокусируйтесь на нескольких самых важных проблемах, отложив десятки остальных. Автор называет это правилом 63 – выбираете 3 проблемы для исправления, а остальные 60 осознанно отпускаете. Такой подход помогает не размазывать свой ресурс слишком тонким слоем, и добиваться видимого результата.
Как организовывать приоритизацию в командах, отвечающих за общие компоненты
Представьте, что ваша команда разрабатывает какой-то кусок системы, от которого зависят нескольких других команд, каждая из которых делает важные для компании штуки. Они постоянно приходят к вам со своими запросами, которые зачастую конфликтуют друг с другом за приоритеты, и вам надо принимать решение, чьей задачей заниматься в первую очередь, и как их вообще совместить с вашими собственными целями. Есть несколько подходов, как это можно организовать:
👉Вы раздаете обещания налево и направо, пытаетесь угодить всем заказчикам, но в итоге подводите по срокам всех. Нереалистичные коммитменты постепенно нарастают друг на друге, и доверия к вашей команде все меньше. Единственный плюс такого подхода – вы выглядите довольно выгодно первые несколько циклов планирования. Основной минус – это впечатление длится недолго.
👉Вы приоритизируете задачи в вакууме, избегаете конфликтов, и противопоставляете части неудовлетворенных заказчиков хороший трек рекорд законченных проектов и собственных выполненных целей. Плюсы – вас ничто не ограничивает, команда движется быстро, дает какой-то результат. Минусы – доверия к команде все еще мало, так как она действует как черный ящик.
👉Вы строите систему, в которой ваши заказчики сражаются друг с другом за приоритеты в очереди задач. Плюсы – удобно для команды, вы снимаете с себя ответственность и ничем не рискуете. Минусы – вас начинают воспринимать сугубо как сервисную команду.
👉Вы делаете так, чтобы в компании появилась сквозная приоритизация для проектов. Условно говоря, если для всей компании проект А важнее, чем проект Б, то и ваши задачи для проекта А получают понятный приоритет. Такой подход дает всем командам понятные ориентиры и позволяет автономно принимать решения. Минус – менеджмент обычно не любит принимать такие сложные решения.
Конечно, сквозная приоритизация – идеальный вариант, но ее появление не всегда зависит от вас. Второе место занимает подход с созданием очереди задач. С его помощью вы избегаете накапливания WIP задач на команде, у команды есть понятные приоритеты, а у вашего руководства – свидетельство того, что со своей частью работы вы справляетесь.
Разработка мобильных приложений на заказ от CleverPumpkin
Я очень давно и хорошо дружу с ребятами из CleverPumpkin, бутиковой студии, которая занимается разработкой мобильных приложений на заказ. С их СЕО мы как-то писали чудесный выпуск Подлодки про то, как вообще выстраивать аутсорс-компании, там работали много моих друзей, а сейчас в QA работает моя жена! Поэтому этот пост, хоть и рекламный, но в этот раз прям от чистого сердца!
Так вот, в чем суть – ребята сейчас активно ищут новых клиентов, для которых готовы сделать какие-то классные приложения. Почему вам стоит прийти именно к CleverPumpkin:
👉Они работают с одними из самых классных компаний в России: Хабром, Авиасейлс, Kassir.ru, Интерфакс, Sports.ru, Комитет, Подари жизнь, Пикабу и многими другими.
👉Помимо приложений на заказ делают и свои продукты, которыми многие из вас даже пользуются – например, Moneon для учета личных финансов.
👉Они угорают и по продуктовому, и по техническому качеству того, что делают – поэтому куча клиентов к ним приходит по рекомендациям.
Чтобы пост был не только рекламным, но еще и полезным, держите ссылки на крутой контент, который ребята делают:
🔗Гайд по этапам разработки мобильного приложения
🔗Как организовать трансфер проекта от аутсорса к инхаус команде
🔗Сколько вообще стоит сделать мобильное приложение
Короче, если вам надо либо сделать приложение под заказ, либо нанять себе на время мощных мобильщиков, свяжитесь с ребятами. А если хотите сохранить себе их контакт на будущее, подписывайтесь на их уютный Телеграм-канал!
Как ментальное здоровье влияет на работу
Headspace, разработчики одного из самых популярных приложений для медитации, раз в год проводят исследование того, как взаимосвязаны работа и ментальное здоровье.
👉Основной источник стресса большинства людей – работа, а не личная жизнь. При этом рабочий стресс негативно повлиял на физическое здоровье аж у 77% опрошенных, а 75% набрали лишний вес.
👉Работа влияет на жизнь людей и с положительной стороны. 53% опрошенных благодаря работе нашли компанию людей с похожими интересами, 48% стали увереннее в себе, а 44% стали менее остро чувствовать одиночество.
👉Топ примеров того, как менеджеры негативно влияют на эмоциональное состояние: отсутствие понимания жизни сотрудника за пределами работы, неравное отношение к разным членам команды, нарушение границ рабочего времени.
👉А вот топ положительных примеров: гибкое отношение к рабочему времени, менторство, поощрение карьерных амбиций.
👉93% опрошенных считают, что работодатель должен помогать с ментальным здоровьем.
Добавлю от себя, что партнерки с различными сервисами психотерапии – очень крутая составляющая соцпакета. Я и сам регулярно ей пользуюсь, и часто направлял туда ребят из своей команды. Если у вас такой нет, настоятельно рекомендую добиться ее появления от своих HR.
Что выделяет топ-1% продактов
Отличного продакта от хорошего отличить еще сложнее, чем в случае тимлида. Ты вроде бы чувствуешь, что он реально крутой, но если тебя попросят объяснить, откуда это чувство берется, сделать это будет очень сложно. Мне понравился набор эвристик, которые выделяет автор поста по ссылке, они в основном соотносятся и с моей чуйкой. Вот некоторые из них:
👉Think big. Крутые продакты смотрят в будущее, не пытаясь ограничивать себя существующими сейчас рамками доступных ресурсов. Они целятся в большие возможности, и переводят их в конкретные планы по их достижению.
👉 Prioritize. Крутые продакты умеют держать баланс между проектами, которые приносят быструю выгоду, и долгосрочными инвестициями в платформу.
👉Execution. Крутые продакты делают все, что нужно, чтобы их проект дошел до результата. И почти всегда это значит выходить сильно за рамки их основной роли.
👉Forecast and measure. Крутые продакты умеют очень приблизительно, но при этом близко к реальности, оценивать потенциальную выгоду от инвестиций, используя свой предыдущий опыт и бенчмарки.
👉Trust. Крутые продакты умеют зарабатывать доверие своих стейкхолдеров, и затем пользоваться им, чтобы двигаться быстрее.
👉Push back effectively. Крутые продакты умеют не просто говорить "нет", но делать это так, чтобы не заводить себе врагов, а, наоборот, убеждать противников своих идей.
👉Driven by impact, not promotion. Крутые продакты думаю не о собственном промо внутри компании, а в первую очередь про импакт, который они могут принести. Промоушн – производная импакта.
Хотите подтвердить свои знания и навыки по облачным технологиям?
Теперь такая возможность есть — Yandex Cloud запустил программу сертификации ИТ-специалистов.
Базовый сертификат Yandex Cloud Certified Engineer Associate подтверждает знания и навыки в шести областях: базовые облачные технологии, хранение и обработка данных, DevOps и автоматизация, бессерверные вычисления, информационная безопасность и облачный биллинг.
Экзамен представляет собой онлайн-тест из 65 вопросов. Чтобы ответить на них, отводится 90 минут. Тестирование проводится с прокторингом — системой, которая контролирует, что экзамен сдаётся честно.
💡 Узнать больше и зарегистрироваться на экзамен можно по ссылке
Новый подкаст про лидерство от Сравни
Ребята из финансового маркетплейса Сравни запускают свой подкаст с фокусом на тимлидов. В пилотном выпуске Сергей Фолимонов, главный в Сравни за Data направление, генерализирует свой опыт и рассказывает, как вообще в компаниях устроена работа с данными в 2024 году, какие у нее есть технические и организационные особенности, и в чем состояют нюансы управления командой, работающей с данными.
Ребята планируют релизить новые выпуски раз в три недели, приглашая как своих лидов, так и гостей из других компаний. В общем, если вы хотите побольше аудио и видеоконтента про прикладное лидерство, подписывайтесь на них на любой удобной площадке!
Реклама ООО "Сравни.ру" (ИНН 7710718303) erid: LjN8KN8w3
Как делать дата-проекты
Офигенный выпуск подкаста от ребят из Yandex Cloud про то, как вообще разрабатываются дата-проекты с руководителем соответствующей платформы из Альфы. Из интересных лично мне тем в выпуске поговорили про:
👉Метрики качества данных и их полноты
👉Определение ответственных за тот или иной кусок данных
👉Из каких кусочков состоит роль руководителя в платформе данных
👉Что там происходит на рынке специалистов по работе с данными
Приглашаем опытных ИТ-лидеров принять участие в создании революционно новой core banking платформы.
ГК «Иннотех» входит в один из крупнейших* ИТ-Холдингов России. С 2020 мы разрабатываем инновации для цифровизации финансового сектора 📈.
🧑🏼💻 Вместе нам предстоит работать над масштабным проектом по импортозамещению: высоконагруженные системы, передовой технологический стек (Spring Boot, Quarkus, Kotlin) и микросервисная архитектура.
Необходимые скилы:
🔹опыт разработки ПО на позиции техдиректора или лидера по системному анализу от 5 лет
🔹опыт проектирования и разработки высоконагруженных и отказоустойчивых приложений и др., подробнее – на сайте.
Что предлагаем:
🔹интересные задачи на развитие hard-скилов
🔹быстрый оффер и фаст-трек
🔹удалёнка, ДМС и бонусы
🔹развитая культура и профессиональная команда
В нашей команде уже 13 000+ ИТ-профессионалов, и мы продолжаем расти.
📅 Успей подать заявку до 30.04!
*По версии CNews Analytics 2022, TAdviser 2021 и RAEX 2023
Реклама. Информация о рекламодателе
Про использование LLM в ваших продуктах
В этому году, кажется, продакты и топ-менеджмент любой компании 80% своего ресурса тратят на то, чтобы понять, где конкретно их бизнесу могут помочь LLM. В посте – довольно неплохая подборка эвристик, которые могут вам помочь в такого рода рассуждениях.
👉LLM предсказывают наиболее резонные ответы на любые промпты.
👉Вы не сможете оценить, насколько точно был дан каждый конкретный ответ.
👉Вы можете в среднем оценивать точность модели и какого-то определенного набора промптов.
👉Точность ответов можно увеличить, используя модели большего размера, но они буду дороже и медленнее.
👉Даже самые быстрые LLM недостаточно быстры для многих задач.
👉Даже самые дорогие LLM не слишком дороги для большинства В2В задач. Даже самые дешевые LLM недостаточно дешевы для большинства консьюмерских задач.
👉Перфоманс моделей продолжит улучшаться в будущем, но скорость его улучшения будет довольно быстро падать.
👉Учитывая приведенные выше ограничения, вам надо либо смириться с неточностью ответов модели, либо комбинировать их с ручными человеческими проверками.
Как подталкивать всех к командной работе
На уровне своей команды:
👉Определять корректные ожидания от людей, которые ориентированы на командный успех, а не на индивидуальный
👉Давать частый фидбэк про то, что работает, а что нет
👉Самому быть ролевой моделью для команды
На уровне всей компании:
👉Выстраивать хорошие личные отношения с людьми из других департаментов
👉Наблюдать за тем, какие проблемы и хотелки есть у коллег из других департаментов и помогать им с ними
👉Иметь общее планирование
Как самому стать лучшим командным игроком:
👉Найти какую-то групповую активность за пределами основной работы
👉Фокусироваться на эмпатии, помощи другим и командных целях
👉Решать проблемы, которые мешают всей команде, но за которые никто не хочет браться
Может ли мобильщик вырасти до СТО
С одной стороны, не мне задавать такой вопрос. Моя карьера выглядит следующим образом:
👉Начал как Android и iOS разработчик
👉Стал тимлидом iOS команды, а затем – руководителем всей мобильной разработки
👉Потом каким-то образом стал руководить большим платформенным департаментом, где кроме мобилки были и фронтенд, и бэкенд, и тестирование, и много чего еще
👉Сгорел, стал продакт-менеджером, ушел делать Котлин
👉Невероятным образом стал руководить всем проектом и командой Kotlin, включая всю разработку
При этом я очень много раз замечал, что в обычной продуктовой компании мобильному разработчику гораздо проще упереться в стеклянный потолок, чем условному бэкендеру. В целом, тут нет ничего удивительного – чаще всего самые сложные инженерные задачи находятся все-таки не на клиенте, и возможностей для роста как по лесенке индивидульного контрибьютора, так и менеджера, бэкенд предоставляет существенно больше.
Илья Царев, с которым мы много пересекались в мою бытность мобильщиком, сейчас вырос до целого Director of Engineering в Яндексе. По ссылке в заголовке – его статья с неплохим разбором отличий между разными уровнями руководителей, ожиданиями от них, и рекомендациями по карьерному росту.
В чем различия между менторством, коучингом и спонсорством
👉Менторство – это процесс передачи опыта от одного человека другому. Чаще всего менторство работает лучше, если вы не находитесь в отношениях "начальник-сотрудник".
Менторство хорошо описывается следующей фразой: "Я сталкивался с похожей ситуацией, вот как я поступил... Мне кажется, тебе стоит...".
👉Коучинг – это помощь человеку в достижении его целей. В отличие от менторства фокус не на развитии навыков, а на правильном применении уже существующих.
Коучинг можно описать так: "Чего ты пытаешься достичь? Что тебе мешает? Пробовал ли ты делать...? Как прошло? Что ты сделаешь по-другому в следующий раз?"
👉Спонсорство – это помощь человеку, уже владеющему всеми нужными навыками и компетенциями, продвинуться внутри организации. Его используют, если кто-то явно способен на большее, но почему-то оказался забдокирован и не может получить нужные возможности самостоятельно.
Спонсорство звучит примерно так: "Этот проект звучит как то, в чем отлично разбирается Вася. Давайте предложим лидить этот проект ему".