Чудес не бывает или я ошибаюсь?

Оцифровали и причесали мое голосовое бухтение на тему карьерной развилки у сеньора. Идти ли дальше в лиды и что делать, если пошел, но не зашло. Ссылка на статью на Хабре: Маршрут перестроен: исповедь лида о том, куда расти дальше (и всегда ли расти)

В блог стал меньше писать, потому что он в моей голове предполагает сейчас какую-то долгую предварительную работу со статьей. Черновики у меня годами лежат. Поэтому, встречайте телеграмм-канал, лайт-версию блога: появилась мысль - отправляется в канал. Тематика та же самая, Подключайтесь . Из мариновавшегося годами тут, но уже появившееся в телеге: Team- vs TechLead Ошибки приводящие к проблемам в IT Про календари менеджера и инженера

Митоз клетки команды Если продукт или набор сервисов, которым занимается команда, успешно развивается, задач становится все больше, размер команды растет, рано или поздно вы приходите к мысли о трансформировании команды в несколько команд.  Иногда это происходит "органически" - в продукте есть свободно отделяемая часть, которую можно передать новой команде. Иногда все сложнее - продукт разделить тяжело и само разделение драйвится тем, что просто людей становится много (или нужно больше) и текущие процессы становятся неэффективными, а результат работы сложно прогнозируемым.  Я наблюдал 3 варианта "рождения" новой дополнительной команды для существующих задач (речь здесь и дальше не про запуск нового продукта, а про дополнительный импульс в развитии существующего): - команда формируется с нуля. Самый сложный вариант, который скорее всего подойдет, когда процесс работы уже заточен под "многокомандность" и новая команда - это лишь еще одна шестеренка в настро...

На базе треда в тви. Признаться, я давно не провожу "каноничные" 1:1.  В 1-ю очередь из-за того, что "каноничность" предполагает регулярность. Практика скорее полезная, но эффективность зависит от многих факторов. Например, количества тех, с кем надо проводить, процессов в командах и твоем в них участии. А я не люблю делать то, что просто "общепринято", но пользы не несет или ее меньше, чем затрат хотя бы времени.  Ну или просто терпения не хватает дождаться реальной пользы. Чаще получаются не классические 1:1, а встречи по онбордингу новичков, обсуждению планов развития, беседы с ребятами, которые сами приходят с запросом. Моя "дверь" для такого всегда открыта и я всем постоянно и везде про это напоминаю. Тем не менее, всегда полезно иметь списочек вопросов, которые можно обсудить: 1.  Вопросы для первой встречи  2. Хорошая замена традиционного вопроса " How's everything going?" -> "What's one thing that could be bett...

 Про то, что менеджмент  - это не единственный путь развития :)

Последовал совету . Пусть это будет очередным отзывом, но точно не рассказом про концепцию"рок-звезд". Я нашел в книге ответы на те вопросы-сомнения, что вертелись в голове практически с того момента, как я стал менеджером. Или может быть даже не ответы, а подкрепление верности своих действий, своего поведения или просто подтверждения факта, что "я не один такой". После прочтения статьи с Хабра первой мыслью, которая меня посетила была "а ведь вся эта история держится только на хороших менеджерах (лидерах?)".  Книга добавила ясности и деталей в эти размышления и позволила порефлексировать. Далеко не каждый менеджер может быть честным, откровенным и открытым. Это сложно. А нужно еще и своих сотрудников учить быть такими. И, что немаловажно, эти все понятия и принципы тесно связаны и хорошо работают именно в комплексе и в обоюдном применении. В итоге, если менеджер говно не справляется, то с его сотрудниками будет ровно то, про что писали в комментах к Ха...

Навеяно тредом под вопросом Charity Majors , своими собеседованиями и собеседованиями меня :) Может кто найдет что-нибудь интересного себе. Кстати, многие из этих вопросов можно задавать нанимающему менеджеру. Disclaimer: Порядка, приоритета в вопросах ниже нет.  Необходимость и момент их вопрошания зависит от течения беседы.  На полноту и ценность для вас список определенно не претендует. Этот список не значит, что на собеседовании со мной вы услышите именно эти вопросы. 1. Что мотивирует людей вообще (немного теории, а-ля Маслоу, Герцберг, RAMP и тдтп в том числе просто "своими словами"). Что мотивирует вас? Ну и дальше про то, как использовалось в работе. Как работали с так называемыми "underperformance" товарищами? 2. Лидерство vs "быть начальником" - что это для вас? Как вы определяете лидерство? 3. Карьерный рост для разработчиков в ваших командах. Как они растут? Что для вас этот рост, что вы думаете о грейдах (уровнях)? Какой процесс оценки уровня...

Черновик с набором ссылочек долго мариновался и вот дождался потребности в себе.  Пусть теперь лежит публично. История началась год назад (твою ж дивизию, вот я торопыга...) с обсуждения в комментах того, что это за роль/должность такая "тимлид". Пересказывать обсуждение тут смысла не вижу, кому интересно - велком в тред. Спустя год тема получила свое продолжение в твиттере Никиты Макарова лайкни оригинальный твит Я думал описать свое видение этой роли, но кому это может быть интересно: жизнь не черно-белая, у всех разные ситуации, забил короче. А вот полезных ресурсов чуток накопилось, поэтому пусть нанесут пользу кому-нибудь. Но какой либо системности просьба не ожидать. Disclamer : если вы только рассматриваете для себя роль лида, технического менеджера и тп, подумайте, оно вам действительно надо, обратно пути может не быть. Ну и опять же, я б учитывал такой забавный момент: лайкни оригинальный твит Ну, если не передумали, то начнем. А начинать я бы рекомендовал с этой кн...

