Я просто пишу для основателей – если видите, что в вашей картине мира поведение сильного инженера токсичное, то риск слишком велик. Дальше кто что с этим делает – это уже конкретный выбор конкретного человека. Нет смысла думать о том - а на самом ли деле чел токсичный или мне так кажется - это стартап, надо двигаться быстро, всем смотреть в одну сторону. Я для себя сделал вывод, что в следующих проектах терпеть такое не буду
я читал - мне не очень понравилась. У Бена все же прям практика и очень много примеров, а слайт эдж – скорее нлп-саморазвитие, я такое не очень. Но кому-то наверное полезно :)
Ну любой стартап какой бы ни был, все равно нервное мероприятие и нестабильное. Ключевые моменты всегда должны обсуждаться, но всего не предусмотреть, и поэтому потом все равно человека будет видно. Главное быстро это понимать и расходиться с теми, с кем видно уже не по пути - так будет лучше всем, вы абсолютно правы. И это то, что мне было тяжело делать, но я научился :)
да, это задача менеджмента балансировать эти штуки - и это сложно, поэтому зачастую инвесторы хорошие могут подсказать, когда стоит нанять опытного человека на это направление. У нас так появился один из кофаундеров с опытом в больших компаниях, мы как два ранних кофаундера не могли уже продуктом эффективно управлять. Корпоративный бекграунд дал другие побочные эффекты, конечно, но и польза в этом была
если вы founding member - о чем мы тут говорим тк я пишу про early-stage проекты (только запускаемся, и вы первый инженер), то бывает больше. У нас например, около 5% главный инженер получил в итоге долю и даже статус кофаундера в какой-то момент.
Про документацию, к сожалению это будет работать только, если мы сейчас на этапе продажи каким-то внешним клиентам сложной интеграции (например, мы продавали grammar checker api/sdk - там доки были хорошие). А когда у нас куча экспериментов по b2c - никто не будет писать документацию тк в этом нет практического смысла - ее обновлять будет невозможно. Даже хелп центр в раннем проекте оч сложно поддерживать.
То есть стресс и неопределенность – это специфика. Если у человека ментальность «меня поставили в такие условия, поэтому я веду себя как говно» – он не нужен в этом стартапе тк это детское поведение, надо было взвешивать риски до принятия оффера. Никто ж не говорит, что работа в стартапе – это история для всех, совсем нет.
ну видно, что вы не занимались запуском стартапов венчурных :) Все работает вообще по-другому. Прям все тезисы неверные:
компания в первые год-два ищет нишу и делает кучу экспериментов, в результате чего бизнес модель завтра может быть на 180 градусов от того, что вчера было
сотрудники это понимают, но также понимают и что возможные выгоды от роста перевешивают, и потому работают - и работают обычно за ниже рынка в зп, но у них есть опционы с существенными долями - проценты equity для первых ключевых людей
и чтобы делать и быстрые итерации и держать качество - эти люди как правило должны быть сильными, а не студентами
при этом упражняться в визионерстве и планировании на годы надо - потому что иначе не дадут инвестиций, но это именно что упражнение, и нормальные инвесторы тоже будут без обид, когда через неделю после транша вы придете и расскажете, что теперь у вас все поменялось, продукт и клиенты, и все по-другому – и покажете цифры, которые это подтверждают
Вы почему-то читаете так, что раз я говорю о токсичных звездах, значит я всех выдающихся в чем-то сотрудников считаю токсичными и призываю только с серыми мышами работать. Видимо потому что это как-то резонирует с вашим опытом, когда вы с его высоты пытались сделать как лучше и не нашли понимания у менеджмента – я вообще не о таких ситуациях говорю, уже несколько примеров привел
я говорю про early-stage стартапы - где вы ищете product/market fit, делаете кучу экспериментов и сегодня у вас может быть идея делать приложение для упрощения сбора задолженностей коллекторами в UK, а через пару месяцев выясняется, что продукт нужен госпиталям в США чтобы лучше собирать плату за услуги со страховых компаний (реальный пример).
Какое долгосрочное планирование в таких условиях вообще возможно? И как еще должно выглядеть все с тз IT кроме полумануального режима до момента, когда ниша хотя бы утвердилась?
если человек при этом устраивает истерики в виде «вы просто не заботитесь о качестве, мне стыдно работать над таким продуктом» - параллельно с проблемами в области дисциплины, чем это не токсичность?
Финансово отношения всегда со всеми сотрудниками у меня строились так, что задержки могут быть у кого угодно из команды фаундеров, но не у инженеров.
Он всего лишь описывает негативную реакцию на изменение ожиданий
Ну не обязательно так. В случае стартапа звездный инженер просто может в какой-то момент начать себя вести так, будто это его компания – и хотеть делать что-то, что даже может быть и имеет какой-то смысл с тз технологий, но вообще противопоказано с точки зрения выживаемости компании.
В итоге была, например, ситуация, когда нам надо делать релиз и планировать маркетинг, а для этого надо как-то принимать деньги от юзеров. Инженер хочет делать свой биллинг тк Stripe и Braintree говно и все едж-кейсы, что он хотел, не обрабатывали на тот момент. То что это займет месяцы, прожить, которые нет денег – не его проблема, а решить ее должен СЕО. В итоге он подчинился аргументам, но это был кирпич в решение расстаться (обоюдное, кстати) после очередной истерики о том, что «мне стыдно сказать что я тут работаю, настолько дерьмово все под капотом у нас».
Про на мороз - понятно в теории, на практике почему-то оказывается не так это просто, особенно в маленькой команде стартапа, где вы только запустились. Собственно, о таком опыте и пост.
Я фанат человека паука, так что как говорил дядя Бен: «С большой силой приходит большая ответственность» :)
И когда звездный сотрудник не хочет слышать аргументы других людей просто по факту наличия большого таланта, а только хочет делать то, что считает нужным - это проблема тк вред от такого поведения в его случае больше, чем могут нанести другие члены команды.
ну у нас уже была эта дискуссия в комментах к прошлому посту - мне кажется, мы по-разному токсичность понимаем.
Для меня вот тут:
> Тот, кто критикует устаревшие и откровенно плохие решения (предлагая выход), или тот, кто видит основной целью удовлетворение пожеланий заказчиков (которых рефакторинг не интересует, и потому на повестке дня его не стоит)?
нет токсичности - а есть обсуждение рабочих моментов. У каждого свои поинты есть – в зависимости от разных факторов верным в моменте может быть и оставить как есть и инвестировать в рефакторинг, чтобы потом не огрести проблем.
Токсичность – это когда человек отказывается быть как раз командным игроком и свои мысли как-то аргументировать. Звездность и талантливость это обычно ухудшают и увеличивают масштаб проблем - пример, как это в реальности бывает, я в посте привел.
дневник - это важная тема. У меня это еще один гугл док по факту. Когда нервные времена и стресс - сильно помогает, или когда большое воодушевление и много планов. Когда все стабильно и хорошо - пишу редко. В итоге можно отслеживать колебания состояния своего морального - мне это тоже кажется интересной техникой.
Я просто пишу для основателей – если видите, что в вашей картине мира поведение сильного инженера токсичное, то риск слишком велик. Дальше кто что с этим делает – это уже конкретный выбор конкретного человека. Нет смысла думать о том - а на самом ли деле чел токсичный или мне так кажется - это стартап, надо двигаться быстро, всем смотреть в одну сторону. Я для себя сделал вывод, что в следующих проектах терпеть такое не буду
я читал - мне не очень понравилась. У Бена все же прям практика и очень много примеров, а слайт эдж – скорее нлп-саморазвитие, я такое не очень. Но кому-то наверное полезно :)
Ну любой стартап какой бы ни был, все равно нервное мероприятие и нестабильное. Ключевые моменты всегда должны обсуждаться, но всего не предусмотреть, и поэтому потом все равно человека будет видно. Главное быстро это понимать и расходиться с теми, с кем видно уже не по пути - так будет лучше всем, вы абсолютно правы. И это то, что мне было тяжело делать, но я научился :)
да, это задача менеджмента балансировать эти штуки - и это сложно, поэтому зачастую инвесторы хорошие могут подсказать, когда стоит нанять опытного человека на это направление. У нас так появился один из кофаундеров с опытом в больших компаниях, мы как два ранних кофаундера не могли уже продуктом эффективно управлять. Корпоративный бекграунд дал другие побочные эффекты, конечно, но и польза в этом была
если вы founding member - о чем мы тут говорим тк я пишу про early-stage проекты (только запускаемся, и вы первый инженер), то бывает больше. У нас например, около 5% главный инженер получил в итоге долю и даже статус кофаундера в какой-то момент.
Про документацию, к сожалению это будет работать только, если мы сейчас на этапе продажи каким-то внешним клиентам сложной интеграции (например, мы продавали grammar checker api/sdk - там доки были хорошие). А когда у нас куча экспериментов по b2c - никто не будет писать документацию тк в этом нет практического смысла - ее обновлять будет невозможно. Даже хелп центр в раннем проекте оч сложно поддерживать.
То есть стресс и неопределенность – это специфика. Если у человека ментальность «меня поставили в такие условия, поэтому я веду себя как говно» – он не нужен в этом стартапе тк это детское поведение, надо было взвешивать риски до принятия оффера. Никто ж не говорит, что работа в стартапе – это история для всех, совсем нет.
ну видно, что вы не занимались запуском стартапов венчурных :) Все работает вообще по-другому. Прям все тезисы неверные:
компания в первые год-два ищет нишу и делает кучу экспериментов, в результате чего бизнес модель завтра может быть на 180 градусов от того, что вчера было
сотрудники это понимают, но также понимают и что возможные выгоды от роста перевешивают, и потому работают - и работают обычно за ниже рынка в зп, но у них есть опционы с существенными долями - проценты equity для первых ключевых людей
и чтобы делать и быстрые итерации и держать качество - эти люди как правило должны быть сильными, а не студентами
при этом упражняться в визионерстве и планировании на годы надо - потому что иначе не дадут инвестиций, но это именно что упражнение, и нормальные инвесторы тоже будут без обид, когда через неделю после транша вы придете и расскажете, что теперь у вас все поменялось, продукт и клиенты, и все по-другому – и покажете цифры, которые это подтверждают
вот этот заголовок
не обещает вот таких тем:
А так да, темы хорошие, и про них я тоже напишу.
Вы почему-то читаете так, что раз я говорю о токсичных звездах, значит я всех выдающихся в чем-то сотрудников считаю токсичными и призываю только с серыми мышами работать. Видимо потому что это как-то резонирует с вашим опытом, когда вы с его высоты пытались сделать как лучше и не нашли понимания у менеджмента – я вообще не о таких ситуациях говорю, уже несколько примеров привел
я говорю про early-stage стартапы - где вы ищете product/market fit, делаете кучу экспериментов и сегодня у вас может быть идея делать приложение для упрощения сбора задолженностей коллекторами в UK, а через пару месяцев выясняется, что продукт нужен госпиталям в США чтобы лучше собирать плату за услуги со страховых компаний (реальный пример).
Какое долгосрочное планирование в таких условиях вообще возможно? И как еще должно выглядеть все с тз IT кроме полумануального режима до момента, когда ниша хотя бы утвердилась?
Смысл стартапа в первые три года - выжить, а не стать корпорацией, поэтому насаждение таких процессов слишком рано - это утопия
если человек при этом устраивает истерики в виде «вы просто не заботитесь о качестве, мне стыдно работать над таким продуктом» - параллельно с проблемами в области дисциплины, чем это не токсичность?
Финансово отношения всегда со всеми сотрудниками у меня строились так, что задержки могут быть у кого угодно из команды фаундеров, но не у инженеров.
Ну не обязательно так. В случае стартапа звездный инженер просто может в какой-то момент начать себя вести так, будто это его компания – и хотеть делать что-то, что даже может быть и имеет какой-то смысл с тз технологий, но вообще противопоказано с точки зрения выживаемости компании.
В итоге была, например, ситуация, когда нам надо делать релиз и планировать маркетинг, а для этого надо как-то принимать деньги от юзеров. Инженер хочет делать свой биллинг тк Stripe и Braintree говно и все едж-кейсы, что он хотел, не обрабатывали на тот момент. То что это займет месяцы, прожить, которые нет денег – не его проблема, а решить ее должен СЕО. В итоге он подчинился аргументам, но это был кирпич в решение расстаться (обоюдное, кстати) после очередной истерики о том, что «мне стыдно сказать что я тут работаю, настолько дерьмово все под капотом у нас».
а что именно непонятно?
Про на мороз - понятно в теории, на практике почему-то оказывается не так это просто, особенно в маленькой команде стартапа, где вы только запустились. Собственно, о таком опыте и пост.
ну можно назвать опытом или просто скиллом - все равно есть более сильные и мене сильные люди, и токсичные звезды - это плохое комбо
Я фанат человека паука, так что как говорил дядя Бен: «С большой силой приходит большая ответственность» :)
И когда звездный сотрудник не хочет слышать аргументы других людей просто по факту наличия большого таланта, а только хочет делать то, что считает нужным - это проблема тк вред от такого поведения в его случае больше, чем могут нанести другие члены команды.
ну у нас уже была эта дискуссия в комментах к прошлому посту - мне кажется, мы по-разному токсичность понимаем.
Для меня вот тут:
> Тот, кто критикует устаревшие и откровенно плохие решения (предлагая выход), или тот, кто видит основной целью удовлетворение пожеланий заказчиков (которых рефакторинг не интересует, и потому на повестке дня его не стоит)?
нет токсичности - а есть обсуждение рабочих моментов. У каждого свои поинты есть – в зависимости от разных факторов верным в моменте может быть и оставить как есть и инвестировать в рефакторинг, чтобы потом не огрести проблем.
Токсичность – это когда человек отказывается быть как раз командным игроком и свои мысли как-то аргументировать. Звездность и талантливость это обычно ухудшают и увеличивают масштаб проблем - пример, как это в реальности бывает, я в посте привел.
дневник - это важная тема. У меня это еще один гугл док по факту. Когда нервные времена и стресс - сильно помогает, или когда большое воодушевление и много планов. Когда все стабильно и хорошо - пишу редко. В итоге можно отслеживать колебания состояния своего морального - мне это тоже кажется интересной техникой.
раздербанить - это хороший подход к задачам!
спасибо!
ну я вот такие формулировки использую в личных задачах, как-то прижилось)