Comments 52
Основной посыл статьи неплохой, однако выводы на основе частных случаев смущают. Например:
Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно
Нет, это просто-напросто неправда. Похоже вас в этом убедила пагубная среда или это ваша гиперответственность материализовалась. На самом деле бывает и даже очень распространена зрелая, спокойная и уверенная тимлидская работа.
История стара как мир наша индустрия. Подобное часто бывает с тимлидами-самоучками (или как сейчас называют first-time manager). Главное не опускать руки, ознакомиться с многочисленными похожими историями и научиться терраформировать окружение под себя, а не пытаться усидеть на всех стульях. И работа снова начнет приносить удовольствие ;)
Конечно, я не имел ввиду, что это нормально. Просто это реалии среднестатистической работы. К сожалению, мой опыт говорит, что очень редко когда можно встретить нормально выстроенные бизнес-процессы в компании. Отсюда и "переработки" ответственных людей.
У меня гиперответственность присутствует, безусловно. Иначе бы я не смог посвятить всю жизнь разработке.
Мой опыт говорит обратное, я перерабатывал только на первой своей работе.
Попробуйте прочитать книжку: "Одноминутный менеджер", мне она помогла, когда я перешел на должность лида.
Дык не только у менеджеров или тимлидов такое бывает. У вполне себе individual contributor бывает также или хуже, вполне бывает что и по субботам надо, и 24/7, иногда переработки оплачивают, иногда не особо. Просто ваш опыт специфичный, менеджером вам быть не повезло в нездоровых коллективах, тогда как инженером вас удалось поработать без лишнего стресса.
Хотя в среднем, конечно, менеджерство - стресса больше, так как больше ответственности. Даже если вы работаете строго 40 часов в неделю и не секундой больше, без переработок, даже такая работа может выматывать и демотивировать, если всё валится из рук, везде бардак, слишком много болтовни и слишком мало дела.
За 20+ лет в разработке я прошёл путь от студента, который изучал C++, до техлида в госкомпании
Вот и ответ, почему такие условия работы
По моему опыту условные "лиды" в госкомпаниях (условные, поскольку должности в госкомпаниях обычно именуются иначе) гораздо реже прояаювляют гиперответстаювенность, чем их коллеги из частных контор.
Другой вопрос, что причины такой гиперответственности (помимо особенностей личности сомого лида) обычно разные. Но таки бывает по разному, и у частника бывает более жесткая рабочая обстановка, чем у госа.
Работал в, фактически, госкомпании много лет. 99% всех "срочностей" создаются искусственно участниками процесса, хотя все эти бурления фактически не влияют ни на что, кроме выполнения ритуалов внутреннего карго-культа со всякими KPI, поддерживающими процессами и прочим барахлом: тома документации, которые никто не читает, так как они устарели ещё до момента утверждения; системы, в которые перестают заходить спустя полгода после релиза; дашборды, наполненные метриками не на основе реальных транзакций, а после ручного докручивания заинтереснованными менеджерами; регистрация интеллектуальной собственности на базу данных, выдранной из стороннего софта - you name it. "Настоящий" же бизнес (то, что японцы кличут "Гэмба") на большинство этих танцев может плевать с высоченной колокольни.
Имхо, наоборот должно быть. В госкомпании в 17.30 закрыл ноут и пошел себе домой. Все незавершенные дела завтра с утра буду думать)))
А я дошёл до тимлида и свалил на удалёнку тогда, когда это ещё не было трендом. И вот теперь, спустя 12 лет, я бы снова не прочь потимлидствовать, но поезд ушёл, второй раз по этому пути не пройти.
После тимлидства чем начали заниматься?
Почему не пройти? Идёте на курсы какого-нибудь менеджмента и звучиваете свою "хотелку" и/или переходите в другое.
Не "не пройти" а лень и "случай" ушёл, и все о вас как о разрабе думают...и вы тоже.
Какие курсы? Везде требования от 5 лет опыта тимлидства на последнем месте работы
Ну так напишите 5 лет тимлидства на последнем месте работы
Aurora прав, напишите лет 5-7 опыта, или вообще напишите его как свой опыт работы в компании, главное понимание того что вы вообще будете делать, но порой даже этого не нужно.
Хороший HR, который сможет вас поймать на лжи в вашей же области знаний - редкость - таких даже меньше чем токарей 8го разряда, котоыре существуют только на бумаге.(Почитал однажды их требования и компетенции, там требуется буквально супермен.)
Хорошие;) Теоретическую базу получить, поучаствовать в семинарах и разборках кейсов. На ютубе были конфы яндекса про тимлидство.
Если команда маленькая - то менеджмент не особо важен ....даже если просят 10 лет опыта.
Но если вы хотите сразу на 10+ человек, а оно вам точно надо?)
Почему не пройти?
Хочешь управлять людьми – становись менеджером. Хочешь решать сложные технические задачи – оставайся разработчиком.
Непонятно только, почему выбор сводится только к тому чтобы либо идти управлять людьми, либо вечно быть в роли разработчика.
Есть же и технические направления роста вплоть до Architect и Principal Engineer :)
Ну, наверное это не всем дано. Не каждый солдат может стать генералом )
технические направления роста вплоть до Architect и Principal Engineer
А можно весь списочек в куда расти на всяк случай? А то меня на одном собеде прям забодали "идите лидом". Правда выяснилось что там попил тендеров для гос.заказов и от "лида" только ответственность и никаких ручек на что-то повлиять
вечно быть в роли разработчика
Вы так пишите, будто это что-то плохое. Я, вот, уже 30 лет разработчик, и всё меня устраивает.
Я не писал про плохо или хорошо. Мой комментарий про наличие опций роста не только в сторону менеджмента.
Есть много людей, которым комфортно и интересно продолжать работать в чистом разработческом фокусе, и в этом нет проблем.
Но тем, кто хочет более стратегических задач, не обязательно идти именно в управление людьми.
ГОДЫ СТРАНСТВИЙ
И тут, когда я эти годы, казалось бы повод для гордости, озвучиваю в резюме, на меня смотрят как на "Overqualification"....
Тимлид – это когда ты должен быть на связи 24/7. Суббота, воскресенье, утро 1 января – не важно. «Можешь быстро посмотреть?», «А как ты думаешь?», «А почему не работает?».
А нельзя сказать им, что в понедельник посмотришь? Я просто уже 16 лет работаю. И я точно могу сказать, что большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент. Да вообще больше половины того, что мы делали, в реальности было бессмысленной работой, большая часть сроков сдачи проектов была взята просто с потолка без учёта имеющихся ресурсов и других проектов. Но все бегают, суетятся, придумывают новые задачи, рефакторинги туда-обратно, новые трансформации и т. д. Может, нам иногда стоит успокоиться и начать более-менее спокойно работать и пытаться отсечь хотя бы часть ненужной работы, а не только узкоколейку за три месяца под дождём и снегом строить.
большая часть задач, которые "срочные", не такие уж и срочные, да и не особо нужные в данный момент
Вот это прям в точку. Более того, из моего опыта: если задача не представляет из себя фикс бага, то чем "срочнее" задача, тем меньше стоит ожидать от нее продуманности. Ну не успевают люди сфокусироваться на ней и продумать, "срочная" задача это часто эскиз какой-то идеи, а вовсе не что-то готовое к выполнению. И это для меня (со стороны исполнителя) обычно означает, что требования к задаче будут докидываться в процессе ее исполнения, иногда меняя ее чуть ли не на противоположную.
Отсюда, имхо, и рождается
больше половины того, что мы делали, в реальности было бессмысленной работой
Это еще и ухудшает само планирование. В сущности "срочность" это часто попытка обойти нормальные процессы планирования, анализа и проектирования. Это вот очередь "я только спросить" к доктору, которые, забежав, там на полноценный прием остаются, да еще и пришедшие без всех анализов (а их на лету надо сделать).
Полностью поддерживаю. По моему опыту, особенно в аутсорсе. Менеджер на стороне компании провайдера услуг гонит всех на ровном месте исключительно для собственных бонусов. Когда удаётся поговорит с заказчиком напрямую и дать обоснованный развернутый ответ, что и почему, и сколько нужно времени. Я ни разу не слышал от заказчика возражений и попыток торопить. А вот от своих же менеджеров очень часто. Мало попадалось действительно толковых.
Ну и в целом, приходишь и говоришь давайте в начале проекта спланируем договоримся и задокументируем хотя бы тикетами. Но нет, так никто не хочет. А вот после дедлайна все переделывать - это пожалуйста.
Не всегда так. Бывает проблема - упал сервер. Тебя дергают. Минут 30 сидишь разбираешься, в итоге это сисадминская проблема. Или проблема другой системы от которой зависит твоя.
больше половины того, что мы делали, в реальности было бессмысленной работой, большая часть сроков сдачи проектов была взята просто с потолка без учёта имеющихся ресурсов и других проектов
Воистину!
Тимлидами тоже надо руководить, чтобы не шарахали команду по экстремальным практикам.
Тоже так скитаюсь, только в тестировании.
Когда последний раз был лидом, понял что кодом то заниматься получается. Но мир меняется очень быстро, новые инструменты, подходы, языки. Но времени их изучать нет. Поэтому спрыгиваю периодически в разработку.
Проблема потом вернуться в некоторых местах. Потому что нет стандартных требований, у одних лид - это чистый менеджер, у других это Senior Principal Test Engineer. А у третьих ты должен быть на уровне Software Architect плюс всё про тестирование. И тут я не очень понимаю, почему позиция по оплате ниже на 20-30% чем Dev Lead требует в 2 раза больше знаний? И зачем тогда программисты, если тестировщики должны знать языки не хуже?
"Молодой, всё еще ищет, а я уже нашел" (С) старый анекдот.
Тимлид — это менеджер младшего звена.
Мой кейс один из самых распространённых: тимлид и техлид в одном лице. Главная моя мотивация стать лидом была возможность наладить процессы, некоторые из них аккуратно отстроить с нуля; вырастить себе замену и уйти в техлиды, делегировав пост тимлида своему протеже.
Сейчас я в середине пути. Выстраивать процессы работа щепетильная и очень деликатная.
Становясь тимлидом, полезно обозначить свой профит и цену за него. Я заранее знал на что подписываюсь, потому двухкратные перегрузки на старте не были внезапными.
По итогу полученный опыт для меня оказался предельно полезным.
По сабжу. Тимлид это вполне себе карьерный рост, но не профильный для трудяг (программистов, тестировщиков, аналитиков и т.п.), а потому это почти всегда отдаление от профиля в сторону менеджмента.
Я достаточно молод как тимлид (1,5 годика), а потому ещё не определился — хочу ли остаться в этом должности или срочно возвращаться к любимому делу.
Любой "рост" в менеджеры - отдаление от предметной области. Я, будучи админом, лет 10 проработал на менеджерских позициях (вплоть до ИТ-директора в компании на 1к+ пользователей), но вернулся "к истокам" - все эти планирования, совещания, бесконечные отчёты... не моё это.
Отличный кейс, внушающий опыт. Охотно почитал бы ваши статьи на тему менеджмента.
Если в течение пары-тройки вернусь к своему основному профилю, то менеджерский опыт для меня будет крайне полезным опытом и в разработке. Ибо то, до чего я бы годами доходил, глядя с позиции исполнителя; с позиции руководителя многие процессы стали понятны почти "моментально" (каких-то 1,5 года) сразу в глубину.
ИМХО, вне зависимости от того продолжить рост в менеджменте или вернуться "в поля" -- профессионал нисколько не потеряет от полученного опыта. Разве что перспективы раскроются в других плоскостях.
п.с. совещания (когда эффективны) и планирование - мне по душе, но вот отчёты - это боль. У любой профессии есть свои издержки :)
совещания (когда эффективны) и планирование - мне по душе, но вот отчёты - это боль.
Совещания - обычно с третьей-пятой итерации превращаются в некий ритуал - в лучшем случае, публично подвести итоги. Планирование - это норма, но зачастую "планы" обрастают кучей бюрократии, ну и согласование годового бюджета - та ещё заноза. Отчёты - неотъемлемая часть совещаний - хорошо, когда на отчётный период пришлось что-то существенное, но если была просто штатная поддержка инфраструктуры, приходится что-то выдумывать, а это - всегда компромисс с совестью - или "изобретать подвиг", или "выглядеть жидко". В общем, линейным исполнителем как-то спокойнее =)
Тимлид – это когда ты должен быть на связи 24/7.
Тимлид - это человек, который, при необходимости поддержки 24/7, должен помочь организовать справедливый график дежурств. Если же вот эти «А как ты думаешь?» приходят от внутренних членов команды, то можно просто игнорировать до рабочего времени.
Да, ты как небольшой руководитель стараешься всё автоматизировать, все процессы работы твоих сотрудников – от Jira правил до автопроверки кода и выкладки Docker-контейнеров на стенд.
Да, от тебя ожидается налаженная работа команды, но не обязательно это делать своими руками. Нарисовал команде вижн "как надо", завел задачи, согласовал с руководством время на их исполнение и распределил по команде.
Все-таки тимлид - это небольшой руководитель и получает "дополнительную пайку" именно за организацию процесса, а не за то, что самый продуктивный кодер.
А почему вы решили что тимлид выше техлида?
"Никого не ждёшь, ни на кого не злишься – просто делаешь"
По мне так работа в команде это не просто делаешь, а делаешь вместе. И тут естественно есть поле для возможных споров, недопониманий и так далее. Так что работа над кодом это всё равно работа с людьми, хотя и в сильно меньшей степени.
Всё то же, но у меня еще и бизнес был по теме. В итоге - просто программер.
Привлек заголовок: ... и обратно.
Следующие тезисы мне близки:
- Мне больше нравится решать задачи кодом, а не людьми.
- Карьерный рост – это не всегда движение вверх по иерархии.
- Мой совет: не гонись за должностями. Иди за тем, что приносит удовольствие.
От джуна до тимлида и обратно: почему я выбрал код