Что там с техлидами, aka staff, aka архитектор?

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

Однако же с техлидом требования выглядят примерно так (по крайней мере в нашей компании): «Ну, сделай то, не знаю что, что-то прямо очень необычное и большое, вооот... И еще тебе это нужно самому придумать и обосновать». Потом те ребята, которым посчастливилось стать техлидами до тебя, будут оценивать, насколько твое творение совпадает с их пониманием, кто такой техлид.

Теперь про плюсы/минусы:

Плюсы:
👉 Ровно как и у тимлида, у тебя выше вилка по ЗП, а также выше коэффициент премии.
👉 У тебя есть возможность расти дальше, но опять-таки на позицию CTO будут претендовать и тимлиды, которые, вероятнее всего, тебя уделают, так как больше парятся про бизнес.
👉 Ты не теряешь в скиллах, скорее даже наоборот – позиция требует, чтобы ты их прокачивал глубже.
👉 Есть рычаги давления на проект как у тимлида, но при этом от тебя не требуется проводить 1-to-1 и вообще заниматься персоналом.

Минусы:
👉 Позиция есть не во всех компаниях, обычно только в биг-техах.
👉 Даже если ты очень крутой спец, который умеет делать уникальные решения, тебя могут не сделать техлидом, если у вашей команды нет на это бюджета.
👉 Порой очень смутные требования для того, чтобы стать техлидом.
👉 Количество усилий, которые нужно приложить, чтобы им стать, не факт, что окупится ростом ЗП.

Я ему сейчас вьебу, честное слово...

Справедливости ради Claude Code прям хорош. Пожалуй один из лучших агентов, которыми я пользовался. Мне кажется он работает на уровне Junior+ или Middle–. Правда такой Middle который переодически в запой уходит и ему становится вообще похеру на твои замечания. Прям как с реальным разрабом получается

Как я так и не получил стаффа в этом году

Короче, рассказываю свою историю факапа. Для получения грейда выше, чем стафф, у нас в компании существует очень чёткий критерий, который я уже упоминал, звучит как: "Ну вы там сделайте что-нибудь прикольное, и те, кто стал стаффами раньше, будут вас оценивать".
Что прикольного сделал я - основные три задачи:

👉 Развернул n8n на всю компанию. Я взял уже готовое решение, развернул его на нашей инфре и сделал мелкие доработки, чтобы оно вообще завелось у нас. Далее договорился с безами, чтобы все могли этим пользоваться.
👉 Импакт-анализ. Кому интересно – подробнее есть статья, кому не интересно – штука, которая запускает только нужные тесты в MR-ах, а не все. И нет, это не как у Авито, у них гораздо примитивнее всё.
👉 Сервис для мобильных релизов. Сервис – это веб-приложение на Next.js, которое позволяет создавать релизы и интегрировано с n8n, чтобы запускать релизные процессы.

Да, все задачи, как вы могли заметить, прям подходят под деятельность мобильного разраба. Короче, почему в итоге этого было мало?

Основная критика строилась вокруг двух вещей:

👉 Нехватка technical complexity
👉 Нет законченности задач

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

Второе это "нет законченности задач". Вот это вообще странная вещь, потому как мы говорим про IT решения. В какой блять момент можно сказать что она закочена? У каждой из этих систем есть хренова гора вещей которые можно улучшать и допиливать до бесконечности.

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

Справедливости ради, были и разумные доводы касательно проработки требований и обеспечения стабильности. Оказалось, что если даже ты выходишь за рамки своего стека, это никого не волнует. Ведь ты во всех стеках должен быть на уровне senior++.

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

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

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

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

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

Мне нравится шутка, что лучший джун - это выгоревший джун. Он, разумеется, не сделает идеально, но, по крайней мере, не наделает такого, после чего придётся самому исправлять.