7 смертных грехов начинающего тимлида. Или как пережить трансформацию из разработчика в руководителя и не сгореть

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

 

 

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

 

 

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

 

Начиналось все достаточно невинно. Я была обычным разработчиком, который решал приходящие таски, и на этом вся моя зона ответственности заканчивалась.

Но в один из дней ко мне пришел мой руководитель и сказал: «Привет, у меня для тебя есть ученик. Хочешь поменторить?» И я подумала: «А почему бы и нет? Возможно, будет весело».

 

 

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

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

И я подошла к своему руководителю и спросила, нормально ли это?

 

 

Он ответил: «Да, ты же теперь тимлид». В этом момент я подумала, что, наверное, это очень хорошо.

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

Так я стала тимлидом, но прежде чем мы перейдем к «грехам», давайте сначала придем к общему пониманию о том, кто такой тимлид.

 

Кто такой тимлид

Для большинства сотрудников тимлид выглядит так:

 

 

Или вот так:

 

 

На самом деле все немного иначе.

 

 

Teamlead – это соединение из слов team – «команда», lead – «лидер», что означает «командный лидер».

Кажется, что все просто, но на самом деле - нет.

 

 

В разных компаниях, а иногда даже и в рамках одной, идут вечные споры о том - «Кто же такой Тимлид и чем он должен заниматься?».

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

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

 

 

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

 

 

И есть «золотая середина», когда специалист-инженер уровня Middle+ становится тимлидом и, соответственно, тоже начинает прокачивать навыки менеджера.

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

Итого: мир тимлидов очень разнообразен.

Мы все в примере - тимлиды. Но, мы – разные тимлиды.

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

 

 

Но какими бы разными мы все ни были, мы все проходим через один и тот же вопрос: «Ну вот я тимлид, а что надо делать?»

 

 

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

Нам приходится разбираться с этим самим. И, конечно же, мы грешим.

Сейчас пришло время мне покаяться в моих прошлых грехах.

 

Грех первый. Гордыня

 

 

Простите меня, ибо я согрешила. И грех мой – гордыня.

 

 

• Когда я стала тимлидом, я думала лишь о том, что я – разработчик. Теперь я стала руководителем группы разработки – это же здорово, это же повышение. Продолжаем жить дальше, мы на верном пути. И конечно же: ничего не будем менять. Я не осознавала, что у меня теперь совершенно другая роль, и должны быть совершенно другие обязанности. И никто ко мне не пришел и не сказал, что можно не заниматься все 100% разработкой. Поэтому я до последнего пыталась сохранять свой уровень разработки и профит от меня в команде, как от разработчика, а так же помимо этого и решать менеджерские задачи.

• Плюс ко всему так же влияло и то, что у меня отсутствовало окружение. Я не понимала, как растут другие тимлиды.

• У меня отсутствовали менеджерские цели. Да, я прекрасно знала какой результат от нас ждет заказчик, но я воспринимала это только через плоскость разработки. Никто из руководства ко мне не приходил и не говорил: «Смотри, у тебя здесь страдают софт-скилы, их нужно подтянуть. Поэтому почитай вот эти книжки, а через месяц мы проверим, как ты усвоила этот материал, и как ты его применяешь».

• Ментора как такового у меня не было, мне пришлось разбираться самой.

 

 

• Во-первых, пришлось осознать, что я теперь, в первую очередь, – не разработчик. Я теперь – лидер команды и ее руководитель. Соответственно, первое, что я сделала – это задалась вопросами «Кто я для своей команды? Что я сделала для нее как руководитель?» И ответы на эти вопросы я, к счастью, находила. А еще поняла почему именно я стала тимлидом (хотя хотелось бы это сразу услышать).

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

• С целями, наоборот, все было проще. Я подошла к руководителю, мы поговорили, и мне дали явные цели.

• А вопрос с ментором закрылся предыдущими двумя пунктами.

 

 

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

• Одним из ключей во внешний мир была попытка завести блог – начать писать туда свои мысли, рефлексировать над своими действиями как тимлида.

• Я начала выступать на конференциях.

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

• И конечно же, все это будет учить вас уметь разговаривать с руководством, аргументировать в дальнейшем свою позицию перед ними, структурировать свои мысли.

 

Грех второй. Чревоугодие

 

 

Когда я поняла, что моя жизнь должна поменяться, я, конечно, начала искать ответы о том, как она должна поменяться и с помощью чего.

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

Мне постоянно нужно было еще. А как иначе? Ведь где-то там в компании сидят руководители с опытом 20-30 лет. А я только вчера узнала, что я тимлид, не понимая, как я могла бы повысить свою экспертность.

