Почему 4 инженера сделали Cursor за полгода, а 200 инженеров иногда не могут победить легаси за годы Управление ожиданиями, культура, процессы, технический долг, сильные инженеры, сроки. Обычно именно про это говорят, когда пытаются объяснить успех или провал больших проектов.
Но последнее время меня не отпускает другой вопрос.
Четыре инженера. Средний возраст — меньше 25 лет.
За полгода они создали Cursor. Еще через пару лет стали миллиардерами.
И тут возникает неудобный вопрос.
Почему тогда компании со 100–200 инженерами иногда годами не могут закрыть критический технический долг?
Почему не могут за полгода съехать с легаси?
Почему не могут переписать систему так, чтобы ей действительно можно было гордиться?
Конечно, масштаб другой.
Конечно, есть пользователи, риски, обязательства, деньги бизнеса.
Но мне кажется, дело не только в этом.
Есть фактор, про который редко говорят на инженерных конференциях.
Состояние.
То самое состояние, когда человек видит цель, хочет её достичь и постоянно ищет путь сделать это быстрее.
Когда задача не просто попадает в Jira.
Когда она живет у тебя в голове.
Когда ты просыпаешься и думаешь о ней.
Когда споришь об архитектуре за обедом.
Когда замечаешь детали в душе.
Когда глаза горят.
Именно в таком состоянии работали те самые четыре инженера.
А теперь посмотрим на другую сторону.
Мы начинаем думать о рисках.
О том, что скажет бизнес. О том, что проект могут закрыть. О том, что ресурсов не дадут. О том, что сроки нереальны. О том, что кто-то будет против.
И постепенно начинаем воспринимать все эти ограничения не как препятствия, которые нужно преодолеть, а как неизбежное будущее.
Мы заранее принимаем поражение.
В нашей команде есть простое разделение.
Над чертой и под чертой.
Под чертой — это когда ты объясняешь, почему не получится.
Над чертой — когда ищешь способ, как сделать так, чтобы получилось.
Под чертой живут оправдания.
Над чертой живет ответственность.
Особенно опасно это для руководителей.
Потому что состояние лидера масштабируется на всю команду.
Если руководитель постоянно рисует вокруг себя квадрат ограничений и ставит себя в центр этого квадрата, то очень скоро вся команда оказывается под чертой.
Недавно читал историю QA-инженера, который за полгода вырос до тимлида разработки.
Не потому что ему повезло.
Он просто начал действовать как владелец своей карьеры.
Начал писать юнит-тесты. Начал исправлять баги. Начал разбираться в архитектуре.
Начал брать ответственность за результат, который формально даже не входил в его зону ответственности.
Его заметили. И у него получилось.
С большими инженерными задачами работает точно так же. Недостаточно быть сильным инженером.
Недостаточно быть хорошим руководителем.
Нужно еще находиться над чертой.
Иногда жестко. Иногда дерзко. Но всегда инженерно.
Потому что великие проекты рождаются не там, где нет ограничений.
Они рождаются там, где люди перестают считать ограничения причиной ничего не делать.
И если честно, главный вопрос для CTO сегодня звучит не так:
«Хватит ли нам ресурсов?» Главный вопрос звучит иначе:
«Находимся ли мы сами над чертой и ведем ли туда команду?» Потому что именно с этого начинается любая инженерная трансформация.
· 30.06
Понимаю посыл. Но давайте посмотрим абстрактнее? Кто эти 4 разработчика, как жили 6 месяцев и какая была гарантия успеха? Сколько таких же горят идеями и о них никто не знает?
Бизнес - не делает быстро, он делает стабильно.
Не обходится без бюрократии, страхов и всего описанного. Главное "но" работает - прибыль есть.
Как и взгляд на "черту" у каждого свой. Начиная от кандидатов на позицию в команде - заканчивая владельцем компании.
Не понимаю, как реализовать найм так, чтобы кандидата оценивали правильно. Сейчас найм субъективен. И это главная проблема. Нет абсолютно никакой гарантии, что человек будет выполнять то, что от него ждут.
Было интересно прочитать это от человека, занимающего руководящую позицию в бигтех.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён