Интро
К сожалению, большая часть работы тимлида скрыта от команды. И в зависимости от многочисленных факторов, таких как размер команды, выстроенные процессы, наличие других ролей, занимающихся работой с командой — она еще и невероятно размыта. Список твоих обязанностей в разных компаниях будет отличаться. Где-то это просто формальная должность человека, который просто перетаскивает задачи из одного статуса в другой в свободное время от написания кода, в другой — это полноценная роль, где придется отложить в сторону свою любимую IDE и заняться кучей других обязанностей. Кстати, очень часто эту роль совмещают с еще одной ролью, техлида, и далеко не всегда это плохо.
Но один момент не меняется — если ты стал тимлидом, в твоей жизни изменится многое, если этого не произошло, это первый знак, говорящий о том, что ты явно не справляешься со своими обязанностями (либо это звание носит сугубо формальный характер).
Если ты никогда раньше этим не занимался, тебе предстоит свой долгий и тернистый путь с огромным количеством разбросанных граблей, на которые тебе придется наткнуться и без поддержки команды, увы, этот путь преодолеть будет невозможно.
Так сложилось, что большинство людей, попадает на эту должность не по своей инициативе. Например бурный рост компании, ты человек, который неплохо пишет код, не зациклен на себе, довольно общительный и кому-то приходит в голову мысль, что ты можешь управлять командой. К этому нельзя быть готовым, потому, что как я уже упоминал вначале, большая часть работы тимлида скрыта от своей команды. Все те комфортные условия, в которых ты работал до этого — это результат отличной работы твоего тимлида, а узнать, что за этим скрыто придется именно тебе.
По началу тебя будет смущать одна маленькая деталь. Вероятнее всего ты будешь видеть все свои косяки (а их будет много), и иногда в тебе будет возникать дурацкое чувство, что ты один такой косячный, а все остальные, чьи статьи и книги ты читал, чьи доклады ты смотрел — делают свою работу идеально и косяков у них не возникает. Учти один факт, люди на этой должности не любят говорить о своих косяках, только достижения. Но, просто поверь, ты не один такой. Этот момент должен тебя успокоить. Так же как и то, что над своими косяками надо работать, надо делать все, чтобы избегать их в будущем.
На самом деле лиды не должны уметь фейлить, они должны уметь делегировать свои фейлы, как и все остальное (сарказм).
Что изменится
Самое главное, тебе предстоит общаться, общаться и еще немного общаться. Со своей командой, с другими командами, с другими лидами, с людьми, с которыми ты умеешь разговаривать на одном языке (по большей части техническом) и с людьми, с которыми тебе предстоит научиться говорить на одном языке — бизнес, менеджмент. Более того, тебе придется выстраивать эти каналы общения. И делать это так, чтобы они были эффективны. Думай всегда о том, что ситуация может измениться, и эффективность этих каналов будет меняться так же. Что приемлемо для команды из двух-трех человек может иметь разрушительных эффект на командах в которых гораздо больше людей.
Так же тебе придется очень много слушать и собирать фидбек. Записывай и анализируй, через тебя будет проходить огромный поток информации. Тебе придется понять как работает feedback loop и всеми возможными путями найти способ сократить эту петлю.
Ты должен стать ответственным, ты — самое ответственное звено в команде, даже если серьезно накосячит твой подчиненный, виноват будешь ты. Потому что ты допустил этот косяк. Но бойся попасть в ловушку гиперответственности, потому что это невероятно опасная вещь.
Ты должен стать тем самым интерфейсом, через который бизнес общается с командой разработки. Бизнесу плевать кто у тебя в команде какой задачей занимается, спрашивать будут с тебя. Общаться будут с тобой. И винить во всех косяках будут именно тебя.
Ты должен будешь защищать интересы своей команды и идти на компромиссы. Нет четкого описания как ты должен этого делать, потому что это слишком сложно. Подходы и выработанные принципы в одной команде (и компании) могут совершенно быть неприемлемыми в другой команде, что уж говорить про совершенно другую компанию.
Интересы твоей команды могут лежать в различных плоскостях — использование различных технологий, накопление технического долга, график работы, мелочи в процессах, куча отвлекающих факторов. Ты должен это все учитывать, чувствовать настрой команды и работать с ним. Большинство людей считают что надо брать все самое модное и новое, это интересно. Они могут видеть как страдает код, если они то и дело делают бизнес задачи. которые на них сыпятся со всех сторон, и так, что невозможно нормально построить архитектуру, это означает, что из за большого количества костылей, тех долга и отставания в технологиях, процесс программирования становится не таким интересным и захватывающим. Компромиссы начинают появляться именно тут.
Какие-то небольшие мелочи, например ограничения, могут являться бессмысленными, пока ты не объяснишь их смысл. А если ты объяснить их смысл не можешь (даже используя слово безопасность), то лучше от них избавится. Это бесполезная трата времени, нервов и еще один демотивирующий фактор для команды.
Ты научишься оценивать все, в деньгах, в часах, в рисках. Ты будешь оценивать все, потому что ты должен принимать огромное количество взвешенных решений, и ты должен уметь доказать почему ты принял именно это решение. Более того, некоторые из этих решений придется протаскивать силой. И умение правильно донести информацию почему это решение было принято — очень сильно облегчит тебе жизнь.
Ты должен будешь все контролировать, но это не означает, что ты должен будешь опуститься до уровня микроменджмента и проверять каждый шаг. Это не даст тебе расти и будет отнимать огромное количество времени и сил. В подавляющем количестве случаев ты должен быть в курсе того, что происходит и быстро найти способ, как взять все в свои руки.
Потому что в конечном итоге ты станешь единой точки ответственности и компетенции команды.
Тебе придется научиться договариваться. Ты будешь это делать постоянно. Договариваться с бизнесом, своими подчиненными, коллегами, другими командами и их лидами, ты будешь делать это постоянно.
Тебе придется быть хорошим, потому что ты будешь являться примером. Если косячит или забивает на свои обязанности лид — ты никогда не сможешь добиться от своей команды выполнения уже обозначенных договоренностей.
Ты должен быть непредвзят. С кем-то у тебя будут складываться хорошие и приятные взаимоотношения, с кем-то нет. И это совсем не значит, что есть хорошие и плохие ребята. Просто ты по разному будешь с ними взаимодействовать, и в рамках рабочих процессов выжимать из этого взаимодействия максимум.
Ты должен будешь научиться делегировать. И задачи, и ответственность. Это тебя разгрузит и позволит выполнять свои обязанности гораздо лучше. Более того, если ты не научишься делегировать, ты просто не справишься с ростом.
Для многих ты станешь ментором, ты будешь передавать им огромное количество опыта, наблюдать за их ростом. Когда ты начнешь это делать, то ты увидишь как изменятся ваши взаимоотношения, ты будешь видеть рост, на долгой дистанции это означает одно — ты будешь помогать человеку двигаться дальше, а он будет помогать двигаться дальше тебе, вы оба будете в плюсе.
Но иногда тебе придется наказывать людей, говорить им неприятные вещи, прощаться с ними. Это очень сложный опыт, это очень сложные ситуации (с эмоциональной точки зрения), но они случаются. Тебе придется этим заниматься, даже через силу.
Ты научишься разрешать споры и конфликты, ты научишься видеть ситуации, где они могут возникать и будешь прикладывать все усилия, чтобы разрешать эти ситуации еще до того, как они наступили. Ты постоянно этим будешь заниматься. Твоя цель, решение этих проблем на ранней стадии.
Два небольших примера из моей практики
В компании, где я работал, был фиксированный график, разработчики должны были приходить в 11 и уходить не раньше 8, но был один программист, который постоянно выхватывал от меня за то, что приходил на 10-20 минут позже (кстати, это тоже работа тимлида, дрочить людей за такие вещи) и всегда ныл на тему того, что далеко живет и не всегда может оценивать время потраченное на дорогу. На одном из таких общений, я понял, что это один из демотивирующих факторов для него и его это бесило — он хорошо работал, но опаздывал. Он даже думал искать работу, где был бы свободный график. Поэтому я потратил кучу своего времени и добился чтобы официально рабочий день для него начинался на полчаса позже, после этого, естественно все эти изменения были внесены с СКД и для этой системы он приходит раньше начала своего рабочего дня. Меня за него больше еженедельно не дрочила система, а я не дрочил его. Кстати, я не сообщил ему о том, что мы решили его проблему именно так. Я просто разрешил ему опаздывать не больше чем на полчаса. Он был счастлив.
Второй пример, в один момент я не уследил за другим своим подчиненным, у него всегда все было хорошо, ничего не напрягало, но в один момент он пришел ко мне с заявлением по собственному. Я был в шоке. Мы говорили с ним часа полтора. Оказалось, что все это время у него была куча вещей, которая демотивировала и поэтому он решил уволиться. Если бы он обозначал свои проблемы, то большую часть мы бы смогли решить без его увольнения, но увы, момент был упущен, парень был дичайше расстроен. После этого я изменил подход в общению с людьми у которых все хорошо, благо наш отдел HR очень неплохо умел общаться с ребятами, я частенько просил их узнать что и как происходит в жизни моего отдела. И, внезапно, люди открывались. Они не знали, будет ли эта информация донесена до меня. Они открывались совершенно другим людям и рассказывали про свои проблемы. Скажу так, это было одно из самых полезных изменений, которое дало мне огромный фидбек и понимание как работают люди.
В какой-то момент ты осознаешь, что общая ответственность не работает, это миф. Если все ответственны за все — никто ни за что не отвечает. Найдется сотня причин, почему никто в критической ситуации не вмешается и не исправит ее. Тебе придется научиться эту ответственность правильно делегировать.
В конечном итоге ты научишься оценивать риски, и научишься работать с ними, будешь задумываться о таких вещах, о которых ты раньше не знал ровным счетом ничего. Тут проще объяснить на примере: вы на следующей неделе начинаете с нуля разрабатывать какую-нибудь новую штуку, к тебе приходит пара твоих подчиненных и говорят — "А давай начнем это писать на котлине". В твоей голове начинают рождаются множество вопросов. Во-первых хватает ли у нас экспертизы для того, чтобы начать писать новую вещь (а она может быть очень критичной для бизнеса), на новом языке с недостаточной экспертизой команды.
А что мы будем делать, если через полгода эти ребята уволятся. Как и сколько времени мы будем искать новых людей, которые имеют необходимую экспертизу для дальнейшей разработки.
А не получится ли так, что на данном проекте мы увеличим bus factor, потому что все остальные ребята не хотят сейчас переходить на котлин, и не имеют экспертизы в нем.
А сколько дополнительного времени нам стоит заложить, потому что факапы будут, причем самое страшное, что мы не знаем какие именно. Но они будут.
А сможем ли мы с этими двумя ребятами сделать все правильно, в срок, обучив другую часть команды. Подхватят ли этот энтузиазм остальные.
А нужно ли это нам именно сейчас, когда все бегают с горящими жопами.
Поэтому тебе придется научиться говорить “нет” и объяснять почему нет. Иногда ты должен будешь зарубить инициативу на корню. Любая инициатива должна поддерживаться сверху, иначе она заглохнет или принесет только проблемы. Не важно, какие поступают предложения — сменить марку кофе, заказываемую в офис, или устаревшую технологию, выбрать новый модный фреймворк или язык программирования. Если предложение неуместно на данный момент и ты можешь объяснить почему, или, как иногда бывает, оно совершенно идиотское, то об этом надо сказать сразу же, без всяких «Мы подумаем», «Необходимо будет обсудить» или «Может быть». И уж тем более без слов: «Бери флаг в руки, а мы подхватим, но чуточку позже, например через месяц».
Всем, кроме данного сотрудника, будет понятно, что ничего не изменится, а когда это станет понятно и ему, то осознание этого может очень сильно подкосить его инициативу. Более того, он будет считать, что его предали. Многие долгое время отказываются делать следующий шаг — предлагать что-либо еще, даже если заранее уверены в успехе. Боятся повторения истории.
Лучше сразу решительно сказать: «Нет, этого не будет никогда» или «Извини, но в данный момент это предложение не уместно, но мы можем попробовать поговорить об этом через 3-6-12 месяцев», (понятно, что, скорее всего, никто не будет возвращаться к этому разговору), чем позволить человеку погрузиться в мир иллюзий, возвращение из которого крайне болезненно. При возвращении в реальный мир, у сотрудника возникают вопросы — «Ценен ли я», «Могу ли я что-нибудь изменить». Это первый шаг к смене работы.
Ты будешь всегда помнить про незаменимых людей и снижение bus factor. Будет очень неприятно, если единственный человек, который знает про какую-то часть кода решит уволится или поедет в отпуск. Это один из рисков. А если человек, который делает критически важные задачи за неделю до релиза собирается в долгожданный отпуск. Тут метод договорится пойти в отпуск после релиза уже не работает.
Ты должен стать прозрачным, как для команды, так и для бизнеса. Прозрачность в выборе технологий, людей, решений. Прозрачность означает, что ты можешь объяснить, доходчиво, почему именно так даже маленькому котенку.
Ты поймешь, что всю твою работу можно разделить на три части: инструменты, подходы и люди. Люди пользуются инструментами в контексте подходов и в зависимости от множества факторов эти подходы могут меняться, могут меняться и люди, но чаще всего будут меняться именно подходы. Подходы в команде из трех человек и 10 — уже не имеют ничего общего.
Ты поймешь, что иногда тебе придется поменять один инструмент на другой, кардинально изменить подход или человека. Но ты должен будешь четко понимать почему это произошло, чтобы объяснить всем. Ты должен это будешь донести эти изменения до всех.
Это даст тебе понимание, что нельзя сходу ворваться и один раз на века выстроить рабочий процесс. Что процесс очень сильно зависит от этих трех частей и над ним придется работать постоянно. Выстраивание процесса разработки — это методичная работа, которая должна проводится тобой все время.
В какой-то момент, ты узнаешь, что все изменения следует мониторить, по ним следует собирать фидбек, как они повлияли, были ли изменения позитивными, может стоит вернутся на пару шагов назад и попробовать что-то другое? Потому что оно не работает. Конкретно для тебя и твоей команды.
Ты станешь гораздо лучше понимать как работаешь ты сам и как работают другие люди, если до этого у тебя была частичная картина, которая формировалась исходя из того, что нравится тебе, как ты себя ощущаешь, то сейчас твоя картина мира дополнится ребятами из твоей команды.
Ты поймешь, что далеко не всегда стоит использовать стиль соковыжималки, люди не могут долгое время работать на пределе своих возможностей. В большинстве компаний замена выгоревших сотрудников — очень дорогостоящий процесс. Просто дай работать своей команде достаточно эффективно. Как минимум у тебя всегда будет запас, на короткий период времени.
Ты научишься мотивировать людей. Ты поймешь, что мотивация у каждого своя. Да, все работают за деньги, но не все работают пропорционально тем деньгам, которые они получают. Поэтому найти те вещи, которые мотивируют твоих ребят, и используй это.
Люди — не бездушные машины, которые выполняют свою работу. У них случаются проблемы, их жизнь меняется, они становятся опытнее, исходя из этого меняются и вещи, которые их мотивируют, или, наоборот, демотивируют. Меняется их перфоманс, меняются их отношение к самим себе, к другим людям в команде.
Поэтому в какой-то момент ты начнешь создавать теплоту и уют в команде. Или найдешь человека, кто готов будет этим заниматься. Иногда чертовски важно бывает, когда коллеги, с которыми ты проводишь время становятся чуть больше чем соседи по офису. В критические ситуации поддержка этих людей может быть невероятно ценна. Тебе когда-нибудь придется столкнутся и с этим.
И с этого момента люди начнут тебе доверять, они не будут считать тебя начальником, они начнуть тебя считать лидером, и смогут дать необходимый фидбек, который очень тяжело собрать другим путем. Они откроются тебе. Кто-то часто ходит по вечерам в паб посидеть с пивом (алкоголь слегка развязывает язык), кто-то находит общие увлечения и может делится своим взглядом. Но пока люди тебе не доверяют, они тебе будут доносить очень мало информации и только ту, которую они посчитают безопасной для себя. Кстати в жизни это работает абсолютно так же.
В какой-то момент ты многое узнаешь о документации, какая она бывает, какая вам нужна, что следует документировать, а что — нет. И да, тебе придется доносить эти знания до твоих ребят. Потому что ты не хочешь тратить свое время на наступание на кучу граблей в темной комнате, потому что никто не написал, что прежде чем войти в нее, следует включить свет. Кстати, тест кейсы — это отличный пример документации.
Кстати, тебе все еще придется быть технически грамотным и более того, начать интересоваться, хоть немного, смежными областями. У тебя в команде могут быть ребята, которые не только пишут код на твоем любимом языке. Как минимум тебе это потребуется, если ты проводить ревью кода в твоей команде — это одна из твоих обязанностей.
И еще ты можешь быть, неявно, и тех лидом, просто потому что для большинства людей, ты самый лучший в команде (на самом деле это далеко не всегда так), поэтому все, что связано с технологиями так же будет на тебе. Выбор технологического стека, инструментов.
Будь готов к тому, что иногда тебе придется рассказывать людям о тех вещах, которые ты сам терпеть не можешь, и следить за их выполнением. Например контролировать время прихода и ухода. Или особые правила в компании.
Ты будешь заниматься подбором людей в свою команду, и это отдельная глобальная тема. Ты начнешь с того, что вспомнишь как проходили твои собеседования, будешь пытаться скопировать стиль. Это даст тебе практически нулевое понимание происходящей ситуации. Потому что большинство твоих собеседований было проведено также не совсем опытными людьми, которые тебя спрашивали как запускать ракеты в космос, а на деле ты json гоняешь из базы в браузер.
Поэтому с опытом, ты узнаешь что, первое —нельзя оценить насколько человек будет хорошо работать конкретно в твоей команде и твоих условиях. Ты можешь только понять о нем некоторые факты, примерно оценить его возможности, отношения к используемым технологиям, его интересы и подходит ли он тебе личностно. Остальное, увы, во время работы. И как хорошо, что люди не роботы и умеют отличную способность адаптироваться ко многим вещам.
Второе — ты перестанешь спрашивать людей о том, с чем человеку не придется сталкиваться никогда, пока он работает совместно с тобой. Ты будешь оценивать техническую грамотность достаточную для твоей команды, будешь понимать мотивацию человека, что ему нужно. Подходит ли этот человек конкретно тебе. Будет ли тебе с ним комфортно и наоборот. И из этого делать свой выбор. Уровень человек должен соответствовать уровню продукта.
Третье, нельзя выбирать самых лучших людей на рынке, активных, пробивных, горячих, они могут быть в команде, но если вся команда состоит из них — будет очень сложно. Они же все передерутся между собой. Поэтому ты будешь четко понимать кто тебе нужен, насколько он вписывается в твою команду. Набирать топовых людей, которые будут апишку делать для перегонки json-а из базы в браузер глупая идея, им будет скучно и в итоге ты потеряешь уйму времени, тоже самое и с нехваткой опыта.
И четвертое, самое главное — сомневаешься в выборе, не бери. Ты никогда не должен сомневаться. Любые сомнения должны конвертироваться в четкое "нет". Этот совет сохранит тебе кучу времени и нервов.
Очень часто ты будешь заниматься не своей работой, потому что ты — главный в команде, кому это еще поручить. Тебя будут готовы познакомить со многими финансовыми аспектами работы твоей команды,. Это только кажется, что очень просто, например распилить премию выданную на команду, по всем ребятам (один из примеров). До первого раза. Так же ты будешь писать кучу унылых отчетов и общаться о своей команде с людьми, кто твою команду даже по именам не знает, и так же отстаивать интересы этих людей. Совещания. Созвоны. Митинги. Презентации. Собеседования. И много других увлекательных и отнимающих у тебя время и силы активностей.
Готовься к тому, что ты будешь затыкать собой дыры, если где-то есть проблема, то ты будешь посреди нее и руководить процессом.
И да, иногда ты будешь писать код. Если у тебя будет хватать времени на это. А иногда ты будешь это делать, даже если времени у тебя не хватает.
Если кратко
Все очень субъективно и границы твоей зоны ответственности размыты и зависят от множества факторов: количество твоих подчиненных и их опыт, от этого зависит сколько времени ты будешь тратить на разговоры, выстраивание коммуникаций, менеджмент, выстраивание процессов, разрешение спорных и конфликтных ситуаций, фасилитацию, оценку всего и вся, даже рисков, менторство и обучение команды или отдельных ее членов.
От этого зависит и то, сколько вещей ты начинаешь делегировать множество на команду. Как будет происходить мониторинг процессов. Сколько сил будет потрачено на подтирание попок и соплей, телесные наказания, валидацию решений принятых в команде, оценку своих сотрудников, преобразование требований бизнеса в технические требования, использование методологий разработки, поиск людей, поиск решений, мистическую прозрачность, общение со своими подчиненными как с людьми, развитие себя, тушение пожаров, контроль, раздача плюшек и пинков, сбор необходимой тебе информации и написание кода.
Если команда небольшая, то большинство из описанных здесь вещей занимают крайне мало времени и позволяет тебе заниматься некогда твоим любимым делом. Если в твоей команде уже пять или шесть человек, то написание кода это уже далеко не твоя обязанность, это больше похоже “а еще я могу и код писать, иногда, в каждый третий четверг месяца, если год високосный”.
Твой путь будет зависеть не только от тебя, но и от внешних факторов, нет какой-то идеальной стратегии, нет какого-то секретного знания, которое может тебе быть отличным тимлидом, никогда не факапить, и тебя будут любить. Говорить как делать хорошо, очень просто, в реальности, даже небольшая вещь может превратится в череду дней, когда ты доводишь эту практику до тех пор пока она не заработает.
Что делать то
Твой путь как тимлида — это путь постоянного развития самого себя, и он очень сильно отличается от того пути, по которому ты шел раньше. Если в работе программиста очень мало тонких граней, серых областей, неопределенности и человеческого фактора. То вся работа с людьми заключается в неопределенности, человеческого фактора, тонких гранях, умения говорить и слушать.
Если раньше какие-то спорные вещи и ситуации ты мог выложить на стековерфлоу и они будут разобраны до косточек, то в твоей ситуации, как лида, тебе придется общаться с более опытными товарищами посвящая их в огромное количество аспектов. И советы, которые они могут дать, могут оказаться нежизнеспособными. Конкретно в твоей ситуации.
Тонны прочитанной литературы дадут тебе какие-то знания, но как ими пользоваться, в какой ситуации, что выбрать из двух совершенно противоположных решений — уже зависит от тебя. На что это повлияет в дальнейшем — зависит от тебя. Справишься ли ты с этим — зависит от тебя. Как ты себя будешь ставить, как будешь уперт, сможешь ли завоевать доверие. Особенно если ты пришел в уже сформированную команду и для них ты совершенно чужой человек.
