Intercom представляет инженерные чаты

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

За прошедшие годы мы многое узнали о наших подкастах. Каждую неделю мы даем вам представление о мире управления продуктами, дизайна, поддержки и маркетинга с помощью Inside Intercom; узнайте, как лидеры отрасли используют CX для развития своего бизнеса с помощью Scale; и показать вам мир соучредителя Intercom Деса Трейнора и старшего вице-президента по продукту Intercom Пола Адамса, поскольку они делятся своими последними мыслями о том, как создавать отличные продукты.

А сейчас нечто соверешнно другое. Впервые мы выпускаем Engineer Chats , внутренний подкаст здесь, в Intercom, обо всем, что связано с инженерией. Ранее его вел Джейми Ослер, старший инженер по продуктам в Intercom на протяжении более семи лет, а теперь главный системный инженер Брайан Сканлан должен принять эстафету и поддерживать чаты.

На этой неделе, помимо Джейми и Брайана, вы также услышите:

• Майк Стюарт, бывший старший инженер Intercom
• Патрик О'Доэрти, бывший старший инженер по безопасности в Intercom, а ныне инженер в Oso.
• Соучредитель Intercom Киаран Ли
• Мина Полич, старший юрисконсульт Intercom, поддерживающая исследования и разработки

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

Если у вас мало времени, вот несколько быстрых выводов:

• Устранение неоднозначности, или процесс сужения широкого спектра решений в каждой проблеме, подходит не только для неоднозначных проектов. Его можно использовать для всего процесса строительства при проектировании и даже управлении продуктом.
• Ядром алгоритмов и систем являются модели данных. Приступая к техническому проектированию системы, убедитесь, что вы всегда понимаете модели данных в первую очередь.
• Автоматизация в инфраструктуре может привести к довольно серьезным ошибкам. И хотя эти проблемы никому не интересны, вы можете использовать их для поиска других «слепых зон» и создания более надежной системы.
• Ваш рабочий ритм по умолчанию должен быть запущен — важно, чтобы стартапы не ставили под угрозу скорость. Если вы можете сделать что-то на этой неделе, а не в следующем квартале, прыгайте.
• Команда юристов не должна замедлять НИОКР. Их приоритетом является обеспечение того, чтобы по мере роста и усложнения компании она продолжала делать это в рамках закона.

Если вам нравится наша дискуссия, посмотрите другие выпуски нашего подкаста. Вы можете подписаться на iTunes, Spotify или получить RSS-канал в выбранном вами плеере. Далее следует слегка отредактированная стенограмма эпизода.

Лайам Герати: Привет и добро пожаловать в Inside Intercom. Я Лиам Джерати. Если вы постоянный слушатель, то знаете, что мы берем интервью у создателей и исполнителей из мира управления продуктами, дизайна, стартапов и маркетинга. У нас также есть два других подкаста — Intercom on Product, в котором соучредитель Intercom Дес Трейнор и старший вице-президент Intercom по продуктам Пол Адамс обсуждают свои последние мысли о том, как создавать успешные продукты в масштабе, и Scale by Intercom, где мы исследуем, как бизнес стимулирование роста через отношения с клиентами.

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

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

Значение неоднозначности полностью вниз

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

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

«У вас есть широкое пространство для решения… это процесс его свертывания на основе доказательств, решений и звонков»

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

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

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

Джейми Ослер: Вы действительно сузили и этот вопрос. Может быть, вы могли бы немного устранить двусмысленность.

Лайам Герати: У Майка отличный способ визуализировать процесс устранения неоднозначности.

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

Методы отличаются, когда вы, скажем, пишете код и выясняете: «Эй, какие у меня понятия в коде и как мне структурировать этот код?» по сравнению с тем, когда вы пытаетесь понять: «Эй, как мне это спроектировать?» и каковы модели данных и движущиеся части по сравнению с решением по сравнению с дорожной картой? Я очень сильно абстрагируюсь, так как это все неоднозначность. Быть очень обдуманным в отношении того, что именно вы атакуете, и на каком уровне масштабирования — это самый важный принцип в моей голове. И именно здесь инженеры могут очень естественно погрузиться в более глубокие уровни масштабирования устранения неоднозначности, выяснения того, как что-то построить, потому что это то, что часто более удобно или легче расколоть орешек.

