Late Night Teamlead Show

Присылайте новые ситуации на разбор! Напоминаем, что публикуем все анонимно) https://forms.gle/YPRNme4k6AQf4zcE8
Чат канала: https://t.me/lnts_chat

Что посоветуете автору вопроса?
anonymous poll

Честно поговорить с руководителем и отказаться – 61
62%

Не примыкать к проекту (и посматривать на вакансии) – 26
26%

Пилить проект, должно сработать – 7
7%

Другое (напишу в чат) – 5
5%

99 people voted so far.

@anatolyp Анатолий Панов

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

Если человек задаёт нам такой вопрос, значит он точно не уверен в правильности происходящего. Если нет уверенности, одобрил ли этот проект СТО или есть какие-то ещё вопросы по проекту, надо прямо про это спросить у своего руководителя.

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

@ashagraev Алексей Шаграев

Я думаю, что подпольная деятельность — это нехорошо, потому что она нарушает договоренности, порождает конфликты и недоверие.

Из описания неясно, одобрит ли CTO на старте создание прототипа.
Зато похоже на то, что вы создание прототипа с СТО вообще не обсуждали. Иначе не писали бы "он его наверняка не одобрит", а написали бы, что "он его не одобрил". Я думаю, что додумывать за людей — в принципе плохая практика, и рекомендовал бы всё-таки с ним поговорить.

Если в этой затее есть смысл и столько людей считают её разумной, то почему СТО должен ставить палки в колёса? Почти наверняка он тоже будет не против создания прототипа. Но договорённость с ним позволит сделать эту работу прозрачной и позволит сформировать его ожидания правильным образом: например — по вопросу о том, сколько сил мы готовы на это потратить. Аргументы уровня "ну нам прямо очень-очень хочется попробовать, разреши, ну позязязяя!!!11", кстати, тоже годятся. В конце концов, иногда начальники разрешают что-то сделать не потому что это разумно, а потому что это кому-то приятно : )

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

Мой опыт говорит о том, что прозрачность и честность — это хорошо и всем выгодно, а заговоры, секретность и скрытие информации — всем вредно.

@dmitry_semenihin Дмитрий Семенихин


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

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

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

@dumtest Роман Ивлиев

Если в компании такое происходит, стоит задуматься, а там ли ты работаешь. И закончится все наверняка плохо. Некоторые менеджеры думают, что «Когда кошку уже принёс домой — не выкинет же». Выкинет. Всех. И кошку, и тех, кто её принёс. Есть вероятность хорошего исхода, но мне удачные случаи такого поведения не встречались.

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

Потом нужно попробовать понять, насколько техническая стратегия важна для руководителя (можно просто спросить у коллег или у тех самых руководителей-заговорщиков). С чего вдруг он пошёл в отказ от проекта, который поддерживает столько людей? Если CTO не самодур — то я бы попробовал выяснить причины, наверняка они были. Если этой информации у заговорщиков нет — очень странно.

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

Ну а дальше попробовать взвесить:

а) интерес и перспективы проекта — принесут ли они лично тебе радость, удовольствие или новый опыт
б) насколько ты готов идти против большой части команды (“вы идите, я на шухере постою)
в) насколько, по ощущениям, получится быстро найти себе работу в случае чего
г) какие карьерные амбиции в этой компании (не всех отступников вешают, но и звёзды новые на погоны не выдают).

Но ещё раз — выглядит это стрёмно.

Ситуация №22: подпольный раскольный проект

«Я тимлид. Руководители разработки (мои прямые руководители) и разные другие руководители (операционные, CPO, аналитика, и т.д.) собрались в некий альянс и решили запустить "подпольный" проект.

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

CTO его 100% не одобрит, спалит эту движуху и надаёт по шапкам.

Вопрос:

Примыкать ли к подпольному проекту? Или активно противостоять ему? Как вообще можно действовать в таких ситуациях?»


