🇰🇿 Алматы, встречай!

Мы запускаем первый офлайн-митап From Code to Talk — вечер, где инженеры, архитекторы и тимлиды выходят за рамки кода, делятся peer-to-peer опытом и просто отлично проводят время!

Обещаем вдохновляющие доклады, много пиццы 🍕, живое общение и по-настоящему тёплую атмосферу комьюнити 🫂

🗓 31 октября, 18:30

🎙Программа:
▸ LLM In & Out: Twenty Minutes Adventure. As if… – Иван Луценко, Android Tech Lead в Bereke Bank
▸ Путь от браузера до приложения – Юрий Морозов, CTO в Paylink

Мероприятие организовано в партнерстве с:

🤝 Bereke Bank – казахстанский банк, активно развивающий цифровые продукты и API для интеграций, использующий современные IT-решения и технологии для улучшения сервисов и автоматизации процессов.

🤝 PayLink – финтех-компания из Казахстана, которая предоставляет бизнесу удобные решения для приема онлайн-платежей: подключение эквайринга, рекуррентных и каскадных платежей, поддержка Apple/Google Pay и другие инструменты, нацеленные на увеличение доходов.

🔗 Регистрация

💡 OaaA: Office as an Architecture.
Как организовать микросервисы в эпоху AI-агентов?

Каждая архитектура рождалась из необходимости − от Layered до Event-driven и микросервисов. Но где место AI-агентам? Отдельный сервис или часть существующего? 🤔

Архитектор и Microsoft AI MVP Alex Pshul представит концепцию Office as an Architecture (OaaA) − подход, в котором система работает как офис: сервисы − отделы, а агенты − новые сотрудники. Вместе они сотрудничают, учатся и создают результат.

🗓 Уже завтра на нашем митапе!
23 октября, начало в 20.00 по GMT+3

Зарегистрироваться и задать вопрос спикеру можно по ссылке🔗

Архитектурные катастрофы – часть 4: AWS US-East-1

На этой неделе AWS неожиданно сломали интернет: встали Netflix, Slack, Epic Games, Venmo, Zoom, Reddit и десятки других сервисов.

🔥 Что произошло?

Ночью 19–20 октября в регионе AWS US-East-1 резко выросли ошибки в DynamoDB. Следом посыпались IAM, Lambda, EC2, ECS, RDS и еще 140 сервисов.

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

🧠 В чем причина?

Триггер – проблема DNS resolution для эндпоинтов DynamoDB. Из-за скрытого race condition два экземпляра DNS Enactor переписали планы, и региональная DNS-запись DynamoDB неожиданно очистилась (все IP стерлись).

Дальше эффект домино: EC2 не может запускать инстансы → мониторинг Network Load Balancer теряет связь → сетевая связность разваливается → все зависимые сервисы встают.

Интересно, есть ли какая-то связь со словами CEO AWS “AI is now pushing 75% of our production code” или это старый-добрый рукотворный факап? 🤔

🛠 Как AWS справились?

Инженеры AWS перешли в режим аврала. К утру они оперативно обнаружили DNS-сбой и восстановили записи DynamoDB. Затем началась вторая волна: поступивший поток запросов создал перегрузку.

Ключевое решение: временный throttling критичных операций. AWS ограничил rate новых запусков, давая системам время на восстановление без повторного коллапса.

Постепенно трафик выровнялся и ограничения сняли спустя примерно 15 часов после начала инцидента. В 15:01 PDT все сервисы официально вернулись в штатный режим.

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

Час простоя US-EAST-1 – $66-100 млн. При 15 часах ущерб составил $1-1.5 млрд для индустрии.

Для Amazon – SLA компенсации и репутационный удар: акции просели на 2.3% ($40 млрд капитализации).

Для пользователей – больше 140 сервисов AWS оказались недоступны или работали некорректно, из-за чего посыпались системы клиентов AWS: самого Amazon, Netflix, OpenAI, Cursor, Slack, Venmo, Perplexity AI, Coinbase, Canva, Duolingo, The NY Times, Apple TV, Twitch и еще десятков компаний с миллионами пользователей.

🔍 Что можно было сделать иначе?

🔹 Chaos Engineering: регулярно и целенаправленно моделировать отказы и сбои в разных местах чтобы протестировать систему на надежность и отработать процесс восстановления.

