Когда меня спросили, интересна ли мне возможность возглавить команду, отвечающую за авторизацию в приложении, я не сразу нашелся с ответом.
В данной команде я на тот момент отработал полгода в должности разработчика на Android, и смене техлида у нас сопутствовала смена менеджера продукта. Мы вступали в эпоху Flux, что, на мой взгляд, могло с равной степенью вероятности обернуться как успехом, так и катастрофой. Возможно, программист, который бы лучше соответствовал типичным представлениям о техлиде в Monzo, стал бы более удачным выбором.
Мое собственное представление о техлиде в Monzo было следующим: бэкенд-разработчик с хорошим стажем и большим запасом технических знаний, связанных с бэкендом. Ведь именно этому человеку предстояло стать точкой соприкосновения с людьми вне команды во всем, что касается внутренних технических процессов Monzo.
Будучи разработчиком на Android, я в своей деятельности специализировался на аспектах, обращенных к клиентам банка. Что если команда решит, что я не гожусь на руководящую роль, или новые обязанности окажутся мне не по силам?
Я изложил свои сомнения начальнику, и мы решили, что я займу должность на пробный период. Нам хотелось проверить, имеют ли мои сомнения под собой какие-то основания или происходят из заблуждений.
Прошло полтора года, и я рад сообщить, что мои сомнения действительно оказались заблуждениями. Ниже я расскажу, чему научился в процессе, какую тактику применял и в каких отношениях, на мой взгляд, этот опыт принес пользу мне и команде.
Для меня было очень важно не уходить от разработки приложений – именно эта работа доставляет мне больше всего удовольствия. Значит, вариант со вступлением на путь переучивания на бэкенд-разработчика или даже на гибридного разработчика, отпадал. Вместо попыток подогнать себя под шаблон техлида Monzo, как я его себе представлял до того момента, я решил подумать, как оптимальным образом применить собственные умения и опыт в новой должности.
Мне казалось важным признавать, что я чего-то не знаю. Я не стеснялся задавать вопросы, даже о самых примитивных вещах. Я действовал с опорой на других людей, когда нужно было восполнить пробелы в умениях, которых мне недоставало, например, при написании технических предложений или разборе запросов от поддержки, связанных с бэкендом. Подобный подход дал нам одно преимущество: я не оттеснял других разработчиков, у них тоже была возможность внести свой вклад. Таким образом мы избежали анти-паттерна управления командой, при котором лид превращается в диктатора или мученика.
Впрочем, всё это не значит, что я пустил бэкенд на самотек. Я просто сосредоточился на основах. Какие у нас есть сервисы? На каких дэшбордах осуществляется мониторинг? Как всё устроено на верхнем уровне?
Затем я применил тот же метод, чтобы помочь другим людям в команде разобраться с ключевыми моментами процесса разработки и характеристиками продукта. Я действовал так:
В Monzo экспериментирование – ключевой компонент для опыта разработки продукта, и мне хотелось привлечь к этому занятию больше людей из команды. Я объединил усилия с нашим специалистом по работе с данными, чтобы развить в команде культуру экспериментирования, в которой люди берут на себя эксперименты и ведут их от начала до конца – от гипотезы до выкатывания. Мы организовали еженедельные сессии со всей командой для обсуждения экспериментов; это давало нам время поделиться прогрессом и проанализировать результаты. Это также способствовало тому, что эксперименты сохраняли фокус, и напоминало нам о том, что все члены команды должны участвовать в ее делах.
Располагая глубоким пониманием устройства клиентских приложений, я сумел наладить работу с менеджером продукта и выработать тактический подход, чтобы быстрее доводить новую функциональность до релиза. Например, путем выявления таких вещей, как:
Благодаря этим приемам у нас сложилось более полное понимание продукта, процессов и пользователей, которое разделяли все. С этим пониманием пришел и рост вклада в сопутствующие разработке процессы: генерацию идей, контроль качества, программирование, управляемое данными. Люди стали охотнее выдвигать инициативы и браться за эксперименты.
Описанный подход позволил нам внедрить широкий круг усовершенствований в процесс авторизации и протестировать их в серии экспериментов, параллельно на iOS и на Android. Недавно мы писали об одном из этих экспериментов у себя в блоге. С опорой на эти эксперименты мы оптимизировали некоторые элементы процесса авторизации, что способствовало выходу Monzo на уровень в восемь миллионов пользователей.
Не всегда было просто, и я столкнулся с рядом трудностей. Практически на всем протяжении своей работы техлидом я оставался единственным разработчиком на Android в команде. Возникали сложности с распределением времени, чтобы эффективно выполнять оба набора обязанностей. Я часто обнаруживал, что пытаюсь убить двух зайцев: и сам выдать результат, и команде помочь с тем же. Делегирование задач оказалось критически важным в таких ситуациях; также мне пришлось научиться здраво расставлять приоритеты в работе и доносить эту информацию до коллег.
Разделяют ли окружающие мое мнение, что мобильный разработчик – необычный выбор для должности техлида? Временами синдром самозванца определенно давал о себе знать. Я и по сей день сталкиваюсь с ситуациями, где требуется определенный уровень познаний в бэкенде, однако мне удается успешно с ними справляться за счет принятия собственных ограничений и способности полагаться на профессионализм других членов команды.
Несмотря на эти трудности я больше не тревожусь о том, что не вписываюсь в предзаданный эталон техлида. Сосредоточившись на своих сильных сторонах и индивидуальной точке зрения, я более естественно занял лидерскую позицию и получил результаты лучше, чем если бы пытался загнать себя в шаблон стандартного бэкенд-техлида.
В последние полгода наша команда становится все более и более ориентированной на продукт, и знание приложения выходит на первый план. Охватили бы в свете этого такие же сомнения о пригодности на роль техлида бэкенд-разработчика, если бы он оказался на моем месте? В конечном счете, эта перемена заставила меня покинуть зону комфорта и без этого я не получил бы многих возможностей. Я однозначно не жалею о своем выборе и получаю большое удовольствие от вызовов, которые бросает мне руководство командой.
Если кто-то из читателей раздумывает над тем, чтобы занять руководящую должность, или уже стоит во главе смешанной команды, занимающей разными дисциплинами, я призываю вас обратить взгляд на свои умения и опыт и подумать, какое уникальное влияние они могли бы оказать на команду. Именно так мне удалось добиться максимальной эффективности. Если бы я зациклился на тревогах, что не подхожу, или попытках вписаться, то мог бы потерять то самое, что помогло мне добиться успеха.
В данной команде я на тот момент отработал полгода в должности разработчика на Android, и смене техлида у нас сопутствовала смена менеджера продукта. Мы вступали в эпоху Flux, что, на мой взгляд, могло с равной степенью вероятности обернуться как успехом, так и катастрофой. Возможно, программист, который бы лучше соответствовал типичным представлениям о техлиде в Monzo, стал бы более удачным выбором.
Мое собственное представление о техлиде в Monzo было следующим: бэкенд-разработчик с хорошим стажем и большим запасом технических знаний, связанных с бэкендом. Ведь именно этому человеку предстояло стать точкой соприкосновения с людьми вне команды во всем, что касается внутренних технических процессов Monzo.
Будучи разработчиком на Android, я в своей деятельности специализировался на аспектах, обращенных к клиентам банка. Что если команда решит, что я не гожусь на руководящую роль, или новые обязанности окажутся мне не по силам?
Я изложил свои сомнения начальнику, и мы решили, что я займу должность на пробный период. Нам хотелось проверить, имеют ли мои сомнения под собой какие-то основания или происходят из заблуждений.
Прошло полтора года, и я рад сообщить, что мои сомнения действительно оказались заблуждениями. Ниже я расскажу, чему научился в процессе, какую тактику применял и в каких отношениях, на мой взгляд, этот опыт принес пользу мне и команде.
Прыжок в неизвестное
Для меня было очень важно не уходить от разработки приложений – именно эта работа доставляет мне больше всего удовольствия. Значит, вариант со вступлением на путь переучивания на бэкенд-разработчика или даже на гибридного разработчика, отпадал. Вместо попыток подогнать себя под шаблон техлида Monzo, как я его себе представлял до того момента, я решил подумать, как оптимальным образом применить собственные умения и опыт в новой должности.
Мне казалось важным признавать, что я чего-то не знаю. Я не стеснялся задавать вопросы, даже о самых примитивных вещах. Я действовал с опорой на других людей, когда нужно было восполнить пробелы в умениях, которых мне недоставало, например, при написании технических предложений или разборе запросов от поддержки, связанных с бэкендом. Подобный подход дал нам одно преимущество: я не оттеснял других разработчиков, у них тоже была возможность внести свой вклад. Таким образом мы избежали анти-паттерна управления командой, при котором лид превращается в диктатора или мученика.
Впрочем, всё это не значит, что я пустил бэкенд на самотек. Я просто сосредоточился на основах. Какие у нас есть сервисы? На каких дэшбордах осуществляется мониторинг? Как всё устроено на верхнем уровне?
Затем я применил тот же метод, чтобы помочь другим людям в команде разобраться с ключевыми моментами процесса разработки и характеристиками продукта. Я действовал так:
- помог упростить обзор экранов авторизации при помощи Figma, клиентской аналитики и дэшбордов Looker, чтобы визуализировать, как проходят их пользователи;
- призывал всю команду к участию в тестировании и использованию билдов для устранения багов;
- поддерживал сотрудников, которые хотели настроить свою собственную среду разработки для клиентской части, давал им возможность самим тестировать изменения и создавать клиентские pull request-ы;
- вникал в процессы, связанные с релизом приложения, чтобы понять, сколько времени займет внедрение изменений и как это может повлиять на наши технические решения.
Стимулирование экспериментов
В Monzo экспериментирование – ключевой компонент для опыта разработки продукта, и мне хотелось привлечь к этому занятию больше людей из команды. Я объединил усилия с нашим специалистом по работе с данными, чтобы развить в команде культуру экспериментирования, в которой люди берут на себя эксперименты и ведут их от начала до конца – от гипотезы до выкатывания. Мы организовали еженедельные сессии со всей командой для обсуждения экспериментов; это давало нам время поделиться прогрессом и проанализировать результаты. Это также способствовало тому, что эксперименты сохраняли фокус, и напоминало нам о том, что все члены команды должны участвовать в ее делах.
Располагая глубоким пониманием устройства клиентских приложений, я сумел наладить работу с менеджером продукта и выработать тактический подход, чтобы быстрее доводить новую функциональность до релиза. Например, путем выявления таких вещей, как:
- случаев, когда можно повторно использовать или приспособить уже существующие решения – скажем, обновить имеющееся в нашем распоряжении решение для заполнения форм, собирающих пользовательские данные, вместо того чтобы делать особый инструмент;
- возможностей провести имплементацию части функциональности, а не всей целиком, что уменьшало объем работ, необходимых для выхода на рынок. Если эксперимент оказывался успешным, мы заполняли оставшиеся лакуны;
- общих обязанностей, которыми может заниматься не только наша команда, но и более широкий круг людей. Например, мы снизили приоритет задачи по улучшению UI-библиотек внутри команды и обратили на нее внимание других сотрудников с соответствующей специализацией.
Благодаря этим приемам у нас сложилось более полное понимание продукта, процессов и пользователей, которое разделяли все. С этим пониманием пришел и рост вклада в сопутствующие разработке процессы: генерацию идей, контроль качества, программирование, управляемое данными. Люди стали охотнее выдвигать инициативы и браться за эксперименты.
Трудности и результаты
Описанный подход позволил нам внедрить широкий круг усовершенствований в процесс авторизации и протестировать их в серии экспериментов, параллельно на iOS и на Android. Недавно мы писали об одном из этих экспериментов у себя в блоге. С опорой на эти эксперименты мы оптимизировали некоторые элементы процесса авторизации, что способствовало выходу Monzo на уровень в восемь миллионов пользователей.
Не всегда было просто, и я столкнулся с рядом трудностей. Практически на всем протяжении своей работы техлидом я оставался единственным разработчиком на Android в команде. Возникали сложности с распределением времени, чтобы эффективно выполнять оба набора обязанностей. Я часто обнаруживал, что пытаюсь убить двух зайцев: и сам выдать результат, и команде помочь с тем же. Делегирование задач оказалось критически важным в таких ситуациях; также мне пришлось научиться здраво расставлять приоритеты в работе и доносить эту информацию до коллег.
Разделяют ли окружающие мое мнение, что мобильный разработчик – необычный выбор для должности техлида? Временами синдром самозванца определенно давал о себе знать. Я и по сей день сталкиваюсь с ситуациями, где требуется определенный уровень познаний в бэкенде, однако мне удается успешно с ними справляться за счет принятия собственных ограничений и способности полагаться на профессионализм других членов команды.
Несмотря на эти трудности я больше не тревожусь о том, что не вписываюсь в предзаданный эталон техлида. Сосредоточившись на своих сильных сторонах и индивидуальной точке зрения, я более естественно занял лидерскую позицию и получил результаты лучше, чем если бы пытался загнать себя в шаблон стандартного бэкенд-техлида.
В последние полгода наша команда становится все более и более ориентированной на продукт, и знание приложения выходит на первый план. Охватили бы в свете этого такие же сомнения о пригодности на роль техлида бэкенд-разработчика, если бы он оказался на моем месте? В конечном счете, эта перемена заставила меня покинуть зону комфорта и без этого я не получил бы многих возможностей. Я однозначно не жалею о своем выборе и получаю большое удовольствие от вызовов, которые бросает мне руководство командой.
Если кто-то из читателей раздумывает над тем, чтобы занять руководящую должность, или уже стоит во главе смешанной команды, занимающей разными дисциплинами, я призываю вас обратить взгляд на свои умения и опыт и подумать, какое уникальное влияние они могли бы оказать на команду. Именно так мне удалось добиться максимальной эффективности. Если бы я зациклился на тревогах, что не подхожу, или попытках вписаться, то мог бы потерять то самое, что помогло мне добиться успеха.