Отвечают:
@dumtest Роман Ивлиев, CTO mos.ru
@dmitry_semenihin Дмитрий Семенихин, Engineering Manager, Badoo
@ashagraev Алексей Шаграев, ex-Yandex, Google
@anatolyp Анатолий Панов, руководитель разработки кластера Verticals, Авито

Присылайте новые ситуации на разбор! Напоминаем, что публикуем все анонимно) https://forms.gle/YPRNme4k6AQf4zcE8

Что вы делаете в такой ситуации?
anonymous poll

Зову на второе интервью с кем-то из коллег – 35
38%

Доверяю интуиции и не нанимаю – 32
35%

Нанимаю и проверяю человека в работе – 18
20%

Записываю риски и свои сомнения, а потом оцениваю – 4
4%

Другое (напишу в чат) – 3
3%

92 people voted so far.

@chernobay Денис Чернобай

Исходя из кейса, я бы сделал вывод что сомнения находятся скорее на уровне ощущений.

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

Бывает, что сомнения продиктованы недостатком информации по конкретным темам: в этом случае может помочь дополнительное интервью. Иногда видны какие-то сигналы, что человек может не справляться с работой в вашей конкретной культуре/компании — тут, опять же, может помочь еще одно интервью с моделированием ситуации, близкой к рабочей. Другой вариант для такой проверки, если позволяет время и возможности, — испытательный срок.

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

@ashagraev Алексей Шаграев

Не представляю себе, чтобы кто-то был «готов к культуре» незнакомой для себя компании сходу на 100%. Вопрос не в этом, а в том, сможет ли он адаптироваться. Можно либо попробовать ответить на этот вопрос непосредственно, либо просто обрисовать перед ним стоящую задачу (адаптацию) и возможные риски (не адаптируется — не пройдет срок) и спокойно нанимать, если ему ок. Еще есть вариант (и я к нему склоняюсь), что вы просто перезаморочились. Идеальных людей не бывает, а разнообразие культур и взглядов — залог здорового коллектива. 80% уверенности — это на самом деле очень много.

Соглашусь и с тем, что можно дать поговорить с кандидатом кому-нибудь ещё. По двум-трём точкам всяко надёжнее прогнозы строить.

@dkushnikov Дмитрий Кушников

Как обычно, Рома украл все мысли. Лучше не нанять двух подходящих, чем нанять одного неподходящего.

«Культура ест стратегию на завтрак» — говаривал Ицхак Адизес.

Поддерживаю, что лучший способ убедиться в unfit — попросить коллегу, с которым culture fit, провести интервью. Если в него будут такие же сомнения — я бы не нанимал.

@dumtest Роман Ивлиев

Однозначного ответа нет. Все очень зависит от позиции и ситуации к конторе/проекте. На такую должность, если она и правда очень важная для конторы, я бы не брал, особенно, если все такое динамичное. Слишком высокие риски. 20% — это много. Это значит, на самом деле, 50%.

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

Но я обычно не беру, если сомневаюсь.

Ситуация №21: нанимать или не нанимать?

«Привет всем! Я потратил 2 часа на собеседование на должность senior cloud architect с очень достойным кандидатом. Большой опыт, технически очень сильный, но... не могу сказать, что мы нашли контакт. В его поведении были черты, которые заставили усомниться, что он нам подходит. Мы — очень динамичная сервисная компания: архитекторам приходится перескакивать между задачами, очень разными клиентами и так далее. Это требует от всех согласованности по культуре, и я просто не совсем уверен, что кандидат подойдет. Я уверен на 80%.

Вопрос:

Понимаю, что это звучит глупо, и, конечно, со своим вопросом я разберусь. Но мне интересно, что вы делаете, когда уверены не на 100%? Как вы справляетесь с сомнениями после интервью? Нанимаете ли в таких случаях?»

Отвечают:
@dumtest Роман Ивлиев, CTO mos.ru
@dkushnikov Дмитрий Кушников, Head of Engineering, ManyChat
@ashagraev Алексей Шаграев
@chernobay Денис Чернобай, Senior Engineering Manager, Badoo

Как бы поступили в этой ситуации вы?
anonymous poll