🔹 Резервные пути и дублирование: снизить зависимость от US-East-1, внедрять мульти-региональные кластеры (например, Global Tables для DynamoDB) или дополнительные DNS-планы, чтобы при сбое был план Б.

🔹 Тестирование автоматизации: регулярно эмулировать аварии DNS (гонки транзакций, сброс старых планов) и тщательно ревьюить критические скрипты обновления. Пусть “AI генерирует 75% кода”, за оставшиеся 25% ручного контроля всё равно отвечают люди.

Что думаете – какие ещё меры могли предотвратить катастрофу? Пишите в комментариях!

🚀 Друзья, уже завтра ждём вас на доклад!

📅 28 октября, 20:00 (GMT+3)

От API-запросов к промптам: как Model Context Protocol (MCP) меняет взаимодействие с внешними сервисами и открывает новый уровень интеграции между людьми, AI и системами.

🎙️ Спикер: Максим Сальников, AI Dev Tools & Platforms Solution Engineer в Microsoft, лидер техсообществ и международный спикер из Осло.

👉 Регистрация

🎙31 октября в 18:30 − офлайн-митап из серии From Code to Talk в Алматы!

🔥 Спикеры митапа:
▸ Иван Луценко, Android Tech Lead в Bereke Bank − LLM In & Out: Twenty Minutes Adventure. As if…
▸ Юрий Морозов, CTO в Paylink − Путь от браузера до приложения, или что происходит, когда вы в браузере вбиваете google.com
▸ Тимур Дуюсов, Technical Product Owner в Bereke Bank − Выгореть, чтобы вырасти: честная история разработчика, ставшего лидом

🍕 Вдохновляющие доклады, пицца, живое общение и уютная атмосфера комьюнити − всё, как мы любим!

🤝 При поддержке Bereke Bank и Paylink
🔗 Регистрация

Как выбрать базу данных для проекта и не пожалеть 🤔

🗓 30 октября, 20:00 GMT+3

От реляционных баз до NoSQL, NewSQL, lakehouse и векторных − за полвека индустрия баз данных прошла длинный путь, полный неожиданных открытий и болезненных ошибок. Мы разберём, как выбор хранилища может привести систему к успеху или краху, какие идеи действительно изменили подход к данным, и как не наступить на старые грабли при проектировании новых решений.

📚 В докладе:
‣ краткая история эволюции систем управления данными;
‣ архитектурные идеи, изменившие индустрию (ACID, LSM-деревья, мультимодельные подходы и др.);
‣ реальные кейсы и уроки, которые помогут не повторять ошибки прошлого;
‣ мини-гайд по осознанному выбору базы данных.

👨‍💻 Спикер: Максим Аршинов, Solution Architect в EPAM Spain

👉 Зарегистрироваться

Гигиенический чеклист техлида при делегировании задач

Корректное делегирование задач — ключ к эффективности команды, но даже опытные техлиды часто упускают важные детали.

⚠️ Ошибка: Делегировать задачу, не передавая полномочия принимать решения

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

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

🔸 Чёткий результат: опишите конечный исход и критерии успеха, а не просто набор шагов.
🔸 Полномочия: обозначьте, какие решения человек может принимать самостоятельно и где нужно с вами согласовать изменения.
🔸 Рамки ответственности: уточните ограничения, в которых исполнитель действует, и как поступать при возникновении сложностей или вопросов.

❗️ Ошибка: Недостаточно контекста и приоритета у исполнителя

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

Что включить в делегирование:

🔹 Бизнес-контекст: "клиент X грозит уйти, если не решим до конца квартала"
🔹 Технический контекст: ссылка на ADR, связанные PR, метрики до/после
🔹 Explicit приоритет: P0 (бросаем всё), P1 (в текущий спринт), P2 (backlog). Без P0/P1/P2 задача не делегирована
🔹 Зависимости: "блокирует миграцию БД, нужна до 15 ноября"

⏰ Ошибка: Делегировать не тому человеку или в неподходящий момент

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

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

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

Про что нужно помнить:

🔸 Capacity check: у человека есть 60–70% времени на новую задачу? Если нет — это не делегирование, а перегрузка
🔸 Growth zone: задача чуть сложнее текущего уровня (70% умеет, 30% новое). Если 100% знакомо — скучно, если 50% новое — стресс
🔸 Bus factor: не давайте критические задачи одним и тем же людям. Распределяйте экспертизу