Быть единым целым с моделями данных

Лайам Герати: Чтобы связать все это с конкретным примером, Джейми приводит этот.

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

Майк Стюарт: Да, конечно. Что касается уровней масштабирования, о которых мы говорили ранее, для меня это правильный уровень масштабирования высокого уровня технического дизайна. Подводя итог, можно сказать, что при выставлении счетов мы были в такой точке: «Эй, мы довольно твердо понимаем, что у нас есть эти две системы. У нас есть собственное приложение Rails и внешняя система Zuora. Мы знаем, что, по крайней мере, в течение приличного промежутка времени у нас будут эти две системы. Мы не собираемся менять это ограничение. У нас многое построено на них двоих, так что отойти невозможно. Нам нужно, чтобы две системы были синхронизированы, и нам нужно, чтобы они согласовывались друг с другом, и все эти проблемы, возникающие из-за того, что мы не можем их согласовать друг с другом, нам нужно, чтобы они исчезли. Мы как бы поняли, что это была миссия.

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

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

Итак, в этой ситуации первое, что мы сделали, когда попали в биллинг, — это поняли наши собственные модели данных. Потому что для нас с тобой, Джейми, приземление там было похоже на дикий запад. Как и большая часть Intercom, мы никогда не видели этого изнутри, это был смелый новый рубеж. Итак, прежде всего, мы должны были понять: «Эй, какого черта все эти таблицы задействованы в нашей собственной системе?» Мы пришли к этому пониманию относительно быстро с помощью предыдущей команды в Сан-Франциско и построили эту ментальную модель.

«Мне никогда не будет комфортно двигаться вперед с техническим дизайном, если я полностью не пойму модели данных»

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

Ваш первоначальный вопрос, чтобы не упустить его из виду, заключается в том, как вы узнаете, когда вам следует это сделать? Для меня это очень просто. Мне никогда не будет комфортно двигаться вперед с техническим дизайном, если я полностью не пойму модели данных. И я расскажу вам об одном месте, где я обжегся из-за того, что не следовал этому принципу в полной мере, позже, когда я пришел в Salesforce, у меня было некоторое понимание основных концепций и моделей данных, что Salesforce — это большой, большой мир. Таким образом, был большой цейтнот. И я не дошел до такой глубины понимания моделей данных, как для Zuora. И я думаю, то же самое было верно для всех в команде. Мы не достигли того же уровня глубины моделей данных. И мы вроде как чувствуем результаты этого в том, что мы построили что-то хорошее, но год спустя, после большего контекста с этими моделями данных, мы поняли: «Эй, мы не поняли их правильно в первый раз. Мы неправильно сопоставили перевод между Salesforce и нашей собственной системой, и нам предстоит еще много работы, чтобы восполнить этот недостаток знаний».

Джейми Ослер: Это очень полезно. Это был отличный разговор о том, как вы устраняете неоднозначность проектов.

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

Джейми Ослер: Содержание хэштега.

Светлая сторона великолепно плохого сбоя

Лайам Джерати: Ранее в этом году, если вы являетесь пользователем Facebook, WhatsApp или Instagram, вы, несомненно, помните тот сбой в октябре. Это был самый продолжительный глобальный сбой Facebook в его истории. Все сводилось к ошибочному изменению конфигурации с их стороны. Так что перебои никому не интересны. Кто-то, кто особенно не любит их, - это главный системный инженер Intercom Брайан Скэнлан.

Брайан Скэнлан: Я ненавижу перебои в работе, поэтому посвятил свою карьеру борьбе с ними.

Лиам Джерати: Брайан сел поговорить с Джейми о них в ноябре 2020 года.

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

Лайам Герати: Брайан вспомнил некоторые заметные перебои в работе Intercom.

«Помню, мне хотелось блевать в мусорное ведро, когда я понял, что Elasticsearch пуст. Я подумал: «О, это так плохо»».

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

Лайам Джерати: Там был Патрик О'Доэрти, старший инженер по безопасности.

Патрик О'Доэрти: Помню, как мне захотелось вырваться в мусорное ведро, когда я понял, что Elasticsearch пуст. Я подумал: «О, это так плохо».

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