Потребовали бы проработать предложение – 107
80%

Вынесли вопрос на обсуждение с командой – 16
12%

Отказали бы – 7
5%

Другое (расскажу в чате) – 3
2%

133 people voted so far.

@ashagraev Алексей Шаграев

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

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

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

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

@iamuyga Илья Агеев

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

Садимся вместе и считаем. Рассматриваем плюсы и минусы имеющегося подхода и предлагаемого. Показываем, что внедрение его решения затрагивает не только его и его отдел, но и других сотрудников тоже. Считаем грубо, прикидками, в формате «3 сотрудника получают 100К в месяц, тратят на внедрение Х человеко-часов и т.д.». Помогаем увидеть ситуацию шире и самому осознать риски.

На это уйдет очень много времени и менеджера и подчиненного. Это, по сути, процесс коучинга, и очень многое зависит от миллиона параметров: открытости и доступности информации (например, зарплаты других людей), способности коуча доносить свои мысли и вести мышление собеседника по нужному руслу, от аналитических способностей самого предлагающего и эмоциональной части его предложения (вследствие эмоциональной привлекательности ему будет трудно услышать рациональные аргументы) и т. д., и т. п. Процесс управления мыслями собеседника через наводящие вопросы — отдельное кунг-фу, далеко не каждый менеджер так умеет.

Поэтому я бы не заморачивался и просто сказал «нет».

@dumtest Роман Ивлиев

Я бы ответил те ми же словами: «При минимальных затратах на внедрение на фронте ее использование потребует существенного переписывания бэкенда, то есть затраты по внедрению на лягут не на плечи этого разработчика. Экспертизы в этой технологии в команде нет, подводные камни неизвестны». А к ним бы добавил: ввиду того, что экспертизы очень мало, то неплохо бы разобраться в преимуществах этой технологии перед той, что уже используется. Технологий тысячи, толковых — единицы. Вдруг эта технология не из списка этих единиц. Дальше я бы что-нибудь запилотил на моках не очень нужное с краю, чтобы, опять же, можно было показать личному составу все достоинства этой технологии, но не менять бэкенд. Следом попросил бы устроить демонстрацию возможностей, дал задание подсветить негативные стороны технологии в сравнении с той, что уже есть (они же у всех есть). По-хорошему, принимать решение должна команда, а не отдельный инженер, т. к. с этой технологией работать потом всем. Хочешь свободы в принятии решений — потрать силы на подтверждение своей гипотезы. Может быть, профит от фронтовой технологии будет такой, что переписывание бэка будет казаться маленькой неприятностью.

Мы в своё время так затягивали mobx. Взяли сотрудника на работу, он с порога объявил, что mobx — вышка, и все эти ваши redux’ы — отстой. Сразу не внедрили, дали сделать небольшой кусок, показали всем, рассказали про технологию, разрешили другим попробовать, убедились, что освоить быстро, явных косяков нет, и постепенно начали внедрять в новые проекты, где это было уместно. Но переписывать, конечно же, всё не стали. Если бы речь шла о том, что нужно менять бэкэнд очень сильно, — скорее всего, отказались бы. Либо сильно больше сил потратили на исследование.

Ситуация №20: “А давайте попробуем новую технологию?”

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

Решение очевидно — надо отказать в ее внедрении. Однако есть нюанс: мы предпочитаем давать разработчикам максимальную свободу в принятии решений и не любим что-то директивно запрещать.

Вопрос:

Как продать разработчику идею, что эта технология не нужна ни ему, ни команде, ни проекту?»

Отвечают:
@dumtest Роман Ивлиев, CTO mos.ru
@iamuyga Илья Агеев, Head Of Engineering (Core services) Badoo
@ashagraev Алексей Шаграев

Без этого вопроса предыдущие результаты будут неполными. Кто вы?
anonymous poll

Тимлид/менеджер – 117
45%

Разработчик – 47
18%

Техлид – 38
15%

Менеджер лидов/менеджеров – 34
13%

Другое – 22
9%

258 people voted so far.