(Не)очевидные советы про архитектуру:

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

Попробуй предварительно нарисовать команду:

Если в твоем продукте три экрана – это не значит, что тебе нужно три микросервиса. Если все три делают два человека – им будет нормально и в одном. А если над продуктом будут работать три команды по 5 человек – лучше резать.

Учитывай этап развития бизнеса:

Сервис, "создающий заказ", для одного rps, для 1000 rps и для 100000 rps – это три разных архитектуры. Проектировать несвоевременно вредно как в большую, так и в меньшую сторону

Выбирая технологию, думай об уровне результата

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

Если нужно "строго лучше" – это может быть хорошим поводом попробовать что-то поменять

(дисклеймер для ковбоев: если у тебя космические требования надежности – это, скорее всего, означает подход "не хуже")

Расскажи об архитектуре не-техническим руководителям

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

Оформи дизайн-документ

RFC/RFD/C4/в пэйнте, не важно. Артефакт, который, во-первых, могут поревьюить (в том же смысле, что и код, а не на словах!) другие инженеры, и который у вас останется – это почти что лучшая документация для технарей, которым лень писать документацию

Погугли как у конкурентов и спроси у GPT

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

Один нюанс при выборе технологического решения

– Запилим сервис сами или купим облачный?
– Построим платформенное решение на три команды или разрешим каждой делать своё?
– Напишем сервис на node.js или python?
– ...

Когда руководители принимают "большие" инженерные решения, велик риск построить обоснование только на инженерных аргументах.

– Я подумал/порисовал – вроде бы можно такой и самим сервис за квартал запрогать
– Я нарисовал на доске принципиальную схему платформенного решения – и оно классно решит задачи двух команд
– Вот в бэнчмарке стек X держит в два раза больше rps, чем стэк Y
...

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

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

Такой сервис, теоретически, возможно запилить за квартал, есть даже команда, которая такое смогла. Но насколько твоя команда похожа на неё?

Обобщенную библиотеку и правда можно написать. Но в каких отношениях находятся лиды, которые будут ее испольовать?

––

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

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

Сколько это стоит?

Есть ли у тебя несколько человек в команде (или целая команда), которая "вроде как" что-то делает, но результат так себе? За квартал в целом что-то выпустили, но планировали в 4 раза больше. Фичу вроде шипнули, но 10 раз переделывать пришлось

Если бы не сделано было абсолютно ничего – ты бы уже давно ее пересобрал. Но вроде пользы "больше нуля"...

Упражнение для технического руководителя / cto / любого другого инженерного управляющего:

1. Посчитай, сколько вы заплатили за содержание команды за тот же период времени. Зп + налоги + премии + сопутствующие вещи типа железок, страховки, прочего-прочего (если не можешь сходу посчитать сам – спроси у hr's, они такое умеют).

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

3. Сравни цифры (1) и (2).

С очень высокой вероятностью после этого ты преисполнишься решимости оживить команду)

––

// конечно, мы понимаем, что оптимизировать нужно не только кост и разработка гораздо сложнее. Есть еще качество, уровень компетенции команды, скорость поставки ценности и прочее-прочее. Но если последнее начало хромать – попробуй посмотреть еще и на кост :)

Как (не) думать вместе с GPT:

GPT (мне, кстати, субъективно нравится gemini, а вам?) – очень крутой помощник в обдумывании идей и решений. Одним запросом можно быстро получить набор идей/подходов к проблеме, или узнать подробнее про какой-то из них. Я и многие мои знакомые используют его каждый день, но..есть один паттерн, который кажется мне жутким:

Часть менеджеров явно использует gpt не как "еще один [негарантированной надежности] источник информациио проблеме", а как конечное решение. Я буквально в ряде чатов, в том числе рабочих, вижу, как люди присылают сообщения, написанные gpt. Может быть, немного отрефакторенные (но не всегда!)

Если ты так тоже делаешь:

– Во-первых, gpt – не узко-экспертная нейросеть, обученная решать задачи из твоего домена. Да, у нее реально есть много информации (почти всегда больше, чем у тебя), но она не обучена максимально эффективно ее применять для решения задач твоей предметной области. By design general-purpose llm может хорошо и красиво тебе собрать инфу по нужной теме и попытаться сделать логические выводы, но..ты ведь уже пытался на старте карьеры принимать решения так, без накопленной личной практики, правда?) И, наверное, помнишь, что из этого иногда выходит

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

GPT – классный инструмент, чтобы дособрать информацию, получить больше мнений и о чем-то детальнее узнать. Используй его как источник информации и как самую базовую логическую проверку своих идей. Не как decision maker, который выдает тебе финальный ответ и решение!

Что общего у плохого резюме и плохого описания вакансии?

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

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

– Разработка кода на Java
– Проведение Code Review
– Написание юнит-тестов
– ...you name it

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

На одном и том же стэке технологий можно разработать

– Платежный процессинг
– Городское такси
– Систему управления роботом
– Да в целом примерно что угодно

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

Если у меня на (виртуальном) столе лежат два резюме, и автор одного из них "разрабатывал код на языке X, писал автотесты с использованием библиотеки Z, формировал функциональные требования", а автор второго – "на языке X разработал сервис рассчета цен на доставку еды, благодаря чему GMV сервиса вырос на 5%" – я, скорее всего, не встречусь с первым человеком.

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

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

Нет, это невозможно

Я снова забросил медийку и занялся делами. За это время адопшен llm и bullshit-менеджмента (и соответствующего контента) во всех моих топ-менеджерских чатах достиг абсолютно неприличного уровня, вызывающего диарею и тошноту при случайном прочтении. Придется продолжить сюда писать, чтобы у всех нас в ленте был хотя бы один не-такой канал.

Кстати, вы ещё здесь?

А зачем им это?

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

– Всем внедрить AI!
– В течение одного дня после инцидента заполнить пост-мортем на 3 страницы!
– Приходить на каждую часовую встречу с новостями компании раз в неделю!
– Использовать/не использовать/делать/не делать <X>

Почти за каждым таким призывом лежит цель или желание руководителя. Например, ты прочитал, что Джек Дорси сократил половину компании "за счет AI" и его акции выросли на 25%. Ты тоже хочешь стать богаче (и реально станешь, если сумеешь это повторить и не просрать компанию). Приходишь к команде, говоришь – "всем сесть на claude code завтра" и..ничего не происходит. И если дважды прийти – ничего не происходит. И трижды.

– Почему? Они что, не понимают?

А зачем? Разработчик получает фиксированную зарплату раз в месяц. Она не увеличится, если он начнет использовать claude code. И не уменьшится, если не начнет. Может уменьшиться, когда большинство людей в той же компании начнут, но..они в такой же ситуации – зачем им это? Можно дождаться, пока случится, а потом дергаться.

Можно попробовать построить положительную мотивацию – например, сделать так, чтобы использовать было намного приятнее, чем не использовать. Например, собрать какое-то окружение, гайдлайны, напилить интеграций во все свои сервисы (и в таск-трекер, и в мессенджер), тогда с какой-то вероятностью начнется adoption. Можно отрицательную – уволить половину сотрудников в компании, а от остальных потребовать любой ценой (например с помощью claude code)) суметь решить все задачи. В первом случае есть риск, что мотивация не сработает. Во втором случае есть риск, что ты развалишь компанию через год. Но и тот и другой приведут к изменению поведения людей.

И то же самое с заполнением отчетов (или посещением встреч на всю компанию). Получает ли человек что-то ценное для себя следуя правилу (или теряет, не следуя ему?). Если ответ "нет" – ты можешь только надеяться на удачу.

Звучит очень заезженно, но если люди не делают чего-то, чего ты хочешь, попробуй задать себе вопрос: "а зачем им это?"

Работа в офисе

Неожиданно, обсуждения (в том числе те, в которых мне приходится участвовать) про офисную работу в IT так никуда и не делись. Я вижу очень простой чеклист решения, нужен ли мне человек в офисе:

– Я могу посадить его рядом с другими людьми, с которыми ему лучше регулярно говорить, чтобы эффективно выполнять свою работу?

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

Проверка, если ты уже заставил их сидеть в офисе по любым причинам: люди фактически говорят друг с другом или нет? Если нет, значит им это не нужно для работы.

– Я могу дать человеку рабочее место не хуже, или не намного хуже, чем он организует себе сам?

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

А sweatshop – кошмар любого работника интеллектуального труда. Это когда полтора квадратных метра на человека, в офисе принято кричать и одна переговорка на этаж. И – да, в 2026 году так продолжают делать. Дешевле же? На самом деле нет. Ты экономишь на стульях и переговорках несколько процентов от бюджета, а в итоге все твои люди работают хуже и ты теряешь половину эффективности

––––

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

Но тут я могу следить, что они правда работают, а не в потолок плюют!

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

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

––

Это примерно все, что нужно знать, рассаживая людей по офисам. Пользуйся и помоги руководителю :)

Вложи в нетворк

Если сомневаешься, во что "с пользой" вложить свое свободное время – вложи в нетворк.
Открываешь linkedin / канал в телеге / рабочий чат <моя компания ALL> / whatever, выбираешь кого-то, кто выглядит интересно (в идеале – человека на >=1 уровень выше твоего текущего в твоей или смежной компании, с которым у тебя есть хоть что-то отдаленно общее), присылаешь в личку свое короткое интро, предлагаешь выпить кофе и поговорить за жизнь и работу, обменяться опытом. Встречаешься и пьешь кофе, повторяешь, если появилось, что обсудить

Эффект накапливается "долго", но дает очень много. Например, я видел кейсы продвижения из тимлида в CTO. И из продакт-лида в CEO. И – да, это происходит и в больших компаниях тоже.

На уровне m1 – это топ-2 (сразу после "классно сделать свою работу, чтоб все были довольны + собрать команду так чтобы в следующий раз это случилось без тебя" ) твой рычаг продвижения и получения интересных карьерных и жизненных возможностей. На уровне m2, m3, cXo и тд – топ-1.

// кстати, мне тоже можно написать 🙂

Не отвлекайся от скучных встреч

Одна из полезных привычек последнего полугода – заходить на встречу без телефона (прям физически его где-нибудь бросить) и заблочить себе на ноуте все кроме зума (есть разный софт для этого, например hammerspoon или cold turkey micromanager).

Некоторые скучные встречи после этого становятся ЧУДОВИЩНО скучными и ты быстрее учишься их полностью избегать/делегировать/проводить быстрее и эффективнее. А на некоторых появляются неожиданные полезные детали.

Если еще не пробовал – попробуй 🙂

Почитать на досуге про переговоры и бизнес

Случайно посмотрев фильм про Трампа (The Apprentice; как по мне, не очень) я узнал, что он написал книгу. И "по фану" скачал и книгу тоже, The Art of the Deal: https://en.wikipedia.org/wiki/The_Art_of_the_Deal

Так вот, в отличие от фильма, книга – отличная. Для менеджера или начинающего предпринимателя она может сдвинуть отношение как к переговорам, так и к ведению бизнеса вообще. Например, в ней:

– Есть кейс огромной и очень дорогой стройки, контракт на которую согласован без реальных денег, а деньги найдены позже и, притом, не свои. И это на старте предпринимательнской карьеры, без накопленной репутации. Не очень бьется со стереотипами о том, как начинается бизнес, да?
– Есть примеры "хороших и не очень длинных переговоров", которые длятся НЕСКОЛЬКО ЛЕТ (а ты спустя сколько попыток договориться теряешь мотивацию?)
– Приводится просто много забавных и интересных кейсов переговоров, подготовки к ним и поведения в процессе

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

Молчание – не знак согласия

Повторяй про себя во время "сложных" коммуникаций и изменений.

Если ты сказал своим подчиненным/коллегам/партнерам/whomever, что теперь их роли меняются таким-то образом и надо делать что-то новое и они промолчали – это абсолютно не значит, что они приняли и сделают.

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