Джейми Ослер: Между выпивкой?

Брайан Скэнлан: Нет, на самом деле это было в пути. Я был трезв в то время. Когда эту подсеть попытались добавить в нашу сеть внутри Amazon, автоматизация, которую мы прописали… Мы использовали инструмент под названием Terraform для управления нашей низкоуровневой инфраструктурой внутри AWS, и у нас была куча командных модулей — подумайте о это повторно используемый код, который мы написали, чтобы попытаться упростить инфраструктуру внутри AWS со всеми настройками и прочим, которые мы хотим применить.

«В тот момент, когда конфигурация была применена, она полностью разрушила или отключила нашу сеть»

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

Джейми Ослер: Я имею в виду, это плохо, верно? Это не хорошо.

Брайан Скэнлан: Да. Таким образом, Intercom полностью отключился. А затем потребовалось некоторое время, чтобы добраться до точки, когда мы могли откатиться назад. Под мы я подразумеваю, а не я. В этот момент я наслаждался напитками. Итак, команда нашла способ проникнуть в нашу инфраструктуру инициализации Terraform и вернуться к изменению конфигурации.

«Выяснение того, что произошло и куда делись эти данные, также заняло очень много времени. Здесь речь идет о восьмичасовом отключении».

Но, к сожалению, в то же время включилась другая автоматизация. На этот раз некоторая автоматизация, принадлежащая AWS. Мы используем эту технологию под названием OpsWorks, которая является управляемой версией Chef, для управления хостами Elasticsearch. У него была встроенная функция, называемая автоматическим восстановлением, которую мы включили по умолчанию в нашей конфигурации на уровне хоста. И если хосты были недоступны для серверной части OpsWorks, система рабочего процесса OpsWorks попытается автоматически восстановить рассматриваемый хост, поскольку она решила, что там что-то пошло не так. ОС упала, возможно, не хватило памяти — случилось что-то нехорошее, так что давайте попробуем это исправить. Итак, эта плоскость управления OpsWorks решила исправить всю нашу инфраструктуру, заменив хосты.

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

«Мы не просто сказали: «Ну, теперь мы знаем об этих двух проблемах, давайте исправим их». Мы пошли искать другие области автоматизации, которые могли бы укусить нас в странных ситуациях».

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

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

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

Брайан Сканлан: Я также получил из этого что-то вроде разговора по внутренней связи. Кроме того, я не присутствовал при инциденте, потому что был в пабе на свой день рождения. Это было здорово. Это был идеальный инцидент.

Со скоростью света

Лайам Герати: В декабре 2020 года, в Рождество, которое, я уверен, мы никогда не забудем, соучредитель Intercom Киаран Ли присоединился к Джейми, чтобы поговорить о скорости и о том, почему Киаран заботится о том, чтобы двигаться быстро.

Киаран Ли: Я крайне нетерпеливый человек. Это одно. Если я могу сделать что-то быстро или медленно, лично я предпочел бы сделать это быстро. Intercom может показаться старой компанией, которой уже 10 лет, но я искренне верю, что мы только начинаем. У нас так много дел. Мы такие амбициозные. Мы можем как бы увидеть картину того, чем мы хотели бы быть, этот универсальный инструмент, который каждый, у кого есть интернет-бизнес, может использовать для общения со своими клиентами. И мы только царапаем поверхность там.

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

«Хорошо, если мы достигнем стопроцентной доступности за квартал, но, может быть, нам следует спросить себя: «Эй, разве мы недостаточно рисковали?»

Джейми Ослер: Если для вашей компании критична скорость, а вы делаете это постоянно, вы, как правило, реже ломаетесь.

Киаран Ли: Да. Двигайтесь быстро и ломайте вещи в пределах допустимых параметров. Это нормально иметь отключения. Иметь ошибки — это нормально — очевидно, некоторые категории ошибок вы хотите иметь меньше, чем другие, но у нас есть бюджеты доступности. Круто, если мы достигнем стопроцентной доступности за квартал, но, возможно, нам следует спросить себя: «Эй, разве мы недостаточно рисковали? Можем ли мы пойти на больший риск, чтобы двигаться быстрее?» Вы должны находиться в преднамеренной точке спектра. И, конечно же, на нас лежит большая ответственность. У нас много клиентов, сотни тысяч людей, вошедших в систему, чья работа заключается в использовании нашего почтового ящика, чтобы каждый день общаться со своими клиентами. Мы не можем уподобиться тому, чтобы ломать их вещи, двигаясь слишком быстро или меняя их так быстро, что они даже не знают, как их использовать. Это было бы неправильно. У нас есть ограничения, но в рамках этих ограничений мы должны двигаться как можно быстрее.

