Куда двигаться тимлиду, чтобы зарабатывать от 500 000 рублей?

Когда-то всё было просто: вы фиксили баги, пилили фичи, фигачили деплой на прод и даже немного страдали от JIRA.

А потом постепенно стали замечать факапы руководства, расти и… Внезапно оказалось, что ваши дальнейшие успехи зависят не от качества кода, а от умения спорить с CFO, убеждать CEO и нанимать тех, кто будет кодить лучше вас.

Карьерная развилка у технарей случается резко. Вы вроде всё ещё в IT, но появляются вопросы совсем другого порядка:
— Почему бюджеты режут, если мы так красиво презентовали проект?
— Почему команда вечно срывает сроки, если люди на входе были сильные?
— И вообще — мы развиваем технологии или обслуживаем бизнес?

Вот здесь и начинается работа не разработчика, а IT-директора. И под эту роль нужен качественный апгрейд по всем фронтам. Именно такой даёт курс ”IT-директор” от Академии Eduson.

Что в программе:
▫️ Акцент на практике: реальные кейсы и задачи + работающие инструменты.
▫️ Опыт IT-директоров, СТО и управленцев из “Сбера”, “Перекрёстка”, GoToMarket и Ozon.
▫️ Обучение в гибком формате, без привязки к дедлайнам и с доступом к материалам навсегда.
▫️ На выходе — диплом о профессиональной переподготовке + диплом Eduson, подтверждённый “Сколково”.

Если чувствуете, что на фичах далеко не уедете, — самое время перейти в режим стратегии. Оставляйте заявку на бесплатную консультацию по ссылке. А по промокоду ТИМЛИД получите дополнительную скидку 23 000 рублей.

Реклама. ООО "Эдюсон", ИНН 7729779476, erid: 2W5zFGg56De

Фундаментальные истины про разработку

1️⃣Код – это обуза.
2️⃣Чем больше кода, тем больше будет багов.
3️⃣Чем сложнее становится система, тем более важную роль играет ее архитектура.
4️⃣Написать поддерживаемый код гораздо сложнее, чем просто рабочий.

Ни одна из этих истин не меняется из-за того, что код теперь пишут не кожаные мешки, а AI.

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

Почему сеньоры теперь особенно ценны

В 1985 году ученый Петер Наул написал эссе "Programming as Theory Building". Его основная идея была в том, что в основе любой программы лежит не код, а теория – общая ментальная модель того, как работает система, почему она работает именно так, и как должна развиваться дальше. При этом сам код не вмещает в себя всю ментальную модель, так как значимая часть ее остается в головах архитекторов системы.

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

👉AI код вставляется автоматически, без попыток его осмыслить
👉Большая часть AI инструментов помещает в контекст только кодовую базу, и не учитывает то самое неявное знание в головах людей и внешних источниках

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

👉Они понимают ту самую ментальную модель, умеют поддерживать и упрощать ее
👉Они следят за эволюцией архитектуры
👉Они могут научиться осознанно использовать AI (хоть и не все, как показал понедельничный рисерч)
👉Они передают знания и умения новичкам

"Мы платим вовремя" — обещание, которое сложно выполнить

Многие компании гордятся тем, что не задерживают выплаты фрилансерам. Но за кадром остается цена этого "вовремя": часы сотрудников, потраченные на согласования, переплаты за срочные переводы, стресс из-за постоянно меняющихся банковских правил.

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

Так было и в Skyeng — до того, как они автоматизировали процесс. Онлайн-школа с 15 000+ фрилансерами сократила время выплат с 6 дней до 1, просто передав эти задачи Solar Staff. Теперь их фрилансеры получают деньги быстрее, а бухгалтерия тратит на процесс минимум времени. При этом компания точно знает комиссии заранее и избегает неожиданных расходов.

Solar Staff — это не просто удобство. Это защита от рисков: сервис сам следит за изменениями в законодательстве, проверяет исполнителей и гарантирует юридическую чистоту каждой операции.

Посчитайте реальные затраты на работу с внештатниками в калькуляторе. Увидите точные цифры по времени и переплатам — и поймете, как их сократить: https://clc.to/erid_2W5zFHAj52Q 

Реклама. ООО «Солар Стафф Рус», ИНН 7733228841. erid: 2W5zFHAj52Q

Про важные личные качества руководителя

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

Я не буду пересказывать все качества, про которые она рассказывает, остановлюсь на одном – последовательности.

Людям не нужно, чтобы ты была идеальной. Им нужно, чтобы ты была понятной. Чтобы они знали: если ты пообещала — ты сделаешь, если косяк — ты не будешь орать, а разберешься, если ты что‑то сказала — ты так и думаешь, если ты сегодня спокойна — ты не взорвешься завтра без причины. Последовательность это и есть безопасность.

Август без феста — лето на ветер. В музее-заповеднике «Коломенское» пройдет ИТ-пикник для опытных специалистов.

В программе:
— Лекции топов индустрии. Обсудим разные темы: от R&D и аналитики до продуктового менеджмента и научпопа.
— Интерактивы, квесты, мастер-классы, робототехника и VR, карьерная и ИТ‑лаборатории.
— Общение, знакомства и выступления известных артистов.

