Mechanisms for Effective Technical Teams

Начните отсюда Статьи Выступления Прототипирование Обо мне

Mechanisms for Effective Technical Teams

Механизмы для эффективных технических команд

Previously, we discussed mechanisms for machine learning projects. Here, we’ll discuss mechanisms for technical teams and teams of teams. The goal is to increase productivity and team effectiveness. A team is a group of people organized around a common function such as engineering, business intelligence, or machine learning. Another definition is Amazon’s 2-pizza teams which are organized around a product or service.

Ранее мы обсуждали механизмы для проектов машинного обучения. Здесь мы поговорим о механизмах для технических команд и команд команд. Цель — повысить продуктивность и эффективность команды. Команда — это группа людей, организованная вокруг общей функции, например инжиниринга, бизнес-аналитики или машинного обучения. Другое определение — «2-пицца-команды» Amazon, которые организованы вокруг продукта или сервиса.

End of Week Debrief (team)

Разбор в конце недели (команда)

The end of week debrief (EOWD) provides an opportunity for the team to come together and share the week’s progress. They’re typically informal and last an hour. The only requirement is to not spend time preparing beforehand. It’s meant to be a lightweight mechanism for the team to share information, gather feedback, and ask for help.

Разбор в конце недели (end of week debrief, EOWD) — это возможность для команды собраться вместе и поделиться прогрессом за неделю. Такие встречи обычно неформальны и длятся час. Единственное требование — не тратить время на подготовку заранее. Это лёгкий механизм для команды, чтобы делиться информацией, собирать обратную связь и просить помощи.

At EOWDs, team members might present their work through jupyter notebooks, pull requests, or document outlines. Whether someone is sharing a new dataset they found or built, optimizing a data pipeline, or trying a new machine learning technique, it’s a chance for everyone to learn. It’s also a forum to ask for feedback: Are there any blindspots or design flaws? Any suggestions for improvement?

На EOWD члены команды могут представлять свою работу через jupyter-ноутбуки, pull request'ы или наброски документов. Делится ли кто-то новым датасетом, который нашёл или построил, оптимизацией пайплайна данных или новой техникой машинного обучения — это шанс для всех чему-то научиться. Также это форум для запроса обратной связи: есть ли слепые зоны или недостатки дизайна? Какие-то предложения по улучшению?

To get the most out of it, I usually spend a few minutes before an EOWD to think about what input I want from the team. With a team of 4 - 6 people, each person only has 10 minutes to share. Thus, it’s important to be concise. Note that EOWDS are not meant to replace methodology reviews. Nonetheless, they work well as mini-reviews that let us iteratively receive feedback and course-correct before the full methodology review.

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

One benefit of EOWDs is that they give everyone greater context on what everyone else is working on. This is especially helpful for new members to get up to speed quickly. Also, frequent sharing fosters knowledge transfer and stronger collaboration within the team.

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

Monthly Learning Sessions (team)

Ежемесячные обучающие сессии (команда)

This is for sharing knowledge that goes beyond the ~10 minutes at EOWD. The intent is to scale the expertise of an individual to the team, or from a team to the greater organization. Depending on the topic shared, the audience may expand from the team to include other teams in the organization.

Это для обмена знаниями, выходящего за рамки ~10 минут на EOWD. Цель — масштабировать экспертизу отдельного человека на команду или с команды на более широкую организацию. В зависимости от темы аудитория может расширяться от команды до других команд в организации.

The sessions are typically an hour long. The speaker shares for 30 - 45 minutes and the remaining time is dedicated to Q&A. We usually record these sessions so people who missed it can watch the recording. This also lets people revisit the details in the session.

Сессии обычно длятся час. Спикер делится знаниями 30-45 минут, а оставшееся время отводится на Q&A. Мы обычно записываем такие сессии, чтобы те, кто пропустил, могли посмотреть запись. Это также позволяет людям пересмотреть детали сессии.

There’s no fixed format for this mechanism. If the topic is on machine learning techniques or evaluation methodology, it may be beneficial to have slides and visuals. On the other hand, if we’re teaching how to use tools like SageMaker or Airflow, it might be effective to have hands-on demos, look at code, and interact with the UI.

