🔹 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 – это человек, который помогает разработчикам писать не просто код, а качественный и масштабируемый код.

🔹 Architect
Фокус: Стратегическое проектирование

📌 Задачи:
✅ Проектирование масштабируемых систем
✅ Выбор технологий и архитектурных подходов
✅ Разработка стандартов и гайдов
✅ Взаимодействие с несколькими командами
✅ Оптимизация производительности и интеграций

🔹 Architect vs Tech Lead
* Tech Lead – решает локальные технические вопросы в рамках одной команды
* Architect – отвечает за глобальные архитектурные решения на уровне всей компании или нескольких проектов

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

🔹 Manager
Фокус: Бизнес и стратегия

📌 Задачи:
✅ Управление командами или отделами
✅ Рост и развитие сотрудников
✅ Найм и адаптация
✅ Взаимодействие с бизнесом и стратегическое планирование
✅ Оптимизация работы всей разработки

🔹 Manager vs Team Lead
* Team Lead – управляет процессами внутри одной команды
* Manager – управляет несколькими командами или целыми отделами.

👉 Это путь для тех, кто хочет полностью перейти в управление и влиять на развитие бизнеса.

🔹 Mentor
Ментор – это не официальная должность, а дополнительная роль, которую можно совмещать с любой позицией.

📌 Чем занимается Mentor?
✅ Помогает младшим разработчикам расти,
✅ Делится знаниями и опытом,
✅ Участвует в адаптации новых сотрудников,
✅ Может вести лекции или внутренние курсы.

🔹 Кто может быть ментором?
Любой опытный разработчик, который хочет передавать знания и помогать другим расти.

👉 Это важная роль, которая помогает всей компании развиваться быстрее.

📌 Итог
Каждый выбирает свой путь в зависимости от интересов:

✔ Любишь управлять людьми? -> 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 человек, которая требовала координации и поддержки
✅ Проводил регулярные архитектурные созвоны, предлгая ключевые технические решения
✅ «Продавал» заказчику новые технологии, объясняя их ценность и обосновывая необходимость внедрения

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

Это был насыщенный путь, полный вызовов, роста и возможностей. Конечно, я рассказал далеко не всё – например, не рассказал про запуск собственных проектов внутри компании, опыт работы в роли engineering manager, попытку бросить университет ради командировок в Штаты и том, как я уволился с предыдущего места работы, чтобы снова стать просто Senior'ом (привет вчерашнему обсуждению в комментариях)...

Если интересно — тегайте @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

🚀 Вам нужен пример для подражания — без этого роста не будет

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

На ранних этапах мне очень помогли (и вам советую обратить на это внимание):

🔹 Ментор — если есть человек, который может корректировать ваш путь и помогать не тратить время на лишнее, это бесценно. Но ментор помогает до уровня Middle. Дальше направление придётся искать самому.
Если вы не знаете как найти ментора - пишите в комментарии, я подскажу.

🔹 Регулярные 1:1 сессии
📅 С тимлидом — раз в две недели
📅 С Engineering Manager (если он есть) — раз в месяц
📅 С HRBP — раз в два месяца

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


🔹 Пример для подражания
Чем выше грейд, тем меньше ритуалов которые помогают расти. В итоге единственной путеводной звездой остаётся пример для подражания.


🔥 Почему важен пример для подражания?

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

✅ Как найти?
🔹 Следите за сильными специалистами в вашей сфере и компании
🔹 Изучайте их решения, принципы и карьерные стратегии
🔹 Знакомьтесь, поддерживайте контакт, спрашивайте совета — в 90% случаев вам не откажут

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

А кто вдохновляет вас? Есть ли у вас пример для подражания? 🔥👇

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

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


📌 С ростом опыта меняется и фокус работы:
🔹 Меньше кода – больше документации, обсуждений и менторства
🔹 Больше общения с командой, стейкхолдерами и заказчиками
🔹 Опыт становится ценнее, когда ты делишься им и помогаешь расти другим

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

Какие софт-скиллы действительно важны?

📌 Коммуникация – четко выражать мысли (устно, письменно, на родном и английском), слушать, убеждать.

📌 Адаптивность – быстро учиться, подстраиваться под изменения.

📌 Тайм-менеджмент – приоритизировать задачи, справляться с дедлайнами.

📌 Критическое мышление – анализировать, замечать детали, искать причины проблем.

📌 Проактивность – брать ответственность, предлагать решения, двигать процессы.

📌 Командная работа – сотрудничать, давать и принимать конструктивную обратную связь.

📌 Клиентоориентированность – понимать потребности бизнеса и пользователей.

📌 Понимание процессов – не бояться слов 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.

🔹 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.

🔹 English is your golden ticket to top-tier jobs

Dreaming of working at FAANG or another global tech giant? Want to make a name for yourself in open-source projects? Hoping to rub elbows with devs from all over the world?

If your answer is yes, then there’s no two ways about it—English is non-negotiable.

📌 Cold, hard facts:

🔸Top companies interview in English. Even if everyone in the office speaks another language, hiring is a whole different ball game.

🔸Most open-source projects run in English. Want to contribute to Linux, Kubernetes, or TensorFlow? Your issues and PRs need to be clear as day—from California to Tokyo.

🔸The better your English, the bigger your paycheck. Employers jump at the chance to hire people who can actually talk the talk.



📌 How do you sharpen your skills?

🔸Watch tech talks, keynotes, and podcasts in English—no subtitles, no excuses.

🔸Speak English in meetings, even if you’re all from the same country.

🔸Try an English Friday—for one day a week, speak only English, even while grabbing coffee.

🔸Write docs and tickets in English from the get-go. It’s like hitting the gym—it hurts at first, but you’ll be flexing those language muscles in no time.

📌 Key Takeaways:

🔹 Use English by default at work—no more “I’ll translate it later” nonsense.

🔹 Stick to formalized terms—don’t turn them into awkward translations.

🔹 Boost your language skills—it’s the secret sauce for career success.

🔹 English opens doors to the best jobs, projects, and opportunities.


Do you agree, or do you think IT can get by without English? Let’s hash it out in the comments! 🚀

Наконец-то можно сказать Happy Friday! 🎉

Как и обещал, собрал для вас подборку Telegram-каналов на тему IT, которые сам читаю помимо Medium, DZone, HackerNoon и HackerNews.
Список без чатов, только каналы — чтобы лента оставалась чистой и по делу 👇

🚀 DevOps & SRE:
@devops_sre_notes
@devopslibrary
@flant_ru
@gitgate
@k8security
@Learnk8sNews
@count0_digest
@sec_devops
@k8sjust
@orangedevops
@awsweekly
@devops_mops
@buhtig
@devops_deflope
@ittales

💡 Golang:
@Golang_google
@goproglib
@HowToGoWrong

🏎️ Performance:
@troubleperf

🏗️ Архитектура и подготовка к собеседованиям:
@fakng_eng
@coding_interviews

🎭 IT-мемы (потому что без них никак!):
@profunctor_io
@TRMemas

🦄 Стартапы:
@kyrillic
@ask_vc
@Theedinorogblog
@temno
@yclibrary

🧩Петпроекты:
@your_pet_project

🧭 Метапоиск каналов:
@meta_it

📝И мой личный канал про DevOps — иногда тоже что-то кидаю:
@devops_universe

Если есть, чем дополнить — кидайте в комментарии! Интересно, что ещё у вас в подборках? 😉

Пятница — время для странностей. Закидывайте в этот тред самые абсурдные или смешные IT-термины, с которыми сталкивались в работе 😄