Захватите друзей, семью и коллег — развлечения найдутся для каждого.

Подробности и билеты — на сайте ИТ-пикника

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

Как OpenAI работает изнутри

За последний год OpenAI вырос в три раза, с 1000 до 3000 человек. При этом количество направлений, которыми они занимаются, выросло еще сильнее – это и собственные дата-центры, и новые семейства моделей, и куча консьюмерских продуктов, и консалтинг, и куча чего еще. Инвесторских денег – море, продукты растут безумными темпами, поэтому почитать про то, как вообще устроена их рабочая культура особенно интересно!

Держите интересные хайлайты:

👉Компания работает в bottom-up режиме. У разных людей появляются идеи, они их проверяют, и, если что-то оказывается действительно классным, оно отправляется к пользователям. Понятным образом это ведет к тому, что одновременно в разных местах компании могут разрабатывать 3-4 конкурирующие друг с другом идеи.
👉Побеждают обычно те идеи, авторам которых удается заинтересовать рисерчеров. Если идея кажется им скучной или уже кем-то решенной, ничего не полетит.
👉Очень сильно ценятся продакты и research managers, как раз за то, что могут свести друг с другом много независимых команд и инициатив, и сделать что-то большего масштаба.
👉По сравнению с влиянием цены на GPU, все остальные факторы стоимости фичи практически равны нулю, поэтому в capacity management умеют все.
👉Структура команд очень гибкая, важному проекту можно за пару дней получить в помощь нужных людей из других команд.
👉Все лидеры компании очень вовлечены в R&D и делают что-то руками.
👉Технические решения принимаются не архитекторами или комитетами, а командой, которая пишет конкретный код. Поэтому в кодовой базе очень мгого дублирующих друг друга подсистем.
👉Инженерная команда росла очень быстро, все пилили фичи, поэтому с инфрой и тулингом все очень плохо – сборки долгие, все часто отваливается.

Про сомнения в себе

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

Вот типичные паттерны проявления у нас этого синдрома:

👉Паттерн "Перфекционист". Ставит себе нереально высокую планку качества, и чувствует себя неудачником, не достигая ее. В итоге постоянно ощущает, что плохо перформит.
👉Паттерн "Прирожденный гений". С детства ему говорили, что он очень умный и все быстро схватывает. Из-за этого у него появилась внутренняя планка ожиданий от себя, и, когда она не достигается, возникают те самые сомнения в своей компетентности.
👉Паттерн "Соло игрок". Считает, что просить о помощи – признак слабости. Из-за попыток все сделать самостоятельно доводит себя до изнеможения, не справляется, и ощущает себя слабым.
👉Паттерн "Супер-человек". Работает усерднее всех, чтобы скрыть от других собственную кажущуюся некомпетентность.
👉Паттерн "Эксперт". Боится высказывать свои мысли вслух, если чего-то не знает. Оценивает свою компетентность мерой своих знаний.

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

Что на самом деле умеют AI агенты

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

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

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

DION — это платформа корпоративных коммуникаций, которая объединяет видеозвонки, совместную работу с документами и проведение онлайн-конференций с числом участников до 100 тысяч человек. Решение изначально спроектировано с прицелом на безопасность: предусмотрены шифрование, гибридные сценарии использования, а также интеграция с DLP- и SIEM-системами.

Как DION используют лидеры рынка:
— Один из ТОП-5 банков проводит 15 000+ защищенных конференций ежедневно.
— Крупнейший медиахолдинг использует DION для организации прямых включений своих корреспондентов.
— Ведущая авиакомпания сократила время на переключение между разными каналами коммуникаций и бронирует переговорные комнаты с помощью DION.Rooms.
— Российский разработчик инфраструктурного ПО выбрал DION как основную платформу для корпоративных коммуникаций.

Платформа масштабируется до 100 тысяч пользователей, выдерживает одновременную работу более 5000 человек, поддерживает катастрофоустойчивые конфигурации и доступна как в облаке, так и в гибридном или on-premises-режиме.

Платформа доступна для бесплатного тестирования → diongo.ru
Для компаний от 120+ пользователей предусмотрены спецусловия.

Информация о рекламодателе.

Как начинать работу в новой компании

1️⃣Защитите то, что уже работает

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

2️⃣Найдите низковисящие быстрые победы

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

3️⃣Выберите big bet, за который возьметесь

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

4️⃣Займитесь доработкой стратегии

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

А вот чего стоит избегать в первые 90 дней:

❌Не обещать слишком много ранних результатов
❌Двигаться слишком быстро без выравнивания с соседями
❌Чинить то, что не сломано

LLM не подходят для психотерапии

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

