У міру того, як команда зростає, з`являються нові продукти, а інженерна команда проходить етапи трансформації - роль CTO легко перетворюється з технічного лідера на менеджера, що дивиться у таблиці та аналітику. І саме в цей момент настає найскладніше: не втратити технічний контекст, не відстати від архітектури, і реального стану справ у командах. У цій доповіді я поділюся власним досвідом: як залишатися Hands-on CTO - зберігати глибоке розуміння технічної бази, впливати на архітектуру й одночасно масштабувати компанію, не перетворюючись на "менеджера без коду". Основні теми, які ми розглянемо: - Як змінюється роль CTO у міру росту компанії - від кодера до системного лідера. - Найпоширеніші пастки: втрата архітектурної пам’яті, розрив між бізнесом і технічкою, залежність від кількох ключових людей. - Хороші звички, що допомагають утримувати технічний контекст: code-review, архітектурні стендапи, "walk the code", R&D-спринти CTO. - Системи прийняття рішень: як використовувати ADR / RFC, щоб зберігати прозорість і контроль. - Комунікація з техлідерами: ефективні формати 1:1, технічні сінки. - Інструменти та платформи, які допомагають не втратити контекст - дашборди, системи моніторингу, архітектурні огляди.

Ми звикли довіряти відчуттям: здається, що процеси працюють, а продукт якісний. Але відчуття не масштабуються. У цій доповіді я покажу, як ми перейшли від інтуїтивних рішень до системи метрик, яка вимірює якість продуктів і процесів у реальному часі. Як команди, маючи «приборну панель», самі керують розвитком своїх продуктів із точки зору якості. І головне — як технічні метрики стають зрозумілими бізнесу, допомагають говорити про ризики однією мовою й приймати рішення на масштабі.

Ця доповідь присвячена шляху розвитку після досягнення рівня сеньйор-інженера. Спираючись на власний досвід — від Junior Engineer до керівника Node.js Department — я розповім про особисті виклики, уроки та ключові моменти, які сформували мою кар’єру. Сесія стане практичним посібником для інженерів, які вже досягли рівня сеньйора і замислюються: «Що далі?». Ми розглянемо можливості як вертикального, так і горизонтального розвитку — від технічної майстерності до лідерства, від становлення експертом до формування команд і цілих департаментів.

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.

There are many obstacles and pitfalls on the path towards operational zen. Many routes could lead to dead ends, and many detours could end up being loops. In this semi-comedy talk, I share some examples of how processes fail for engineering teams that I observed through my career, using two pillars of the Internet culture - memes and numbered lists.

На шляху до інженерної нірвани існує безліч перешкод. Є багато місць, де можна зробити помилку і стежок, що ведуть в нікуди. В цій напівжартівливій доповіді я поділюся прикладами того, як процеси підводять інженерні команди. Всі приклади взяті із життя і подані за допомогою двох стовпів інтернет-культури - мемів і нумерованих списків.