Роль тимлида в корпорации — это (относительная) стабильность. Можно быть уверенным, что через месяц руководство не растворится в тумане вместе с деньгами инвесторов, оставив вашу фотографию украшать сайт скандально обанкротившегося стартапа. Вы попадаете в респектабельную компанию с понятным продуктом и прозрачными условиями по ТК РФ. Но не стоит ждать, что вы окажетесь в сказке.
Александр Поломодов, руководитель разработки в управлении привлечением в Tinkoff.ru, продолжает срывать покровы с граблей, которые могут ждать тимлида на новом рабочем месте. В прошлой статье он рассказывал о работе в стартапах; сегодня речь про боли тимлидов в большой компании. Что делать, если компания работает, как в прошлом веке, о чем спрашивать на собеседовании, чтобы на работе не было мучительно больно, как (и стоит ли) бороться с ригидной оргструктурой — обо всем этом под катом.
Естественное желание тимлида — быть на переднем крае технологий, получать новый опыт, работать в среде, которая способствует развитию. В большой компании все эти ожидания могут разбиться об устоявшуюся годами корпоративную структуру. Продукт – дойная корова, которая приносит стабильный доход, перемен никто не хочет.
Особенно много людей, будто застывших в патоке, скапливается в enterprise. Они работают как в бюджетной организации, от зарплаты до зарплаты, и о динамике стартапа здесь нечего и мечтать.
Решение. Осознать, принять и полюбить. Другого выхода по большому счету нет. В стартапе многие процессы можно подстроить под себя, но в крупной компании это проблематично.
Чтобы положение дел внутри не стало сюрпризом, стоит заранее выяснить, на что вы подписываетесь. Если задавать правильные вопросы, необходимое расскажут еще на собеседовании.
Спросите, новая это позиция или замена, и как она образовалась. Дальше узнайте у будущих коллег, какие задачи и с помощью какого стека технологий они решают. Поинтересуйтесь, почему из всех доступных альтернатив выбрали именно эту: потому, что этот стек оптимален для решения задач, или потому, что руководство сказало, а команда молча терпит, но по ночам плачет в подушку. Спросите, есть ли элемент творческой свободы в разработке, или нужно делать все строго по инструкции, которую спустил сверху условный enterprise-архитектор.
Это ключевые вопросы, которые помогут понять, в каком году живет команда и насколько она свободна в принятии решений.
Попав в организацию, тимлид начинает работать в одном ритме со всеми над большим продуктом. На горизонте маячит крупный релиз, и тимлид вкалывает, как гребец на галере, а разносящийся над палубой барабанный бой все быстрее. Только выбиваешься из ритма, а коллеги уже косо посматривают.
Такая культура формируется со временем. После пары жестких переработок большинство перформящих сотрудников решают, что справились слишком большой ценой, и уходят туда, где они смогут наладить work-life balance и не быть белыми воронами. Остаются только самые увлекающиеся натуры, и когда таких в команде большинство, давление со стороны команды многократно усиливает эффект.
Такая культура осложняет жизнь сразу по двум направлениям. Во-первых, очень легко выгореть самому. Во-вторых, велика вероятность, что один за другим перегорят сотрудники — как раз из тех, кто больше всего склонен увлекаться.
Тимлид предлагает такому спецу взять отпуск, а он отвечает, что еще месяц поработает, фичу допилит и там отдохнет. Месяц проходит, фича закрыта, лицо разработчика приобретает отчетливо зеленый цвет, но подъехала новая интересная задача, и взять паузу он никак не может: «скоро Новый год, на праздники куда-нибудь съезжу». Пятого января выясняется, что он и из офиса-то, наверное, не выходил: «наконец-то никто не мешает, можно сделать все, что хотел».
Смотрит на это тимлид и думает: «Я трудоголик, он трудоголик. Чем я могу ему помочь? Я сделал, что мог». Невозможно насильно заставить отдыхать взрослого человека.
Решение. Составить примерное представление о том, ждут ли вас вирусные переработки, можно еще на собеседовании.Стоит спросить, как выставляются дедлайны, есть ли внешние коммиты. Например, если к выходу новой фичи планируется рекламная кампания на федеральном ТВ, временные слоты выкупаются заранее, и вариантов просто нет — релиз должен состояться до старта кампании. Хорошо бы понять, кто составляет план релизов: один Product Owner, с которым можно найти общий язык, или пара десятков человек (тогда дело плохо). Важно также, кто оценивает сроки — продакт или команда.
Если вы закрыли глаза на все красные флажки и уже пришли в компанию, где ненормированный рабочий день стал вариантом нормы — учтите, серебряной пули для таких случаев не существует.
Тимлиду нужно научиться чувствовать команду и сообщать наверх, как долго они смогут работать в форсированном режиме: например «неделю перед релизом мы готовы, но полгода — извините, нет».
Только в квантовой физике частица и античастица могут появиться, а потом схлопнуться и бесследно исчезнуть. Задачи и сроки на их выполнение не берутся из вакуума. Всегда есть люди, которые отвечают за дальнейшие планы. С ними важно найти общий язык и научиться работать.
У хороших Product Owner’ов все фичи приоритизированы, разбиты по категориям. Они умеют жонглировать сроками, а значит, могут смягчить многие дедлайны. Это не значит, что все хотелки бизнеса попадают в спринты, а значит, что туда попадают задачи, которые отвечают интересам бизнеса и которые можно реализовать существующей командой. «Product Owner здорового человека» делает бутылочным горлышком себя и сам выдерживает объем хотелок, попадающих в разработку, а «Product Owner курильщика» вместе с пользователями создает дополнительное давление на тимлида и делает его горлышком на отсечение всего лишнего.
Также важно, чтобы у команды был способ коллективно расслабиться. Не хотите отдыхать поодиночке — значит, будете вместе. Во время совместного похода в бар тимлид может снять фидбек — понять, кто из сотрудников насколько загружен, у кого какие боли.
В матричной структуре управления часто происходят потери эффективности на границах между подразделениями и отделами. Это случается, даже если используются современные методологии, а рабочие процессы дебюрократизированы.
Типичный кейс. Если для проекта требуется сотня программистов, кадровый вопрос решается расширением числа используемых языков. В теории монолитный продукт распадается на отдельные сервисы, которые будут общаться через API. Если заранее не разделить архитектуру этой системы на логические части, то над каждым компонентом будут работать люди из обеих команд, и результат на выходе получится, как на гравюрах с мифическими животными: тело зайца, рога оленя. Работать и развиваться продукт, соответственно, тоже будет медленнее, чем мог бы при соблюдении единства технологий или грамотном планировании архитектуры.
Может случиться и так, что над сервисом работали четыре отдела, ваша команда со своей частью отлично справилась, а продукт не взлетел и проект свернули. Скорее всего, вас виноватым не назначат, но от этого не легче: вы-то всей командой год корпели над этой работой, вкладывались и надеялись, что бизнес-задача будет решена, а теперь все эти усилия пошли прахом.
Решение. Бороться с системой бессмысленно — используйте ее. Но, эскалируя проблему наверх, не рассчитывайте, что там сразу вас услышат.
Прежде чем что-то предлагать, разберитесь если у компании глобальная цель привести текущую ситуацию в порядок. Не номинально, а реально, вкладываясь в это в том числе ресурсами компании.
Если такое желание есть, то определите, кто вам сможет помочь в этом внутри компании, какие ресурсы будут выделены на это и какого уровня качества продукта и процессов люди хотят достигнуть. Вам придется разобраться в архитектуре целевой системы и в структуре компании, в том, как они стыкуются и что мешает им функционировать как единое целое.
В этом поможет изучение лучших практик. Из докладов по тестированию и инфраструктуре несложно понять, как работают в Google, Amazon и Netflix. В их подходах нет ничего сверхъестественно сложного, их можно применять у себя.
Затем можно обратиться к техническому руководителю бизнес-направления, только не с планом кардинальной перестройки процессов, а с чем-нибудь сравнительно простым: «Сейчас, когда мы не синхронизированы, мы как лебедь, рак и щука — никуда не движемся. Пускай тестировщик, как прежде, отчитывается главному по QA, но задачи получает от команды API, интегрируется в нее. Это поможет нормально автоматизировать тестирование, чаще релизиться и сократить time to market».
Продавая такие идеи, наращивая кроссфункциональность команды, сетапя людей и показывая на практике, что это работает, зарабатываешь карму и репутацию, чтобы постепенно, шаг за шагом, преобразовывать корпоративную культуру.
Поначалу работа в большой компании напоминает сизифов труд, но упорство приносит результаты, и однажды тимлид получает левел ап: «Отлично получается! Давай масштабировать твой опыт. Найди себе зама, собери вторую команду, и будешь тимлидом у тимлидов». Но это уже другой уровень, другие проблемы и другая история.
Александр Поломодов будет выступать на Тeamlead Meetup в Digital October 1 марта. На повестке митапа — оценка и мотивация сотрудников, будут спикеры из Tinkoff, AGIMA, CSSSR и Digital HR. Александр расскажет, как нанимают и мотивируют сотрудников в привлечении Tinkoff.ru. А еще Александр — куратор интенсива Teamlead Weekend; ближайший курс пройдет 23-24 марта.
Александр Поломодов, руководитель разработки в управлении привлечением в Tinkoff.ru, продолжает срывать покровы с граблей, которые могут ждать тимлида на новом рабочем месте. В прошлой статье он рассказывал о работе в стартапах; сегодня речь про боли тимлидов в большой компании. Что делать, если компания работает, как в прошлом веке, о чем спрашивать на собеседовании, чтобы на работе не было мучительно больно, как (и стоит ли) бороться с ригидной оргструктурой — обо всем этом под катом.
1. Скука смертная, а всем норм
Естественное желание тимлида — быть на переднем крае технологий, получать новый опыт, работать в среде, которая способствует развитию. В большой компании все эти ожидания могут разбиться об устоявшуюся годами корпоративную структуру. Продукт – дойная корова, которая приносит стабильный доход, перемен никто не хочет.
Особенно много людей, будто застывших в патоке, скапливается в enterprise. Они работают как в бюджетной организации, от зарплаты до зарплаты, и о динамике стартапа здесь нечего и мечтать.
Характерная фраза: «Зачем эти эксперименты? Деньги и без них текут».Еще один негативный сценарий — будто оказаться в команде релятивистского звездолета. На дворе 2019-й, а здесь используют waterfall без итераций и знать не знают о современных методиках разработки ПО, возможности создания CI/CD конвейера и автоматизации тестирования. Вам выделили сферу ответственности, но реализовывать ваши идеи и менять устоявшиеся практики никто не собирается. Для того, чтобы сломать традиции, вашего авторитета не хватает.
Решение. Осознать, принять и полюбить. Другого выхода по большому счету нет. В стартапе многие процессы можно подстроить под себя, но в крупной компании это проблематично.
Чтобы положение дел внутри не стало сюрпризом, стоит заранее выяснить, на что вы подписываетесь. Если задавать правильные вопросы, необходимое расскажут еще на собеседовании.
Спросите, новая это позиция или замена, и как она образовалась. Дальше узнайте у будущих коллег, какие задачи и с помощью какого стека технологий они решают. Поинтересуйтесь, почему из всех доступных альтернатив выбрали именно эту: потому, что этот стек оптимален для решения задач, или потому, что руководство сказало, а команда молча терпит, но по ночам плачет в подушку. Спросите, есть ли элемент творческой свободы в разработке, или нужно делать все строго по инструкции, которую спустил сверху условный enterprise-архитектор.
Это ключевые вопросы, которые помогут понять, в каком году живет команда и насколько она свободна в принятии решений.
2. Кранчи, кранчи, кранчи
Попав в организацию, тимлид начинает работать в одном ритме со всеми над большим продуктом. На горизонте маячит крупный релиз, и тимлид вкалывает, как гребец на галере, а разносящийся над палубой барабанный бой все быстрее. Только выбиваешься из ритма, а коллеги уже косо посматривают.
Характерная фраза: «Пришел в десять утра, ушел в десять вечера. Что-то он отрывается от коллектива — тестировщики-то на всю ночь остались».Типичный кейс. Актуальная история из игровой индустрии. Rockstar Games всегда специализировалась на AAA-играх и разрывала чарты. И вот рок-звезды решили приоткрыть внутреннюю кухню и оказалось, что работать по 18 часов там в порядке вещей. И вроде как никто даже не жалуется, но со стороны условия труда выглядят дико.
Такая культура формируется со временем. После пары жестких переработок большинство перформящих сотрудников решают, что справились слишком большой ценой, и уходят туда, где они смогут наладить work-life balance и не быть белыми воронами. Остаются только самые увлекающиеся натуры, и когда таких в команде большинство, давление со стороны команды многократно усиливает эффект.
Такая культура осложняет жизнь сразу по двум направлениям. Во-первых, очень легко выгореть самому. Во-вторых, велика вероятность, что один за другим перегорят сотрудники — как раз из тех, кто больше всего склонен увлекаться.
Тимлид предлагает такому спецу взять отпуск, а он отвечает, что еще месяц поработает, фичу допилит и там отдохнет. Месяц проходит, фича закрыта, лицо разработчика приобретает отчетливо зеленый цвет, но подъехала новая интересная задача, и взять паузу он никак не может: «скоро Новый год, на праздники куда-нибудь съезжу». Пятого января выясняется, что он и из офиса-то, наверное, не выходил: «наконец-то никто не мешает, можно сделать все, что хотел».
Смотрит на это тимлид и думает: «Я трудоголик, он трудоголик. Чем я могу ему помочь? Я сделал, что мог». Невозможно насильно заставить отдыхать взрослого человека.
Решение. Составить примерное представление о том, ждут ли вас вирусные переработки, можно еще на собеседовании.Стоит спросить, как выставляются дедлайны, есть ли внешние коммиты. Например, если к выходу новой фичи планируется рекламная кампания на федеральном ТВ, временные слоты выкупаются заранее, и вариантов просто нет — релиз должен состояться до старта кампании. Хорошо бы понять, кто составляет план релизов: один Product Owner, с которым можно найти общий язык, или пара десятков человек (тогда дело плохо). Важно также, кто оценивает сроки — продакт или команда.
Если вы закрыли глаза на все красные флажки и уже пришли в компанию, где ненормированный рабочий день стал вариантом нормы — учтите, серебряной пули для таких случаев не существует.
Тимлиду нужно научиться чувствовать команду и сообщать наверх, как долго они смогут работать в форсированном режиме: например «неделю перед релизом мы готовы, но полгода — извините, нет».
Только в квантовой физике частица и античастица могут появиться, а потом схлопнуться и бесследно исчезнуть. Задачи и сроки на их выполнение не берутся из вакуума. Всегда есть люди, которые отвечают за дальнейшие планы. С ними важно найти общий язык и научиться работать.
У хороших Product Owner’ов все фичи приоритизированы, разбиты по категориям. Они умеют жонглировать сроками, а значит, могут смягчить многие дедлайны. Это не значит, что все хотелки бизнеса попадают в спринты, а значит, что туда попадают задачи, которые отвечают интересам бизнеса и которые можно реализовать существующей командой. «Product Owner здорового человека» делает бутылочным горлышком себя и сам выдерживает объем хотелок, попадающих в разработку, а «Product Owner курильщика» вместе с пользователями создает дополнительное давление на тимлида и делает его горлышком на отсечение всего лишнего.
Также важно, чтобы у команды был способ коллективно расслабиться. Не хотите отдыхать поодиночке — значит, будете вместе. Во время совместного похода в бар тимлид может снять фидбек — понять, кто из сотрудников насколько загружен, у кого какие боли.
3. Достучаться до системы
В матричной структуре управления часто происходят потери эффективности на границах между подразделениями и отделами. Это случается, даже если используются современные методологии, а рабочие процессы дебюрократизированы.
Типичный кейс. Если для проекта требуется сотня программистов, кадровый вопрос решается расширением числа используемых языков. В теории монолитный продукт распадается на отдельные сервисы, которые будут общаться через API. Если заранее не разделить архитектуру этой системы на логические части, то над каждым компонентом будут работать люди из обеих команд, и результат на выходе получится, как на гравюрах с мифическими животными: тело зайца, рога оленя. Работать и развиваться продукт, соответственно, тоже будет медленнее, чем мог бы при соблюдении единства технологий или грамотном планировании архитектуры.
Характерная фраза: «Если три команды отвечают за разработку компилятора, то и компилятор будет трехпроходным».Сложность коммуникаций усугубляется сложной структурой подчинения. Например, тестировщик приписан к подразделению, автоматизирующему тестирование во всей компании.Фреймворк, написанный в этом подразделении, для конкретной команды и ее задач вообще не подходит, но хочешь не хочешь — приходится забивать шуруп молотком.
Может случиться и так, что над сервисом работали четыре отдела, ваша команда со своей частью отлично справилась, а продукт не взлетел и проект свернули. Скорее всего, вас виноватым не назначат, но от этого не легче: вы-то всей командой год корпели над этой работой, вкладывались и надеялись, что бизнес-задача будет решена, а теперь все эти усилия пошли прахом.
Решение. Бороться с системой бессмысленно — используйте ее. Но, эскалируя проблему наверх, не рассчитывайте, что там сразу вас услышат.
Прежде чем что-то предлагать, разберитесь если у компании глобальная цель привести текущую ситуацию в порядок. Не номинально, а реально, вкладываясь в это в том числе ресурсами компании.
Если такое желание есть, то определите, кто вам сможет помочь в этом внутри компании, какие ресурсы будут выделены на это и какого уровня качества продукта и процессов люди хотят достигнуть. Вам придется разобраться в архитектуре целевой системы и в структуре компании, в том, как они стыкуются и что мешает им функционировать как единое целое.
В этом поможет изучение лучших практик. Из докладов по тестированию и инфраструктуре несложно понять, как работают в Google, Amazon и Netflix. В их подходах нет ничего сверхъестественно сложного, их можно применять у себя.
Затем можно обратиться к техническому руководителю бизнес-направления, только не с планом кардинальной перестройки процессов, а с чем-нибудь сравнительно простым: «Сейчас, когда мы не синхронизированы, мы как лебедь, рак и щука — никуда не движемся. Пускай тестировщик, как прежде, отчитывается главному по QA, но задачи получает от команды API, интегрируется в нее. Это поможет нормально автоматизировать тестирование, чаще релизиться и сократить time to market».
Продавая такие идеи, наращивая кроссфункциональность команды, сетапя людей и показывая на практике, что это работает, зарабатываешь карму и репутацию, чтобы постепенно, шаг за шагом, преобразовывать корпоративную культуру.
Поначалу работа в большой компании напоминает сизифов труд, но упорство приносит результаты, и однажды тимлид получает левел ап: «Отлично получается! Давай масштабировать твой опыт. Найди себе зама, собери вторую команду, и будешь тимлидом у тимлидов». Но это уже другой уровень, другие проблемы и другая история.
Александр Поломодов будет выступать на Тeamlead Meetup в Digital October 1 марта. На повестке митапа — оценка и мотивация сотрудников, будут спикеры из Tinkoff, AGIMA, CSSSR и Digital HR. Александр расскажет, как нанимают и мотивируют сотрудников в привлечении Tinkoff.ru. А еще Александр — куратор интенсива Teamlead Weekend; ближайший курс пройдет 23-24 марта.
