Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 35
Насчет токсичных талантов мне в принципе не нравится такое разделение. Токсичность -- это как с быдлом: оно всегда не ты...
Был у меня коллега-подчиненный, категорически отказывался давать на ревью свой код, не придерживался никаких гайдлайнов и кодстайлов. Сроки срывал всегда (собственно ничего полезного так и не сделав). Мне однажды попалась его страничка в линкедине: там в первой же строке он описывает себя как очень хорошего командного игрока. Причем, полагаю, что он искренне в этом был уверен, а меня считал токсичным тимлидом, мешающим ему работать... Звезд с неба, кстати, не хватал, так что талантом не был. И вот теперь вопрос: кто из нас токсик?
Теперь рассмотрим ужасный 30-летний легаси код, который все больше трещит по швам. Менеджер (отработавший в проекте 26 лет) настолько консервативен, что категорически отвергает любой рефакторинг. Человек, присоединившийся к команде 3 года назад, видит деградацию и предлагает решения по улучшению. Кто из них токсичен? Тот, кто критикует устаревшие и откровенно плохие решения (предлагая выход), или тот, кто видит основной целью удовлетворение пожеланий заказчиков (которых рефакторинг не интересует, и потому на повестке дня его не стоит)? А кто из них командный игрок? Кто больше за проект? Кому менее все равно?
ну у нас уже была эта дискуссия в комментах к прошлому посту - мне кажется, мы по-разному токсичность понимаем.
Для меня вот тут:
> Тот, кто критикует устаревшие и откровенно плохие решения (предлагая выход), или тот, кто видит основной целью удовлетворение пожеланий заказчиков (которых рефакторинг не интересует, и потому на повестке дня его не стоит)?
нет токсичности - а есть обсуждение рабочих моментов. У каждого свои поинты есть – в зависимости от разных факторов верным в моменте может быть и оставить как есть и инвестировать в рефакторинг, чтобы потом не огрести проблем.
Токсичность – это когда человек отказывается быть как раз командным игроком и свои мысли как-то аргументировать. Звездность и талантливость это обычно ухудшают и увеличивают масштаб проблем - пример, как это в реальности бывает, я в посте привел.
Вот в точку. Обычно люди именно аргументацию воспринимают как токсичность. Ты ведь своей позицией покушаешься на их правильную точку зрения - ты токсичный.
Вот я и пытаюсь донести мысль, что даже самый по всем параметрам токсичный сотрудник на самом деле таковым считает вас. А понять аргументацию талантливого человека -- намного сложнее, чем считать, что он отказывается от аргументации.
Человек либо аргументирует либо нет. Я плохо понимаю как можно аргументацию талантливого человека считать, что ее нет? Если человек аргументирует, то не важно талантив он или нет.
Я не то чтобы кардинально с вами не согласен, скорее даже наоборот. Просто у меня на виду примеры того, когда аргументацию даже не хотят услышать. Да и вспомните хотя бы как во все времена относились к гонцам, приносящим плохие (но правдивые) вести. Ну или про судьбу Кассандры.
А самым моим любимым примером гениев, чью железобетонную аргументацию категорически отвергали, является Игнац Филипп Земмельвейс, человек, которого сейчас потомки зовут "спасителем матерей". Просто он заметил, статистически (а потом и эксперементально) аргументировал, что в родильном отделении, где врачи с утра посещают морг, а потом, лишь ополоснув без мыла руки, навещают рожениц, смертность от родильной горячки в разы больше, чем в отделении, где врачи морг посещают уже после общения с живыми. Почитайте его историю: уж кого, как не его, при жизни считали токсичным и умалишенным. Плохо, кстати, кончил. Между прочим, у оппонентов тоже была аргументация, что в Библии все описано не так, как рассказывал Земмельвейс. Так что я очень осторожен в употреблении слов "гений" и "токсичность" в одной фразе.
Я фанат человека паука, так что как говорил дядя Бен: «С большой силой приходит большая ответственность» :)
И когда звездный сотрудник не хочет слышать аргументы других людей просто по факту наличия большого таланта, а только хочет делать то, что считает нужным - это проблема тк вред от такого поведения в его случае больше, чем могут нанести другие члены команды.
Талант в разработке? Позвольте уточнить, что такого звездного может разработчик, только если это не rocket science в каком-нибудь openai?
p.s. в школе у нас была сильная математика и где-то с 8 класса я писал контрольные за 10 минут и сидел помогал соседям. Мне преподаватель тогда сказала: в детстве - вундеркинд, в юношестве - гений, в молодости - ты одаренный, а в зрелом возрасте ты обычный человек. Я с ней соглашусь сейчас, когда мне 40 😆
Это я к тому что 99% задач требуют знаний и опыта, а талант нужен олимпиады решать.
Очень даже просто. Вопрос приоритетов. Вот владелец стартапа - качество кода - да ну его. Нам на этапе стартапа важнее скорость. Сидит 1 CTO, и понимает, что в перспективе людей больше не будет. Если не построить всю обвязку с контейнерами и CI/CD, то ты просто повесишься. Потому что это ведёт к давай быстрей, и отсутствие нормальных инструментов и автоматизации загоняет тебя в порочный круг мануальной рутины из которого не вырваться. Мануальные тесты, мануальный репортинг, сбор метрик и т.д. бизнес не считает это за работу. Это некая магия которую можно сделать за секунды. А на практике ты просто зависает в море цифр и либо начинаешь клепать ошибки, либо тратишь на это все свое время.
Ну попробуйте объяснить это бизнесу, я пытался раз 10. Ни разу не удалось.
А все почему, когда людям говоришь про PMBoK, на тебя смотрят с широко открытыми глазами. Про тактику и стратегию, на тебя смотрят с широко открытыми глазами. Про долгосрочное планирование, на тебя смотрят ... Ну вы поняли.
Люди приводят доводы, проблема в том, что даже чтобы их услышать, не говоря о том чтобы понять - нужно обладать хотя бы соизмеримыми знаниями с собеседником. Если между вами пропасть, вы не договоритесь, сколько бы вы на одном языке не разговаривали.
Это как вы обсуждаете материаловедение и FEA, а собеседник не то что Теор Мех с Высшей Математикой не учил, так он ещё и школьный курс алгебры и геометрии прошёл мимо. Ну и как вам договориться?
Про долгосрочное планирование,
я говорю про early-stage стартапы - где вы ищете product/market fit, делаете кучу экспериментов и сегодня у вас может быть идея делать приложение для упрощения сбора задолженностей коллекторами в UK, а через пару месяцев выясняется, что продукт нужен госпиталям в США чтобы лучше собирать плату за услуги со страховых компаний (реальный пример).
Какое долгосрочное планирование в таких условиях вообще возможно? И как еще должно выглядеть все с тз IT кроме полумануального режима до момента, когда ниша хотя бы утвердилась?
Долгосрочное планирование - нужно любой компании. Если ее прогнозируемый срок жизни больше года. Если, вы признаете что компания просуществует год то закроется если не будет продана, то какого отношения можно ожидать от сотрудников? Они в условиях, что чтобы ни случилось, через год искать новую компанию, а может и раньше. Ну и кроме того, они то работают за зарплату, а не за потенциальные 10%+ от продажи компании. Потому стартапы и платят выше рынка, потому что для сотрудников - это повышенные риски. Энтерпрайз компании могут просуществовать гораздо дольше, поэтому риск остаться без работы меньше.
Ну а если план делать мануально - надо понимать, что тут нужно много низкоквалифицированных сотрудников с минимальной ставкой. А не начинать с 1-2 высококвалифицированных.
План выглядеть будет примерно так:
1 год. Берем студентов пилим как попало, определяемся с нишей. Не тратится на тулы и бест практис. Репортер так же не окупиться ввиду низкой стоимости сотрудников. Получаем, PoC и строим дальнейший роадмап продукта.
2 год. Берем Архитектора и переделываем весь процесс, еще пол года уйдет на стафинг, потому что стартап, не все захотят пойти. Определяем тулы, строим CI/CD и репортер с мониторингом. Начинаем переписывать продукт.
3 год. Приводим в порядок продукт по процесам.
ну видно, что вы не занимались запуском стартапов венчурных :) Все работает вообще по-другому. Прям все тезисы неверные:
компания в первые год-два ищет нишу и делает кучу экспериментов, в результате чего бизнес модель завтра может быть на 180 градусов от того, что вчера было
сотрудники это понимают, но также понимают и что возможные выгоды от роста перевешивают, и потому работают - и работают обычно за ниже рынка в зп, но у них есть опционы с существенными долями - проценты equity для первых ключевых людей
и чтобы делать и быстрые итерации и держать качество - эти люди как правило должны быть сильными, а не студентами
при этом упражняться в визионерстве и планировании на годы надо - потому что иначе не дадут инвестиций, но это именно что упражнение, и нормальные инвесторы тоже будут без обид, когда через неделю после транша вы придете и расскажете, что теперь у вас все поменялось, продукт и клиенты, и все по-другому – и покажете цифры, которые это подтверждают
Существенная доля это сколько?
Мне попадались, только что-то до 1,5% доли. И то с кучей условий, которые делают их получение скорее теоретическим.
Кроме того, продукт продуктом. Но не меньшую роль играет установка процессов в самой компании.
И тут начинаются все нюансы. Если разработчик вообще 1 он же СТО, он же архитектор. То нет смысла вкладываться даже в git сервер. Можно локальный поднять с бекапами. Если есть более-менее команда, хотя бы человек на 5 то тут уже нужен сервер, Task Manаger, писать вменяемый комментарии на коммиты. Если люди еще и в разных тайм-зонах с процентом пересечения не более 40%, то тут уже нужно культуру документации прививать, иначе они будут сидеть по пол-дня ожидая других, чтобы узнать что вчера такого случилось, что теперь перестало работать. Или сидеть разбирать логи теже пол дня, чтобы понять. Вместо того чтобы прочитать за 15 минут. В случае одной тайм зоны - еще можно позвонить.
И вот эти все организационные заморочки и съедают львиную долю времени, вместо того чтобы работать над продуктом. Часто видел прыжки с одного Task Manager на другой без видимого профита, просто новому сотруднику так привычней, а других нужно всех переучивать. Или вообще на это забивают. Тогда нет нормальной коммуникации и все сотрудники в постоянном стресе. А потом удивляются, что они такие токсичные? Так их просто сделали такими, поставив в условия, где только так можно выжить не поехав кукухой.
Дайте разработчикам и тестировщикам более-менее удобные и стабильные инструменты и понимание размера команды. Тогда они и не будут такими токсичными.
Переделывать продукт и его архитектуру - это нормально для стартапа. А вот когда сама компания перестраивается по 20 раз на месяц - это уже диагноз нездоровой компании.
если вы founding member - о чем мы тут говорим тк я пишу про early-stage проекты (только запускаемся, и вы первый инженер), то бывает больше. У нас например, около 5% главный инженер получил в итоге долю и даже статус кофаундера в какой-то момент.
Про документацию, к сожалению это будет работать только, если мы сейчас на этапе продажи каким-то внешним клиентам сложной интеграции (например, мы продавали grammar checker api/sdk - там доки были хорошие). А когда у нас куча экспериментов по b2c - никто не будет писать документацию тк в этом нет практического смысла - ее обновлять будет невозможно. Даже хелп центр в раннем проекте оч сложно поддерживать.
То есть стресс и неопределенность – это специфика. Если у человека ментальность «меня поставили в такие условия, поэтому я веду себя как говно» – он не нужен в этом стартапе тк это детское поведение, надо было взвешивать риски до принятия оффера. Никто ж не говорит, что работа в стартапе – это история для всех, совсем нет.
Стартапы бывают разные. Т если с человеком на берегу не обсудили эти моменты, то он вообще не обязан был на них закладываться. То что потом возникло несовпадение ожиданий - не так это ожидаемо, что непроговоренные вопросы - вылазят боком.
Человеку не место в компании, ну так и компании не место в его жизни.
Так бывает, как стартапы выживают 1 из сотни, так и людив них не всегда приживаются. Когда-то сотрудники промахтваются с выбором, а часто и не могут им. Объяснить на собеседовании чего ожидать, в надежде, что все видят стартап одинаково и без обсуждениях.
Ну любой стартап какой бы ни был, все равно нервное мероприятие и нестабильное. Ключевые моменты всегда должны обсуждаться, но всего не предусмотреть, и поэтому потом все равно человека будет видно. Главное быстро это понимать и расходиться с теми, с кем видно уже не по пути - так будет лучше всем, вы абсолютно правы. И это то, что мне было тяжело делать, но я научился :)
Хорошая статья и полезное обсуждение про токсичность. Мои пять копеек для формирования понятия токсичный. Имхо, если токсичный отказывается быть командным игроком, то проблемы нет. Он снаружи команды. Скорее токсичный это тот кто изображает "командность", но на самом деле команду разрушает. Как подвариант, когда его втащили в команду, но он не в команде. Он просто винтик в найме и чего ему не вести себя как хочется?
Кажется, что лишний термин. Или человек часть команды или не в команде (винтик) или внутри команды но сознательно работает на разрушение. Можно быть в компании и отказаться быть в команде, такие люди всюду есть и почему твой вахтёр должен быть в команде. Хорошо конечно, но не обязательно.
Токсичность - плохой термин. Он всего лишь описывает негативную реакцию на изменение ожиданий. Я бы преддожил от него отказаться вовсе и оперировать терминами: лучшее решение, причины и ожидания. Может еще чего-то стоит добавить.
В этом ключе у вас было бы так.
1) Был коллега-подчиненный, который нарушал все ожидания в компании. Он запретил ревьювит свой код, хотя в было установлено формлатное правило. Далее нужно ответить на вопрос почему для него и для вас такое положение дел было лучшим решением. Понятно, что за изменениями буду какие-то эмоции, но термин токсичность заводит в тупик и не дает ответов на вопросы.
2) Менеджер отказывается вносить изменения и принимать риски на себя. Он ждет, что все и так будет работать.
Остается ответит на вопрос почему для него это лучшее решение. И почему вы считаете лучшим другое. Опять же если мыслить категориями токсичности, то встаете в тупик, так как любое изменение, которое кто-то не поддержал становится токсичным.
Он всего лишь описывает негативную реакцию на изменение ожиданий
Ну не обязательно так. В случае стартапа звездный инженер просто может в какой-то момент начать себя вести так, будто это его компания – и хотеть делать что-то, что даже может быть и имеет какой-то смысл с тз технологий, но вообще противопоказано с точки зрения выживаемости компании.
В итоге была, например, ситуация, когда нам надо делать релиз и планировать маркетинг, а для этого надо как-то принимать деньги от юзеров. Инженер хочет делать свой биллинг тк Stripe и Braintree говно и все едж-кейсы, что он хотел, не обрабатывали на тот момент. То что это займет месяцы, прожить, которые нет денег – не его проблема, а решить ее должен СЕО. В итоге он подчинился аргументам, но это был кирпич в решение расстаться (обоюдное, кстати) после очередной истерики о том, что «мне стыдно сказать что я тут работаю, настолько дерьмово все под капотом у нас».
Вот вы почему-то продолжаете увязывать понятия "звездный" и "токсичный". Весь этот геморрой, вами описанный, может исходить и от совершенно ординарного сотрудника (и, как правило, именно от таких и исходит). Да, конечно, в изначальной формулировке принцип звучал как "если звездный начинает быть геморройным, то не стоит смотреть на звездность"... Но вот я в своей карьере не помню ни одной звезды, чтобы уж совсем так. Зато целый паноптикум случаев, когда посредственности даже не пытались прислушаться к человеку, превосходящего по интеллекту или опыту, сразу записывая в токсичные.
Вы почему-то читаете так, что раз я говорю о токсичных звездах, значит я всех выдающихся в чем-то сотрудников считаю токсичными и призываю только с серыми мышами работать. Видимо потому что это как-то резонирует с вашим опытом, когда вы с его высоты пытались сделать как лучше и не нашли понимания у менеджмента – я вообще не о таких ситуациях говорю, уже несколько примеров привел
Вот в вашей терминологии это было бы токсичным поведением инженера. Или непонятно кто токсичный.
В моей нужно разобраться почему он так решил и готов ли двигаться в своих ожиданиях. Нет ярлыков вообще. Не справился со своими эмоциями и решил пойти туда, где все на его взгляд хорошо. Ну и слава Богу.
Тот же самый конфликт описывается более точным словами. Не нужно искать кто токсичный: владелец или инженер. Достатачно понять, что не сошлись в ожиданих по продукту.
Я просто пишу для основателей – если видите, что в вашей картине мира поведение сильного инженера токсичное, то риск слишком велик. Дальше кто что с этим делает – это уже конкретный выбор конкретного человека. Нет смысла думать о том - а на самом ли деле чел токсичный или мне так кажется - это стартап, надо двигаться быстро, всем смотреть в одну сторону. Я для себя сделал вывод, что в следующих проектах терпеть такое не буду
Тоже очень непонятно с токсичностью, командной работой, к чему эти размытые определения? Есть просто некая минимально-базовая дисциплина нарушение которой, особенно неоднократное - на мороз...
а что именно непонятно?
Про на мороз - понятно в теории, на практике почему-то оказывается не так это просто, особенно в маленькой команде стартапа, где вы только запустились. Собственно, о таком опыте и пост.
Где токсичность если это нарушение дисциплины? Дисциплина не в смысле на 5 минут опоздал, можно даже не появляться на работе если у тебя всё сделано четко и в срок, а если не сделано - то сообщено что да как. А расзвездяй, который без полицейского с дубиной стоящего за спиной ничего не делает это горе и для коллег и для предприятия(есть исключение - отправлять на "грязную", неответственную работу, тогда еще ничё), при этом он может быть абсолютно не токсичным. Но можно и копнуть глубже - например, а не строились ли отношения с ним изначально по принципу - ну сделай когда сможешь, а мы как сможем заплатим? А потом вдруг что-то с него требовать стали - тогда вообще другая картина... и совет будет другим - обговаривать условия заранее, вот сейчас будет как только, так сразу за столько денег, а потом как положно, но за столько денег.
если человек при этом устраивает истерики в виде «вы просто не заботитесь о качестве, мне стыдно работать над таким продуктом» - параллельно с проблемами в области дисциплины, чем это не токсичность?
Финансово отношения всегда со всеми сотрудниками у меня строились так, что задержки могут быть у кого угодно из команды фаундеров, но не у инженеров.
не работали в стартапе? то что вы говорите - это в корпорациях пройдет, где ,при правильной организации, есть определенная рабочая избыточность. а специфика стартапов что там бусфактор мизерный и, как правило, не стоит очередь подходящих скиластых ребят, готовых тащить и кранчить за некую туманную перспективу. ты его конечно можешь на мороз - но будь готов идти на мороз следом. потому коллектив и подбирается ... гм, атмосферный и специфический и есть сильная склонность к звездообразованию.
Смысл стартапа вроде стать корпорацией, а не просто потусоваться... Как раз наверно в этом будет урок, что надо немного подумать о транзите, о том что будет некий момент когда у компании появятся обязательства снаружи, под которые появятся обязательства внутренние. И на мороз вероятно придется в обоих случаях...
Смысл стартапа в первые три года - выжить, а не стать корпорацией, поэтому насаждение таких процессов слишком рано - это утопия
Каждой компании свои процессы.
Я работал в старикан, где я был 5м инженером. Потом компания выросла до 50+ человек.
И я могу 100% сказать, что невозможно работать с однимими процессами на 5 человек и на 20 человек. Там где 5 всегда можно собрать вместе и обсудить, 20 - не соберется почти никогда. Кто-то в отпуске, кто-то болеет у кого-то семейные проблемы, и т.д. да и руководитель уже не запомнит в голове так легко информацию от всех.
Поэтому и существуют 5 уровней зрелости компаний от гаража до махрового Enterprise. И задача руководства стартера, планировать рост и решать все проблемы вовремя по мере роста. Не бежать впереди паровоза вводя политики и тренинги на 3 сотрудника, но и не тормозить пытаясь вести отчеты и планировать в экселях, когда на проекте уже 30 человек. И по прежнему зажимая ресурсы на DevOps и поддержку рабочих инструментов с лицензиями.
да, это задача менеджмента балансировать эти штуки - и это сложно, поэтому зачастую инвесторы хорошие могут подсказать, когда стоит нанять опытного человека на это направление. У нас так появился один из кофаундеров с опытом в больших компаниях, мы как два ранних кофаундера не могли уже продуктом эффективно управлять. Корпоративный бекграунд дал другие побочные эффекты, конечно, но и польза в этом была
Открывал статью в надежде почитать про выстраивание процессов и их корректировку, балансирование команды и доращивание компетенций, может ещё про поиск своей ниши в этом мире. А прочёл про то, что вовремя от проблемных сотрудников избавляться надо и культурный код...
С одной стороны, понимаю, что речь про стартап. С другой, ну это выводы тимлида за 3 года работы
вот этот заголовок
Минус $150k, потеря контроля в своей компании, сорванный экзит: 5 примеров последствий управленческого долга в стартапе
не обещает вот таких тем:
про выстраивание процессов и их корректировку, балансирование команды и доращивание компетенций, может ещё про поиск своей ниши в этом мире
А так да, темы хорошие, и про них я тоже напишу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Минус $150k, потеря контроля в своей компании, сорванный экзит: 5 примеров последствий управленческого долга в стартапе