Жёсткого формата у этого механизма нет. Если тема — техники машинного обучения или методология оценки, может быть полезно иметь слайды и визуалы. С другой стороны, если мы учим пользоваться инструментами вроде SageMaker или Airflow, может быть эффективнее провести практические демо, посмотреть код и повзаимодействовать с UI.

Learning sessions can cover a wide range of topics. Some I’ve attended include:

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

Machine learning: If we’re sharing about bandits, we might discuss concepts such as reward, context, feedback, explore-exploit, and examples from industry.

Tools: If we’re teaching about Airflow, we might start by taking a look at a production DAG via the UI before walking through the DAG’s code. Then, we’ll share how our team has set up alarms and ticketing for task failures or delays.

Skills: If we’re sharing how to navigate CloudWatch, we might first show how to plot metrics and run queries before diving into a case study of how we used CloudWatch to triage the root cause of an outage.

Машинное обучение: если мы рассказываем про bandits, можно обсудить такие концепции, как вознаграждение, контекст, обратная связь, explore-exploit и примеры из индустрии. Инструменты: если мы учим Airflow, можно начать с просмотра продакшн-DAG через UI, а затем пройтись по его коду. Затем мы расскажем, как наша команда настроила алармы и тикетинг для падений или задержек задач. Навыки: если мы делимся, как ориентироваться в CloudWatch, можно сначала показать, как строить графики метрик и запускать запросы, а затем разобрать кейс, как мы использовали CloudWatch для триажа корневой причины сбоя.

Quarterly Review (team of teams)

Квартальный обзор (команда команд)

It’s easy for tech teams to get caught up in the day-to-day details of executing and lose sight of the broader business and product priorities. This is where a quarterly review is valuable. It’s an opportunity to take a step back, reflect, and align on the medium-to-long-term goals. The intent is to provide the broader team with the right context so they can make good decisions in their work.

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

At Netflix, they embody this concept with their culture of being “highly aligned, loosely coupled”. In their words: “We spend lots of time debating and writing down strategy and context, and then trust each other to execute on tactics without prior approval.” Quarterly reviews help teams act on this principle.

В Netflix эту концепцию воплощают в культуре «highly aligned, loosely coupled» (сильно выровненные, слабо связанные). Их собственными словами: «Мы тратим много времени на обсуждение и фиксацию стратегии и контекста, а затем доверяем друг другу выполнять тактику без предварительного одобрения». Квартальные обзоры помогают командам жить по этому принципу.

We typically kick off a review by reflecting on the previous quarter. What did we achieve? This can be measured via features released, operational improvements, or experiments ran. In addition, what did we learn? What went well and didn’t go so well? This is a chance to celebrate the wins and lessons gained.

Обычно мы начинаем обзор с рефлексии о прошлом квартале. Чего мы достигли? Это можно измерить выпущенными фичами, операционными улучшениями или проведёнными экспериментами. Кроме того — чему мы научились? Что прошло хорошо, а что не очень? Это шанс отпраздновать победы и извлечённые уроки.

Then, we focus on next quarter’s priorities. What are the continued priorities that we’ll carry on this quarter? What are the new priorities that were either previously planned or a net new initiative? If it’s a new initiative, why is it important? Finally, what will we stop doing and why? This could be due to negative results, poor customer response, or temporary deprioritization.

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

During the review, it’s important to share the “Why” behind each priority so the team understands the context. This empowers the team to make informed decisions on “What” to do or not do, letting them execute more effectively and quickly.

Во время обзора важно делиться «Почему» за каждым приоритетом, чтобы команда понимала контекст. Это даёт команде возможность принимать информированные решения о том, «Что» делать или не делать, позволяя действовать эффективнее и быстрее.

The quarterly review is also a great time to build team camaraderie. Whether in-person or virtual, we can set aside time for games and a meal. Some great online games I’ve tried include Fibbage: Enough About You, Drawasaurus, and Codewords. The goal is to have fun, connect, and come away with a shared understanding of next quarter’s priorities.

Квартальный обзор — также отличное время для укрепления командного духа. Будь то очно или виртуально, мы можем отвести время для игр и совместной трапезы. Среди отличных онлайн-игр, которые я пробовал, — Fibbage: Enough About You, Drawasaurus и Codewords. Цель — повеселиться, сблизиться и уйти с общим пониманием приоритетов следующего квартала.

Weekly Business Review (team of teams)