Как попросить человека выразить активное согласие или несогласие?

Например – спросить, как, по его пониманию, изменится его жизнь/работа и что он об этом думает. + дослушать до конца. + поспрашивать, если явного ответа нет или договориться обсудить позже (и реально обсудить)

Зачем?

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

Кстати, тема пересекается с "Зачем им это?"

Экспериментальный формат консультаций (вдруг это так работает!)

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

Эксперимент с зумерским коротким форматом:

По цене ~подписки на gpt (+ налоги + доставка + на пиво) можно купить у меня самую короткую консультацию на диком западе:

– одно сообщение с твоим контекстом и вопросом про IT и управление
– одно сообщение с моим ответом

Вопрос и ответ – не больше 4000 символов, один экран. Никаких уточнений, комментариев, whatever else (это для длинного формата).

Купить можно здесь: https://boosty.to/leads/posts/bc4a1abe-25c5-4ab1-b91c-bd3243a31e75

После покупки поста написать мне в сообщения на бусти, отвечу в течение 24 часов.

Хороший консультант/непонятный консультант

Интересно, сколько хейта я поймаю этим постом...)

На самом деле, отличить хорошего консультанта от непонятного очень просто.
Если человек на большом масштабе делал что-то "для себя" + говорит на языке, который ты знаешь – это хороший консультант. Если хотя бы раз-другой хорошо получилось – значит человеку есть что рассказать. Он, кстати, может при этом не называться консультантом и даже не знать, что он – консультант.

Например, ты строишь большой е-ком и не знаешь, как сделать движок рекомендаций. Лучший консультант по технической части – это инженер, сделавший рекомендации в другом большом екоме. А по продуктовой – такой же продакт менеджер. И так далее. СКОРЕЕ ВСЕГО они не называют себя консультантами и просто заняты основной работой – они буквально получают свои деньги за то, что их движок рекомендаций хорошо работает (обрати внимание – не за то, что они кому-то уже продали консалтинг о построении движков рекомендаций). Бывают, конечно, исключения (я гораздо больше делаю "своего", чем консультирую, но и консультирую тоже), но обычно у таких людей public visibility стремится к нулю.

Вот именно их и стоит нанять на консалтинг. Они не нарисуют тебе идеальную презентацию, бенчмарк по рынку, эксель на 500 строчек. Они просто коротко скажут тебе что делать. Чтобы их найти – надо поговорить с людьми, которые более-менее глубоко встроены в IT-сообщество и работают в нем сами. Кстати, у меня тоже можно спросить про таких людей 🙂

––

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

Почему? Такой консалт тебе сегодня уже сделает и claude. Реально это будет обзор рынка и набор кое-каких практик (скорее всего, не этого года). И скорее всего ты не получишь при этом экспертизы реального использования "для себя".

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

––

– И что, мне вообще не обращаться в обычный консалтинг?

Смотря для чего. Чтобы получить быстрый верхнеуровневый overview – вполне можно.
Чтобы получить детальное экспертное решение – ну..лучше бы нет. Можешь спросить у своих консультантов, есть ли среди них человек, за последние 2-3 года делавшие это не в качестве консалтинга. Или могут ли они тебе привести такого человека из своего нетворка 🙂

– А как найти "экспертного" консультанта?

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

– А их не остановит NDA?

Теоретически – должен. Практически – они ведь не покажут тебе исходники as is и не сделают copy-paste, правда?)
Да и в целом – я еще ни разу не видел, чтобы NDA кого-то от чего-то остановил...

Опять же, половина меж-банковского найма, например, ровно за этим и делается 🙂

Буллшит-бинго / Найми одного QA

––

Дисклеймер:

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

––

Блядь, но ты сам реально пользовался тем самым "AI-прорывом", который ты сделал за прошлую ночь без разработки и вот-вот задизраптишь рынок? Или такой же поделкой от какого-нибудь известного парня из долины? Попробуй, перед тем как в следующий раз кинуть что-то в чат на большое количество людей, или в свою ленту, или на сцену, показать свой "работающий и почти готовый к продакшену AI-продукт" тестировщику. Хотя бы миддлу, но можно и младшему. Имеющему опыт работы.