🔄 Ошибка: Превращать контроль в микроменеджмент или не контролировать вовсе

Частые проверки мелких деталей подавляют инициативу, а полное отсутствие контроля может привести к неприятным сюрпризам на завершающих этапах.

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

🔹 Checkpoint 30%: "покажи дизайн/RFC, обсудим риски" — на этом этапе дешево менять направление
🔹 Checkpoint 70%: "code review драфта, проверим интеграцию" — исправляем архитектурные косяки
🔹 Checkpoint 100%: "demo + метрики, готовность к production"

🔹 Критерии успеха: согласуйте заранее, что конкретно должно быть сделано (например, в виде Acceptance Criteria или тестового списка), чтобы в конце не было разногласий.
🔹 Автономия с отчётностью: позвольте исполнителю самому выбирать подход, но попросите периодически информировать вас о ходе и возникающих проблемах.

🧱 Ошибка: Не убирать системные блокеры и не закреплять результат в процессах

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

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

🎙Друзья, редкий в наше время Архитектурный Трёп − уже завтра!

🗓 4 ноября, 20:00 (GMT+3)

Тема − огонь🔥: если вы когда-либо совмещали несколько проектов, думали о втором источнике дохода или проходили через удачный (или не очень) опыт работы на двух фронтах − приходите обсудить и поделиться опытом.

Модерирует Настя Бакулова, ей тоже есть что рассказать. Ждём честного, живого разговора.

💬 Приходите участвовать вживую! Напоминаем, что Трёпы не записываются. Пожалуйста, не подключайте свои AI-тулы для записи бесед − мы будем их удалять со встречи из соображений безопасности.

Подробности и регистрация по ссылке🔗

⚡️ High-load будущего: serverless, edge computing и AI-driven оптимизации

Как меняются архитектуры под нагрузкой и зачем крупные компании уходят в edge и serverless? Разберём, где заканчивается бесконечный скейл и как ИИ помогает в автоскейлинге, capacity planning и anomaly detection.

🎙 Спикер: Андрей Якушин, Solution Architect и Engineering Manager с 18+ годами опыта в IT.

📅 Сегодня в 20.00 GMT+3

👉 Регистрация

12 зон ответственности CTO – и главная ошибка, из-за которой ломаются компании

💥 70 % digital-трансформаций проваливаются – и не из-за технологий.

Когда CTO зацикливается на технологиях – компания теряет скорость.
Когда CTO фокусируется только на людях – теряет качество.
Когда CTO забывает про бизнес – теряет смысл.

🔭 Мы собрали карту из 12 зон ответственности CTO – от архитектуры и инноваций до найма, безопасности и бюджета.

Но на практике почти каждый CTO проваливает одну и ту же вещь: Коммуникации и доверие.

CTO может идеально считать ROI, управлять облачными расходами и внедрять GenAI –но если команда не доверяет друг другу, все эти метрики ничего не стоят.

🗣 Бизнес рушится не из-за багов или неэффективных пайплайнов, а из-за сломанных коммуникаций.

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

Согласно опросу Gartner Peer Community 2023 года, 63% опрошенных назвали навыки межличностного общения и 55% – навыки ведения переговоров – самыми важными качествами CTO для успеха в бизнес-роли, тогда как чисто технические навыки подразумеваются как базовые.

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

А в какой из 12 зон вы чаще всего «проваливаетесь» – технологии, люди или бизнес?

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

Месяц назад мы рассказывали, что совместно с Алексеем Обыскаловым, CTO и автором канала «CTO: порядок из хаоса» проводим исследование, чтобы выявить инженерные практики, которые сильнее всего влияют на зрелость инженерных процессов.

🔭 В исследовании приняли участие 106 инженеров. После обработки данных и проверки 1900 статистических гипотез, мы выявили 10 практик, внедрение которых кратно повышает качество процессов, интересные взаимосвязи между размером команды и инженерной зрелостью, а главное, что настоящая инженерная зрелость – это когда система устойчиво растёт без героизма.

👉 Полные выводы исследования читайте в статье на нашем сайте

👉 Также мы подготовили тест, в котором вы сможете оценить инженерную зрелость в своей команде

А пока, вот некоторые результаты:

🔥 Хаос не масштабируется. Команды с 30+ разработчиками не опускаются ниже индекса зрелости 4 из 10. Вероятно, при таком размере со слабыми процессами просто не выживают.

🔢 80% зрелости дают всего 4 блока практик. Самый влиятельный блок – тестирование. Тесты с управляемыми данными, которым доверяет команда, дают почти половину прироста зрелости. Подробнее в статье.

🕸 Чем больше команды, тем сильнее они похожи друг на друга. Если небольшие компании еще могут себе позволить не обновлять документацию, релизить по готовности, а не в рамках четкого цикла, то с ростом числа разработчиков приходится отлаживать процессы и вводить best practices.

✨Всего одна практика позволяет существенно улучшить ревью и инцидент-менеджмент, и, тем самым, существенно прибавить зрелости команде. Это внедрение PR/MR “паспортов” (цель, тест-ноты, откат).

🔌 Networking as a System: как построить сеть, которая приносит офферы

18 ноября в 20:00 (GMT+3) говорим о том, как осознанно прокачать свой нетворкинг.

В программе:
• Как пробить “стену” AI-рекрутеров и сотен резюме на вакансию
• Социальный капитал и «слабые связи»: почему они работают лучше всего
• Архетипы нетворкеров – какой ваш?
• Как превратить хаотичные связи в систему, которая работает даже без вас

Спикер:
Никита Щетько – человек, который объединяет IT-шников. Ментор HardSoftSkills, организатор IT SOUL CAMP ⛺️, Frontend Lead в 3dway.io и кофаундер healthtech-стартапа.

Регистрация🔗

"Двойная жизнь" разработчика: выводы Архитектурного Трепа #128

💻 Планирование и физическое разграничение

Ключ к выживанию – жёсткие границы. Эффективно работает разделение по времени: один проект утром, второй – вечером.

Идеально, если клиенты находятся в разных часовых поясах. Физическое разделение – обязательно для фокуса.

У меня два ноутбука. То есть один клиент на одном ноутбуке, второй клиент на втором. И вот этот момент очень круто сработал, потому что фокус внимания смещается

Для переключения контекста помогают «точки остановок» – фиксация в конце дня (или недели), что сделано, а что нет. Многим удобнее всего вести их в бумажном блокноте.

Я вернулась к старому доброму способу. Я каждое утро пишу точку остановок. В конце дня я зачеркиваю, что сделано. У меня ушла тревога, что я что-то забуду

⚖️ Юридические рамки и конфликт интересов

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

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

Важные юридические моменты:

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

🚀 Эффективность vs Выгорание

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

То, что ты раньше делал 8 часов, тебе желательно впихнуть в 6, а еще лучше в 4. Мозг работает максимально

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

Нет времени на вот эту рефлексию. Ты как бы эффективен, но ты эффективен в моменте. Ты не можешь думать наперед

Восстановление становится критически важным: ритуалы (режим дня), спорт или массаж, и делегирование бытовых задач (клининг, готовка). Многие также делегируют рефлексию психологу.

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

🗣 Коммуникация и ожидания

Говорить ли о второй работе? Консенсус: не афишировать с флагом, но и не врать, если спросят. Важно выстроить прозрачные отношения через регулярные 1:1, чтобы убедиться, что качество вашей работы не страдает.

У нас есть one-to-one митинги, когда я спрашиваю у своего менеджера, типа, все окей, всем все нравится?

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

🏁 Стратегия совмещения и горизонт

Мотивы со временем меняются: часто начинают из-за денег, но потом остаются ради интереса, изучения нового стека или развития soft skills.

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

Ключевое – иметь стратегию выхода или пересмотра:

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

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

На следующей неделе встретимся, чтобы обсудить найм инженеров: как определить толкового специалиста, как проводить собеседования и как оценивать soft skills и что вообще происходит на рынке.

🔗 Регистрируйтесь по ссылке

Друзья, рады сообщить, что впереди нас ждут два Трёпа, и ближайший уже завтра! 🚀

🎙 Архитектурный Трёп №129
📅 20 ноября, 20:00 (GMT+3)

Тема: Как искать толковых инженеров и проводить собеседования, когда рынок перегрет

Обсудим самое важное и живое:

1️⃣ Кто такой “толковый инженер” сегодня?
2️⃣ Как проектировать интервью: задачи, архитектурные кейсы, обсуждение фейлов — что реально раскрывает кандидата?
3️⃣ Soft skills: что и как оцениваем?
4️⃣ Эра LLM и новая инженерная роль — что теперь важнее?
…и многое другое!