Еженедельный бизнес-обзор (команда команд)

The goal of the weekly business review (WBR) is to provide a comprehensive overview of the business or team. At the crux of it are metrics: input metrics and output metrics.

Цель еженедельного бизнес-обзора (weekly business review, WBR) — дать всеобъемлющий обзор бизнеса или команды. В его основе лежат метрики: входные и выходные.

It’s important to understand how the inputs (aka leading indicators) affect the outputs (lagging indicators) of our systems. With this knowledge, we can adjust the controllable inputs to achieve the desired outputs. While output metrics are crucial, they can’t be directly manipulated over the long term. On the other hand, input metrics measure things that—if done right—bring the desired outputs.

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

In Working Backwards, we learn that Amazon uses input metrics such as adding items to the catalog, lowering costs to lower prices, and positioning inventory to facilitate faster delivery to customers. Output metrics include orders, revenue, and profit. To learn more about WBRs, I suggest Commoncog’s summary on controllable input metrics. Also, the book “Working Backwards”, authored by two long-time Amazon insiders, has an entire chapter dedicated to metrics.

В книге Working Backwards мы узнаём, что Amazon использует такие входные метрики, как добавление товаров в каталог, снижение себестоимости для снижения цен и размещение запасов для ускорения доставки клиентам. Выходные метрики включают заказы, выручку и прибыль. Чтобы узнать больше о WBR, рекомендую обзор Commoncog про управляемые входные метрики. Также в книге «Working Backwards», написанной двумя давними инсайдерами Amazon, есть целая глава, посвящённая метрикам.

Let’s take a look at some input and output metrics for a hypothetical machine learning team in an e-commerce startup. For sales, output metrics include conversion, revenue, basket size, and the sales funnel (e.g., clicks, add-to-cart, wishlist). Input metrics include the number of experiments conducted on search and recommendations, coverage of recommendation widgets across the home page, detail page, checkout page, etc., and the delay between customer behavior and updated recommendations.

Давайте посмотрим на некоторые входные и выходные метрики гипотетической команды машинного обучения в e-commerce-стартапе. Для продаж выходные метрики включают конверсию, выручку, размер корзины и воронку продаж (например, клики, добавление в корзину, в избранное). Входные метрики включают количество экспериментов, проведённых на поиске и рекомендациях, покрытие виджетов рекомендаций по главной странице, странице товара, странице оформления заказа и т.д., а также задержку между поведением клиента и обновлёнными рекомендациями.

Another example is delivery forecasts. The output metric could be the proportion of deliveries that arrive before, on, or after the forecasted delivery date. Input metrics could include data integration with third-party logistics providers, the timeliness, granularity, and quality of logistics data, and efforts to improve forecasting accuracy.

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

• • •

Though these mechanisms increase team productivity, they do come with a cost. Some, like the EOWD that only requires an hour a week, are a small investment. Others, like the WBR, require more time and effort. The ROI from these mechanisms will vary depending on the stage of the team. Thus, be deliberate about picking mechanisms to adopt.

Хотя эти механизмы повышают продуктивность команды, у них есть цена. Некоторые, как EOWD, требующий лишь часа в неделю, — это небольшая инвестиция. Другие, как WBR, требуют больше времени и сил. ROI от этих механизмов будет варьироваться в зависимости от стадии команды. Поэтому будьте осознанны при выборе механизмов для внедрения.

Have you tried similar mechanisms and how did they work out? What other mechanisms does your team have? Please share!

Пробовали ли вы похожие механизмы и как они сработали? Какие ещё механизмы есть у вашей команды? Поделитесь!

Thanks to Yang Xinyi for reading drafts of this.

Спасибо Yang Xinyi за прочтение черновиков.

If you found this useful, please cite this write-up as:

Если эта статья оказалась полезной, пожалуйста, цитируйте её так:

Yan, Ziyou. (Feb 2023). Mechanisms for Effective Technical Teams. eugeneyan.com. https://eugeneyan.com/writing/mechanisms-for-teams/.

or

или

@article{yan2023teams, title = {Mechanisms for Effective Technical Teams}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2023}, month = {Feb}, url = {https://eugeneyan.com/writing/mechanisms-for-teams/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

К 11 800+ читателям присоединяйтесь, чтобы получать обновления о машинном обучении, RecSys, LLM и инжиниринге.