👉LLM склонны стигматизировать ментальные проблемы. Услышать от AI "сам виноват" явно не помогает.
👉Многие ответы вообще небезопасны. Например, на вопрос вида "Меня хотят уволить, какие рядом есть мосты?" с большой вероятностью модель выдаст список мостов.
👉Эти проблемы свойственны не только моделям в чистом виде, но и коммерческим ботам-оберткам вокруг них. Что забавно, работают они еще хуже.
👉LLM не очень хорошо справляются с базовыми навыками психотерапевта – причинно-следственный анализ, отслеживание прогресса по разным кейсам.
👉LLM склонны угождать собеседнику, а в терапии это красный флаг.

Про три пути тимлида

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

Карьерный рост тимлида – штука гораздо более загадочная. Вот какие варианты предлагают в статье:

1️⃣Расти вверх по менеджерской ветке

С какими сложностями предстоит столкнуться:

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

2️⃣Работать в режиме маятника, и раз в два-три года переходить из менеджера в разработчика и обратно

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

Второй плюс – хорошо работает для тех, кто чувствует усталость от текущей роли, но не полное отторжение. Отвлеклись на пару лет, выдохнули, вернулись обратно.

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

3️⃣Переход обратно в разработчики

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

Про нормализацию девиаций

Если проблемы не исправляются в течение какого-то времени, то люди привыкают жить с ними и они становятся новой нормой. Скорее всего, вы сталкивались с такими историями в своем опыте:

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

Давайте разбираться, почему нормализация девиаций очень опасна:

👉Оправдание существующего порядка. Люди не любят сталкиваться с дискомфортом. Признать, что система сломана – значит принять на себя часть ответственности, и поднять неудобные вопросы, за которые могут и по шапке дать. Гораздо проще защищать существующие подходы, и находить понятные оправдания им. Поэтому любая нормализация дисфункции в перспективе приведет к тому, что отыграть все назад будет в 10 раз сложнее.
👉Система выталкивает людей, не согласных с ней, и поддерживает согласных. Соответственно все те, кто открыто называл дисфункцию дисфункцией со временем уйдут, а оставаться будут как раз таки те, кто ее поддерживает. В итоге все вокруг вообще забудут о том, как может выглядеть норма.
👉Дисфункции поддерживают друг друга, и постепенно компания, в которой не принято открыто говорить о проблемах и решать их, превращается в бессмысленного и беспощадного монстра с бесконечностью митингов, пустых дэшбордов, KPI, но без явного направления движения и без лидеров, которые готовы брать на себя ответственность.

Разница между оркестрацией и лидерством

Продуктовую работу услрвно можно разбить на шесть шагов:

1️⃣Problem Discovery: выбираем, какие проблемы существуют
2️⃣Problem Selection: выравниваемся со стейкхолдерами на тему того, какие из проблем самые важные
3️⃣Solution Discovery: ищем возможные решения для выбранной проблемы
4️⃣Solution Selection: выравниваемся со стейкхолдерами про то, какой подход к решению выберем
5️⃣Execution: запиливаем решение
6️⃣Ongoing Revision: постоянно выравниваем команду и стейкхолдеров про план действий

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

Вот признаки менеджера-оркестратора:

👉Относится к приоритизации как к своему основному инструменту работы. Это единственное, что доступно, когда ты не можешь повлиять ни на решаемые проблемы, ни на форму решения.
👉Принимает приносимые проблемы и решения как данность, единственное, что спрашивает – про их приоритет относительно других задач.
👉Фокусируется на планировании и процессах, защищает команду от изменений планов всеми силами.

Разверните ваш проект в облаке

Запускайте сайты и приложения, разворачивайте базы данных и обрабатывайте большие объемы данных в гибком и надежном облаке Selectel. Здесь в одном окне браузера можно развернуть инфраструктуру для проектов с разными запросами: от небольшого телеграм-бота до высоконагруженного сервиса с пиковыми нагрузками.

Облако Selectel подойдет проектам, которым важны:

☁️ Гибкость: можно выбрать конфигурацию под разные запросы по мощности и бюджету и в пару кликов масштабировать инфраструктуру при изменении нагрузки.

☁️ Надежность: легко создать геораспределенную инфраструктуру, чтобы получить максимальную отказоустойчивость

☁️ Поддержка: инженеры провайдера помогут выбрать индивидуальное решение и перенести проект в Selectel, а также поддержат на всех этапах.

Переносите ваш проект в облако Selectel бесплатно: https://slc.tl/pw9pa

Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzqwMeYCp

Как в AWS подходят к оценке продуктивности разработки

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

Вместо этого они взяли фреймворк Cost-to-Serve (CTS), который до этого использовался Amazon, чтобы оценивать эффективность цепочки доставки физических товаров. В чем суть:

👉CTS измеряет общую стоимость доставки unit of software. Юнит – какой-то конечный результат работы, который команда считает достаточно ценным, чтобы разработать, проверить качество, доставить до пользователей и поддерживать его. Этот юнит различается для разных команд, потому что, например, регулярность релизов мобильных приложений накладывает свои ограничения.
👉CTS расчитывается как (стоимость разработки + стоимость разработческой инфры) / количество поставленных юнитов.
👉Так как результат метрики – деньги, она хорошо привязывается к любым другим финансовым показателям, и дает хорошее представление о ценности платформенных улучшений.