Growing and Running Your Data Science Team

eugeneyan

eugeneyan

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

Growing and Running Your Data Science Team

Как растить команду data science и управлять ею

[ leadership datascience ] · 16 min read

[ leadership datascience ] · 16 мин чтения

An effective data science team is like the goose that lays the golden eggs. Sometimes, we focus too much on the eggs (i.e., results)—how can we get more, faster? As a result, the goose (i.e., team) can get neglected.

Эффективная команда data science — как гусыня, несущая золотые яйца. Иногда мы слишком сосредотачиваемся на яйцах (то есть на результатах) — как получить их больше и быстрее? В итоге гусыней (то есть командой) можно начать пренебрегать.

Stage 3 manager:

A manager who is all-business & primarily views people as "resources". May care about people. May even care a lot.

But cares much more about short term results & targets. So when the two are in conflict, she will unabashedly prioritize short term results.

Менеджер 3-й стадии: менеджер, для которого всё — бизнес и который воспринимает людей прежде всего как «ресурсы». Может заботиться о людях. Может даже заботиться очень сильно. Но гораздо больше его волнуют краткосрочные результаты и цели. Поэтому, когда одно вступает в конфликт с другим, он без зазрения совести отдаст приоритет краткосрочным результатам. — Shreyas Doshi (@shreyas) 30 января 2021

Here, we’ll focus on the goose. I’ll share what I learned about growing (hiring, training) and running (innovation, discipline, camaraderie) data science teams. This is based on my experience at Lazada (as an early DS who eventually led the team) and uCare (where we shipped an ML system for Southeast Asia’s largest hospital chain). I measured myself on team productivity, growth, and well-being. Here’s what made the biggest impact.

Здесь же мы сосредоточимся на гусыне. Я поделюсь тем, что узнал о том, как растить (наём, обучение) и как вести (инновации, дисциплина, товарищество) команды data science. Это основано на моём опыте в Lazada (где я был одним из первых DS и в итоге возглавил команду) и uCare (где мы запустили ML-систему для крупнейшей сети больниц Юго-Восточной Азии). Я оценивал себя по продуктивности, росту и благополучию команды. Вот что дало наибольший эффект.

This was requested on the topic-poll. Please add your topics and vote! 🙏

Это было запрошено в опросе тем. Пожалуйста, добавляйте свои темы и голосуйте! 🙏

Hiring: The most important thing you can do

Наём: самое важное, что вы можете сделать

Hiring is the most important thing everyone on the team can do to contribute to our success. We should always try to raise the bar by finding people who will improve the talent pool. Here’s how I identify such people:

Наём — самое важное, что каждый в команде может сделать для нашего успеха. Мы всегда должны стараться поднимать планку, находя людей, которые улучшат пул талантов. Вот как я выявляю таких людей:

Что этот человек (потенциально) может делать лучше, чем кто-либо ещё в команде? Чему наша команда может у него научиться? Хотел бы я быть частью проекта, который ведёт этот человек?

This doesn’t mean that we only hire people who have better qualifications or are more senior. Recent grads and juniors contribute infectious energy, a fresh pair of eyes, new ideas, and knowledge of the latest research and technology. Mentoring them is also rewarding for everyone on the team. We don’t need new hires to be better than everyone on the team now, but we should believe that they will surpass us in future.

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

If each of us hires people who are smaller than we are, we shall become a company of dwarfs. But if each of us hires people who are bigger than we are, we shall become a company of giants. — David Ogilvy

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

I had the chance to interview hundreds of candidates and work with those who made it through the process, including people I was against hiring (I wasn’t the final decision maker sometimes). This gave me a rare opportunity to observe a wide spectrum of candidates and follow their journey through several projects. There were three traits most great hires had.

Мне довелось проинтервьюировать сотни кандидатов и работать с теми, кто прошёл отбор, включая людей, против найма которых я был (иногда не я принимал окончательное решение). Это дало мне редкую возможность наблюдать широкий спектр кандидатов и следить за их путём через несколько проектов. У большинства отличных сотрудников были три черты.