Компилятор, сгенерированный полностью агентами и компилирующий дум, на старте не мог скомпилировать hello world.
Браузер, написанный полностью агентами, работал и работает..специфично

Надо ли говорить о том, что я вижу на демо и в личках?)

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

// пузырь – это не обязательно что-то полностью фейковое. Это, довольно часто, что-то, имеющее реальную ценность, но ОЧЕНЬ криво интерпретированное людьми, управляющими деньгами.

Границы зоны ответственности / Let Them Fail

Знал я одного менеджера очень высокого уровня, как-то раз в интервью сказавшего: "моя зона ответственности – вся компания".
Интересно, много ли у меня подписчиков, видевших это интервью и работавших со мной в той же самой компании?)

Так вот – это в части случаев не работает.

Если смотреть на вещи реально:

Команду в своем официальном управлении ты можешь заставить сделать что угодно

Да, могут быть проволочки, да, может быть сопротивление, да, это может быть долго, но eventually все, что могут сделать физически твои подчиненные – зона твоей полной ответственности (в предельном случае, если человек что-то не делает, ты всегда можешь заменить)

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

Если твои горизонтальные коллеги делают свою работу "плохо" / "неправильно" / полностью не делают – ты, в общем случае, не можешь get it done.

– Ты можешь прийти и о чем-то попросить (или жестче – "обозначить свои ожидания", если функция сервисная).
– Ты можешь предложить несколько решений, если у тебя есть идеи.
– Ты можешь аргументировать, поспорить, отработать возражения.
– Ты иногда можешь сделать заплатку своими силами. Например, если продакт не может доформулировать для тебя описание задачи, а делать надо и дедлайн горит, можно кое-как самостоятельно описать и сделать. У этого есть риски, но лучше, чем ничего. Если команда office management & hr не может устроить тебе рабочее место (вот вы смеетесь, а такое бывает) – ты можешь до какой-то степени сам себе найти где работать. А если команда инфраструктуры не достраивает вовремя датацентр – ничего не сделаешь сам. Или еще какие-нибудь люди, работу которых ты практически не понимаешь.
– Ты можешь проэскалировать проблему (начиная со своего прямого руководителя до минимального общего) и с некоторой вероятностью другой руководитель это решит

Но в общем случае, если не твои люди что-то фейлят и серьезно настроены – они зафейлят и ты их не остановишь.
Если ты попробовал все из списка выше – ты отработал свою зону ответственности (как бы она не называлась; за исключением ситуации, когда ты – ceo/owner и можешь заменить буквально любую часть компании) и можешь спокойно пойти спать.

– А если проект и компания развалятся из-за этого?

Значит развалятся. Если люди делают что-то НУ ОЧЕНЬ СТРЕМНОЕ, ты честно им об этом сказал, предложил альтернативы, поэскалировал и это не помогло – это конец твоего влияния. Верни фокус на свою работу. Просто в одном случае все развалится, а ты будешь параллельно жить спокойно и не почувствуешь своей вины, а в другом – все развалится, а ты параллельно пожжешь кучу нервов, со всеми разругаешься, еще и останешься виноватым. Что выгоднее?)

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

–––––

Фокусируйся на доступном и получится лучше :)

Sanity Check

Одни из самых интересных клиентов на консультациях – владельцы или CEO's стартапов, доживших до стадии роста.
В такой позиции часто ты оказываешься наедине со своими проблемами, ощущениями и не очень высокогрейдовой командой. Команда проблемы/опасения не разделяет, а ты – не эксперт в разработке. И вроде происходит "что-то не то", а вроде и давить страшно – вдруг ты не прав?

В таких ситуациях очень полезным бывает sanity check – быстрый разговор о своих опасениях и предположениях с кем-то опытным в engineering management. Бесплатно, без регистрации и СМС, даю ниже набор тейков, которые подтвердят или опровергнут твои сомнения без полноценного консалтинга:

––––

Если сомневаешься, нормально ли релизить раз в месяц – не нормально

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

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

Мобилу можно катать не реже, чем раз в 2w. За единицы дней +- невозможно (ревью в store), за неделю – можно, но каждую неделю будете тратить время на ревью, команда может считать неоптимальным, за 2 – должно быть легко. Если нелегко – это проблема

––

Если сомневаешься, нужен ли процесс – нужен

Спринты, скрам, канбан, эджайл, ретро, доски, сторипоинты..а мне что-то из этого нужно?
Если команда больше единиц человек И ты не можешь лично отслеживать все, что делает каждый – нужно.
Какой процесс правильный? В целом – любой, который ты сам можешь быстро понять, никаких других требований для старта нет. Если "интуитивно" понятным и удобным не выглядит ни один – попробуй что-нибудь похожее на скрам (можешь у claude или gpt спросить как для твоей команды выглядит максимально облегченная его версия). Сможешь чуть чаще спать по ночам и спорить об эффективности команды и обещаниях не только на воспоминаниях.

––

Если сомневаешься, нужен ли человек на любой не-производящей роли – не нужен

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

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

––

Если сомневаешься, можно ли масштабировать команду только за счет AI – нельзя

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

И – да, когда ты вырастаешь (не 5-6 человек), fullstack начинает работать хуже, придется (частично) специализироваться.

––

Если сомневаешься, нужен ли тебе в команде кто-то "посильнее" – нужен, для начала хотя бы один человек

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

Даю 90% вероятности из своего опыта, что если ты начинал свой стартап без длинного трека в сильном tech и без десятка свободных миллионов долларов на счету – твоя первая команда состоит из других людей. Это не плохо, так почти у всех. Когда деньги начинают литься, идет рост, а в tech что-то идет не так (все вопросы из поста – об этом), тебе нужен хотя бы кто-то, кто не просто верит в тебя, в идею, а еще и имеет твердую экспертизу. Да, за это нужно что-то заплатить. Да, скорее всего ты не наймешь сам, понадобится еще и интервьюер. Но хотя бы один такой человек в команде (или как лид, или как senior/staff engineer) может сильно поменять происходящее. В какой-то момент (еще раз дисклеймер: когда деньги на это будут не из твоих сбережений на черный день) в команду нужно вложить денег и это вернется.

И – не интервьюируй людей полностью сам. Ты так уже делал на старте 🙂

Реорганизации и миддл-менеджмент:

AI-трансформации в компаниях, помимо общего сокращения штата (ожидаемо), дают еще один интересный эффект: сокращение миддл-менеджмента. Из моих наблюдений за big techs, именно такие люди хуже всего переживают оптимизации и реорги – им просто нет места. cXo все еще нужен – это человек, закрывающий всю головную боль и ответственность по функции в компании. Линейный руководитель (тимлид) все еще нужен – нельзя же всех исполнителей воткнуть в cXo, их даже после сокращений остаются, как минимум, сотни.

А вот middle-management, руководитель нескольких лидов, но еще не директор..уже начинает попадать под нож (по крайней мере две крупные технологические компании, в которых такое происходит, я уже видел).

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

Для фаундера:

Если у тебя есть структура

dev -> tl -> middle manager -> cto и ты понимаешь, что middle manager как роль больше не нужен тк все стали очень эффективными – конкретный человек в роли, если он сильный, ОЧЕНЬ возможно способен разделить эту точку зрения и принять работу уровнем ниже. Возможно, даже заменить двух tl (это будет выгодно, он получает не x2). Или одного tl и троих IC, если он вырос в свою позицию не просто так. Это можно, как минимум, обсудить. "Не нужна роль" и "не нужен человек" – это очень разные вещи.

Для миддл-менеджера:

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

–––

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

// кстати, хороший чек на квалификацию миддл-менеджера: если он без проблем готов начать снова "производить" – он скорее всего хорошо помнит как это делается и может наносить много пользы. Если нет – ты не ошибаешься с оптимизацией