У подкасті Confluent Developer Field CTO компанії Confluent Вілл ЛаФорест розповідає про свою роботу на перетині складних систем потокової обробки даних і реальних організаційних процесів у клієнтів. Попри глибокий технічний бекграунд — від асемблера на RISC?процесорах до сучасних платформ на кшталт Kafka — він переконаний: найважчі виклики в кар’єрі ніколи не були технічними. Справжні труднощі — це люди, комунікація й те, як змусити організацію взагалі захотіти скористатися потужністю нових технологій.
Ця напруга між «просунутою технікою» та «тим, щоб людям було не байдуже» сьогодні визначає успіх чи провал багатьох ініціатив у сфері data?streaming. І досвід ЛаФореста добре показує, чому.
Коли інженерія — не головний ворог
ЛаФорест формулює це без обмовок: технічні задачі ніколи не були для нього найважчими. Складні алгоритми, оптимізація продуктивності, архітектура розподілених систем — усе це, за його відчуттями, розв’язувалося простіше, ніж питання, пов’язані з людьми.
Це не означає, що інженерні проблеми тривіальні. Але в його кар’єрі вони виявлялися обмеженими, чітко окресленими й підпорядкованими логіці: є вхідні дані, є обмеження, є набір інструментів. Урешті?решт, достатньо часу, експериментів і досвіду — і рішення знаходиться.
З людськими ж викликами все інакше. Тут немає стабільних API, передбачуваних контрактів чи детермінованих відповідей. Кожна організація має власну культуру, політику, страхи, мотивації й «невидимі» обмеження, які не описані в жодній технічній документації. Саме в цій площині, за його словами, і лежали найважчі задачі — від узгодження очікувань до побудови довіри між технічними й бізнес?командами.
Це особливо помітно в сучасному світі потокових даних. Kafka, Flink, платформи на кшталт Confluent дають компаніям можливість будувати реальний «нервовий центр» бізнесу в реальному часі. Але сам факт наявності технології ще не означає, що хтось у компанії готовий змінювати процеси, брати на себе ризики й інвестувати в нову архітектуру. І саме тут технічні знання перестають бути достатніми.
Field CTO між Kafka та оргструктурою
Посада Field CTO в Confluent — це не «CTO в мініатюрі» й не класичний пресейлз?інженер. ЛаФорест описує її як роль на перетині трьох площин: глибокої технічної експертизи, постійної роботи з клієнтами та впливу на продуктовий напрям усередині компанії.
З одного боку, значну частину часу він проводить із клієнтськими командами, допомагаючи їм розв’язувати конкретні задачі за допомогою технологій Confluent. Це не абстрактні розмови про «потокову платформу майбутнього», а дуже приземлені питання: як інтегруватися з існуючими системами, як змінити подієву модель, як побудувати надійний стримінг?шар, який витримає навантаження реального бізнесу.
З іншого боку, Field CTO збирає «сигнал» від ринку — проблеми, з якими стикаються клієнти, прогалини в продукті, бар’єри впровадження — і повертає це всередину Confluent у вигляді зворотного зв’язку для продуктових команд. Це двосторонній канал: не лише «ось наш продукт, ось як ним користуватися», а й «ось як продукт сприймають, де він не стикується з реальністю, що потрібно змінити».
Ключовий момент у тому, що вся ця робота відбувається не в стерильному технічному вакуумі, а в живих організаціях. У кімнаті з ЛаФорестом можуть одночасно сидіти розробники, архітектори, керівники підрозділів і топ?менеджери. Для одних Kafka — це знайомий інструмент, для інших — слово, яке вони чули на конференції, але не вважають критично важливим для бізнесу. І саме в такому середовищі стає очевидно: технічна правильність рішення — лише половина справи.
Довіра як функція глибини й «людської мови»
ЛаФорест чітко формулює вимогу до своєї ролі: щоб мати авторитет як Field CTO, недостатньо вміти добре говорити з людьми. Потрібна глибока технічна обізнаність. Без неї будь?яка комунікаційна майстерність втрачає вагу.
У типових зустрічах із клієнтами завжди є хтось, хто здатен поставити незручне, дуже конкретне запитання: про семантику доставки повідомлень, про поведінку кластера в умовах часткових відмов, про компроміси між латентністю та консистентністю. Якщо людина в ролі Field CTO не може впевнено й по суті відповісти на такі питання, її швидко «знімають із п’єдесталу». Довіра зникає, а разом із нею — можливість впливати на рішення організації.
Водночас самих лише глибоких знань недостатньо. ЛаФорест наголошує: потрібно вміти говорити «людською мовою». Це означає не просто уникати жаргону, а перекладати технічні можливості в категорії, які мають сенс для конкретної аудиторії.
Для розробників це можуть бути аргументи про спрощення архітектури, зменшення кількості крихких інтеграцій, полегшення дебагу. Для архітекторів — про узгодженість даних між сервісами, масштабованість і надійність. Для керівників бізнес?напрямів — про швидкість виведення нових продуктів, зменшення операційних ризиків, кращу видимість у реальному часі. Для топ?менеджменту — про конкурентні переваги й здатність організації реагувати на події ринку не через тиждень, а за секунди.
Ця двокомпонентна модель — глибина плюс «людська мова» — і є, на думку ЛаФореста, основою професійної легітимності в його ролі. Без технічного фундаменту не буде довіри. Без вміння говорити зрозуміло не буде впливу.
Коли Kafka — це не про Kafka, а про історію
Один із найцікавіших аспектів підходу ЛаФореста — акцент на наративах. Він прямо говорить, що одне з найскладніших завдань у його роботі — пояснити, що може зробити технологічний стек Confluent «у термінах, які мають значення для них, у їхньому бізнесі».
Це означає, що універсальних презентацій «про Kafka» недостатньо. Те, що працює для банку, не спрацює для ритейлу; те, що резонує з командою, яка будує платіжну інфраструктуру, може бути абсолютно нецікавим для відділу логістики. Тому ЛаФорест робить наголос на адаптації історій і демонстрацій до конкретного домену клієнта.
Якщо організація живе показниками часу доставки, варто говорити про події, що відстежують шлях замовлення в реальному часі, а не про абстрактні «топіки» й «консюмери». Якщо ключова проблема — шахрайство, історія має обертатися навколо виявлення аномалій у потоках транзакцій, а не навколо внутрішньої архітектури брокера.
Цей підхід виходить далеко за межі класичного «демо продукту». Йдеться про побудову наративу, в якому технологія не є головним героєм. Головний герой — бізнес?ситуація клієнта, а Kafka та інші компоненти виступають інструментами, що дозволяють змінити хід цієї історії.
Саме тут проявляється головна теза ЛаФореста: успіх технологій на кшталт Kafka і загалом стримінгових платформ залежить не лише від того, наскільки добре вони вирішують інженерні задачі, а й від того, наскільки переконливо їх можна вписати в історію конкретної організації. Якщо люди не бачать себе в цій історії, якщо не розуміють, чому їм має бути не байдуже, — жодна технічна досконалість не допоможе.
Людський вимір data?streaming: узгодження, а не лише оптимізація
Погляд ЛаФореста на «найважчі проблеми» має важливі наслідки для всієї індустрії потокової обробки даних. Він фактично стверджує, що ключ до успіху проєктів у цій сфері лежить у площині узгодження людей і наративів не менше, ніж у площині інженерії.
По?перше, це означає, що організації, які інвестують лише в технологічний стек — кластери Kafka, інфраструктуру, інструменти — але ігнорують питання комунікації, зміни процесів і побудови спільного розуміння між командами, ризикують отримати «дорогу шину подій», яка не змінює спосіб роботи бізнесу. Технологія є, але вона не стає частиною щоденних рішень.
По?друге, це підкреслює важливість ролей на кшталт Field CTO, архітекторів?євангелістів і технічних лідерів, які здатні одночасно «говорити з кластерами» й «говорити з людьми». Їхнє завдання — не лише вибрати правильну конфігурацію брокерів, а й допомогти організації домовитися про те, що вважати подіями, як змінити відповідальність між командами, як вимірювати успіх.
По?третє, це ставить у центр уваги навички, які традиційно недооцінювалися в інженерному середовищі: уміння слухати, ставити уточнювальні запитання, будувати довіру, адаптувати мову до аудиторії. Для ЛаФореста саме ці «людські» компетенції виявилися найскладнішими, але й найважливішими для реального впливу на те, як організації використовують стримінгові технології.
І нарешті, його досвід показує, що навіть у світі, де все більше рішень автоматизується, а інфраструктура стає «як сервіс», найкритичніші вузли залишаються там, де зустрічаються люди: на стику між технічними й бізнес?командами, між візією й повсякденною практикою, між потенціалом технології й готовністю організації змінюватися.
Висновок: найважчий компонент стримінгової платформи — люди
Історія Вілла ЛаФореста в Confluent і його погляд на власну кар’єру пропонують тверезу корекцію для будь?якого технооптимізму. Навіть у сфері, де все крутиться навколо високонавантажених кластерів, реального часу й складних протоколів, найважчі проблеми виявляються не в коді, а в людях.
Field CTO, який працює з Kafka та потоковими платформами, опиняється не лише в ролі архітектора, а й у ролі перекладача, модератора й оповідача. Його успіх вимірюється не тільки тим, наскільки елегантною вийшла технічна схема, а й тим, наскільки організація прийняла цю схему як свою історію й почала діяти відповідно.
У цьому сенсі досвід ЛаФореста — нагадування для всієї індустрії: інвестуючи в стримінгові технології, варто так само серйозно інвестувати в комунікацію, довіру й спільне розуміння. Бо саме там, де технологія зустрічається з людьми, і вирішується, чи стане вона справжнім драйвером змін, чи залишиться ще одним «крутим стеком», про який усі забули через рік.
Джерело
Tech vs. People: The Hardest Problem with Will LaForest | Ep. 26 | Confluent Developer Podcast