👤 Модератор: Юрий Морозов

🔗 Регистрация

Слабые места всех команд разработки – выводы исследования инженерной зрелости

Мы проанализировали ответы 106 инженеров и CTO, чтобы понять, из чего на самом деле состоит инженерная зрелость. Полный разбор исследования с графиками, картой аномалий и рекомендациями для команд разного размера читайте в статье на нашем сайте.

Пройдите наш тест, чтобы узнать, на каком уровне зрелости находится ваша команда.

А теперь к выводам.

CI/CD научились настраивать почти все – в 2025 году это уже базовая гигиена. А вот процессы, требующие коммуникации и дисциплины, остаются слабым местом даже у крупных команд.

📄 Документация: Хронический техдолг

Блок Documentation & Processes остается на низком уровне у всех групп респондентов (рост всего с 3.65 до 5.24 по десятибалльной шкале). Эта область не лечится простым увеличением штата или бюджета.

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

В исследовании мы увидели, что документация работает как скрытый мультипликатор. Она не двигает метрики сами по себе, но усиливает эффект всех остальных практик.

Что реально работает:

🔹 Живой Engineering Handbook: не мертвая вики, а обновляемый гайд, который является «источником правды» для команды

🔹 Культура ADR (Architecture Decision Records): фиксация контекста важных решений, чтобы через год не гадать, почему выбрали именно эту базу данных

🔹 Онбординг-гайды: практика с высоким ROI, которая напрямую влияет на скорость включения новичков и снижает нагрузку на лидов

Что еще можно сделать, чтобы улучшить документацию, читайте в нашем посте.

🚀 Release Management: От "как готово" к DRI

С ростом размера команды метрика Release Management растет незначительно (3.54 → 5.12). Если в малых командах (до 10 человек) релизят по готовности и без четкого цикла, то на масштабе 50+ человек такой подход превращается в хаос.

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

Признаки зрелого релизного цикла:

🔸 DRI (Directly Responsible Individual): назначение конкретного ответственного за релиз, чтобы избежать коллективной безответственности

🔸 Feature flags: возможность выкатывать код, не ломая прод, и отвязывать деплой от релиза бизнес-фичи

🔸 Rollback-тренировки: понимание, как быстро откатиться, если что-то пошло не так, вместо панического фикса на живую

👀 Code Review: Культура важнее инструментов

Качество ревью растет очень умеренно (5.17 → 5.79) даже при кратном росте команд.

Наличие code owners и линтеров помогает, но не решает фундаментальную проблему. Если в культуре принято аппрувить не глядя или, наоборот, устраивать холивары из-за отступов, никакие инструменты не спасут.

Эффективные практики здесь – чисто организационные:

🔹 Включенный PR/MR size-guard: жесткое ограничение размера пулл-реквеста. Чем меньше изменений, тем качественнее ревью

🔹 PR-паспорт: обязательное описание цели, тест-ноты и план отката прямо в описании задачи. Это дает максимальный эффект при минимальных усилиях (+3.96 к удовлетворенности инцидент-менеджментом)

💎 Куда инвестировать усилия: Матрица ROI

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

🔸 Управляемые тест-данные (фикстуры/снепшоты): база для доверия к тестам. Без этого вы будете бояться собственных релизов

🔸 Централизованные секреты (Vault): влияет сразу на 5 метрик зрелости, включая безопасность и CI/CD

🔸 Burn-rate алерты по SLO: переход от “упал сервер” к “мы тратим бюджет ошибок слишком быстро”

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

Мы готовим закрытый митап про архитектуру системы под названием "техлид".

27 ноября Павел проведет закрытое мероприятие для техлидов.

Если вы раньше интересовались нашим курсом «Технический лидер» или были на консультации с Павлом, проверте почту или чатбот @HardSoftSkills_Assistant_bot – там может быть ваше приглашение.

Что будет на митапе:

- из каких компонентов состоит техлид;
- как взаимодействуют между собой компоненты техлида;
- SLA техлида;
- типичные кейсы неправильного использования техлида на уровне компонентов и их взаимодействия;
- как апгрейдить компоненты техлида;
- чек-лист «10 признаков стабильного техлида».

Запись только для участников.