First, they are curious. When stakeholders ask them to solve a problem, they’ll ask “Why? How does solving this problem create value?” (This can annoy stakeholders but is correct behavior IMHO). When given access to data, they’ll trace it upstream so they can clean and use it correctly, often building their own data pipelines. They’ll dig into issues that haven’t become full-blown problems yet, bring attention to them, and start solving them.

Во-первых, они любопытны. Когда стейкхолдеры просят их решить проблему, они спрашивают: «Зачем? Как решение этой проблемы создаёт ценность?» (Это может раздражать стейкхолдеров, но, на мой взгляд, это правильное поведение). Получив доступ к данным, они прослеживают их вверх по цепочке, чтобы очистить и использовать их корректно, нередко выстраивая собственные пайплайны данных. Они докапываются до проблем, которые ещё не переросли в полноценные, привлекают к ним внимание и начинают их решать.

They also have grit. A big chunk of our work involves R&D and experimentation. Failure and negative results are to be expected. Having grit (and a touch of optimism) helps them push through the low points.

У них также есть упорство. Большая часть нашей работы связана с R&D и экспериментами. Неудачи и отрицательные результаты следует ожидать. Упорство (и щепотка оптимизма) помогает им проходить через тяжёлые моменты.

Finally, they are humble. They don’t let their egos get in the way and are less prone to the “Not Invented Here” syndrome. They’re stay detached from their assumptions and hypotheses, especially when data and experimentation disagree. They’re also more willing to accept feedback on their designs and work, leading to improved outcomes for the team (also see Crocker’s Law).

Наконец, они скромны. Они не дают своему эго встать на пути и менее подвержены синдрому «придумано не здесь». Они сохраняют отстранённость от собственных предположений и гипотез, особенно когда данные и эксперименты с ними не согласуются. Они также охотнее принимают обратную связь по своим решениям и работе, что улучшает результаты для команды (см. также закон Крокера).

Hire character, train skill. — Peter Schutz

Нанимай за характер, обучай навыкам. — Peter Schutz

Skills-wise, I noticed that great hires could deliver projects mostly end-to-end. Thus, they start, and continue, delivering value faster than most. (Note: This observation is likely biased by my experience in start-ups and scale-ups). And if they lacked the skill or knowledge (e.g., Docker, CI/CD), they were enthusiastic to learn the ropes, helping them be more productive on their next project.

