Техдир

Жил-был технический директор. Он жил долго и счастливо. И пригласили его на интересный и перспективный проект. Владельцы бизнеса размахивали руками, поднимая сквозняк в помещении и рисовали маркерами прямо на оконных стёклах счастливое будущее, масштабность задачи, нули после первой цифры в зарплате. Звучит, как сказка.

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

Техдир пришёл к ним, поздоровался и спросил: Ребята, скажите честно, какой аццкий зверь меня ждёт в этом проекте? Потому что стейкхолдеры рассказали только о единорогах с радужными хвостами и розовых пони? Legacy, да?

Legacy, ..., грустно ответили разработчики.

Сказка закончилась. Началась работа и непростые решения.

Cитуация. Первый извечный вопрос русской интеллигенции Кто виноват?

Закрываем глаза и представляем рядовую ситуацию. Бизнес приходит с какой-либо идеей и он пробует ее сделать сразу и быстро. То есть с помощью ..., пустых банок из-под колы и палок. Бизнес-управленцы пробуют каким-то образом решить эту проблему в минимальные сроки.

Они привлекает либо аутсорсеров, либо от других своих проектов отвлекает разработчиков. В общем, буквально экономят на всём, пытаются за копейки сделать какой-нибудь мини MVP, с помощью которого проверить гипотезу. Допустим.

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

Эти остаточные явления можно назвать культурными наслоениями. И это в принципе, наверное, оправданный подход, потому что пока вот эти супер дорогие программисты построят все по-правильному и бабло в канализацию спустишь, и идея убежит, и все сроки пройдут. А так ты быстро на коленке собрал работающее MVP.

И погнали. Оно работает с помощью каких-то негров с опахалами, шамана, бивня мамонта, летающей китайской крысы и панголина.

Продукт обрастает вот такими культурными наслоениями, костылями и чем-то еще. Проблема еще заключается в том, что, так как гипотезы проверяются часто из la merde и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу. И они к этому относятся а давайте-ка я тут попробую один метод программирования, а сейчас попробую другую концепцию. И в результате получается месиво подходов.

Вроде бы у тебя есть и решение, внутри которого кодом записано, как должен работать продукт. Но с другой стороны, там столько всего намешано, что, казалось бы, там функциональности с гулькин нос. Если все просто переписать, можно было бы вполне спокойно развивать продукт, но там ведь наскоками дают тебе пять минут раз в месяц позаниматься этим, ты прибегаешь туда и пока ты расковыряешь все эти зависимости Документации же нет от слова совсем. Откуда там документация?

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

Сами гипотезы-то быстро проверяются берут программиста из какого-нибудь проекта, выдергивают его на пол дня, он быстро-быстро налепил и убежал, потом берут другого программиста или вообще фрилансера какого-нибудь.

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

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

И проблема заключается в том что, во-первых, цена разработки высокая: она складывается из того, что ты погружаешься заново, проводишь R&D такой на то, чтобы разобраться, как здесь все работает. С другой стороны, документации нет. Документация нужна для того, чтобы ты разобрался, сформировал справочник и мог им пользоваться в дальнейшем. Документация это такой коммуникатор между стейкхолдерами, между разработчиками и постановщиком задач, между продуктоунером и конечными пользователями. Такая форма дешевой коммуникации, как железная дорога. Её долго и дорого строить, но зато потом очень дёшево перебрасывать грузы и людей на огромные расстояния.

Итак, техдир приходит на выстреливший проект. Программисты там, что могли, сделали. Теперь приходит технический управленец, который знает, как построить правильно, как масштабироваться и так далее. И он видит вот это вот нечто. Да, именно Нечто, как в фильме ужасов. И у него возникает дилемма, с одной стороны, он же новый человек перед проектом, ему тоже нужно какие-то свои KPI выдерживать, как-то показывать себя перед бизнесом.

А бизнес вообще не знает, что проблема есть. Бизнес вообще не понимает: Ну как так, MVP же работает?. Работает. А почему новую фичу нельзя вот прям счаз воткнуть? И с чем сталкиваются многие технические управленцы, они не могут объяснить, в чем конкретно проблема и самое тяжелое они не могут показать в метрике, измеримой бизнесу, чтобы они понимали, что в текущем состоянии разработка фичи стоит 100 рублей, а в оптимизированном, например, 10 рублей.

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

Решение проблемы. Ломать нельзя рефакторить. Или уходя гасите всех

И мы переходим к решению проблемы. Существуют различные попытки решить проблему.

Решение номер раз. Помножить на ноль

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

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

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

