Не совсем. Это не про “часть корабля, часть команды”, а про то, чтобы не терять людей по глупости.
Если кто-то уходит, мы всегда сначала спрашиваем себя: а всё ли мы сделали, чтобы человек остался? И да, можно наложить вето - это означает “стоп, не увольняемся сгоряча, давай разберёмся, может, мы можем что-то изменить”.
Это работает. Иногда человек действительно уходит, а иногда остаётся, но на других условиях: с новым стеком, с другим командой, с другой миссией. И начинает расти дальше.
Дополнительно уточнил у ребят из своей команды перед тем, как отвечать:
Джуны действительно чаще перерабатывают. По их словам, в среднем 45 часов в неделю. Постоянно на 1-1 нагрузку чекаю, ребятам говорят им ок.
Мидлы и сеньоры - реже. У них обычно больше опыта в планировании и выстраивании границ.
Чаще всего перерабатывают дежурные: из-за алертов, инцидентов, срочных фиксов. Это часть реальности.
При это само время не трекаем. Да и задачи оцениваем с точностью до дня, а не 2-4 часа. У нас есть механизм оплаты овертаймов. Например, если алерт ночью или нужно на выходных катить обновления. Я сам этим пользовался, когда исправлял последствия инцидентов вместе с командой.
Если кандидат может придумать и реализовать решение сам, это только плюс. Но мы и не запрещаем пользоваться инструментами: в реальной работе все гуглят, используют LLM. GPT - это один из таких инструментов. Главное, понимать, что ты делаешь и зачем, а не просто вставлять ответы бездумно.
У нас ItSec - это отдельная команда, которая отвечает за безопасность всей компании.
А SecOps - это команда, которая фокусируется на безопасности в разработке: ролевая модель, авторизация, сканеры уязвимостей, CI/CD, интеграция с SIEM, обучение, библиотеки и т.п.
Отдельных ролей типа AppSec и DevSecOps нет - есть SecOps-специалисты и команда инженеров, которые это всё вместе двигают как продукт.
А название - просто ярлык. Можно было бы назвать DevSec, Dev3 или просто Security Engineering. Пока масштаб команды не требует таких разграничений.
Текущий CEO начинал как клиентский менеджер, потом стал продактом, потом лидом, теперь управляет всей компанией. CTO - бывший разработчик. У нас это нормально.
Есть и опционная программа. Так что “пашешь, но не растёшь” - это не про нас.
Да, такие ситуации бывают. Иногда джун правда начинает “агрономить” не по делу, а просто потому что уверен, что “наконец-то можно говорить вслух”, и хочет проявиться. Это нормальный этап.
Что с этим делаем:
публичные обсуждения и обратная связь часто сами выравнивают поведение: когда тебе аргументированно отвечают на каждый наброс, быстро учишься говорить по делу. Плюс подсвечиваем, что у обсуждения должна быть цель, а не просто похоливарить (если это не оффтопик какой-нибудь).
вне критичных путей можем дать попробовать “сделать по-своему”, с возможностью ошибиться и потом отрефлексировать
если ситуация не лечится, заводится “карточка несчастья” (по факту как жёлтая карточка в футболе): что не так, план исправления, сроки. Если не помогает — честно расстаёмся.
Так что да, допускаем ошибки. Но не бесконечно и не без последствий.
Не только разработчик, вообще любой сотрудник может узнать о прибыли компании, ее расходах и доходах. Более того, мы ежегодно в своем публичном блоге публикуем результаты года. Например, вот итого 2024 года. Там и финансовые показатели, и количество клиентов, и данные по сотрудниках.
о доходах топ менеджеров?
Доходы топов - тоже публичны внутри компании. Как и цели, по которым они себе ставят ЗП. Если у сотрудников возникают вопросы по эффективности их работы, они могут публично их задать. Открытость у нас не выборочная.
Да, самодисциплина и вовлечённость реально важны. Без этого открытость не работает.
Если человек молчит, но его мнение важно, есть несколько способов:
можно подойти напрямую и обсудить тет-а-тет,
можно пингануть в личке, созвоне или комменте
можно взять ответственность за решение на себя, но проговорить, что человек не принял участие в обсуждении.
У нас нет культа “все обязаны участвовать”. Но если ты участвуешь - твой голос считается. А если молчишь, это тоже ок, просто решение может быть принято без тебя.
Мы не говорим, что наш подход идеален или единственно верный. Мы свои подходы заимствовали у разных компаний: Neflix, Spotify. В РФ похожие практики есть у DoDo и Райфайзена. Рассказываем, как устроено у нас - с плюсами, минусами и фактами. Кому-то это интересно и полезно. Кому-то удобнее назвать это сектой, сомнительно, но окэй.
Но если на аргументы и открытость в ответ прилетает набор ярлыков - это уже не диалог. А значит, бессмысленно продолжать.
Да, искали двух сеньоров. Одну позицию закрыли, вторая еще в поиске. Если бы подход был “берём любого, кто откликнулся” - команда уже была бы собрана. Но хочется долгосрочных отношений. Так что да, подбираем долго, зато метко.
Пользуюсь случаем, немного попиарю вакансию в свою команду SecOps - https://hh.ru/vacancy/79405175 Занимаемся продуктом безопасности (авторизация, права доступа, ролевая модель, журналы событий) и повышением безопасности всей разработки (SIEM, сканеры уязвимостей, аспекты безопасной разработки). Команда только формируется, можно быстро вырасти в лидирующие роли.
У нас высокие требования к качеству и продуктивности, выше среднего по рынку. Мы не скрываем этого, и многие приходят именно за этим: расти и делать сложные задачи.
Но это не значит, что мы поощряем переработки. Мы не бежим спринт, мы бежим марафон: – есть ежеквартальный опрос о нагрузке – EM'ы регулярно отслеживают баланс и состояние ребят в команде – если человек стабильно перерабатывает, это сигнал, что что-то сломано: в оценке, в процессе или в коммуникации. Это надо чинить.
Да, рост требует усилий, а не просто поработать доп. часы вечером. Это может быть инициатива, взятие доп. ответственности.
Что касается возраста, в компании есть люди 20+, 30+, 40+. В моей команде средний возраст - 29 лет.
Принцип открытости работает не только в разработке. Он распространяется на всю компанию. Мы не делаем “открытость ради открытости”, а хотим, чтобы любой, кого задевает решение, мог быть услышан.
Во-вторых, мы сильно выросли: за 2 года с 234 до 420 человек. Это помогает компании эффективно развиваться.
Открытость != “зови всех на каждый созвон”.
Мы уведомляем, даем возможность подключиться и высказаться, если хочешь или это тебя касается.
Не касается? Не подключаешься. Но если затронуло, у тебя есть возможность включиться обсуждение/принятия решения.
Это не мешает работать, наоборот, помогает не принимать решения в слепую.
Экспертиза важна. К мнению сильных инженеров прислушиваются чаще, потому что за их словами обычно стоит опыт, контекст и зрелость.
Но в наших командах решение побеждает не потому, что ты старше или авторитетнее, а потому что оно ведет к результату.
Если сеньор месяц проектирует идеальный микросервис по всем канонам DDD, а другой просто делает качественно и доводит до продакшна, мы выберем второго. Даже если другой - это джун или миддл.
Правильно понимаю, что рядовой разраб должен вместо работы изучать продуктовые метрики и искать точки роста, чтобы самому себе поставить задачу?
Нет, не совсем так. За метрики, точки роста и продуктовую стратегию у нас отвечают продакты. Разработчики не заменяют продактов. Никто не ждет, что миддл будет сам анализировать бизнес и “придумывать себе работу”. Но мы поощряем инициативу. Если ты заметил проблему, которую можешь решить, и это в контексте команды, ты можешь поднять эту задачу сам.
Ты не обязан это делать. Но если хочешь, тебе дадут фидбек, помогут, подскажут, выровняют по целям.
Это работает в связке с EM, командой и продактом - никто не один в поле.
И высший приоритет тоже сам разработчик себе выставляет, чтобы баги не мешали поднимать ЗП?
Тоже нет.
Приоритеты команда определяет вместе на викли. Учитываются задачи продакта, баги, техдолг, технические улучшения - все взвешивается.
Цель для ЗП человек ставит сам, но в рамках задач команды и своего грейда. Это может быть: – залидить проект – сократить алерты – улучшить DevEx по части пайплайнов и т.п.
Если цель не совпадает с приоритетами команды или выглядит странно - EM или команда это подсветят, и цель скорректируют.
Так что “выставить себе левую цель, чтобы апнуть ЗП” - не сработает.
Мы не требуем инициативы, но даём все инструменты для тех, кто хочет брать на себя больше.
А рост, ЗП, ответственность - идут за реальной пользой, а не за “активностью ради активности”.
а кто несёт ответственность за совместные решения?
У нас - всегда тот, кто решение принял. Даже если оно было “коллективным” - это значит, что человек выслушал, обсудил, но сам взял на себя ответственность и последствия. Иногда это несколько человек, если решение действительно общее. Ошибки, конечно, случаются. Но за счёт прозрачности и открытой обратной связи их не нужно скрывать, они быстро всплывают и обсуждаются по существу.
Пример из практики.
Миддл из моей команды (назовём его Геннакер) участвовал в проекте другой команды. Там техлид долго “прорабатывал архитектуру” и зарывался в неважные детали. Геннакер начал задавать вопросы, в какой-то момент эскалировал до архитектора. Архитектор включился, посмотрел, разобрался - и помог принять более простые и адекватные решения.
Никто не испугался того, что это делает миддл. Никто не защищал “священное право сеньора”. Это и есть культура, где важно качество решений, а не иерархия.
Ошибаться можно. Но если ошибка повторяется или ломает другим работу - у нас есть карточка “несчастья” (аналог желтой карточки в футболе). Это не скандал и не выговор. Это формальный способ зафиксировать, что что-то пошло не так: сформулировать, в чём именно проблема, предложить путь выхода, договориться о сроках.
Если несчастье не лечится - честно расстаёмся.
Свобода решений работает только там, где работает и ответственность. И у нас она работает.
У нас можно принять решение самому - без согласования и обсуждения. Но если оно затрагивает других, ты обязан прозрачно уведомить тех, на кого оно повлияет. Это основа доверия и зрелости.
Если кто-то задаёт вопросы, ты можешь:
— обсудить и учесть их аргументы,
— объяснить, почему делаешь по-своему,
— сослаться на свою экспертизу.
Но если ты просто “сделал и всё”, не объяснил, не выслушал - тогда любой может наложить вето. Это защита от закрытых и потенциально вредных решений.
При этом вето - не запрет, а старт диалога. Ответственность все равно остаётся на тебе, просто придется обосновать, почему ты уверен.
И да, часто вообще никто не спорит. Но возможность поспорить - это и есть безопасность.
Смотри, никто в Mindbox не требует “одобрения от джунов”, и у нас нет “голосования” по техническим решениям.
Но мы считаем нормой, когда любой человек может задать вопрос, если что-то кажется ему спорным. И ты как инженер должен объяснить свою позицию. Не потому что ты “не эксперт”, а потому что в инженерной культуре доказательства и прозрачность важнее статуса.
Не совсем. Это не про “часть корабля, часть команды”, а про то, чтобы не терять людей по глупости.
Если кто-то уходит, мы всегда сначала спрашиваем себя: а всё ли мы сделали, чтобы человек остался? И да, можно наложить вето - это означает “стоп, не увольняемся сгоряча, давай разберёмся, может, мы можем что-то изменить”.
Это работает. Иногда человек действительно уходит, а иногда остаётся, но на других условиях: с новым стеком, с другим командой, с другой миссией. И начинает расти дальше.
Для нас это окей. Люди не расходный материал.
Дополнительно уточнил у ребят из своей команды перед тем, как отвечать:
Джуны действительно чаще перерабатывают. По их словам, в среднем 45 часов в неделю. Постоянно на 1-1 нагрузку чекаю, ребятам говорят им ок.
Мидлы и сеньоры - реже. У них обычно больше опыта в планировании и выстраивании границ.
Чаще всего перерабатывают дежурные: из-за алертов, инцидентов, срочных фиксов. Это часть реальности.
При это само время не трекаем. Да и задачи оцениваем с точностью до дня, а не 2-4 часа.
У нас есть механизм оплаты овертаймов. Например, если алерт ночью или нужно на выходных катить обновления. Я сам этим пользовался, когда исправлял последствия инцидентов вместе с командой.
Если кандидат может придумать и реализовать решение сам, это только плюс. Но мы и не запрещаем пользоваться инструментами: в реальной работе все гуглят, используют LLM. GPT - это один из таких инструментов. Главное, понимать, что ты делаешь и зачем, а не просто вставлять ответы бездумно.
У нас ItSec - это отдельная команда, которая отвечает за безопасность всей компании.
А SecOps - это команда, которая фокусируется на безопасности в разработке: ролевая модель, авторизация, сканеры уязвимостей, CI/CD, интеграция с SIEM, обучение, библиотеки и т.п.
Отдельных ролей типа AppSec и DevSecOps нет - есть SecOps-специалисты и команда инженеров, которые это всё вместе двигают как продукт.
А название - просто ярлык. Можно было бы назвать DevSec, Dev3 или просто Security Engineering. Пока масштаб команды не требует таких разграничений.
Ну, в нашем случае “лошадь” стала CEO.
Текущий CEO начинал как клиентский менеджер, потом стал продактом, потом лидом, теперь управляет всей компанией.
CTO - бывший разработчик. У нас это нормально.
Есть и опционная программа. Так что “пашешь, но не растёшь” - это не про нас.
Да, такие ситуации бывают. Иногда джун правда начинает “агрономить” не по делу, а просто потому что уверен, что “наконец-то можно говорить вслух”, и хочет проявиться. Это нормальный этап.
Что с этим делаем:
публичные обсуждения и обратная связь часто сами выравнивают поведение: когда тебе аргументированно отвечают на каждый наброс, быстро учишься говорить по делу. Плюс подсвечиваем, что у обсуждения должна быть цель, а не просто похоливарить (если это не оффтопик какой-нибудь).
вне критичных путей можем дать попробовать “сделать по-своему”, с возможностью ошибиться и потом отрефлексировать
если ситуация не лечится, заводится “карточка несчастья” (по факту как жёлтая карточка в футболе): что не так, план исправления, сроки. Если не помогает — честно расстаёмся.
Так что да, допускаем ошибки. Но не бесконечно и не без последствий.
Не только разработчик, вообще любой сотрудник может узнать о прибыли компании, ее расходах и доходах. Более того, мы ежегодно в своем публичном блоге публикуем результаты года. Например, вот итого 2024 года. Там и финансовые показатели, и количество клиентов, и данные по сотрудниках.
Доходы топов - тоже публичны внутри компании. Как и цели, по которым они себе ставят ЗП. Если у сотрудников возникают вопросы по эффективности их работы, они могут публично их задать. Открытость у нас не выборочная.
Да, самодисциплина и вовлечённость реально важны. Без этого открытость не работает.
Если человек молчит, но его мнение важно, есть несколько способов:
можно подойти напрямую и обсудить тет-а-тет,
можно пингануть в личке, созвоне или комменте
можно взять ответственность за решение на себя, но проговорить, что человек не принял участие в обсуждении.
У нас нет культа “все обязаны участвовать”. Но если ты участвуешь - твой голос считается. А если молчишь, это тоже ок, просто решение может быть принято без тебя.
Каждый видит то, что хочет видеть.
Мы не говорим, что наш подход идеален или единственно верный. Мы свои подходы заимствовали у разных компаний: Neflix, Spotify. В РФ похожие практики есть у DoDo и Райфайзена. Рассказываем, как устроено у нас - с плюсами, минусами и фактами. Кому-то это интересно и полезно. Кому-то удобнее назвать это сектой, сомнительно, но окэй.
Но если на аргументы и открытость в ответ прилетает набор ярлыков - это уже не диалог. А значит, бессмысленно продолжать.
Да, искали двух сеньоров. Одну позицию закрыли, вторая еще в поиске.
Если бы подход был “берём любого, кто откликнулся” - команда уже была бы собрана. Но хочется долгосрочных отношений. Так что да, подбираем долго, зато метко.
Пользуюсь случаем, немного попиарю вакансию в свою команду SecOps - https://hh.ru/vacancy/79405175
Занимаемся продуктом безопасности (авторизация, права доступа, ролевая модель, журналы событий) и повышением безопасности всей разработки (SIEM, сканеры уязвимостей, аспекты безопасной разработки).
Команда только формируется, можно быстро вырасти в лидирующие роли.
У нас высокие требования к качеству и продуктивности, выше среднего по рынку. Мы не скрываем этого, и многие приходят именно за этим: расти и делать сложные задачи.
Но это не значит, что мы поощряем переработки. Мы не бежим спринт, мы бежим марафон:
– есть ежеквартальный опрос о нагрузке
– EM'ы регулярно отслеживают баланс и состояние ребят в команде
– если человек стабильно перерабатывает, это сигнал, что что-то сломано: в оценке, в процессе или в коммуникации. Это надо чинить.
Да, рост требует усилий, а не просто поработать доп. часы вечером. Это может быть инициатива, взятие доп. ответственности.
Что касается возраста, в компании есть люди 20+, 30+, 40+. В моей команде средний возраст - 29 лет.
Принцип открытости работает не только в разработке. Он распространяется на всю компанию. Мы не делаем “открытость ради открытости”, а хотим, чтобы любой, кого задевает решение, мог быть услышан.
Во-вторых, мы сильно выросли: за 2 года с 234 до 420 человек. Это помогает компании эффективно развиваться.
Открытость != “зови всех на каждый созвон”.
Мы уведомляем, даем возможность подключиться и высказаться, если хочешь или это тебя касается.
Не касается? Не подключаешься. Но если затронуло, у тебя есть возможность включиться обсуждение/принятия решения.
Это не мешает работать, наоборот, помогает не принимать решения в слепую.
Криво мысль выразил, переформулирую ее.
Экспертиза важна. К мнению сильных инженеров прислушиваются чаще, потому что за их словами обычно стоит опыт, контекст и зрелость.
Но в наших командах решение побеждает не потому, что ты старше или авторитетнее, а потому что оно ведет к результату.
Если сеньор месяц проектирует идеальный микросервис по всем канонам DDD, а другой просто делает качественно и доводит до продакшна, мы выберем второго. Даже если другой - это джун или миддл.
Можно наложить вето на увольнение. И такое было.
Не сработает. У нас ЗеПку поднимают не за “всех раскидал”, а за “всех выслушал и сделал нормально”.
У нас каждое внутреннее демо - это ор, мемы и специфичные шутки. Уверен, тебе зайдет)
Привет!
Нет, не совсем так.
За метрики, точки роста и продуктовую стратегию у нас отвечают продакты. Разработчики не заменяют продактов. Никто не ждет, что миддл будет сам анализировать бизнес и “придумывать себе работу”.
Но мы поощряем инициативу. Если ты заметил проблему, которую можешь решить, и это в контексте команды, ты можешь поднять эту задачу сам.
Ты не обязан это делать. Но если хочешь, тебе дадут фидбек, помогут, подскажут, выровняют по целям.
Это работает в связке с EM, командой и продактом - никто не один в поле.
Тоже нет.
Приоритеты команда определяет вместе на викли. Учитываются задачи продакта, баги, техдолг, технические улучшения - все взвешивается.
Цель для ЗП человек ставит сам, но в рамках задач команды и своего грейда. Это может быть:
– залидить проект
– сократить алерты
– улучшить DevEx по части пайплайнов и т.п.
Если цель не совпадает с приоритетами команды или выглядит странно - EM или команда это подсветят, и цель скорректируют.
Так что “выставить себе левую цель, чтобы апнуть ЗП” - не сработает.
Мы не требуем инициативы, но даём все инструменты для тех, кто хочет брать на себя больше.
А рост, ЗП, ответственность - идут за реальной пользой, а не за “активностью ради активности”.
У нас - всегда тот, кто решение принял. Даже если оно было “коллективным” - это значит, что человек выслушал, обсудил, но сам взял на себя ответственность и последствия. Иногда это несколько человек, если решение действительно общее.
Ошибки, конечно, случаются. Но за счёт прозрачности и открытой обратной связи их не нужно скрывать, они быстро всплывают и обсуждаются по существу.
Пример из практики.
Миддл из моей команды (назовём его Геннакер) участвовал в проекте другой команды. Там техлид долго “прорабатывал архитектуру” и зарывался в неважные детали. Геннакер начал задавать вопросы, в какой-то момент эскалировал до архитектора. Архитектор включился, посмотрел, разобрался - и помог принять более простые и адекватные решения.
Никто не испугался того, что это делает миддл. Никто не защищал “священное право сеньора”. Это и есть культура, где важно качество решений, а не иерархия.
Ошибаться можно. Но если ошибка повторяется или ломает другим работу - у нас есть карточка “несчастья” (аналог желтой карточки в футболе). Это не скандал и не выговор. Это формальный способ зафиксировать, что что-то пошло не так: сформулировать, в чём именно проблема, предложить путь выхода, договориться о сроках.
Если несчастье не лечится - честно расстаёмся.
Свобода решений работает только там, где работает и ответственность. И у нас она работает.
У нас можно принять решение самому - без согласования и обсуждения. Но если оно затрагивает других, ты обязан прозрачно уведомить тех, на кого оно повлияет. Это основа доверия и зрелости.
Если кто-то задаёт вопросы, ты можешь:
— обсудить и учесть их аргументы,
— объяснить, почему делаешь по-своему,
— сослаться на свою экспертизу.
Но если ты просто “сделал и всё”, не объяснил, не выслушал - тогда любой может наложить вето. Это защита от закрытых и потенциально вредных решений.
При этом вето - не запрет, а старт диалога. Ответственность все равно остаётся на тебе, просто придется обосновать, почему ты уверен.
И да, часто вообще никто не спорит. Но возможность поспорить - это и есть безопасность.
Смотри, никто в Mindbox не требует “одобрения от джунов”, и у нас нет “голосования” по техническим решениям.
Но мы считаем нормой, когда любой человек может задать вопрос, если что-то кажется ему спорным. И ты как инженер должен объяснить свою позицию. Не потому что ты “не эксперт”, а потому что в инженерной культуре доказательства и прозрачность важнее статуса.