Мне нужно было научиться, и поэтому я очень увлекалась тем, что делала.

 

 

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

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

 

 

Другие тимлиды, наоборот, старались по максимуму. Наверняка среди вас есть люди, которые любят читать книги про крупные корпорации, такие как Google, Netflix и так далее. «Опасность» этих книг в том, что неопытному уму кажется, что в них уже расписано все, как нужно работать. И вместо того, чтобы провести анализ на сколько в принципе описанный процесс подходит под реалии, неопытный руководитель просто тащит это в команду «как есть» и абсолютно не адаптируя. Еще попутно проявляя недовольство в духе: «Почему у нас в компании все не так? Вот же в книге уже все описано». Что ж, поздравим этого тимлида с тем, что он постарался убить работающий процесс.

Если вы задумали что-то поменять, важно научиться анализировать, нужны ли эти изменения, которые вы собирались внедрить:

 

 

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

Почему мы говорим о таких «простых» вещах как попросить совет? Когда нам говорят, что мы стали тимлидами, руководителями, нам кажется, что «руководитель» – это гордое слово, оно ассоциируется с властью, управлением, принятием решений. И когда мы сталкиваемся с трудностью или не уверены в своих действиях, то мы не хотим ни к кому идти за советом, т.к это расходится с нашим пониманием и ассоциацией того, что именно мы должны принимать решения.

Поэтому не все могут попросить совет тогда, когда действительно стоило бы это сделать. Для нас это выглядит так, словно мы пытаемся переложить ответственность на кого-то другого (что, конечно, недопустимо в нашей новой роли)… и … из-за этого мы грешим снова: пытаемся «совокупляться» с проблемами 1-1.

 

Грех третий. Похоть

 

 

На самом деле страх, что попросить совета = все будут думать, что ты пытаешься переложить ответственность на другого - не единственная причина этого греха.

Есть и другая сторона - боязнь признаться себе и коллегам, что ты не на все знаешь ответ, что у тебя не хватает экспертизы, чтобы самостоятельно решить проблему. И поэтому мы тянем.. и тянем … пока не станет слишком поздно.

 

 

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

 

 

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

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

Затем вы с этим набором говорите, допустим, вашему руководителю или иному ЛПР, о том:

• какую проблему вы увидели;

• почему вы считаете это проблемой;

• как вы ее проработали;

• какие плюсы и минусы и у какого способа;

• «Я считаю, что верным решением будет вот это. Как ты думаешь, я прав?» и попросить подискутировать об этом.

И вы не должны соглашаться с решением руководителя до тех пор, пока вы в нем не уверены на 100%. Конечно, если вы планируете в дальнейшем стать хорошим руководителем, а не тем, кто делает так, как кто-то ему сказал.

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

 

Грех четвертый. Жадность

 

 

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

Простите меня, ибо я согрешила. И грех мой – жадность.

Когда я стала тимлидом, я думала только о том, что «я лучше знаю» и продолжала брать кучу задач разработки на себя, еще и по принципу «чем сложнее - тем лучше». И я не хотела ни с кем делиться сложными задачами, ведь в продукте архитектура, которую именно я создавала и и я проектировала. А другие коллеги будут тратить еще время на понимание того, что там.

Я думала о том, что можно ничего не детализировать – все и так понятно. И, конечно же, я ошибалась.

 

 

Сейчас я сконцентрируюсь именно на вопросе делегирования.

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

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

• Второе, до чего я дошла – это организация процессов. Процессы в команде я выстраивала сама, и так как моя команда масштабировалась, то я могла принимать некоторые изменения на лету. Могла что-то менять, подкручивать, и я понимала, почему я это делаю, и как это работает. Но команда росла, меня стало не хватать на нее. И я пришла к тому, что мне нужно некоторые организационные моменты, которые уже проработаны, смело передавать. Но было тяжело. Ведь если ты передашь, то что организационно сам принимал, то это означает, что ты уже будешь не нужен? Тебя можно уволить? Очень тяжело принять, что даже если ты все передашь, ты все равно еще нужен этой компании.

• И самая «заковырка» – это способ оправдания. «Сегодня мне некогда, но завтра я обязательно это сделаю. Обязательно передам, но через неделю. А сейчас я все сделаю сам».

• И еще я встречала тимлидов, которые вообще не знали, что можно делегировать.

 

 

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

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

 

 

• Когда я училась делегировать, я нашла для себя такой вопрос, который помогает мне передавать задачи: «А что я могу делегировать уже завтра?»

• В делегировании важно подбирать исполнителей, исходя из их компетенций. То есть не только hard skills, но и soft skills.

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

 

 

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

 

