company_banner

Как я был разработчиком, а теперь тимлид

    enter image description here


    Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!


    Для начала несколько слов обо мне


    Меня зовут Виталий Шароватов. Сейчас я – тимлид команды из 12 разработчиков в подразделении мобильного веба в Badoo. Уже полтора года я живу в Лондоне. Но на этой должности я оказался в результате довольно долгого пути, историю которого я расскажу далее.


    Мне 32 года, общий опыт работы в индустрии — почти 15 лет. Начинал я, как и многие, с фриланса. Много и плодотворно занимался серверным программированием, немного – системным администрированием.


    • Программировать начал с PHP 4, потом был PHP 5, писал на C# для ASP.NET MVC и ASP.NET Web Forms, писал на VBScript в ASP.
    • Построил несколько систем с IE ActiveX-компонентами, интегрирующих клиентский код с разными устройствами (сканерами паспортов, сканерами штрихкодов, принтерами наклеек и так далее).
    • Построил сеть, объединяющую три географически разделённых офиса на D-Link’ах DFL с дублированием канала и VPN.
    • Администрировал Exchange, Windows 2003 AD.

    Но больше всего я любил клиентскую разработку.


    RealRussia. 2007–2012


    Впервые я стал тимлидом в RealRussia. Это британская компания, занимающаяся въездным туризмом в Россию. Сначала она занималась только организацией получения российских туристических и бизнес-виз для англичан, но за время моей работы были созданы сервис заказа билетов на поезда, интегрированный с системой «Экспресс-3» и РЖД, сервис заказа отелей, а также полноценные интегрированные Workflow-бэкенды для обслуживания всех процессов.


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


    Мне повезло, что рынок труда разработчиков на тот момент был наполнен предложениями, и нам удавалось нанимать людей, очень похожих на меня: у них было такое же отношение к работе (ответственность и проактивность), они относились практически к такому же личностному типу (по натуре я довольно энергичный, и с тяжёлыми на подъём коллегами мне было бы трудно сработаться). Работать в таком коллективе было очень просто, я не видел в этом какого-то вызова.


    К тому же в то время я ещё не был уверен, что мне хочется заниматься руководством. Я был достаточно юн и хотел сосредоточиться на работе с JavaScript, поэтому через несколько лет работы тимлидом в RealRussia я переехал из города Волжский (Волгоградская область) в Москву и устроился в Mail.Ru Group на должность фронтенд-разработчика.


    Mail.Ru Group. 2012–2015


    После ухода из RealRussia я хотел найти какой-нибудь highload-проект, в котором было бы достаточно технических и организационных вызовов. В результате я стал фронтенд-разработчиком в проекте «Мой Мир», где занимался обычной продуктовой разработкой, а через некоторое время мне предложили работать над мобильной версией проекта.


    Зная, что во всём мире уже давно очевиден тренд роста мобильного потребления контента, я, конечно же, согласился. Мои обязанности заключались во всё той же классической продуктовой разработке. Из интересного технически — в тот период я провёл исследование и реализовал полноценную поддержку работы сайта в Opera Mini.


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


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


    Badoo. 2015–наши дни


    В Badoo очень развита культура роста сотрудников внутри компании: Head of product вырос за несколько лет из Paralegal, CTO – из разработчика, большинство Heads of departments тоже выросли из разработчиков. Что уж говорить про тимлидов! Меня, как и многих других приходящих в компанию разработчиков, мотивированных перспективами роста и вызовами, не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа.


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


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


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


    Особенности


    Особенность №1. Ты и один, и не один


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


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


    То же самое относится и к проблемам. Ты уже не можешь сказать: «А, это Саня (Лёха, Андрюха) допустил баг!» Нет, за этот баг теперь отвечаешь именно ты вне зависимости от того, кто писал код.


    Это тяжёлая ноша, вызов, или что-то, что у тебя получилось бы принять легко и непринужденно? Можешь ли ты доверять людям, с которыми работаешь?


    Особенность №2. Неопределённость


    Когда ты – просто разработчик, то привыкаешь к нескольким предсказуемым источникам неопределённости. Например, баги в браузере, странное поведение устройства. Обычно ты знаешь, как с ними работать, или хотя бы можешь как-то спрогнозировать риски. Но, став тимлидом, ты оказываешься лицом к лицу с новым источником неопределённости: с людьми.


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


    Особенность №3. Все разные


    В RealRussia все члены моей команды были так на меня похожи, что мне стало казаться, что вообще все должны быть со мной на одной волне с точки зрения подходов, мотивации, психотипа, мироощущения и силы воли. Я работал с каждым разработчиком так, как если бы я работал с самим собой.


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


    Банальный пример: можно постоянно довольно жёстко подталкивать к цели одного человека (можно даже поставить перед ним недостижимую цель), он расценит это как вызов и будет демонстрировать максимальную эффективность. Однако применив этот подход к человеку другого психотипа, можно потерять разработчика — он будет серьёзно демотивирован тем, что время идёт, а ему не удаётся даже приблизиться к достижению цели.


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


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


    Ещё один пример в качестве иллюстрации. Программист всегда очень тщательно проводит ревью кода, искренне любит делать ревью «правильно», тратя на анализ кода по несколько часов, чтобы вникнуть во все детали. Но как тимлид ты знаешь, что для многих задач такая тщательность ревью просто избыточна. Станешь ли ты пытаться изменить подход своего сотрудника, попытаешься заставить его прекратить делать любимое дело и нанесёшь тем самым удар по его мотивации? Или лучше будет направить его усилия на ревью тикетов, где его страсть к такой работе принесёт максимальную выгоду?


    Особенность №4. Нехватка знаний и опыта


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


    Затем нужно научиться формировать эту атмосферу, создавать командный дух.


    Прирождённые лидеры, с самого детства собирающие вокруг себя и ведущие за собой людей, часто формируют атмосферу команды интуитивно, на уровне неосознанной компетентности. Такой человек, став тимлидом, практически сразу будет чувствовать себя на своём месте. Остальным же придётся вырабатывать и развивать в себе лидерские качества, что называется, в процессе: выполнять функции тимлида придётся даже в условиях явной нехватки знаний об управлении, никто не будет ждать, пока ты получишь MBA.


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


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


    Особенность №5. Нехватка времени


    Нужно быть готовым к тому, что никогда не будет хватать времени, чтобы сделать всё – всегда будет оставаться что-то, что нужно сделать.


    А новый уровень неопределённости всегда влечёт за собой множество новых задач, которые необходимо срочно решить. Запросы от других команд, когда что-то идёт не так, эскалация проблем от разработчиков, административные вопросы и так далее.
    Одна только поддержка текущих процессов разработки отнимает кучу времени. И чем больше людей в команде — тем больше времени: раз в две недели индивидуальные встречи с каждым сотрудником, kick-off-встречи и VQA, планёрки, ретроспективы, месячные оценки.


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


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


    • Доверие. Ты понимаешь, что твоё задание по каким-то причинам может быть не выполнено вовремя (или вообще не выполнено). Все мы — живые люди, разработчики могут болеть, их производительность может снизиться, может случиться что-то ещё. Всегда есть риск.


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

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


    Особенность №6. Отвлекающие факторы


    Тимлида отвлекают весь день — мессенджеры, телефон, почта, люди. Постепенно твой мозг привыкает к такому формату работы, когда нужно держать в голове много дел одновременно и при необходимости быстро переключаться между ними. Этот навык развивается точно так же, как и все остальные ежедневно тренируемые навыки — сравнивая планы на день любого дня этой зимы и такого же дня год назад, я поражаюсь разнице: сейчас «тяжеловесных» задач, с которыми удаётся справляться в течение дня, намного больше.


    Однако этот навык сам по себе иногда становится проблемой. Привыкнув к частому переключению между делами, мозгу становится очень трудно сосредоточиться на чём-то одном, когда это необходимо. Начинает ощущаться почти физический дискомфорт из-за того, что не нужно переключать внимание, и ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры. Когда мне приходится фокусироваться на чём-то долгое время, я использую технику Pomodoro — какое-то время фокусируюсь полностью, а потом позволяю себе отвлечься на что-нибудь. Таким образом убирается психологический дискомфорт от того, что не удалось удержать внимание, – отвлечение фактически легитимизируется.


    Из-за отвлекающих факторов поначалу ещё труднее планировать своё время, что может привести к работе без отдыха и сна. Ты думаешь: «Я только начинаю, поэтому должен быть максимально продуктивен. Поработаю пока по 11–14 часов день, чтобы быстрее достичь цели», работаешь в таком режиме месяц, два, три, «выгораешь», заболеваешь на несколько дней, а затем вновь вступаешь на этот порочный круг. Я через это прошёл и после нескольких циклов «переработка – «выгорание» – восстановление – переработка» заметил, что моя производительность всё больше и больше снижается.


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


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


    Особенность №7. Компромиссы


    Из-за всё той же нехватки времени постоянно приходится идти на компромиссы, выбирать приоритетные задачи и проблемы. Есть известный метод: сортируйте задачи по срочности, важности и по срочности + важности и действуйте в соответствии с получившимися списками. Но что делать, если даже список «срочно + важно» так велик, что не удаётся с ним разобраться в разумный срок?


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


    Прежде чем заработала моя интуиция, я придерживался простого критерия «наименьшего из зол». Выбирая из двух задач, я спрашивал себя: что потеряет компания/ команда, если не будет выполнена одна из них?


    Поиск баланса при расстановке приоритетов — сложная задача, подход к которой необходимо постоянно пересматривать. К примеру, есть один час и две задачи: поговорить по душам с разработчиком, который демотивирован из-за какого-то конфликта, либо помочь другому сотруднику исправить баг, возникающий у миллионов пользователей. Что может помочь в определении приоритета? Сразу возникает много вопросов: какая атмосфера в команде? насколько устойчив конкретный разработчик к конфликтным ситуациям? сколько может подождать решение проблемы с мотивацией разработчика? возможно ли за пять минут разговора перенести полноценный разговор по душам на завтра? каков масштаб бага? есть ли эксперт в области подобных проблем, которому можно было бы делегировать оказание помощи разработчику? Ответы помогают сравнить важность совершенно разных по сути задач. А с опытом управления растёт и количество вопросов, и на многие из них ответы получаются практически интуитивно.


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


    Особенность №8. Политика компании


    Главная цель расстановки приоритетов — оставаться как можно более эффективным в любых условиях.


    И одно из условий, с которым постоянно сталкивается тимлид, — соблюдение баланса интересов компании в целом и своей команды в частности. Приходится постоянно быть «зонтиком», «фильтром», посредником, находиться под давлением со всех сторон, но действовать при этом исключительно в соответствии с приоритетами.


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


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


    Особенность №9. Ты в ответе за всё


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


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


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


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


    Результаты


    Результат №1. Демотивация и мотивация


    Я столкнулся с несколькими видами демотивации, и вы тоже можете с ними столкнуться.


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


    Для меня ключевым фактором принятия окончательного решения стать тимлидом было чёткое видение того, что в компании нет потолка роста, и мне дадут столько ответственности, сколько я смогу и захочу на себя взять (и обязательно добиться результатов). В таких условиях хочется работать больше и продуктивнее, и демотивационные факторы нисколько не сдвигают чашу весов в свою сторону.
    Ещё одна демотивационная вещь, с которой я столкнулся: все процессы идут настолько постепенно, что никогда не удастся всё улучшить в один присест.


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


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


    В работе тимлида достаточно демотивирующих факторов. Но вряд ли люди становились бы тимлидами, если бы не было чего-то хорошего.


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


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


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


    Результат №2. Победы


    Несмотря на неопределённость и дефицит всего и вся, благодаря мотивации и её подкреплению обратной связью хочется добиваться всё больших побед в роли тимлида. Для меня главная победа — сделать команду счастливой и вместе с ней достичь хорошего результата.


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


    Поверьте, невероятно приятно в ответ на такую заботу получать положительную обратную связь со всех уровней.


    Заключение и текущие достижения


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


    enter image description here


    • Команда выросла с четырёх до 12 разработчиков (лишь один разработчик за это время ушёл от нас по семейным обстоятельствам), все они имеют чёткий план роста и развития внутри команды и компании.
    • Год назад мы доставляли в среднем одну фичу в неделю (иногда – меньше), теперь — до десяти фич в неделю. Кроме того, мы фиксим кучу багов, стали релизиться раз в день и чаще (а раньше релизились раз в одну – две недели), нагнали отставание в 200 продуктовых фич, ежедневно релизим что-то без QA (и нет, это не означает плохое качество фич).
    • Была достигнута поставленная цель стать экспериментальной платформой — мы быстро проводим важные А/В-тестирования, на основании результатов которых другие команды выбирают, какой вариант идей продуктовых менеджеров стоит реализовать.

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


    Если вы, несмотря на все «но», выбираете управление и начинаете с роли тимлида, я искренне желаю вам удачи! Учитесь, развивайтесь, каждый день спрашивайте себя: что можно было сделать лучше? что идёт не так? Будьте готовы к негативной обратной связи и воспринимайте её как инструмент роста; будьте честны с собой и сотрудниками, помогайте им развиваться и расти; научитесь находить удовольствие в построении островков порядка в море хаоса и неопределённости — и всё получится. Надеюсь, мой опыт будет вам полезен и, конечно, с удовольствием отвечу на любые вопросы.


    P. S. Не могу не воспользоваться случаем рассказать про наши вакансии! Приходите (переезжайте) работать в наш лондонский офис.


    iOS-разработчик: [описание]
    Android-разработчик: [описание]

    Badoo 235,75
    Big Dating
    Поделиться публикацией
    Похожие публикации

    Вакансии компании Badoo

    Комментарии 168
    • +3
      выполнять функции тимлида придётся даже в условиях явной нехватки знаний об управлении, никто не будет ждать, пока ты получишь MBA.

      Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства. Ну и некоторые функции исполнять приходилось временно, пока не найдут кого-то, но я делал всё, чтобы как можно сильнее мотивировать руководство найти как можно быстрее :)


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

      • +6
        Сильно тянуть не надо. Можно дождаться что предлагать больше не будут, поскольку найдут другого героя (с меньшей квалификацией). И самое страшное, что он станет вашим начальником. МВА — хорошо, но проблем не решает. Управленческие навыки с опытом приходят. Тут главное понимание, что «сотрудники — это люди».
        • +4

          Предлагают практически на каждом месте работы после года-двух, максимум трех.


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

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

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


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

              • +2

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

                • +2
                  даже прав доступа к репе лишить не имею прав.

                  А это какой вид рычага: поощрение или наказание? Какой в этом вообще смысл?
                  • 0

                    Физическое отстранение от работы.

                    • 0

                      Вот вам еще одна аналогия. Поставили человечка надзирать за рабами, а он взял и убил одного из них. Хозяин будет счастлив?

                      • 0
                        если он ухайдокал других рабов да еще вытоптал поле и в рояль насрал то имхо будет очень счастлив
                        • 0

                          Ну вот как раз сделал то, что собирается сделать VolCh

                        • +1

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

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

                            Не рабы, а мои коллеги.
                            Не подчинённые, а моя команда.
                            Не приказывать, а нам совместно находить решения производственных задач. Или даже отойти в сторонку и наблюдать, как это делают без вас. Можно давать советы и делиться опытом, но делать то всё равно им.
                            Не наказывать, а учиться на ошибках. Ещё и ещё раз. Вместе с ними. Или помогать учиться им.
                            Не ругать за..., а мотивировать к… Своим примером. Своим идеальным, несокрушимым, честным, прямым примером того, как надо поступать,

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

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

                            А если заранее есть даже малейшее подозрение на зловред в репозиторий от нехорошего сотрудника — зачем такому человеку 2 недели отрабатывать? Я видел, как такого за руки без вещей выводили из офиса два серьёзных человека и он больше не появлялся.

                            • 0

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


                              Не про зловреды речь, а просто про код, написанный в нарушение соглашений.

                        • 0
                          для этого есть увольнение. Зачем платить зп человеку который не может выполнять свою работу?
                          • +1

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

                      • –1
                        Младший офицерский состав имеет право расстреливать без суда и следствия за неисполнение
                        приказа подчиненным

                        Серьезно? И многих расстреляли уже? В мирное время?


                        имеет право взять под арест, выносить дисциплинарные наказания и поощрения.

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


                        Я же даже прав доступа к репе лишить не имею прав.

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

                        • 0
                          Насколько я помню. лейтенант может только взыскания и благодарности объявлять, а остальное старший офицерский состав.
                          И уж тем более расстреливать перед строем он не имеет права и в военное время. Для этого есть трибунал.
                          • +1

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

                            • +1

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


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


                              Вообще определение лидера:


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


                              Т.е. это не функция, а роль в социуме.

                              • +1

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


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

                                • +1
                                  Сказать может кто угодно что угодно, но пустые угрозы быстро начинают игнорировать

                                  А кто говорил об угрозах кроме вас?


                                  а пустые обещания "плюшек" начинают раздражать

                                  А кто говорил о том, что кто-то обещает какие-то плюшки?


                                  а что им хочется слышать ("я обеспечу тебе премию").

                                  И они правы. Не обещайте то, чего не можете выполнить. Вообще деньги не единственный мотиватор.


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

                                  Лидеры не бывают формальными. Бывают формальные управляющие (менеджеры). Задача такого менеджера определить лидера в группе и либо научиться с ним очень хорошо взаимодействовать либо отодвинуть его.


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

                                  Печально. Судя по тому, что вы написали — у вас отношение к другим людям как к тем, кто не хочет ничего делать в лучшем случае и в худшем вредить. Это не так.

                                  • 0
                                    А кто говорил об угрозах кроме вас?

                                    А кто говорил о том, что кто-то обещает какие-то плюшки?

                                    Метод кнута и пряника.


                                    И они правы. Не обещайте то, чего не можете выполнить

                                    Я обещаю попросить и я прошу. Сам премию я могу дать разве что из собственного кармана.


                                    Лидеры не бывают формальными.

                                    Бывают, навскидку http://www.psychologos.ru/articles/view/formalnyy_lider


                                    Судя по тому, что вы написали — у вас отношение к другим людям как к тем, кто не хочет ничего делать в лучшем случае и в худшем вредить. Это не так.

                                    Нет у меня такого отношения по умолчанию. С чего вы взяли? Нормально человек работает — нет претензий. Хорошо — пряник. Плохо — кнут.

                                    • 0

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

                                      • 0

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

                                        • 0
                                          И про микроменеджмент ваши фантазии.

                                          Мои фантазии? Зачем мне фантазировать о ваших проблемах? Вы считаете, что это задача тимлида — проверять код за подчиненным, верно?


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

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

                                          • 0
                                            Вы считаете, что это задача тимлида — проверять код за подчиненным, верно?

                                            Обычное code review


                                            Материально-административные методы мотивации доступны даже самому простому джуниору, если он знает как ими пользоваться.

                                            Не в рамках рабочих процессов, обычно.


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

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

                                            • 0
                                              Обычное code review

                                              Сколько Code Review вы можете делать в день? Когда вы собираетесь заниматься своими прямыми обязанностями?


                                              Не в рамках рабочих процессов, обычно.

                                              Распределение бюджета вообще к процессам отношение слабое имеет. Или вы считаете, что выделение определенной суммы каждый месяц прописывается в орг. схеме?


                                              Но, как минимум, я хочу явных полномочий инициировать формальные
                                              процессы взысканий

                                              Так ведь они есть у вас. Как и у любого другого. Вы собираете данные, представляете их на рассмотрение, человеку дают возможность оправдаться или исправиться и если не может — уходит.


                                              а не так что прихожу просить повышения зарплаты, а мне говорят "у него,
                                              что, своего языка нет?"

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

                                              • 0

                                                Code Review входит в мои прямые обязанности.


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

                                                • 0
                                                  На постоянные косяки будете вправлять мозг подчиненным, а не переделывать в личное время — глядишь и «отсутствующие» полномочия дадут. Очевидно, что руководство не видит в Вас «биг-босса», а Вы могли бы уже давно стать им.
                                                  • 0

                                                    Как вправлять без полномочий? Не поощрить, не наказать.

                                                    • 0
                                                      Вам уже очень популярно Все объяснили. Вы просто не хотите… или не можете услышать. Видимо вы просто хотите, что-бы все «полномочия» вам предоставили на «блюдечке с голубой каемочкой». Такого в реальной жизни не бывает. Все необходимые полномочия у вас, Если вы будете тимлидом- у вас будут. Чего не будет- Аргументированно объясните руководству и появится. Рецепт предельно прост.
                                                      • 0

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

                                                        • 0
                                                          Эмм… вы Реально понимаете, что ФСЁ в должностной инструкции «прописано» быть не может? Просто потому, что ВСЕГО предусмотреть невозможно.
                                                          • 0

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

                                                            • 0
                                                              Вы Снова меня не слышите. Начальство, я Уверен, ценит Грамотных специалистов. Умеющих Обосновать, а не просто «хотеть» чего-то. Вы просто «хотите»? Ну, хотите дальше.
                                                      • 0
                                                        В указанной вами статье "Формальный лидер" есть также описание «неформального лидера». Посмотрите, подумайте — как так получается, что у неформального лидера полномочий нет, но команда преданными глазами смотри на него, слушает его советов, делает то, что он сказал, хотя он не приказывал и поощрить за выполнение не может. Но они делают.
                                                        Управляет без кнута и пряника. Нонсенс, не правда ли?
                                                        Вам такой встречался? Попробуйте проанализировать, как он это делает. Меняйте своё сознание, чтобы было как у него. Приобретайте новые навыки, такие как у него. Копируйте его. Тренируйтесь.
                                                        • 0

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

                                            • +2
                                              Командой управляют не только материально-административными методами. Если в ход пускаются эти методы, значит в команде нездоровый климат.

                                              По книге "Лидер и племя" — признаки второго или даже первого уровня мышления («моя жизнь дерьмо — я буду страдать, жаловаться и саботировать» и «вся жизнь дерьмо — я буду выживать») — и практические советы по работе с сотрудниками.

                                              По книге "Как пасти котов" — главы про «Как руководить собой», «Как вести за собой стаю» и практические советы.
                                              • 0

                                                Спасибо, почитаю.

                                              • 0
                                                А я вот вам скажу, что не стоит.
                                                Вам бы с этим военным подходом идти руководить в армию, но никак не в IT. Читаю комменты и любуюсь просто – должностная инструкция, формальные права. Упаси боже с таким работать, видно, что вы вообще не чувствуете людей и их потребности. Кнут, пряник – вы можете эту бинарную логику оставить для разработки, в менеджменте и общении с людьми все сильно сложнее и по-другому.
                                                Формальный лидер как сущность опять же работает в армии, но не в разработке – если с вами плохо, люди просто уйдут, слишком много хороших мест и слишком мало разработчиков.
                                • 0
                                  Серьезно? И многих расстреляли уже? В мирное время?

                                  Право имеет применять оружие для подчинения в мирное время, например, неисполнение приказа "сдать оружие! или если неисполнение приказа содержит признаки госизмены. А расстреляли или нет кого — дело десятое. Такие права даны прежде всего для предупреждения нарушений, а не как наказание, чтоб даже не думали не выполнять приказ.


                                  но никто вам не запрещяет их выносить — заставлять работать в выходной

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


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

                                  Если человек портит репу, то закрытие доступа к ней означает сокращение убытков.

                                  • +1
                                    Если человек портит репу, то закрытие доступа к ней означает сокращение убытков.

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


                                    Портит репу — это вообще что значит? Ломает билды? Нарушает консистентность хранилища? Коммитит плохой код?

                                    • 0

                                      Предлагали как самому технически компетентному из команды.


                                      Коммитит плохой код, в том числе ломающий билды, который потом нужно откатывать. Время на откат — дополнительные прямые убытки.

                                      • 0
                                        Предлагали как самому технически компетентному из команды.

                                        Часто это может быть минусом. Хороший тех. спец часто бывает перфекционистом.


                                        Коммитит плохой код

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


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

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


                                        Ломает билды — пусть чинит. Один раз сломал — ошибся со всяким бывает. Поддержать, обучить, прикрепить к более опытному коллеге, чтобы учился. Если не учится и продолжает ломать билды — подсчитать убытки (кол-во сотрундиков, вынужденых пинать баклуши = x, цена рабочего часа одного сотрудника = y, кол-во потерянного времени z:
                                        x y z = $ потери в деньгах — если эти потери больше чем рассходы на найм нового сотрудника — есть смысл пообщаться с руководством на тему замены человека.

                                        • 0
                                          Часто это может быть минусом. Хороший тех. спец часто бывает перфекционистом.

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


                                          Плохой код — переводится как код, который не нравится вам.

                                          Плохой код — переводится как код, который или сам не работает, или сам работает, но ломает что-то другое, либо и то, и другое

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

                                            Вы понимаете, что это субъективно?


                                            Плохой код — переводится как код, который или сам не работает, или сам работает,
                                            но ломает что-то другое, либо и то, и другое

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

                                            • 0

                                              Конечно.


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

                                              • 0

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


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

                                                • 0
                                                  и вы, судя по вашим словам, не готовы содействовать

                                                  Почему не готов? Готов потратить кучу времени на объяснение своих ожиданий от сотрудника как организационных, так и технических.

                                                  • +1
                                                    Почему не готов? Готов потратить кучу времени на объяснение своих
                                                    ожиданий от сотрудника как организационных, так и технических.

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


                                                    Ваша задача как управляющего коммандой — сделать так чтобы член комманды был эффективен. Как вы этого добъетесь — ваш выбор. Вы можете его обучить, запугать, подбодрить, перевести на другую задачу, и еще миллион вариантов по вашему усмотрению. Я перечислил 4 способа просто из головы, за все комментарии в этой статье вы предложили только два — дать денег или выгнать. Оба способа, предложенные вами — экстремальные. Уволеный сотрудник — это личный фейл руководителя, за исключением сокращений — тогда это фейл департамента развития бизнеса. Фейлы бывают — ничего не поделаешь, но вы же хотите стать руководителем специально для того чтобы фейлить.

                                                    • 0

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

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

                                                        Да не в технологиях и процессах дело. Люди могут, но не хотят.

                                                • 0
                                                  Потому что это надо настраивать дженкинс, надо внедрять ревью, надо менять процесс, надо договариваться, надо уметь аргументировать свою точку зрения. Если тимлид хороший, он этим и занимается.

                                                  Если же он стал тимлидом потому что других не нашлось, то ничего кроме права запрещать доступ к репе и махать угрозой увольнения ему в голову не приходит.
                                                  • 0

                                                    Зачем мне дженкинс? У нас ютрэк и ревью я занимаюсь.


                                                    С кем и о чём договариваться? Договоренность это "ты мне — я тебе". Что я могу дать сотруднику? Разве что в бар его сводить за свой счёт.


                                                    Ещё мне в голову приходит дать ему премию, например, или поднять зарплату, если вижу, что он по сайтам вакансий лазит.

                                            • 0
                                              Мне кажется вам надо пересмотреть требования к новому коду.
                                              IMHO юнит и интеграционные тесты должны запрещать возможность переноса кода в мастер-ветку.
                                              Так же ревьюверы кода должны недопустить просто некачественный код в репозиторий. Тут можно или ждать 1+ разрешений от любого из сокомандников или как минимум 1 от проверенных разработчиков (архитекторов, сеньоров. лучше, если по каждому из языков будет получаться допуск к ревью, т.е. люди не следующие рекомендациям не смогут протилкивать коммиты друг друга).

                                              Простите, если поднял старую ветку — давно тут не был ^_^
                                              • 0

                                                Про мастер-ветку речи даже не идёт, исключительно о дев-ветках. И ревьювер я один.

                                                • 0
                                                  Т.е. ломаются ветки фич?
                                                  Может стоит запретить коммитить в них напрямую — только через pull request?
                                                  Я уже долго работаю по принципу отдельная ветка на каждую фичу — никаких проблем со сломанным чужим кодом давно не было.
                                                  • 0

                                                    Или ветки фич, над которыми работают два и более разработчика одновременно (банально фронт и бэк), или общая девелопмент ветка, куда сливаются фичи самими разработчиками.

                              • +3
                                Мой классический ответ на предложение занять подобную должность: у меня нет управленческого образования — оплачивайте и ждите. Пока, максимум, курсы предлагали на пару месяцев без отрыва от производства.

                                Два месяца — это же прекрасно :) Хорошие курсы, да за два месяца, да при постоянной практике, дать могут ого-го сколько!

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

                                Я вижу, что при хорошо построенных процессах и атмосфере в команде, ну и до определённого размера команды, конечно же, все же остается вариант «hands-on» работы, где остается достаточно времени на сохранение технической квалификации. Однако, конечно, есть вероятность и того, что погрузиться в управление придется полностью, и тут уже нужно выбирать :)

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

                                Согласен полностью, без мотивационных инструментов работать намного труднее.
                                • 0
                                  Я нашел для себя баланс в должности principal software developer. Минимальный менеджмент команды за счет менеджера в подчинении и можно сфокусироваться на техническом аспекте :)
                                • +1
                                  предложения были связаны с полной ответственностью за результат команды, но без права как-то заметно решать вопросы материальной и административной мотивации

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

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

                                    • 0
                                      ну тогда два варианта:
                                      — у этих людей слабая связь с реальным миром
                                      — у вас недостаточная аргументация

                                      Какой вариант вам ближе? )

                                      ну и в моем мире разбрасывание задач — это лишь малая часть работы тимлида
                                      • 0

                                        Я ещё и аргументы должен подыскивать кроме как "не справляется с работой" или "очень хорошо справляется с работой, сильно пожалеем если уйдёт куда-то на бОльшую ЗП"?


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

                                      • 0

                                        Что-то, VolCh, помню, как вы отвечали на какой-то мой пост, имея в виду коммуникационную проблему, что представляли людей как чёрные ящики и не знали, как добиться от них детерминированного поведения. Проблема коммуникационная, а вовсе не в курсах или отсутствии рычагов.

                                        • 0

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

                                          • 0

                                            Эти меры — это "оружие судного дня". В 99.99% случаев им не пользуются.

                                  • +1
                                    >не может не вдохновлять атмосфера, где поощряются взятие на себя большей ответственности и продуктивная работа

                                    повезло, в основном работает принцип «кто везет на том и едут»
                                    • 0
                                      повезло, в основном работает принцип «кто везет на том и едут»

                                      Если я правильно понял, Вы о ситуации, когда ответственностей «накидывают» больше и больше, но не дают обратной связи по результатам. В таком случае, это вопрос не везения, а сознательного выбора компании.
                                      • 0
                                        повезло работнику (Вам), что в вашей компании это не так. Обратная связь требует вовлечения в процесс тех, кто над вами, а это им сложно и менее интересно, чем другие дела.
                                        • 0
                                          Я все же ещё раз хочу сказать, что это не везение, а осознанный выбор такой компании :)
                                          • +1

                                            Повезло, что такая компания вообще попалась в процессе поиска :)

                                            • 0
                                              С вашего позволения немного встряну.
                                              Думаю, что слово осознанный здесь лишнее, чаще это неосознанный выбор компании как коллективного бессознательного.
                                              • 0
                                                Если речь про мой случай, то выбор был именно осознанный :)
                                            • +1

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

                                          • 0
                                            Это очень хороший принцип!
                                            Он дает Вам полное моральное право требовать больше:
                                            — Больше зарплату
                                            — Лучше условия
                                            — Больше подчиненных
                                            — Больше интересных задач
                                            — Больше опыта

                                            А если на такие требования отвечают отказом, то это самый главный сигнал о том. что нужно менять работу.
                                          • 0
                                            На сколько %% зп тимлида выше разработчика?
                                            • +4
                                              Очень сложно ответить на такой вопрос.

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

                                              На мой взгляд, нужно просто понимать, что должность тимлид — это старт карьерной лестницы в управлении, а там и другие метрики оценки, и совсем другое развитие.
                                              • 0
                                                Вопрос простой, связан ли ваш переход в тимлидерство с повышением личной материальной составляющей или только из-за желания потребовать для кого-то недооцененного ))
                                                • +1
                                                  Я перешел в тимлидство потому, что мне нравится и хочется этим заниматься :) Да и после определённого уровня зарплата перестаёт становиться основным мотивирующим фактором, важнее становится уже другие вещи — challenge и рост, например. По крайней мере, для меня так.

                                                  Ну а правильный рост оценивается и материально тоже.
                                                  • +3
                                                    Ощущение, что ваши ответы контролирует ваш непосредственный начальник, корпоративный блог, этика и все такое. Главное Вызов! Вперед! Ура!

                                                    Вы указали, что ранее ваш день длился 11-14 часов, как сейчас обстоит с этим дело?
                                                    Как часто случаются переработки и по каким причинам?
                                                    Сколько % времени занимает менеджерская работа, а сколько техническая (с кодом, технологиями)?
                                                    • +1
                                                      Думаю, мой начальник не выдержал бы нагрузки, если бы приходилось контролировать такие мелочи. Не понимаю, почему мотивация на challenge у Вас вызывает какой-то сарказм, честно. У всех разная мотивация же.

                                                      Про время — сейчас я работаю с 9 до 7, иногда и раньше ухожу. Переработки случаются тогда, когда ну уж очень интересное что-то делаю и не могу оторваться :)

                                                      С кодом последние полгода не работаю вообще, но планирую в этом квартале уже начать выделять время.
                                                      • +1
                                                        Личный вопрос, можете не отвечать, если сочтете некорректным: как к вашей 10 часовой работе относится семья?
                                                        • 0
                                                          И еще вопросик. Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании?! Может ли тимлидом быть чел. с немаксимальными техническими знаниями, как он будет принимать решения?
                                                          • 0
                                                            Как думаете кто больше подойдет для тимлида: великолепный разработчик с посредственными коммуникациями или посредственный разработчик душа компании

                                                            Мне сложно ответить «абстрактно» — как лидерские качества, так и технические знания можно наработать, а вот требуемые на это инвестиции ресурсов будут очень различаться в зависимости от требований бизнеса к этой роли и от личностей кандидатов.

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

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

                                                            Принимать решения он может, например, основываясь на максимальных технических знаниях кого-то из подчинённых. Безусловно, это может вырасти в проблему, но можно стараться находить всякие обходные пути. В любом случае, лучше иметь хороший баланс — и большой общий технический опыт, и хорошие знания в предметной области, и лидерские качества.
                                                          • 0
                                                            Семья понимает, что для меня работа — очень важная составляющая жизни, далеко не только средство зарабатывания денег, и так было всегда :)
                                                  • 0
                                                    Насчет старта карьерной лестницы. Мне кажется, что тимлид это довольно специфичная ступенька. Тимлид сам разработчик, а выше в иерархию начинают подмешиваться выходцы из всех прочих специальностей (QA, аналитики, PM и т.д.) и совсем другая конкуренция, где технические знания значат гораздо меньше разнообразных business skills.
                                                    • +1
                                                      Тимлид сам разработчик

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

                                                        А у нас вообще дизайнер одно время был, а я при нём техлидом, решающим технические вопросы.

                                                        • 0
                                                          Тут уже тонкий вопрос терминологии, но, имхо, дизайнер, поставленный над программерами, — это уже менеджер.
                                                          • 0

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


                                                            Или мы с "менеджером" взяли обязанности тимлида и чётко поделили на технические и нет?

                                                          • 0
                                                            Воистину. Сейчас норма, что тимлид вообще никогда код не видел(ну может в институте) зато МВА, аналитик который в аналитике вообще не смыслит, а уж куча всяких с приставкой Digital-хсгоры вообще море
                                                          • 0
                                                            Это конечно. Правильнее было сказать — тимлид вышел из разработчиков.
                                                        • +1
                                                          >>На сколько %% зп тимлида выше разработчика?
                                                          >Очень сложно ответить на такой вопрос.

                                                          И все же, как повлияло взятие на себя обязанностей тимлида на вашу ЗП?
                                                          Как вы думаете на сколько должна изменятся ЗП после «навешивания лычек TL»?
                                                        • 0
                                                          Все очень зависимо и от условий и от обязанностей, ответственности.
                                                          Может вообще не отличатся — команда из 3х синьеров, один выполняет роль лида(связующего звена с клиентом).
                                                          А может отличатся на порядок(команда джунов и лид) в Украине зп новичков начинается от 300$, синьеры/лиды — 3-4К$ далеко не редкость.
                                                        • –1
                                                          С точки зрения мотивации статья хорошая, она говорит что старайся и всё получится, с точки зрения информативности — никакая. Вы что-то делали для того, чтобы стать тимлидом? Как-то развивались? Какие трудности для вас были в этом направлении?

                                                          Я не вижу сколько-нибудь значимой информации на эту тему. Статью понимаю так так: если проработать пару лет на одном месте предложат должность. Раствор резюме в воде. Раствор истории успеха в воде с ароматизатором Лондон идентичным натуральному. Раствор общих принципов руководства в воде. Ссылка на вакансии.

                                                          Особенно мне понравился это пассаж:
                                                          «во всём мире уже давно очевиден тренд роста мобильного потребления контента»
                                                          Вы своим подчинённым так же задачи ставите?
                                                          • +2
                                                            а вы точно статью прочитали?.. там про трудности написано в разделе про особенности.

                                                            и про проработать пару лет на одном месте: автор очень четко описал, что было достигнуто за _один_ год. Считайте такие достижения шаблоном целей, которые должен ставить перед собой тим лид. Они достаточно универсальны.
                                                            • +7
                                                              А вы точно комментарий читали? Давайте ещё раз, более конкретно выражу свою критику.

                                                              Статья называется «Как я был разработчиком, а теперь тимлид». Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом. Никаких сведений на эту тему нет. Зато красной нитью проходит мысль — пара лет и ты тимлид. Не по каким-то причинам, а просто потому, что в далёкой-далёкой галактике вуки ударил ногой в бубен.

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

                                                              Постепенно продуктовой нагрузки становилось всё больше, и я «оброс» двумя подчинёнными

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


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

                                                              Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».

                                                              Но это чертовски плохой маркетинг. Посмотрите на статьи о лазерной коррекции зрения. Я вообще не разбираюсь в микрохирургии глаза, тем не менее статьи на эту тему читаю на Хабре с удовольствием и даже задумываюсь об операции. Потому, что пишут не копирайтеры, а врачи, которые описывают СВОЙ опыт, описывают интересно и подробно, а не по конспектам пятичасового выступления бизнес-тренера. Это прекрасно читается между строк и сильно влияет на восприятие компании. Статьи профессионалов в написании статей никому не интересны, зато реальные истории реальных професионалов читать всегда увлекательно, пусть даже они пишут о непонятных для тебя вещах.

                                                              • 0
                                                                Люто плюсую. Мотивационная статья из разряда «Я уеду жить в Лондон… мне Москва будет сниться ...»
                                                                • +1
                                                                  Лично мне кажется, что в статье должен быть раскрыт процесс того, как и почему разработчик становится тимлидом


                                                                  В этой статье я рассказываю только о себе, а опыт у меня вот такой, вы уж не обессудьте :)

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

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

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

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

                                                                  Статья очевидно маркетинговая. Она прошла через редактирование, причём, вероятно, весьма серьёзное. Она максимально обезличена. Если пропустить историю человека, то часть про сложности управления я бы счёл заказной статьёй для ответственного копирайтера, который слово «тимлид» загуглил три месяца назад, потому, что «во всём мире уже давно очевиден тренд роста потребления контента о тимлидах».

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

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

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

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

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

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

                                                            • 0
                                                              А что за «тренинг по курсу теории ситуационного управления»?
                                                              • +1
                                                                Мы занимались у Натальи Зверёк http://bc-expert.ru/corporate/trainers/zverok/ и у James Brook http://www.strengthspartnership.com/people/james-brook/

                                                                Вот Наталью как тренера очень сильно рекомендую, программу она подберет сообразно бизнес-требованиям и запросам идеально.
                                                              • 0
                                                                Ещё до начала кризиса доткомов работал в команде единомышленников. Человек 5-6, каждый был начальником в рамках компетентности.

                                                                Почему так лучше.
                                                                Отношение стоимости проектов к оплате труда работников — Бывает и 100 к одному. Сто евро работа — 1000 евро стоимость проекта.

                                                                Хрестоматийные примеры.
                                                                Шведская компания Crisp управляется без начальства уже 3 года.
                                                                Интернет-магазин Zappos с 1,5 тысячами сотрудников.
                                                                Ким Ир Сен давно умер и стал вечным президентом. Северной Корее теперь живой президент не нужен.
                                                                Директор Фунт с дореволюционных времен — номинальный руководитель фирм.
                                                                • +3
                                                                  Из описания к одной из вакансий: «Мы рады за наших коллег, которые становятся родителями: +две недели оплачиваемого отпуска и 30 000 р. на первые погремушки:)»

                                                                  За это отдельный респект! Продвижение семейных ценностей на любом уровне очень важно в наш «европейский» век.

                                                                  • +2
                                                                    ты бессознательно начинаешь искать себе «помехи» — соцсети, новостные сайты, мессенджеры

                                                                    Так, будучи тимлидом, я попал сюда:)
                                                                    Спасибо за статью, почерпал для себя несколько важных тезисов.
                                                                    • –16
                                                                      ТИМЛИД, ТИМБОТ, ТИМДАУН…
                                                                      Пиши на английском, что ты на русском то пишешь!
                                                                      • 0

                                                                        Бригадир? :)

                                                                        • 0
                                                                          Бригадир — из французского пришло (
                                                                          Начальник артели (начарт) — вроде ок.
                                                                          • +5
                                                                            Артель — из итальянского пришло, от arte. Может вождь дружины? :)
                                                                      • –2
                                                                        из статьи не очень понятно — зачем все это надо?
                                                                        командуя 12 людьми очень сложно оставаться технически подкованным
                                                                        • +9
                                                                          статья о том, как заработать больше денег, а потом писать мемуары на хабре
                                                                          • +2

                                                                            Если ты хочешь написать кусочек системы — то незачем. Если ты хочешь создавать всю систему — то тебе нужны помощники.


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


                                                                            Если ты участвовал в 20 продуктах и не видел разницы между SCRUM-ом и скрабом, или RUP-ом и рупором или Agile-ом и Ajax-ом — то поять же незачем. А если ты видишь, что в каком-то месте разработчики (в том числе и ты) теряют кучу времени и знаешь как исправить — то это способ.

                                                                          • 0
                                                                            Отличная мотивирующая статья не более.
                                                                            • +1

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

                                                                              • +2

                                                                                Это рост. Из-за того, что увеличивается зона ответственности. Но это не единственный карьерный путь.

                                                                              • +5
                                                                                Там сидит по деревом
                                                                                Доктор Айболит.
                                                                                Он фулл стак девелопер
                                                                                И фулл тайм тимлид!
                                                                                • 0
                                                                                  Сам по себе рост численности команды не является позитивным результатом для бизнеса, зря Вы его поставили на первое место в достижениях. Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).
                                                                                  • 0
                                                                                    Сам по себе рост численности команды не является позитивным результатом для бизнеса

                                                                                    Вы абсолютно правы. Рост численности команды — один из вариантов того, как можно справиться с увеличением нагрузки. Упомянул я его исключительно для того, чтобы показать retention.
                                                                                    Я бы посоветовал объединить в будущих отчётах первый и второй пункты и говорить, что раньше производительность труда составляла одну фичу в месяц на разработчика, а теперь более трёх (кстати, это к вопросу об обосновании повышения зарплаты).

                                                                                    Так и делаем :) У нас отчеты перед руководством совершенного иного формата, исключительно о результатах, имеющих измеримый business value.
                                                                                  • +1
                                                                                    глядя на окружающих меня менеджеров я подозреваю, что вы — первый и единственный в мире их представитель, который вообще задумывается о подобных вещах :)
                                                                                    • 0
                                                                                      К счастью, не первый и не единственный, но раз контент интересный, буду продолжать писать :)
                                                                                    • 0
                                                                                      Виталий, какие перспективы карьерного роста у разработчика, который не хочет перекладывать бумажки в jira?
                                                                                      • 0
                                                                                        Vearutop, не совсем понимаю про «перекладывание бумажек в jira» :)

                                                                                        Перспективы роста разработчика очень сильно зависят от компании. Навскидку: расти в сторону технического лидерства, можно брать большие проекты и вести их, брать на себя целые направления межкомандные (скажем, становясь спецом по безопасности).
                                                                                      • 0
                                                                                        Есть довольно прикладной вопрос — а какую литературу вы изучали в рамках освоения на новой должности?
                                                                                        • 0
                                                                                          Всего несколько книг:
                                                                                          • Одноминутный менеджер (мотивационное про делегирование и ответственность)
                                                                                          • Management Of Organizational Behavior (собственно теория)
                                                                                          • почти все на HBR https://hbr.org
                                                                                          • 0
                                                                                            Спасибо большое. Поинтересуюсь.
                                                                                        • +2

                                                                                          Короче, становитесь тимлидом. И у вас будет много личной экспертизы и жидкого стула для статей :/

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