Что касается навыков, я заметил, что отличные сотрудники могли вести проекты преимущественно end-to-end. Поэтому они начинают — и продолжают — приносить ценность быстрее большинства. (Замечу: это наблюдение, вероятно, искажено моим опытом в стартапах и scale-up'ах). А если им не хватало навыка или знаний (например, Docker, CI/CD), они с энтузиазмом осваивали азы, что делало их продуктивнее на следующем проекте.

Here are some heuristics I use to assess the above (caveat emptor):

Вот несколько эвристик, которые я использую для оценки вышеперечисленного (caveat emptor — будьте осторожны):

Масштаб прошлой работы показывает, насколько развиты их навыки end-to-end. Личные проекты говорят о любопытстве учиться в своё свободное время. Аналогично, масштаб демонстрирует их способность работать end-to-end и упорство в доведении дела до конца, особенно если им пришлось чему-то новому учиться (например, деплою на AWS). Способность принимать обратную связь и действовать по ней во время дизайн-/кодинг-интервью может выявить эго (и недостаток скромности). Чрезмерная оборонительная реакция или нежелание рассматривать альтернативы могут быть тревожным сигналом. Занятия спортом на соревновательном уровне (например, марафоны, киберспорт) и наличие устойчивых привычек демонстрируют упорство и, в некоторой степени, надёжность.

One other valuable—but rare—trait is hunger. As I interact and work with some people, I sense that they are hungry to learn, hungry to get shit done, hungry for impact. Such people have a perpetual-motion engine in them and need lesser management. They also deliver disproportionally outsized results relative to the rest of the team.

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

Great companies don’t hire skilled people and motivate them, they hire already motivated people and inspire them. — Simon Sinek

Великие компании не нанимают умелых людей и не мотивируют их — они нанимают уже мотивированных людей и вдохновляют их. — Simon Sinek

However, I think this trait depends on a person’s life stage. I see it mostly in younger folks, especially those just out of school, who have not started families of their own. They’re idealistic and ambitious, and have more time and energy to focus on learning and career. Hunger can also subside with time—a new mum will have less time to learn new tech or tinker on personal projects on the weekends. Thus, I don’t emphasize it when hiring.

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

It’s not easy to assess hunger over interviews. Some candidates appeared dispassionate and quiet during interviews but turned out to be hungry after getting to know them better, and vice versa. If you have a way to assess this, I would love to hear from you.

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

Referrals and meetups/conferences were our best channels for hiring—about 90% of hires came from them. At Lazada, our first data engineer brought in fellow rockstars in the big data space, one of whom eventually became our VP of data engineering. Referrals are a great source of quality candidates as we only tend to refer people we (i) enjoy working with and/or (ii) can learn from, especially if the referral is joining the same team.

Рекомендации и митапы/конференции были нашими лучшими каналами для найма — около 90% сотрудников пришли через них. В Lazada наш первый дата-инженер привёл других звёзд в области больших данных, один из которых в итоге стал нашим VP of data engineering. Рекомендации — отличный источник качественных кандидатов, так как мы обычно рекомендуем только тех, с кем (i) нам приятно работать и/или (ii) у кого можем учиться, особенно если рекомендуемый присоединяется к той же команде.

Hiring via meetups is a hack to cheaply building/scaling a team. I observed this first-hand in Singapore’s meetup scene where companies would speak at meetups to hire. AXA, Twitter, and Uber hosted meetups as they were setting up tech hubs while Go-Jek, HonestBee, Facebook, and Shopee actively shared at meetups to scale their teams. Similarly, Lazada’s sharing at conferences and meetups helped with several great hires.

Наём через митапы — это лайфхак для дешёвого построения/масштабирования команды. Я наблюдал это воочию в сингапурской митап-сцене, где компании выступали на митапах ради найма. AXA, Twitter и Uber проводили митапы, когда открывали техно-хабы, а Go-Jek, HonestBee, Facebook и Shopee активно делились на митапах, чтобы масштабировать свои команды. Точно так же выступления Lazada на конференциях и митапах помогли с несколькими отличными наймами.

Training: Similar to transfer learning

Обучение: похоже на transfer learning

As we hire people who raise the bar, training almost takes care of itself. IMHO, the best way to develop the team is to surround them with superb teammates they can learn from, and give them ambitious problems to work on. For example, as the team collaborates with the newly joined NLP expert, they pick up some of her hard-won NLP tricks and best practices.

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

Nothing we do is more important than hiring and developing people. At the end of the day, you bet on people, not on strategies. — Lawrence Bossidy

Нет ничего важнее того, что мы делаем при найме и развитии людей. В конце концов, ставку делаешь на людей, а не на стратегии. — Lawrence Bossidy

Demos are a great way to promote learning. (If you adopt scrum, demos come as part of the process.) Everyone loves demos. Demo-ers are excited to share their work and get feedback. Attendees love learning more about what everyone else on the team is working on. Demos provide a way for the team to sync, learn from each other, and learn from the questions others may ask.

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

Another favorite practice is paper-lunches (aka lunch-and-learn). Every two weeks, two people share a paper each. Ideally, something they’re excited about and applicable to their work. They focus on understanding the paper thoroughly—this happens as part of project research anyway—and giving a quick walkthrough of it. The rest of the team is expected to read the paper beforehand and come prepared with questions and discussion points. In a year, the team would have discussed 50 papers! (More on why we should read papers.)

Ещё одна любимая практика — paper-lunches (он же lunch-and-learn). Раз в две недели два человека разбирают по одной статье каждый. В идеале — что-то, что их увлекает и применимо к их работе. Они сосредотачиваются на том, чтобы досконально понять статью — это в любом случае происходит в рамках исследования по проекту — и дать по ней быстрый разбор. От остальной команды ожидается, что они прочитают статью заранее и придут подготовленными, с вопросами и темами для обсуждения. За год команда обсудит 50 статей! (Подробнее о том, почему стоит читать статьи.)

A final approach is conducting reviews (e.g, code, design reviews). Reviews are not just a process for seniors to vet design documents and code; it’s also a learning and development opportunity. Reviewing pull requests is a great way for new joiners to ramp up on the codebase and standards. It’s also an avenue to clarify doubts and provide feedback.

Ещё один подход — проведение ревью (например, код-ревью, дизайн-ревью). Ревью — это не просто процесс, в котором сеньоры проверяют дизайн-документы и код; это ещё и возможность для обучения и развития. Ревью pull request'ов — отличный способ для новых сотрудников освоиться с кодовой базой и стандартами. Это также возможность прояснить сомнения и дать обратную связь.

Sitting in design reviews helps team members learn how business stakeholders and senior engineers/scientists think, balance trade-offs, and make decisions. For example, stakeholders focus on business requirements (e.g., bottom-line metrics, user experience) and ROI, while engineers focus on technical requirements (e.g., scalability, latency, failover) and long-term ops costs. Scientists focus on data flows, methodology, experimental results, A/B testing, etc.

Участие в дизайн-ревью помогает членам команды понять, как мыслят бизнес-стейкхолдеры и старшие инженеры/учёные, как они балансируют компромиссы и принимают решения. Например, стейкхолдеры сосредоточены на бизнес-требованиях (например, итоговые метрики, пользовательский опыт) и ROI, инженеры — на технических требованиях (например, масштабируемость, задержка, отказоустойчивость) и долгосрочных операционных расходах. Учёные сосредоточены на потоках данных, методологии, результатах экспериментов, A/B-тестировании и т. д.

By participating in reviews, the team picks up best practices and learns how to balance the concerns of different stakeholders, helping them to improve their future designs and code.

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

Innovation: Encouraging creativity, ideas, and risks

Инновации: поощрение творчества, идей и рисков

As the data science team achieves success and improves metrics, we’ll be expected to continue growing these metrics linearly (or even exponentially). For example, if revenue attributed to our ML systems (e.g., recommendations, push notifications) increased 10% last year, this year’s targets will be the same, if not more. Such demanding expectations can leave little room for riskier, longer-term, projects.

По мере того как команда data science добивается успеха и улучшает метрики, от нас будут ожидать продолжения линейного (или даже экспоненциального) роста этих метрик. Например, если выручка, приписываемая нашим ML-системам (например, рекомендациям, push-уведомлениям), выросла в прошлом году на 10%, цели на этот год будут такими же, если не выше. Такие требовательные ожидания могут не оставлять места для более рискованных, долгосрочных проектов.

I find this akin to the innovator’s dilemma. To keep delivering on increasing targets, we focus on safe, incremental gains. However, past a certain threshold, we hit the point of diminishing returns on the current paradigm (e.g., daily recommendations) and a shift (e.g., real-time recommendations) is necessary. However, such paradigm shifts can be risky, with the payoff in an uncertain future.

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

Nonetheless, such innovation is essential. Without continuous innovation and product improvement, we can get to a point where all we’re left with is a Hail Mary bet at the end.

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

Companies that don’t continue to experiment or embrace failure eventually get in the position where the only thing they can do is make a Hail Mary bet at the end of their corporate existence. — Jeff Bezos

Компании, которые не продолжают экспериментировать или принимать неудачи, в итоге оказываются в положении, когда единственное, что им остаётся, — сделать отчаянную ставку в конце своего корпоративного существования. — Jeff Bezos

In the ‘70s, hard drive producers focused on building hard drives for mainframe producers. These mainframe producers wanted more storage and faster transfer rates and the hard drive incumbents gave it to them.

В 70-х производители жёстких дисков сосредотачивались на выпуске дисков для производителей мейнфреймов. Эти производители мейнфреймов хотели больше объёма и более высокой скорости передачи, и устоявшиеся производители дисков давали им это.

However, some start-ups and smaller companies went in the opposite direction. They started producing hard drives that had lesser storage and slower transfer rates, but were half the size. These drives were mainly for the then-nascent minicomputer market.

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

Back then, minicomputers were a small fraction of the hard drive market and incumbents weren’t interested in serving them (i.e., small portion of overall revenue).

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

However, as we know, mini and personal computers flourished while mainframes declined. As a result, the underdogs who focused on disruptive, initially unpopular, technology (i.e., smaller hard drives) now had a lion’s share of the market.

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

This shows that disruptive tech (smaller computers, smaller drives) can initially underperform and thus not make sense financially. However, they may become fully competitive tomorrow, and not investing in them could be a company’s downfall.

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

One way to foster innovation is by sharing openly about failure. When team members confide their project and A/B testing anxieties, sharing about my flop puts them at ease. I also openly share our team’s failures and negative experiments (if the people involved are 100% okay with it). By doing so, I hope to inculcate the mindset—especially among stakeholders—that experimentation and failure learning are a key part of our work. As my old boss, John used to say: “That’s not a mistake; it’s an opportunity to learn!”

Один из способов взращивать инновации — открыто говорить о неудачах. Когда члены команды делятся своими тревогами по поводу проекта и A/B-тестов, рассказ о моём провале их успокаивает. Я также открыто рассказываю о неудачах нашей команды и неудачных экспериментах (если все причастные на 100% не против). Делая так, я надеюсь привить установку — особенно среди стейкхолдеров, — что эксперименты и обучение на неудачах являются ключевой частью нашей работы. Как любил говорить мой бывший начальник Джон: «Это не ошибка, это возможность чему-то научиться!»

“Failure is an option here. If things are not failing, you’re not innovating enough” — Elon Musk

«Неудача здесь допустима. Если у вас ничего не проваливается, значит, вы недостаточно инновационны» — Elon Musk

I’ve also found it helpful to be an accountability partner and cheerleader on 20% projects. Though 20% projects start with passion, they can get pushed to the back burner to make way for more urgent work, or lose steam due to lack of accountability and visibility. After a year, there’s nothing to show for it—this is unfulfilling for both the people involved and the business.

Я также обнаружил, что полезно быть партнёром по подотчётности и «болельщиком» в 20%-проектах. Хотя 20%-проекты начинаются со страсти, их можно отодвинуть на задний план ради более срочной работы или они теряют запал из-за отсутствия подотчётности и видимости. Через год показать нечего — это разочаровывает и причастных людей, и бизнес.

Thus, when someone proposes a 20% project, I work with them to scope it out and check in now and then, making sure they have the space, time, and resources to work on it. This also signals that the 20% project is as important as regular work, if not more. And if the project is a success, it graduates out of “incubation” and becomes an MVP that we can put in front of customers and get their feedback.

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

Discipline: Bridging ideas and results

Дисциплина: мост между идеями и результатами

With a team of creative, intelligent data scientists, we want to give them the freedom and autonomy to innovate and do great work. I’ve found having a culture of discipline helps.

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

Discipline starts as early as selecting the right problems to solve. The goal of a business is to create value for customers and the organization. Thus, when deciding on projects, we should start from our customers (e.g., Working Backwards) and business needs, or focus on capabilities that will allow us to meet those needs more effectively.

Дисциплина начинается уже на этапе выбора правильных задач для решения. Цель бизнеса — создавать ценность для клиентов и для организации. Поэтому, принимая решение о проектах, мы должны отталкиваться от наших клиентов (например, Working Backwards) и потребностей бизнеса либо фокусироваться на возможностях, которые позволят нам эффективнее эти потребности удовлетворять.

Operationalizing this via a one-pager is helpful. The one-pager defines the intent, desired outcome, deliverables, and constraints. It is then circulated to get alignment with stakeholders before any substantial work starts. Doing this upfront ensures we ask the right questions and solve the right problems, instead of unnecessarily going down rabbit holes or boiling the ocean.

Операционализировать это через one-pager очень полезно. One-pager определяет замысел, желаемый результат, поставляемые артефакты и ограничения. Затем он рассылается, чтобы достичь согласования со стейкхолдерами до того, как начнётся какая-либо существенная работа. Делая это заранее, мы гарантируем, что задаём правильные вопросы и решаем правильные проблемы, вместо того чтобы без необходимости уходить в дебри или пытаться объять необъятное.

Discipline also matters in execution. I view this as executing with a sense of urgency. Basecamp found 6-week cycles to work best for them—it’s long enough to finish something meaningful yet short enough to feel urgent. IMHO, most data science projects should be run like a start-up. We want to ship early and ship often, so we can quickly get feedback from customers, iterate, and improve.

Дисциплина важна и в исполнении. Я рассматриваю это как исполнение с чувством срочности. Basecamp обнаружили, что 6-недельные циклы работают для них лучше всего — они достаточно длинные, чтобы завершить что-то значимое, и достаточно короткие, чтобы ощущать срочность. На мой взгляд, большинство проектов data science стоит вести как стартап. Мы хотим выпускать рано и выпускать часто, чтобы быстро получать обратную связь от клиентов, итерировать и улучшаться.

The number one predictor of success for a very young startup: rate of iteration. — Sam Altman

Главный предсказатель успеха для очень молодого стартапа — скорость итераций. — Sam Altman

This thinking explains my inclination towards scrum and time-boxing for data science. Each sprint delivers milestones that we can bring to stakeholders and/or customers to get their feedback on. We want to be like stochastic gradient descent (i.e., incremental deliverables) rather than batch gradient descent (i.e., Big Bang integration).

Это мышление объясняет мою склонность к scrum и тайм-боксингу в data science. Каждый спринт даёт результаты-вехи, которые мы можем принести стейкхолдерам и/или клиентам, чтобы получить их обратную связь. Мы хотим быть как стохастический градиентный спуск (то есть инкрементальные поставки), а не как пакетный градиентный спуск (то есть Big Bang-интеграция).

We also foster discipline through the standards we uphold (or tolerate). For example, we should have objective standards for linting, type checks, and functional tests. Another way is to actively share examples of great work (e.g., documents, deliverables) that meet and surpass our standards, so we have ideals to aspire towards.

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

While such standards can seem stifling, they provide more freedom in the medium-to-long term. Consistent processes and standards let us focus on the work that matters (instead of constantly reinventing processes or templates). And because everyone adopts the same standards, it’s much easier to understand and provide feedback on projects across the entire team, as well as fluidly move between projects as required.

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

Camaraderie: Gluing the team together

Товарищество: то, что скрепляет команду

One of my biggest contributions while leading teams was to build camaraderie. While at Lazada, together with the VP of data engineering, we would open and close the “bar” every Friday. (We started happy hour so the team could point to us and join in, and stay back to clean up). In my next role, happy hour didn’t work but Counterstrike did. Fragging each other (especially the QA and CTO) on Friday nights was great for team bonding.

Один из моих самых больших вкладов в руководстве командами — выстраивание товарищества. В Lazada мы вместе с VP of data engineering каждую пятницу открывали и закрывали «бар». (Мы запустили happy hour, чтобы команда могла указать на нас и присоединиться, а потом задержаться, чтобы убрать). На следующей работе happy hour не сработал, зато сработал Counterstrike. Фрагать друг друга (особенно QA и CTO) в пятницу вечером было отлично для сплочения команды.

Team bonding helps to build trust. With a high level of trust, there’s no more second-guessing. I know you’re critiquing my work because you objectively think there’s room for improvement, and not because you have something personal against me (i.e., Crocker’s Law). This lets us disagree openly and figure out the best possible outcome. It also saves time and cognitive capacity. There’s no need to read between the lines or try to figure out what someone really meant.

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

A team is not a group of people that work together. A team is a group of people that trust each other. — Simon Sinek

Команда — это не группа людей, которые работают вместе. Команда — это группа людей, которые доверяют друг другу. — Simon Sinek

As trust builds, people share more too. I noticed a team member behaving slightly off and not joining for team lunch as much as she used to, and casually asked if she was alright. She shared that, with 6 months left on her work visa, she had difficulty renewing the lease on her apartment. Most landlords had a minimum lease of 1 year and few wanted to take the risk of renting to her. Knowing this, I worked with HR to renew her visa, indirectly helping her secure an apartment. With that worry off her mind, she could focus on her work better.

По мере того как доверие растёт, люди и делятся большим. Я заметил, что одна сотрудница вела себя чуть иначе и не так часто, как раньше, присоединялась к командным обедам, и невзначай спросил, всё ли у неё в порядке. Она рассказала, что, когда до конца её рабочей визы оставалось 6 месяцев, ей было трудно продлить аренду квартиры. У большинства арендодателей минимальный срок аренды был 1 год, и мало кто хотел брать на себя риск сдавать ей жильё. Узнав об этом, я поработал с HR, чтобы продлить её визу, косвенно помогая ей закрепить квартиру. Сняв эту тревогу, она смогла лучше сосредоточиться на работе.

Having camaraderie also makes work more enjoyable. We’re going to be spending at least 8 hours a day, every weekday, with the team (though less now with WFH)—why not make it fun? Research shows that team camaraderie can translate into measurable outcomes. Gallup found that employees who have a best friend at work were twice as likely to be engaged. They were also less likely to be looking for, or watching for job opportunities, thus helping to improve retention.

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

Conclusion

Заключение

It’s great to have a results-oriented team—they deliver! Nonetheless, do also make sure to take care of the goose, and not just focus on the golden eggs.

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

What other practices did you find useful for building and running effective data science teams? Would love to hear from you @eugeneyan or in the comments below.

Какие ещё практики оказались для вас полезными в построении и управлении эффективными командами data science? С удовольствием услышу от вас @eugeneyan или в комментариях ниже.

How do we grow & run an effective data team?

Here's what I learned about:
• Hiring: The most important thing
• Training: Knowledge transfer
• Innovation: Encouraging creativity
• Discipline: Bridging ideas & results
• Camaraderie: Gluing the team https://t.co/NLZjFjvgg8

Как растить эффективную дата-команду и управлять ею? Вот что я узнал о: • Найме: самое важное • Обучении: передача знаний • Инновациях: поощрение творчества • Дисциплине: мост между идеями и результатами • Товариществе: то, что скрепляет команду https://t.co/NLZjFjvgg8 — Eugene Yan (@eugeneyan) 2 февраля 2021

Thanks to Yang Xinyi for reading drafts of this.

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

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

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

Yan, Ziyou. (Jan 2021). Growing and Running Your Data Science Team. eugeneyan.com. https://eugeneyan.com/writing/data-science-teams/.

Yan, Ziyou. (Jan 2021). Growing and Running Your Data Science Team. eugeneyan.com. https://eugeneyan.com/writing/data-science-teams/.

or

или

@article{yan2021team, title = {Growing and Running Your Data Science Team}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jan}, url = {https://eugeneyan.com/writing/data-science-teams/} }

@article{yan2021team, title = {Growing and Running Your Data Science Team}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Jan}, url = {https://eugeneyan.com/writing/data-science-teams/} }

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

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