🔹 Middle: золотая середина
"Решаю проблемы, а не пишу код"
🔥 Что реально требуется:
* Понимание устройства всего проекта
* Умение писать код любой сложности, если есть более или менее чёткие критерии
* Готовность брать на себя ответственность за задачи и их дедлайны.
* Способность перевести простой бизнес-запрос в технические спецификации
* Понимание, как ваш код влияет на смежные модули
* Умение отстаивать своё решение (с аргументами, а не «мне так нравится»)
🆚 Middle vs Senior:
Middle спрашивает: «Как сделать?», Senior — «Зачем делать?»
🎯 Главная цель:
Перестать быть «исполнителем» и начать видеть системные взаимосвязи.
👉 Как расти до Senior?
* Участвовать в обсуждениях бизнес-процессов,
* Работать с бэклогом, самостоятельно формулировать acceptance criteria,
* Начинать менторить и помогать другим.
"Решаю проблемы, а не пишу код"
🔥 Что реально требуется:
* Понимание устройства всего проекта
* Умение писать код любой сложности, если есть более или менее чёткие критерии
* Готовность брать на себя ответственность за задачи и их дедлайны.
* Способность перевести простой бизнес-запрос в технические спецификации
* Понимание, как ваш код влияет на смежные модули
* Умение отстаивать своё решение (с аргументами, а не «мне так нравится»)
🆚 Middle vs Senior:
Middle спрашивает: «Как сделать?», Senior — «Зачем делать?»
🎯 Главная цель:
Перестать быть «исполнителем» и начать видеть системные взаимосвязи.
👉 Как расти до Senior?
* Участвовать в обсуждениях бизнес-процессов,
* Работать с бэклогом, самостоятельно формулировать acceptance criteria,
* Начинать менторить и помогать другим.
🔹 Senior
"Разрабатываю не фичи, а бизнес-ценность"
Здесь начинается игра на совсем другом уровне. Senior — это не просто опытный разработчик, а человек, который понимает бизнес, берет на себя ответственность и влияет на продукт.
📌 Что отличает настоящего Senior:
* Видит разницу между «можно сделать» и «нужно сделать»
* Умеет сказать «нет» заказчику (и предложить альтернативу)
* Автоматизирует рутину команды, а не только свою
* Пишет документацию, которую реально читают
* Лидит процессы. Участвует в оптимизации разработки, CI/CD, DevOps и техническом долге.
* Строит долгосрочные решения, а не просто пилит фичи
* Обучает и помогает Junior/Middle-разработчикам
💼 Неочевидные навыки:
* Выступление на митапах / написание статей (формирование экспертного статуса)
* Управление ожиданиями стейкхолдеров («это займёт 2 месяца» → «это невозможно в ваши сроки, но вот что мы можем...»)
🎯 Главная цель:
Перевести фокус с технологии на бизнес-результат.
👉 Как расти до Lead?
* Брать ответственность за ключевые решения в проекте,
* Учиться делегировать и эффективно распределять задачи,
* Работать не только над кодом, но и над процессами в команде.
* Смотреть на проекты вокруг себя. Расширять свою техническую компитенцию и экспертизу.
"Разрабатываю не фичи, а бизнес-ценность"
Здесь начинается игра на совсем другом уровне. Senior — это не просто опытный разработчик, а человек, который понимает бизнес, берет на себя ответственность и влияет на продукт.
📌 Что отличает настоящего Senior:
* Видит разницу между «можно сделать» и «нужно сделать»
* Умеет сказать «нет» заказчику (и предложить альтернативу)
* Автоматизирует рутину команды, а не только свою
* Пишет документацию, которую реально читают
* Лидит процессы. Участвует в оптимизации разработки, CI/CD, DevOps и техническом долге.
* Строит долгосрочные решения, а не просто пилит фичи
* Обучает и помогает Junior/Middle-разработчикам
💼 Неочевидные навыки:
* Выступление на митапах / написание статей (формирование экспертного статуса)
* Управление ожиданиями стейкхолдеров («это займёт 2 месяца» → «это невозможно в ваши сроки, но вот что мы можем...»)
🎯 Главная цель:
Перевести фокус с технологии на бизнес-результат.
👉 Как расти до Lead?
* Брать ответственность за ключевые решения в проекте,
* Учиться делегировать и эффективно распределять задачи,
* Работать не только над кодом, но и над процессами в команде.
* Смотреть на проекты вокруг себя. Расширять свою техническую компитенцию и экспертизу.
🔹 Lead
"Моя роль — превращать хаос в процессы"
На этом уровне разработка отходит на второй план, а на первый выходит управление командой и процессами.
⚙️ Чем занят Lead:
* Создаёт культуру команды (как проводят ретро, как спорят, как празднуют успехи)
* Формирует стратегию. Как и что будет разрабатываться в ближайшие месяцы и годы.
* Выстраивает команду. Занимается наймом, адаптацией и развитием сотрудников.
* Разрешает конфликты и управляет ожиданиями. Lead — это основной буфер между бизнесом и технической командой.
* Выстраивает процессы. Это включает как ежедневные ритуалы (скрам-митинги, ретро, демо), так и технические процессы: деплой, откаты (rollback), работу над постмортемами, а также внедрение и адаптацию новых инструментов.
* Делегирует задачи. Разрабатывает не сам, а распределяет задачи среди команды.
"Моя роль — превращать хаос в процессы"
На этом уровне разработка отходит на второй план, а на первый выходит управление командой и процессами.
⚙️ Чем занят Lead:
* Создаёт культуру команды (как проводят ретро, как спорят, как празднуют успехи)
* Формирует стратегию. Как и что будет разрабатываться в ближайшие месяцы и годы.
* Выстраивает команду. Занимается наймом, адаптацией и развитием сотрудников.
* Разрешает конфликты и управляет ожиданиями. Lead — это основной буфер между бизнесом и технической командой.
* Выстраивает процессы. Это включает как ежедневные ритуалы (скрам-митинги, ретро, демо), так и технические процессы: деплой, откаты (rollback), работу над постмортемами, а также внедрение и адаптацию новых инструментов.
* Делегирует задачи. Разрабатывает не сам, а распределяет задачи среди команды.
💣 Типичные ошибки:
Застревание в «техническом режиме» → микроменеджмент вместо делегирования.
🆚 Lead vs Senior:
* Senior отвечает за код, Lead — за людей и процессы
* Senior все еще пишет код сам, Lead следит, чтобы команда писала правильно
🎯 Главная цель:
Построить систему, которая работает без вашего ежедневного вмешательства.
Итог
Каждый уровень — это не просто рост технических навыков, а смена фокуса:
🔸 Intern → Junior: «Учусь делать» → «Делаю сам»
🔸 Junior → Middle: «Вижу задачу» → «Вижу систему»
🔸 Middle → Senior: «Решаю проблемы» → «Предотвращаю проблемы»
🔸 Senior → Lead: «Создаю код» → «Создаю среду»
А какой переход был для вас самым сложным? Поделитесь лайфхаками в комментариях!
P.S. А если вы Lead, который до сих пор пишет код по ночам — это нормально. Мы вас видим 👀
Застревание в «техническом режиме» → микроменеджмент вместо делегирования.
🆚 Lead vs Senior:
* Senior отвечает за код, Lead — за людей и процессы
* Senior все еще пишет код сам, Lead следит, чтобы команда писала правильно
🎯 Главная цель:
Построить систему, которая работает без вашего ежедневного вмешательства.
Итог
Каждый уровень — это не просто рост технических навыков, а смена фокуса:
🔸 Intern → Junior: «Учусь делать» → «Делаю сам»
🔸 Junior → Middle: «Вижу задачу» → «Вижу систему»
🔸 Middle → Senior: «Решаю проблемы» → «Предотвращаю проблемы»
🔸 Senior → Lead: «Создаю код» → «Создаю среду»
А какой переход был для вас самым сложным? Поделитесь лайфхаками в комментариях!
P.S. А если вы Lead, который до сих пор пишет код по ночам — это нормально. Мы вас видим 👀
🔥 Карьера разработчика: что после Senior?
Когда разработчик доходит до уровня Senior, возникает вопрос: «А что дальше?» Спойлер: карьера только начинается! На этом этапе открываются четыре основные ветки развития:
🔹 Team Lead – управление командой и процессами
🔹 Tech Lead – техническое лидерство и развитие продукта
🔹 Architect – проектирование архитектуры и стратегические решения
🔹 Manager – переход в управление.
Помимо этих направлений, есть и дополнительные роли, которые можно совмещать с основной позицией:
🔹 Mentor – обучение и поддержка коллег
🔹Engineering Manager - работа с направлением внутри компании (но в данном посте мы не будем погружаться в детали этой роли).
Давайте разберёмся в каждой из описанных позиций подробнее.
Когда разработчик доходит до уровня Senior, возникает вопрос: «А что дальше?» Спойлер: карьера только начинается! На этом этапе открываются четыре основные ветки развития:
🔹 Team Lead – управление командой и процессами
🔹 Tech Lead – техническое лидерство и развитие продукта
🔹 Architect – проектирование архитектуры и стратегические решения
🔹 Manager – переход в управление.
Помимо этих направлений, есть и дополнительные роли, которые можно совмещать с основной позицией:
🔹 Mentor – обучение и поддержка коллег
🔹Engineering Manager - работа с направлением внутри компании (но в данном посте мы не будем погружаться в детали этой роли).
Давайте разберёмся в каждой из описанных позиций подробнее.
🔹 Team Lead
Фокус: Люди и процессы
📌 Задачи:
✅ Организация работы команды (скрам-митинги, ретро, планирование),
✅ Отвечает за продуктивность и мотивацию команды,
✅ Решает административные вопросы (перформанс-ревью, найм, онбординг, увольнение),
✅ Следит за сроками и распределением задач,
✅ Работает над ростом сотрудников и их карьерными планами.
🔹 Senior vs Team Lead
* Senior – фокус на коде и архитектуре,
* Team Lead – фокус на людях и управлении командой.
👉 Ключевой навык для Team Lead – умение выстраивать эффективную команду, а не просто разрабатывать самому.
Фокус: Люди и процессы
📌 Задачи:
✅ Организация работы команды (скрам-митинги, ретро, планирование),
✅ Отвечает за продуктивность и мотивацию команды,
✅ Решает административные вопросы (перформанс-ревью, найм, онбординг, увольнение),
✅ Следит за сроками и распределением задач,
✅ Работает над ростом сотрудников и их карьерными планами.
🔹 Senior vs Team Lead
* Senior – фокус на коде и архитектуре,
* Team Lead – фокус на людях и управлении командой.
👉 Ключевой навык для Team Lead – умение выстраивать эффективную команду, а не просто разрабатывать самому.
🔹 Tech Lead
Фокус: Разработка и технологии
📌 Задачи:
✅ Определяет архитектурные и технологические решения,
✅ Разрабатывает стратегию развития кода и инфраструктуры,
✅ Контролирует код-ревью и следит за качеством кода,
✅ Помогает команде с техническими сложностями,
✅ Работает с техническим долгом и DevOps-процессами.
🔹 Tech Lead vs Team Lead
* Tech Lead – фокус на техническом развитии продукта (качество и масштабируемость)
* Team Lead – фокус на команде и процессах.
👉 Tech Lead – это человек, который помогает разработчикам писать не просто код, а качественный и масштабируемый код.
Фокус: Разработка и технологии
📌 Задачи:
✅ Определяет архитектурные и технологические решения,
✅ Разрабатывает стратегию развития кода и инфраструктуры,
✅ Контролирует код-ревью и следит за качеством кода,
✅ Помогает команде с техническими сложностями,
✅ Работает с техническим долгом и DevOps-процессами.
🔹 Tech Lead vs Team Lead
* Tech Lead – фокус на техническом развитии продукта (качество и масштабируемость)
* Team Lead – фокус на команде и процессах.
👉 Tech Lead – это человек, который помогает разработчикам писать не просто код, а качественный и масштабируемый код.
🔹 Architect
Фокус: Стратегическое проектирование
📌 Задачи:
✅ Проектирование масштабируемых систем
✅ Выбор технологий и архитектурных подходов
✅ Разработка стандартов и гайдов
✅ Взаимодействие с несколькими командами
✅ Оптимизация производительности и интеграций
🔹 Architect vs Tech Lead
* Tech Lead – решает локальные технические вопросы в рамках одной команды
* Architect – отвечает за глобальные архитектурные решения на уровне всей компании или нескольких проектов
👉 Это роль для тех, кто хочет уйти глубже в инженерные решения и решать бизнес-задачи, а не просто писать код.
Фокус: Стратегическое проектирование
📌 Задачи:
✅ Проектирование масштабируемых систем
✅ Выбор технологий и архитектурных подходов
✅ Разработка стандартов и гайдов
✅ Взаимодействие с несколькими командами
✅ Оптимизация производительности и интеграций
🔹 Architect vs Tech Lead
* Tech Lead – решает локальные технические вопросы в рамках одной команды
* Architect – отвечает за глобальные архитектурные решения на уровне всей компании или нескольких проектов
👉 Это роль для тех, кто хочет уйти глубже в инженерные решения и решать бизнес-задачи, а не просто писать код.
🔹 Manager
Фокус: Бизнес и стратегия
📌 Задачи:
✅ Управление командами или отделами
✅ Рост и развитие сотрудников
✅ Найм и адаптация
✅ Взаимодействие с бизнесом и стратегическое планирование
✅ Оптимизация работы всей разработки
🔹 Manager vs Team Lead
* Team Lead – управляет процессами внутри одной команды
* Manager – управляет несколькими командами или целыми отделами.
👉 Это путь для тех, кто хочет полностью перейти в управление и влиять на развитие бизнеса.
Фокус: Бизнес и стратегия
📌 Задачи:
✅ Управление командами или отделами
✅ Рост и развитие сотрудников
✅ Найм и адаптация
✅ Взаимодействие с бизнесом и стратегическое планирование
✅ Оптимизация работы всей разработки
🔹 Manager vs Team Lead
* Team Lead – управляет процессами внутри одной команды
* Manager – управляет несколькими командами или целыми отделами.
👉 Это путь для тех, кто хочет полностью перейти в управление и влиять на развитие бизнеса.
🔹 Mentor
Ментор – это не официальная должность, а дополнительная роль, которую можно совмещать с любой позицией.
📌 Чем занимается Mentor?
✅ Помогает младшим разработчикам расти,
✅ Делится знаниями и опытом,
✅ Участвует в адаптации новых сотрудников,
✅ Может вести лекции или внутренние курсы.
🔹 Кто может быть ментором?
Любой опытный разработчик, который хочет передавать знания и помогать другим расти.
👉 Это важная роль, которая помогает всей компании развиваться быстрее.
Ментор – это не официальная должность, а дополнительная роль, которую можно совмещать с любой позицией.
📌 Чем занимается Mentor?
✅ Помогает младшим разработчикам расти,
✅ Делится знаниями и опытом,
✅ Участвует в адаптации новых сотрудников,
✅ Может вести лекции или внутренние курсы.
🔹 Кто может быть ментором?
Любой опытный разработчик, который хочет передавать знания и помогать другим расти.
👉 Это важная роль, которая помогает всей компании развиваться быстрее.
📌 Итог
Каждый выбирает свой путь в зависимости от интересов:
✔ Любишь управлять людьми? -> Team Lead
✔ Хочешь влиять на технологии? -> Tech Lead
✔ Мечтаешь строить архитектуру? -> Architect
✔ Тянешься к бизнесу? -> Manager
А какой путь выбрали вы? Делитесь в комментариях! 🚀
Каждый выбирает свой путь в зависимости от интересов:
✔ Любишь управлять людьми? -> Team Lead
✔ Хочешь влиять на технологии? -> Tech Lead
✔ Мечтаешь строить архитектуру? -> Architect
✔ Тянешься к бизнесу? -> Manager
А какой путь выбрали вы? Делитесь в комментариях! 🚀
Привет! Мы уже обсуждали грейды, а теперь хочу поделиться своей историей. Возможно, это поможет вам лучше понять возможные пути развития.
Начало пути
Я начал работать в 2016 году на позиции DevOps Intern. В самом начале у меня был небольшой, уютный внутренний проект, но вскоре мне его стало мало. Я начал погружаться в соседние задачи, помогая команде осваивать Terraform (ещё версии 0.6.X!), Jenkins, Docker и прочий базовый DevOps стек.
Через три месяца меня взяли на первый коммерческий проект – для одного из топ-3 ритейлеров США (при этом я очень плохо разговаривал на английском!). Это было страшно: моя команда состояла на 80% из сеньоров, и я очень боялся не справиться. Но через пару месяцев освоился (спасибо коллегам, с которыми до сих пор общаемся!) и получил промоушен до Junior.
Переход в Middle
Со временем я глубже погружался в энтерпрайз-разработку. Однажды мне предложили pre-sale проект, где я смог применить накопленные знания и полноценно залидить его с позиции Junior. Это привело к промоушену в Middle.
В этой роли я задержался примерно на 1–1,5 года. Перейти в Senior помогло то, что я активно участвовал не только в основном проекте, но и в соседних инициативах, расширяя зону ответственности и визибилити в компании. Меня начали узнавать даже на кухне в офисах разных стран.
Путь к Senior
На границе между Middle и Senior у меня появилась первая команда из двух человек (включая меня). Позже, сменив проект, я начал работать уже с командой из пяти человек. Мы переносили легаси-приложения на новую архитектуру в Kubernetes, разрабатывая её параллельно с миграцией.
Проект был сложным – сопротивление архитекторов, менеджеров и других стейкхолдеров порой тормозило процесс. По неопытности, я иногда задерживался в офисе до 10–11 вечера, пытаясь доделать работу за команду (не повторяйте моих ошибок!).
Время шло, и в какой-то момент менеджер попросил собрать очный митинг в 11 утра, на который он пришёл с фразой:
«Увольняем всю команду» (не из компании, а с проекта).
Но вместо стресса это стало для меня толчком к развитию.
Лидерство и R&D
На этом этапе я уже больше года занимался менторингом: помогал коллегам с проектами, направлял их развитие, проводил регулярные 1:1 сессии. Для меня ключевыми KPI были:
✅ Сколько человек перешли из Junior → Middle и из Middle → Senior
✅ Сколько инженеров получили сертификации
Через неделю после завершения предыдущего проекта, где всю мою команду уволили с проекта, меня пригласили в R&D, чтобы создать полноценный Data Lake с AI, batch, streaming и множеством ETL-пайплайнов – продукт, который можно было продавать как сервис.
Это был крутой и сложный опыт, который включал:
🔹 Регулярные созвоны с AWS-архитекторами
🔹 Постоянный поиск обходных путей из-за ограничений AWS
🔹Первый “взрослый” опыт работы devops-архитектором
Техлидство и масштабные проекты
После R&D наступил новый этап. Меня пригласили строить команду с нуля для крупного клиента – одной из топ-3 фастфуд-сетей США.
Здесь мне предстояло создать полноценную инфраструктуру с нуля, включая:
🏗 Multi-regional Kubernetes-кластеры с высокой отказоустойчивостью
🔀 Service Mesh для управления трафиком и безопасностью микросервисов
⚙️ 100+ микросервисов, работающих в распределённой среде
🏗 30+ окружений
🔧 Самописные Kubernetes-операторы, автоматизирующие рутинные процессы
Но кроме технической части, я также управлял процессами:
✅ Нанимал и ротировал людей, создавая эффективную команду из ~ 30 человек, которая требовала координации и поддержки
✅ Проводил регулярные архитектурные созвоны, предлгая ключевые технические решения
✅ «Продавал» заказчику новые технологии, объясняя их ценность и обосновывая необходимость внедрения
Этот этап стал для меня уникальным опытом, который позволил не только углубиться в архитектуру, но и развить лидерские и стратегические навыки. Несмотря на это, я выбрал не менеджмент или архитектуру, а стал техлидом.
Начало пути
Я начал работать в 2016 году на позиции DevOps Intern. В самом начале у меня был небольшой, уютный внутренний проект, но вскоре мне его стало мало. Я начал погружаться в соседние задачи, помогая команде осваивать Terraform (ещё версии 0.6.X!), Jenkins, Docker и прочий базовый DevOps стек.
Через три месяца меня взяли на первый коммерческий проект – для одного из топ-3 ритейлеров США (при этом я очень плохо разговаривал на английском!). Это было страшно: моя команда состояла на 80% из сеньоров, и я очень боялся не справиться. Но через пару месяцев освоился (спасибо коллегам, с которыми до сих пор общаемся!) и получил промоушен до Junior.
Переход в Middle
Со временем я глубже погружался в энтерпрайз-разработку. Однажды мне предложили pre-sale проект, где я смог применить накопленные знания и полноценно залидить его с позиции Junior. Это привело к промоушену в Middle.
В этой роли я задержался примерно на 1–1,5 года. Перейти в Senior помогло то, что я активно участвовал не только в основном проекте, но и в соседних инициативах, расширяя зону ответственности и визибилити в компании. Меня начали узнавать даже на кухне в офисах разных стран.
Путь к Senior
На границе между Middle и Senior у меня появилась первая команда из двух человек (включая меня). Позже, сменив проект, я начал работать уже с командой из пяти человек. Мы переносили легаси-приложения на новую архитектуру в Kubernetes, разрабатывая её параллельно с миграцией.
Проект был сложным – сопротивление архитекторов, менеджеров и других стейкхолдеров порой тормозило процесс. По неопытности, я иногда задерживался в офисе до 10–11 вечера, пытаясь доделать работу за команду (не повторяйте моих ошибок!).
Время шло, и в какой-то момент менеджер попросил собрать очный митинг в 11 утра, на который он пришёл с фразой:
«Увольняем всю команду» (не из компании, а с проекта).
Но вместо стресса это стало для меня толчком к развитию.
Лидерство и R&D
На этом этапе я уже больше года занимался менторингом: помогал коллегам с проектами, направлял их развитие, проводил регулярные 1:1 сессии. Для меня ключевыми KPI были:
✅ Сколько человек перешли из Junior → Middle и из Middle → Senior
✅ Сколько инженеров получили сертификации
Через неделю после завершения предыдущего проекта, где всю мою команду уволили с проекта, меня пригласили в R&D, чтобы создать полноценный Data Lake с AI, batch, streaming и множеством ETL-пайплайнов – продукт, который можно было продавать как сервис.
Это был крутой и сложный опыт, который включал:
🔹 Регулярные созвоны с AWS-архитекторами
🔹 Постоянный поиск обходных путей из-за ограничений AWS
🔹Первый “взрослый” опыт работы devops-архитектором
Техлидство и масштабные проекты
После R&D наступил новый этап. Меня пригласили строить команду с нуля для крупного клиента – одной из топ-3 фастфуд-сетей США.
Здесь мне предстояло создать полноценную инфраструктуру с нуля, включая:
🏗 Multi-regional Kubernetes-кластеры с высокой отказоустойчивостью
🔀 Service Mesh для управления трафиком и безопасностью микросервисов
⚙️ 100+ микросервисов, работающих в распределённой среде
🏗 30+ окружений
🔧 Самописные Kubernetes-операторы, автоматизирующие рутинные процессы
Но кроме технической части, я также управлял процессами:
✅ Нанимал и ротировал людей, создавая эффективную команду из ~ 30 человек, которая требовала координации и поддержки
✅ Проводил регулярные архитектурные созвоны, предлгая ключевые технические решения
✅ «Продавал» заказчику новые технологии, объясняя их ценность и обосновывая необходимость внедрения
Этот этап стал для меня уникальным опытом, который позволил не только углубиться в архитектуру, но и развить лидерские и стратегические навыки. Несмотря на это, я выбрал не менеджмент или архитектуру, а стал техлидом.
Это был насыщенный путь, полный вызовов, роста и возможностей. Конечно, я рассказал далеко не всё – например, не рассказал про запуск собственных проектов внутри компании, опыт работы в роли engineering manager, попытку бросить университет ради командировок в Штаты и том, как я уволился с предыдущего места работы, чтобы снова стать просто Senior'ом (привет вчерашнему обсуждению в комментариях)...
Если интересно — тегайте @mercdevchat в комментариях, с радостью расскажу ещё пару карьерных историй. А у вас как? Делитесь самыми яркими моментами из своей карьеры — будет интересно почитать!
Если интересно — тегайте @mercdevchat в комментариях, с радостью расскажу ещё пару карьерных историй. А у вас как? Делитесь самыми яркими моментами из своей карьеры — будет интересно почитать!
🔥 Быть активным в компании — это плюс или ловушка?
С одной стороны, активность = заметность. Ты участвуешь в митапах, двигаешь инициативы, знакомишься с топами. Карьера растёт! 🚀
Но не всё так просто:
⚡ Перегореть легко — ты делаешь больше, но зарплата остаётся прежней. В большинстве случаев корпоративные инициативы не оплачиваются.
⚡ Не все любят энтузиастов — можно нарваться на сопротивление «старожилов», которым и так нормально.
⚡ Активность ≠ результат —важны не только идеи, но и их реальная польза.
С одной стороны, активность = заметность. Ты участвуешь в митапах, двигаешь инициативы, знакомишься с топами. Карьера растёт! 🚀
Но не всё так просто:
⚡ Перегореть легко — ты делаешь больше, но зарплата остаётся прежней. В большинстве случаев корпоративные инициативы не оплачиваются.
⚡ Не все любят энтузиастов — можно нарваться на сопротивление «старожилов», которым и так нормально.
⚡ Активность ≠ результат —важны не только идеи, но и их реальная польза.
🎯 Кейc: как я запускал Random Coffee и что из этого вышло
На прошлой работе я внедрил Random Coffee — Slack-бот, который автоматически соединял случайных коллег на короткие встречи. Где-то это оживило коммуникацию, а где-то бот просто висел мёртвым грузом. Почему так?
🔹 Культура. В закрытых средах люди не готовы болтать с незнакомцами, особенно из других локаций или на другом языке. Тут я часто видел “сопротивление” для общения между людьми в разных локациях.
🔹 Формат. Без явной пользы (например, обмена опытом) разговоры быстро превращались в «привет-пока». Для интровертов — вообще стресс. Для продуктивных - путая трата времени.
🔹 Навязанность - если людей заставляют участвовать, а не вовлекают, инициатива тухнет. А если не навязывают, то сложно набрать аудиторию.
🚀 Вывод: активность тоже надо продавать
⚡ Любую инициативу нужно продвигать, как pet-project. Недостаточно просто придумать что-то полезное — важно донести ценность и найти сторонников.
⚡ SSM важен даже внутри компании. Нужно уметь продавать идеи командам, менеджерам, и даже CEO.
Этот проект я вёл несколько лет — и за это время я не успел перегореть. Он мне дал много новых, полезных знакомст, а еще удовлетворения от хорошей затеи.
Так что же лучше: тихо работать или заявлять о себе? Делись своим опытом! 👇
PS: Если вы хотите запустить random coffee в своей компании - feel free to use https://github.com/kvendingoldo/random_coffee_slack
На прошлой работе я внедрил Random Coffee — Slack-бот, который автоматически соединял случайных коллег на короткие встречи. Где-то это оживило коммуникацию, а где-то бот просто висел мёртвым грузом. Почему так?
🔹 Культура. В закрытых средах люди не готовы болтать с незнакомцами, особенно из других локаций или на другом языке. Тут я часто видел “сопротивление” для общения между людьми в разных локациях.
🔹 Формат. Без явной пользы (например, обмена опытом) разговоры быстро превращались в «привет-пока». Для интровертов — вообще стресс. Для продуктивных - путая трата времени.
🔹 Навязанность - если людей заставляют участвовать, а не вовлекают, инициатива тухнет. А если не навязывают, то сложно набрать аудиторию.
🚀 Вывод: активность тоже надо продавать
⚡ Любую инициативу нужно продвигать, как pet-project. Недостаточно просто придумать что-то полезное — важно донести ценность и найти сторонников.
⚡ SSM важен даже внутри компании. Нужно уметь продавать идеи командам, менеджерам, и даже CEO.
Этот проект я вёл несколько лет — и за это время я не успел перегореть. Он мне дал много новых, полезных знакомст, а еще удовлетворения от хорошей затеи.
Так что же лучше: тихо работать или заявлять о себе? Делись своим опытом! 👇
PS: Если вы хотите запустить random coffee в своей компании - feel free to use https://github.com/kvendingoldo/random_coffee_slack
GitHub
GitHub - kvendingoldo/random_coffee_slack
Contribute to kvendingoldo/random_coffee_slack development by creating an account on GitHub.
🚀 Вам нужен пример для подражания — без этого роста не будет
Развитие в любой области — сложная задача, и IT тут не исключение. Когда я только начинал, было слишком много вариантов: какие технологии учить, какие книги читать, куда двигаться? Полный хаос.
На ранних этапах мне очень помогли (и вам советую обратить на это внимание):
🔹 Ментор — если есть человек, который может корректировать ваш путь и помогать не тратить время на лишнее, это бесценно. Но ментор помогает до уровня Middle. Дальше направление придётся искать самому.
Если вы не знаете как найти ментора - пишите в комментарии, я подскажу.
🔹 Регулярные 1:1 сессии
📅 С тимлидом — раз в две недели
📅 С Engineering Manager (если он есть) — раз в месяц
📅 С HRBP — раз в два месяца
Если честно, то 1:1 в свое время я ждал как сеанса психотерапии, до тех пор, пока сам не начал их проводить 🙂
Если у вас никогда небыло 1:1 сессий - просто попросите о них.
🔹 Пример для подражания
Чем выше грейд, тем меньше ритуалов которые помогают расти. В итоге единственной путеводной звездой остаётся пример для подражания.
🔥 Почему важен пример для подражания?
✅ Ролевые модели — это люди, чей путь вдохновляет. Они не дадут вам пошаговую инструкцию, но помогут увидеть возможности и понять, где можно быть через 3–5–7 лет.
✅ Как найти?
🔹 Следите за сильными специалистами в вашей сфере и компании
🔹 Изучайте их решения, принципы и карьерные стратегии
🔹 Знакомьтесь, поддерживайте контакт, спрашивайте совета — в 90% случаев вам не откажут
💡 Вывод: хотите расти — ищите людей, чьи решения вам откликаются. Это сэкономит годы поиска и убережёт от лишних ошибок.
А кто вдохновляет вас? Есть ли у вас пример для подражания? 🔥👇
Развитие в любой области — сложная задача, и IT тут не исключение. Когда я только начинал, было слишком много вариантов: какие технологии учить, какие книги читать, куда двигаться? Полный хаос.
На ранних этапах мне очень помогли (и вам советую обратить на это внимание):
🔹 Ментор — если есть человек, который может корректировать ваш путь и помогать не тратить время на лишнее, это бесценно. Но ментор помогает до уровня Middle. Дальше направление придётся искать самому.
Если вы не знаете как найти ментора - пишите в комментарии, я подскажу.
🔹 Регулярные 1:1 сессии
📅 С тимлидом — раз в две недели
📅 С Engineering Manager (если он есть) — раз в месяц
📅 С HRBP — раз в два месяца
Если честно, то 1:1 в свое время я ждал как сеанса психотерапии, до тех пор, пока сам не начал их проводить 🙂
Если у вас никогда небыло 1:1 сессий - просто попросите о них.
🔹 Пример для подражания
Чем выше грейд, тем меньше ритуалов которые помогают расти. В итоге единственной путеводной звездой остаётся пример для подражания.
🔥 Почему важен пример для подражания?
✅ Ролевые модели — это люди, чей путь вдохновляет. Они не дадут вам пошаговую инструкцию, но помогут увидеть возможности и понять, где можно быть через 3–5–7 лет.
✅ Как найти?
🔹 Следите за сильными специалистами в вашей сфере и компании
🔹 Изучайте их решения, принципы и карьерные стратегии
🔹 Знакомьтесь, поддерживайте контакт, спрашивайте совета — в 90% случаев вам не откажут
💡 Вывод: хотите расти — ищите людей, чьи решения вам откликаются. Это сэкономит годы поиска и убережёт от лишних ошибок.
А кто вдохновляет вас? Есть ли у вас пример для подражания? 🔥👇
Когда я только начинал карьеру, мне казалось, что хард-скиллы – единственное, что делает меня специалистом. Думал, что чем лучше я знаю технологии, тем ценнее я как инженер.
Но со временем я понял: чем выше уровень ответственности, тем важнее не только технические знания, но и умение договариваться, презентовать идеи и передавать знания.
📌 С ростом опыта меняется и фокус работы:
🔹 Меньше кода – больше документации, обсуждений и менторства
🔹 Больше общения с командой, стейкхолдерами и заказчиками
🔹 Опыт становится ценнее, когда ты делишься им и помогаешь расти другим
Без развитых софт-скиллов всё это становится сложной задачей. Поэтому, если вы хотите не просто быть хорошим инженером, а расти в роли, уделяйте внимание не только хард-скиллам, но и умению общаться, договариваться и обучать.
Но со временем я понял: чем выше уровень ответственности, тем важнее не только технические знания, но и умение договариваться, презентовать идеи и передавать знания.
📌 С ростом опыта меняется и фокус работы:
🔹 Меньше кода – больше документации, обсуждений и менторства
🔹 Больше общения с командой, стейкхолдерами и заказчиками
🔹 Опыт становится ценнее, когда ты делишься им и помогаешь расти другим
Без развитых софт-скиллов всё это становится сложной задачей. Поэтому, если вы хотите не просто быть хорошим инженером, а расти в роли, уделяйте внимание не только хард-скиллам, но и умению общаться, договариваться и обучать.
Какие софт-скиллы действительно важны?
📌 Коммуникация – четко выражать мысли (устно, письменно, на родном и английском), слушать, убеждать.
📌 Адаптивность – быстро учиться, подстраиваться под изменения.
📌 Тайм-менеджмент – приоритизировать задачи, справляться с дедлайнами.
📌 Критическое мышление – анализировать, замечать детали, искать причины проблем.
📌 Проактивность – брать ответственность, предлагать решения, двигать процессы.
📌 Командная работа – сотрудничать, давать и принимать конструктивную обратную связь.
📌 Клиентоориентированность – понимать потребности бизнеса и пользователей.
📌 Понимание процессов – не бояться слов KPI, SWOT, IDEF и других инструментов управления.
Конечно, никто не требует прокачивать их все сразу. Но лично я советую: раз в полгода выбирайте один и работайте над ним — тренинг, курс по речи, практика в проектах и тд.
💬 А какие софт-скиллы помогли вам в карьере? Насколько они повлияли на вашу карьеру? 👇
P.S. Не самый очевидный совет, но иногда прокачать софт-скиллы помогает не очередной курс на Coursera, а совсем неожиданные активности: обучение актерскому мастерству, практика в дискуссионном клубе или волонтерство.
📌 Коммуникация – четко выражать мысли (устно, письменно, на родном и английском), слушать, убеждать.
📌 Адаптивность – быстро учиться, подстраиваться под изменения.
📌 Тайм-менеджмент – приоритизировать задачи, справляться с дедлайнами.
📌 Критическое мышление – анализировать, замечать детали, искать причины проблем.
📌 Проактивность – брать ответственность, предлагать решения, двигать процессы.
📌 Командная работа – сотрудничать, давать и принимать конструктивную обратную связь.
📌 Клиентоориентированность – понимать потребности бизнеса и пользователей.
📌 Понимание процессов – не бояться слов KPI, SWOT, IDEF и других инструментов управления.
Конечно, никто не требует прокачивать их все сразу. Но лично я советую: раз в полгода выбирайте один и работайте над ним — тренинг, курс по речи, практика в проектах и тд.
💬 А какие софт-скиллы помогли вам в карьере? Насколько они повлияли на вашу карьеру? 👇
P.S. Не самый очевидный совет, но иногда прокачать софт-скиллы помогает не очередной курс на Coursera, а совсем неожиданные активности: обучение актерскому мастерству, практика в дискуссионном клубе или волонтерство.
А давайте похоливарим.
А что, если я скажу, что айтишник не должен использовать в работе никакой язык, кроме английского? Да, я серьёзно! 💥 И сейчас объясню, почему качать writing, reading, speaking и прочие языковые скиллы — это не просто «хорошо бы», а must-have. Let’s get started!
🔹 IT == English by default.
IT was born and raised in the U.S., and it’s still calling the shots. Startups, projects, and groundbreaking tech—everything is discussed in English first.
📌 Want to stay on top of global trends?
Get used to digesting information in English quickly. Here’s the deal: when was the last time you saw a full translation of an AWS re:Invent or Google I/O keynote? Exactly—sometimes, they don’t even exist at all. By the time you’re waiting for a translation, the rest of the world has already moved on.
А что, если я скажу, что айтишник не должен использовать в работе никакой язык, кроме английского? Да, я серьёзно! 💥 И сейчас объясню, почему качать writing, reading, speaking и прочие языковые скиллы — это не просто «хорошо бы», а must-have. Let’s get started!
🔹 IT == English by default.
IT was born and raised in the U.S., and it’s still calling the shots. Startups, projects, and groundbreaking tech—everything is discussed in English first.
📌 Want to stay on top of global trends?
Get used to digesting information in English quickly. Here’s the deal: when was the last time you saw a full translation of an AWS re:Invent or Google I/O keynote? Exactly—sometimes, they don’t even exist at all. By the time you’re waiting for a translation, the rest of the world has already moved on.
🔹 Terminology is sacred—no ifs, ands, or buts.
It still makes me cringe when:
❌ A meeting is called a "собрание"
❌ Environment turns into a "контур"
❌ Deployment becomes "развёртывание"
📌 Why is this a big deal?
IT terms should be set in stone—universal and crystal clear.
If your team isn’t on the same page, you’re asking for confusion, delays, and a whole lot of back-and-forth.
And if you’re used to localizing everything, good luck integrating into an international team—you’ll stick out like a sore thumb.
📌 What’s the game plan?
🔸Stick to English terms at work—yes, even in Slack chats.
🔸Read English documentation straight from the source without translation (even if it feels like pulling teeth at first).
🔸Write code and comments in English—future you (and that poor dev from Sydney refactoring your code) will thank you.
It still makes me cringe when:
❌ A meeting is called a "собрание"
❌ Environment turns into a "контур"
❌ Deployment becomes "развёртывание"
📌 Why is this a big deal?
IT terms should be set in stone—universal and crystal clear.
If your team isn’t on the same page, you’re asking for confusion, delays, and a whole lot of back-and-forth.
And if you’re used to localizing everything, good luck integrating into an international team—you’ll stick out like a sore thumb.
📌 What’s the game plan?
🔸Stick to English terms at work—yes, even in Slack chats.
🔸Read English documentation straight from the source without translation (even if it feels like pulling teeth at first).
🔸Write code and comments in English—future you (and that poor dev from Sydney refactoring your code) will thank you.