спасибо за ваше дополнение.

Я составил список вопросов без порядка и приоритета, о чем пишу прямо в первых параграфах.

Я также не заставляю никого использовать ни один, ни половину, ни все вопросы из этого списка.

Треть вопросов как минимум к коммерческому дир-ру (другие на них не ответят)

Скажите, на основе какой выборки статистической вы приходите к выводу, что «другие не ответят»?

Практически все СТО, с кем я беседовал за последние полгода (где-то человек 15-20), имели достаточно информации, чтобы ответить на все вопросы.

треть — снижают шанс пройти на следующий этап минимум наполовину

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

бывает, что вопрос «как вы относитесь к переработкам» задают собеседующие. Это чаще всего свидетельствует о том, что переработки-таки будут, ну или иногда бывают.

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

Ну а впрочем, каждому решать, какие вопросы задавать.

Почему вам не нравится эта идея?

Мне казалось, что стоит все условия «контракта» прояснить до его подписания. В том числе и риски.

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

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

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

А «сделает вид, что не знает» — ну тут можно и дальше поспрашивать.

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

После вступления в должность — безусловно :)

Я буду очень рад, если Вы поделитесь конкретными советами или покритикуете что-то предметно :)

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

Спасибо! Проще вот тут: www.youtube.com/watch?v=RevF1_cQ4Uc

Как всегда, мы упираемся в «Быстро, качественно, недорого — выбирайте любые два пункта».

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

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

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

и мы этот митап будем всесторонне развивать и улучшать :) Так что приходите :)

К счастью, не первый и не единственный, но раз контент интересный, буду продолжать писать :)

И вот уже более полугода живём без тимлида, вроде ничего.

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

Можете поподробнее рассказать что это за план такой?

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

У вас правда есть в этом необходимость? Что это даёт?

Да, раз в две недели для нас — оптимально. Одна из этих встреч будет посвящена всегда результатам ежемесячной оценки, вторая — разным другим темам. Реже не получается, чаще не имеет смысла :)
О нашей системе performance review очень хорошо рассказывал Алексей Рыбак на techleads meetup #2: https://youtu.be/f-Uf3TiZV2k (отдельно слайды https://www.slideshare.net/BadooDev/techleads-meetup-badoo?ref=https://habrahabr.ru/company/badoo/blog/323630/ )

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

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

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

Сам по себе рост численности команды не является позитивным результатом для бизнеса

Вы абсолютно правы. Рост численности команды — один из вариантов того, как можно справиться с увеличением нагрузки. Упомянул я его исключительно для того, чтобы показать retention.

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

Так и делаем :) У нас отчеты перед руководством совершенного иного формата, исключительно о результатах, имеющих измеримый business value.

Спасибо!

Наталью Зверёк http://bc-expert.ru/corporate/trainers/zverok/ очень и очень рекомендую, её тренинг за кратчайшее время открывает глаза на очень многое.

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

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

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

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

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

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

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

Я не знаю, как Вы определяете, какое редактирование проходит статья, если интересна «внутренняя кухня» подготовки статей — все довольно просто: автор пишет статью, корректор исправляет ошибки, заинтересованные коллеги комментируют/проясняют какие-то неочевидные моменты, и статья идет «в тираж». К сожалению, каких-то отдельных специалистов-маркетологов, которые помогали бы статью «адаптировать» к каким-то требованиям, у нас пока нет.

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

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