Когда приходит закон

Лайам Джерати: И мы движемся так быстро, как только можем, в этом эпизоде. Далее, Интерком, старший юрисконсульт, Мина Полич. Мина входит в нашу юридическую команду и занимается продуктами и инженерными разработками. В январе 2021 года Мина и Джейми обсудили, как юридические и инженерные команды могут работать вместе.

«Мы здесь как бы идем в ногу с компанией и всеми нашими клиентами, чтобы добраться туда, куда нам нужно, ответственно, никого не замедляя»

Мина Полич: Для нас очень важно понять продукт. Как мы можем информировать компанию о том, какие правила будут влиять на нас или какие законы мы должны соблюдать, если мы на самом деле не понимаем, что мы продаем? На самом базовом уровне, со стратегической точки зрения, нам нужно понимать не только то, что мы продаем сейчас, но и то, что мы хотим продавать, и как мы хотим позиционировать себя и расти. Таким образом, мы можем начать строить прогнозы вещей, которые нам понадобятся, чтобы следить с юридической точки зрения. И просто убедиться, что мы здесь как бы шагаем в ногу с компанией и всеми нашими клиентами, чтобы добраться туда, куда нам нужно, ответственно, не замедляя никого. С более тактической точки зрения, понимание ценностей и продукта компании чрезвычайно полезно для ведения переговоров с клиентами и даже поставщиками. Когда я понимаю, что мы пытаемся сделать, это ставит меня в гораздо более выгодное положение. И затем я могу объяснить нашим поставщикам: «Поскольку мы пытаемся сделать это, нам нужно, чтобы вы могли это сделать».

И наоборот, когда я веду переговоры с клиентами, часто люди по другую сторону стола — это другие юристы или агенты по закупкам, которые так же, если не хуже, техничны, чем я. Итак, будучи в состоянии объяснить, что делает продукт, как юрист, который говорит: «Послушайте, я знаю, что вас беспокоит с точки зрения управления юридическими рисками, но вот как на самом деле работает платформа. Вот как продукт работает на практике. И именно поэтому это не предотвратит тот риск, который вас беспокоит. Это не приведет к тому риску, который вас беспокоит».

«Моей первоочередной задачей является помочь R&D понять, что я здесь не для того, чтобы сводить на нет удивительный прогресс, которого мы добиваемся»

Джейми Ослер: Я думаю, это работает в обе стороны, верно? Если R&D лучше разбирается в юридическом обзоре высокого уровня проблемных областей, это помогает им избегать непреднамеренных действий или создания продуктов, которые были бы рискованными или нарушали бы эти законы.

Мина Полич: Да, абсолютно. И это самое важное, что нужно вынести или попытаться сосредоточиться при выстраивании юридических отношений с R&D. Моя первоочередная задача — помочь отделам разработки понять, что я здесь не для того, чтобы сводить на нет удивительный прогресс, которого мы добиваемся, и моя команда здесь не для того, чтобы мешать нам продолжать выходить на рынок с превосходными продуктами. Наша команда здесь, чтобы убедиться, что по мере того, как мы растем и становится все труднее следить за всем, что делает каждый человек в компании, мы продолжаем поступать этично и в рамках закона. И когда мы можем, мы пытаемся управлять этим риском.

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

Лайам Герати: Я благодарю Джейми Ослера, создавшего Engineer Chats , его нового ведущего Брайана Сканлана и всех сегодняшних гостей, которые любезно позволили нам перенести свои внутренние чаты на внешние. Если вам понравилось сегодняшнее шоу, почему бы не оставить нам отзыв или не поблагодарить нас в социальных сетях. Мы любим видеть и слышать, что вы думаете. Это все на сегодня. Мы вернемся на следующей неделе с еще одним выпуском Inside Intercom.