И один из очень интересных подходов заключается в том, чтобы помножить на ноль все усилия для команды. Значит, он говорит: Всё херня, кроме пчёл! Переделывайте нафиг!. В этот момент случилась следующая вещь у него есть в голове какая-то своя новая концепция продукта, в котором он лучше всего разбирается, а команда не разбирается. Она разбирается в той старой схеме. Но старую схему он обнулил на правах того, что он технический лидер и получается, что он теперь в дамках. И чтобы сохранить свое положение в дамках он же красавчик в глазах начальства он обнулил все заслуги команды, и теперь он предложил играть по его правилам.

И у команды есть свои резоны и свой выбор о том, как им действовать. Кто-то говорит: Ну-ну, посмотрим, что эта ваша новая схема стоит, будет он помогать или не будет, это большой вопрос. Кто-то встает по стойке смирно и говорит: дДа, хорошо, я готов. Некоторые начинают откровенно вредить. Почему? У них же раньше была власть, ещё вчера у них была власть, они были опытными сотрудниками, которых ценили на проекте за то, что они могли решить любую проблему. А проблемы заключались в том, что там всё это было в таком бардаке, что никто не знал.

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

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

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

Это один из таких способов, но он подразумевает, что какое-то время продукт не будет никак развиваться. У меня была реальная ситуация, когда ко мне пришёл за консультацией генеральный директор, у которого реально дергался глаз оказалось 14 месяцев назад команда сказала, что ей нужен рефакторинг, мол, иначе всё умрёт. И за эти 14 месяцев она ничего не сделала, точнее как, продукт не развивался а что происходило в рефакторинге никто не знает. Там ящик Шрёдингера и что там с кошкой, можно понять только по запаху.

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

Решение номер два. И давайте тут чуть-чуть починим

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

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

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

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

Во втором примере новой концепции нет и это реально проблема.

Решение номер три. Золотая середина. Микроверсия нового продукта

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

Вот что это такое за новая концепция, это о чем? Артефакты какие бывают? Это документ или это серия видеороликов про то, как писать, или это книга Чистый код. Должен быть какой-то артефакт и таким неплохим артефактом является микро версия, написанная в новой архитектуре вот самого основного продукта. Буквально совсем маленькая система, в которой есть основные функциональные части.

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

И теперь важная тема. В книге Фредерика Брукса приводится приводится пример того, как раньше строили храмы и там был пример храма Temple Expiatori de la Sagrada Famlia в Барселоне, строящегося на частные пожертвования начиная с 1882 года, знаменитый проект Антонио Гауди.

Суть в том, что Sagrada Famlia придумал Гауди и он выработал архитектуру, каким храм должен быть, но так как проект огромный, его строили много поколений и он еще недостроен, его достраивают еще.

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

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

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

Теперь давайте посмотрим на поток задач, который приходят в спринт. Там есть какие-то мелкие правки, какие-то мелкие фичи. И вот эти вот вещи, какие-то мелочи, которые приходят, их нужно делать по-старому, по-плохому. Точно так же вонзаем какие-то костыли, делаем по-старому.

И вот к нам приходит большая новая фича. Значит, мы берем место, где надо располагать новую фичу и разбиваем нашу задачу фичи на две части. Они должны быть строго отдельными. Сначала мы расчищаем место, полностью рефакторим этот кусок кода, где должна быть фича. То есть функционал старый работает, мы его рефакторим, выкатываем в продакшн, чтобы он по-прежнему был работающий, у нас получается отрефакторенный код и потом мы на это место насаждаем новые концепции, новую фичу.

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

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

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

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

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

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

фото с сайта pilot.com
В 2012 году Джессика МакКеллар с командой друзей из MIT (Мичиганский Технический Университет) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.

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

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

Что значит напрямую поддерживать команду?

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

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

Необходимо искать равновесие между структурированной еженедельной рутиной и временем на двустороннюю обратную связь в режиме здесь и сейчас. Одно это уже сделает вас весьма эффективным менеджером в проекции дня.

Большую сложность представляет вопрос, как помогать людям строить долгосрочный план по достижению удовлетворенности и продуктивности в вашей компании. Сюда относится много факторов. Если немного упростить, то 50% помочь людям понять, что они хотят делать, и 50% включить это в ежедневную рутину, планирование и проекты.

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

Хорошие лидеры экспертно вычленяют эту информацию и делают такой вариант осуществимым.

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

1. навыки, которые они хотят улучшить;
2. технический и нетехнический опыт, который хотят получить;
3. насколько они хотят расширить пределы своего влияния в компании.

Как только они смогут эти три пункта сформулировать, вам с намного большей долей вероятности удастся найти для них подходящие возможности. А они с намного большей долей вероятности эти возможности реализуют.

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

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

Все это может сработать только в случае, если каждый искренен с другими. На плечах менеджера лежит обязанность задать этот тон. Дайте людям понять, что они спокойно могут сказать, что в перспективе они хотят работать где-то еще или заниматься чем-то другим. Я стараюсь это представлять в таком свете: Все ли мы с компанией Dropbox делаем правильно, чтобы вы получили желаемый опыт для занятия тем, чем вы хотите, в будущем?

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

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

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

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

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

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

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

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

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