Грех пятый. Гнев

Кажется, что рассказать как делать один вид задач не так сложно. Просто рассказал и все на этом. Но на деле происходит так:

Ты объясняешь один раз, второй, третий… но каждый раз одно и то же.

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

Простите меня, ибо я согрешила и грех мой - Гнев.

 

 

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

 

 

При этом важно также помнить, что тимлид отвечает не только за задачи, но преимущественно и за команду. Атмосфера в команде определяет ее успех.

 

 

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

Для создания атмосферы в команде я начала плавно вводить другие практики. Есть известная 1:1, есть различные тимбилдинги и прочее. В общем, мир рекомендует очень многое, а ИТ-мир – особенно.

Важно ваше желание все это делать.

• Я проводила 1:1 не потому, что в какой-то книге было написано его провести. А потому, что мне было искренне интересно, что тревожит сотрудника. Почему он где-то выполнил свою работу чуть хуже, если до этого всегда делал ее идеально.

• Также мы начали развивать неформальное общение. Оно помогает понимать, какие у человека личные проблемы. Потому что бывают проблемы в семье, кризис возраста или чего-то еще. Может быть очень много влияющих факторов и важно это замечать.

• Митинги.

Не смотря на то, что все из этого вы наверняка слышали я по-прежнему вижу, как многие руководители совершают одни и те же ошибки: синх по статусам задач называют «1-1», а на тимбилдингах заставляют участвовать сотрудников против их воли. Вряд ли это похоже на заботу о команде.

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

Если говорить о некоторых способах определения, есть вербальные признаки, признаки изменения поведения, внешнего вида, взаимодействия, коммуникаций и т.д.

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

 

 

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

 

 

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

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

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

• Не забываем про рост сотрудников.

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

 

Грех шестой. Зависть

Когда мы научились работать с командой, построили процессы и порадовались пройденному пути.. мы попадаем в новую историю.

Очередной митинг, мы собираемся все вместе, слушаем друг друга. Один рассказал о том, как запилил крутую фичу, другой рассказал, как он исправил баги, а ты… ничего, просто менторил, просто лидил команду, просто организовывал процессы: коммуникации, взаимодействия, совещания.

Простите меня, ибо я согрешила, и грех мой – зависть.

 

 

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

Мой же день выглядел иначе. Встречи, созвоны, мероприятия, совещания, контроль за изменениями рынка..

В этом моменте важно осознать, что изменения в вашей деятельности не означают, что она безрезультатна. То, как работает команда – это и есть ваш результат. То, как они решают задачи – это и есть ваш результат.

 

 

Но мне хотелось чувствовать свое влияние и свою значимость тоже. И нашла выход – стала использовать открытый календарь.

У меня есть сотрудница, которая планирует мне день. Когда я увидела, что мои задачи распланированы на две недели вперед, я начала понимать, что я не то, что работаю наряду со всеми, но даже сильно больше. Это помогло мне понять, что я – не бесполезна. Что я – важный механизм, без которого в части взаимодействия, внимания и моей организации работы, команда не объединится в единое целое, и задачи, которые на нас ставятся, не будут решены.

Прежде чем я до этого дошла и поняла, что очень много работаю, произошло еще кое-что.

Мне всегда нравилось много работать, могла прийти домой в 23:00, был момент, когда меня в 4:00 утра закрыли в офисе, и я не могла выйти и уехать домой.

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

 

Грех седьмой. Уныние

 

 

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

Разные спикеры и книги на тему выгорания говорят разное. Кто-то говорит, что выгорание существует. Кто-то – что его нет. Существует оно или нет – это неважно. Важно лишь то состояние, которое вы испытываете.

Здесь стоит прислушаться к себе и понять причину.

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

Я очень много в это вкладывалась… и по пути выгорела.

 

 

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

У нас три продукта, я приходила на работу, и день начинался с того, что первая задача – это один продукт, вторая – второй, третья – третий, а потом по новой: первый, второй, третий и т.д.

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

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

 

 

Полезности

• https://youtube.com/@ManagementChannel – канал конференции TeamLead Conf, где тимлиды делятся опытом

• https://tlroadmap.io/ – карта навыков и модель развития тимлидов

• Книги:

  • Элияху Голдратт - серия книг

  • Максим Дорофеев  - серия книг

  • Максим Ильяхов  - серия книг

  • Паттерсон, Гренни, Макмиллан, Свитцлер - Трудные диалоги

 

Надеюсь этот перечень материалов позволит начинающим ребятам в мире тимлидства сгладить переход от разработчика в мир менеджмента.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Moscow Premiere.