На самом деле про попытку отказа от менеджеров я узнал раскручивая попавшуюся на глаза историю про проект Oxygen . История на самом деле давняя, берет свое начало аж в 2002 году . Лари Пейдж и Сергей Брин решили, что менеджеры только мешают быстрой разработке, и решили их попробовать без них. Эксперимент закончился через несколько месяцев: число страждущих порешать проблемы напрямую через Пейджа (а другого способа не было) превысило его пропускную способность :) В итоге менеджеров вернули, потому что они все-таки приносили пользу: помощь в приоритезации проектов, фасилитации взаимодействия, поддержка в карьере сотрудников и направление процессов и систем в соответствии с целями компании. Но вопрос в том, как понять, какой менеджер полезен, а какой так себе. В 2009 (по другим источникам в 2008) Google запустил проект Oxygen, целью которого стал ответ на вопросы "Зачем нужны менеджеры и какие". Вылилось это в исследование с анализом работы более 10000 менеджеров по 100 п...

1.    Sharing Our Engineering Ladder "Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve." "In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring." Я уверен, приведенные в ссылках характеристики коими должен обладать разработчик и менеджер на разных позициях в своей карьере, будут полезными многим. 2.   If Your Boss Could Do Your Job, You’re More Likely to ...

Белая кобра Тхунтх из мультика "Маугли" Часто в работе менеджера-бывшего программиста возникают случаи, когда есть срочная задача, а решать ее некому. Возникает ощущение, что "бывших не бывает", закатываешь рукава и вперед. К сожалению, случается и так, что эта "вкусняшка" не поддается усталым челюстям и решить ее можно только "покунав" не в одну чашку чая-кофе. Самое неприятное - это когда ты даже после N-чашек не можешь справиться с задачей, "потому что кобра настолько стара и дряхла, что у нее уже не осталось ядовитых зубов". Можно по-разному к этому относится, но это факт. Но приятно, когда к задаче приступает программист, и спокойно ее решает. В эти моменты я забываю, что сам разгрызть "вкусняшку" не смог (про себя стараюсь ответить на вопрос "почему-что делать-как дальше жить-как дошел до жизни такой"), и радуюсь. А есть ведь еще задачи, к которым ты даже подойти то не знаешь с какой стороны, а кома...

В посылке, полученной от издательства "Манн, Иванов и Фербер" для участников IT Global Meetup 6 , была интересная книжечка " Искусство войны в иллюстрациях ". Не удержался и, воспользовавшись "служебным положением", полистал ее. Очень забавная книжечка. Давно хотел почитать "Искусство войны", но каждый раз заканчивал на первых страницах. Тяжело давалась восточная мудрость. Даже скорее не сама по себе военная мудрость, а ее трансляция в обычную жизнь. Тут же перед нами оригинальная попытка перевести витиеватые восточные фразы, да еще и на военную тематику, на современный язык графическим способом. В итоге получился сборник советов для менеджеров, тех кто планирует ими стать и сочувствующих :) На самом деле, есть даже советы и просто для жизни. Понятно, что этот "перевод" скорее всего субъективен, но большей частью получилось очень изящно. Рекомендую и вам посмотреть, хотя бы в книжном магазине полистать :) Ниже несколько цепа...

По наводке Леши Пименова прочитал эту книжку . Общее резюме (сразу в начале): книга ОБЯЗАТЕЛЬНА к прочтению менеджерами-новичками и теми, кто хочет ими стать. Разработчикам-технарям тоже будет полезна (разработка - это командная работа) - надо выйти за рамки IDE и посмотреть на свою работу с другой стороны. Те менеджеры, которые отработали уже от ~5 лет и выше, скорее всего, набили все шишки и к решениям из книги пришли самостоятельно. Они им или уже следуют, или идут своим "уникальным" путем. Таким эта книжка покажется "попсовой": одни, правильные, менеджеры найдут там мало нового, другие, эээ "уникальные", менеджеры советам скорее всего не внемлют. Мои заметки на полях (возможно сумбурно) . Разработка - командная работа.  Строится на 3-х китах: Скромность, Уважение, Доверие. Работа в команде без общения - нонсенс. Надо уметь правильно коммуницировать. Сихнронные vs Асинхронные коммуникации. Про лидерство в команде Вредные советы - чег...

Как то, стоя в пробке, задал себе вопрос "что надо знать и уметь" и вот что получилось в ответах. Список 100% неполный, но это первое, что пришло в голову :) Найти правильных людей Дать им цель Не мешать или не допекать излишним вниманием Уметь и иметь желание играть в игру "одна голова хорошо, а две лучше" - по запросу от команды Уметь слушать Обучать команду и себя Получать удовольствие от работы и от команды (в первоначальном варианте называлось "профит") Что еще добавить? Убрать? Из комментов понравился вариант "Знать ответ на вопрос 'Когда будет готово?' " :) А тут правильный список от Google .

Конспект книги " Общаться с ребенком. Как? ". Прочитал по совету Леши Авдея, который он дал на конференции "План Б" . На первый взгляд, непонятно как эта книга вписывается в формат тематики блога. Но, если вы внимательно прочитаете ее и вникните в рекомендации (скорее это даже правила), то вы найдете их работающими не только в области воспитания и общения с детьми. Просто замените слово "ребенок" на "сотрудник" ("подчиненный" плохое слово) и большинство правил отлично подходит Ну а если у вас есть дети, то после прочтения книги вы посмотрите на себя (вернее на вашу манеру общения с детьми) совсем с другой стороны. Очень рекомендую, не пожалеете :) Ниже будет много прямых цитат. Итак правила : Не вмешивайтесь в дело, которым занят ребенок, если он не просит помощи. Если ребенку трудно и он готов принять вашу помощь, обязательно помогите ему. Правило "зоны ближайшего развития". Фактически, это список дел которые ре...