Производительность вашей команды = ваши возможности как руководителя

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

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

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

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

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

Кого-то очень мотивирует абстрактно теоретизированная работа по созданию прототипа, которую они могут быстро повторить, даже если впоследствии придется половину выбросить. Кто-то очень любит создавать стабильный продукт, который они точно это знают будут использовать 300 миллионов человек. Существует целый ряд мотиваций. Вам просто нужно понять, в чем заключаются естественные склонности человека и использовать это, назначая его на проект, в котором его работа будет оптимальной.

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

Во время одной из наших встреч я просто сказала: Слушай, тебе явно нравится думать о таких вещах. Что если ты сможешь уделять мыслям о них гораздо больше времени? Я рассказала ему, что придется совершить вираж, и призналась, что, на мой взгляд, ему понравится переход от написания кода к другим задачам. Сейчас этот инженер руководит собственной командой технических специалистов. Было видно, что он уже мыслил, как менеджер. Вопрос был лишь в том, чтобы предоставить ему площадку для перехода в новую роль.

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

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

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

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

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

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

Новые люди всегда приносят свежие идеи и задают конструктивные вопросы по поводу правильного способа ведения дел. Новые инженеры не принимают на веру, что определенные вещи никогда не работали. А это очень оздоравливает компанию. Опытные инженеры, в свою очередь, привносят полезные привычки и дисциплину в непростые проекты. У вас постоянно будет определенное количество крутых проектов. Распределяйте их равномерно между обеими категориями сотрудников.

Вам нужно непрерывно прокачивать всех членов команды. Мастерство подтянется.

Помимо руководства командами инженеров в Dropbox Джессика МакКеллар еще является директором Python Software Foundation. Она ведет твиттер @jessicamckellar. Фото: Бонни Рай Миллз

Помогайте людям работать быстрее с помощью правильных инструментов

Одна из причин, по которой я рада работать в Dropbox, размер продукта и вызовы, которые его сопровождают. Мы покрываем вопросы продукта и инфраструктуры, которыми обычно занимаются более крупные компании. Это означает, что у каждого инженера Dropbox огромная ответственность и влияние. У нас нет времени, которое бы можно было потерять. В то же самое время это значит, что автоматизация, инструменты и масштабируемые практики намного более важны. Для меня это многоуровневое утверждение: я одновременно руковожу и тимлидами, и своей командой инженеров. Планирование имеет решающее значение в обоих случаях.

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

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

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

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

Среда

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

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

Летучки

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

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

Вам нужна система, которая позволит одновременно замечать пропущенную запятую и поможет людям серьезнее задуматься о том, что такое хорошая архитектура.

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

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

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

Классический пример очень длинная цепочка писем по одному поводу, в которой нет решения проблемы. Соберите всех, кто включен в эту переписку, в одной комнате на 10 минут и решение будет найдено.

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

Мотивация

Люди редко относятся к мотивации как к инструменту или так называемому защитному ограждению. Но она играет большую роль в удержании людей на пути к цели. И нет лучшего инструмента для преодоления серийных провалов, чем мотивация. Загвоздка в том, что менеджеры могут вкладывать сколько угодно усилий в поддержание духа, но наиболее эффективный тип мотивации сам собой рождается из удачно подобранных людей на проекты и личной преданности компании в целом. И это то, к чему менеджерам стоит прилагать большую часть своих усилий.

Люди всегда с энтузиазмом относятся к новому большому делу. Сложнее оказывается доделать последние 5% проекта, на который ты уже потратил вечность. И в такой ситуации нам надо, чтобы над задачей трудился тот, кто горячо заинтересован в работе и хорошо понимает, откуда взялся Dropbox. Наш бренд всегда запускает что-то классное, а для этого приходится основательно вкалывать над последними 5%.

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

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

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

В Dropbox большая часть естественной мотивации произрастает из того, что компания делает упор на поистине высококачественном и беспроблемном пользовательском опыте. По большому счету, основное конкурентное преимущество можно сформулировать так: у нас очень понятный, легкий продукт, который просто работает. Именно эта ценность делает мотивацию на последних 5% проще, потому что именно отсюда берется удовлетворение пользователя. Именно поэтому люди любят продукт.

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

Эти ценности можно легко вычленить, так как часто инженеры называют их в качестве причин, по которым хотят работать в этой компании. Они же должны взывать к тому, какими инженерами сотрудники хотят быть сейчас и в будущем. Усердными, внимательными к мельчайшим деталям, желающим, чтобы даже код был красивым. Лучшие техлиды используют дух компании или продукта, чтобы побуждать людей показывать свою лучшую работу.