Как стать автором
Обновить

Комментарии 33

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

Желание это важно, все остальное результат поставленных целей и упорного труда !)

Эта роль - для меня. Только роль пока об этом не знает, к сожалению хехе))

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

Понятно, что выше приведен сатиричный и гиперболизированный пример.

Ощущаю себя примерно так после тех 4 замечательных жизненных примеров. Разве что каноничного "Привет" без продолжения не хватает

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

Ой, эти приветы без продолжения, прекрасно понимаю))

Кодь. Когда решишь, что достаточно- два раза повтори. Хабр, Мартин, другой Мартин, Эванс тебе в помощь

Могу только согласиться с советом)

Кликбейтный заголовок о диагностировании эректильной дисфункции на основании желаний пациента.

лихо завернули !)

Лидом просто так не стать, это особенность характера. И если в характере есть особенность, то ты хочешь или нет, будешь лидить. А если нет этого, как не пытайся в хорошие лиды не выбиться.

После такой статьи человек не захочет быть лидом, нет совершенно плюсов

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

Тимлид же может быть даже вполне себе мидлом и заимствовать техническую экспертизу уже со стороны своих сеньоров.

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

В каждой компании будет индивидуальный набор требований на эту позицию.

После такой статьи человек не захочет быть лидом, нет совершенно плюсов

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

База, уровень предопределен с рождения

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

После такой статьи человек не захочет быть лидом, нет совершенно плюсов

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

Я например перечитав статью понял что это описание того чем я занимаюсь сейчас буквально, и могу сказать что не выбирал эту должность как цель, я пытался быть на этой позиции всегда даже когда был формально джуном (и скорее всего досаждал своим лидам) лет 10+ назад

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

Тех лид - это

  1. Техническое виденье продуктов, технологии, технические подходы в решении задач. Примерами могут являться - курирование разработки единой платформы для всех продуктов, R&D для оценки внедрения очередной технологии (колоночная БД, какой-нибудь новый брокер, тарантул, замена джунов внедрение ИИ и тому подобное)

  2. Я бы сказал, что он делит обязанности улучшения процессов (наравне с тим-лидом, руководителем отдела, CTO). Например внедрение метрик качества архитектуры, ревью кода и тому подобное

  3. Тех-лид НЕ решает межличностные конфликты. Не является единственным или главным ЛПР при найме в команду или увольнении. Тех-лид не распределяет задачи и не является ведущим дейликов

  4. Тех-лид обязан работать с кодом и технологиями, иначе со временем его знания и кругозор устареет. Поэтому, если на него вешать еще и пункты 2 и 3 в полной мере - у такого человека не будет времени поддерживать техническую экспертизу

  5. Тех-лид обязан читать техническую литературу

Тим-лид - а вот этот чувак перформит команду:

  1. Решает конфликты, строит планы обучения и развития карьеры

  2. Принимает на работу с (совместно руководителем отдела, CTO), проводит ежегодную оценку, увольняет

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

  4. Тим-лид читает литературу по управлению людьми, психологии.

И если пройтись по этим пунктам

Разработчик 1: «О чёрт, все пропало! Помнишь, я вливал в релиз свою доработку? Кажется, она сломала нам прод».

Ну так иди и чини ее. Но на самом деле это больше к руководителю отдела / CTO, потому что проблема в отсутствии тестирования / сбой в процессах. Тех-лид может посоветовать какую технологию или подход использовать для тестирования. Или посоветовать с настройкой человеческих процессов.

Разработчик 2: «Блин, да этот разработчик N вечно придирается ко мне на ревью, так и хочется пойти поругаться с ним»

Это чисто работа тим-лида.

Продукт овнер: «У нас тут такая интересная идея: хотим пользователю после негативного отзыва на наше приложение блокировать использование телефона. Чтобы ему неповадно было нам плохие отзывы оставлять. Крутая идея?»

Почему продукт овнер перекладывает свою работу на тех-лида? Оценка идей - это не работа тех-лида. У него можно спросить "а можно ли в телефоне заблокировать звонки" и только.

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

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

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

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

каждая компания под лычкой лида понимает что-то свое. Но я не ожидал такого от Альфа-Банка. В описании мешанина тим-лида и тех-лида

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

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

PS. Блиииин, я вспомнил, 20+ лет назад работал в микрофилиале одной компании и там реально был отдельный (неформальный) технологический лидер и отдельно нетехнический директор филиальчика, выполнявший функции тима́. Но это была совершенно плоская структура из 6 человек. Как только они стали расти, появились тим+тех-и в одном флаконе, как везде.

Да, мир не идеален.

Из личного опыта - в далеком 2012 году я устроился на новую работу, в один из московских системных интеграторов с обещанием дать мне возможность стать ведущим программистом. Руководитель обещание сдержал и в конце 2012 - начале 2013 назначил меня тех лидом. Команда на каждом проекте была от 2-4 до 5-7 человек. Я успел поучаствовать в двух проектах.

Кстати мне было 27-28 лет. Почти што 23 летний сениор 😅. Было ссыкотно. Интегратор работал в банковской сфере и я все ждал когда из банков наших клиентов ко мне придут матерые и лютые энтерпрайз архитекторы с вопросами "а почему ты выбрал такую архитектуру?" или "как ты собираешься интегрировать свои сервисы с нашей IBM Service Bus" и все вскроется, а меня уволят 😁

Я не настраивал процессы, не лез в душу к людям, не нанимал и не увольнял. Я делал каркас солюшена, выбирал технологии, закладывал подходы. И потом программисты пилили бизнес-логику уже без меня. Один из проектов был основным, где я участвовал в роли программиста и проводил код ревью. Изумительное время тогда было. Процессы были самые лучшие из всех, когда я либо видел до и после. Я работал с людьми, кто впоследствии стали лидами/сениорами во всяких Швециях, Испаниях, Германиях и Канадах.

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

Спасибо вам за столь подробный анализ !
Очень приятно, когда человек готов настолько подробный фидбэк оставить

В 27 лет Tech Lead мощно 💪

Благодарю !)

Лучше расскажи про "готовность работать с бюрократией" в Альфе)

Как вчерашние МФТИшники и просто умные ребята приходят в банк и получают в нос бэклогом и "увеличением эффективности".

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

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

А раз нет границ зон ответственности, то и возникают казусы вроде прибегающих дизайнеров.

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

Как ещё можно повышать доход, кроме как расти по грейду?

Грейд не обязан расти в управление.

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

Варианты есть. Другое дело, доступны ли вам.

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

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

Зачем стоять на своем? Необходимо провести технический анализ и обозначить риски. Дальше бизнес принимает решение сам, готов ли он пойти на эти риски или нет.

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

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий