Intercom apresenta bate-papos de engenheiros

Contamos tudo sobre nossos produtos e recursos e os lançamentos com os quais estamos empolgados. Agora, levamos você aos bastidores e apresentamos o trabalho das pessoas que fazem isso acontecer.

Ao longo dos anos, cobrimos muito terreno em nossos podcasts. Toda semana, damos a você uma visão do mundo de gerenciamento de produtos, design, suporte e marketing com o Inside Intercom; explorar como os líderes do setor estão usando o CX para expandir seus negócios com Escala; e mostrar a você o mundo do cofundador da Intercom, Des Traynor, e do vice-presidente sênior de produtos da Intercom, Paul Adams, enquanto eles compartilham suas últimas ideias sobre como criar ótimos produtos.

E agora para algo completamente diferente. Pela primeira vez, estamos lançando o Engineer Chats , um podcast interno aqui na Intercom sobre todas as coisas de engenharia. Anteriormente hospedado por Jamie Osler, engenheiro de produto sênior da Intercom por mais de sete anos, agora cabe ao engenheiro de sistemas principal Brian Scanlan pegar o bastão e manter as conversas.

Esta semana, além de Jamie e Brian, você também ouvirá:

• Mike Stewart, ex-engenheiro-chefe sênior da Intercom
• Patrick O'Doherty, ex-engenheiro de segurança sênior da Intercom e agora engenheiro da Oso
• Ciaran Lee, cofundador da Intercom
• Meena Polich, Conselheira Sênior da Intercom que apoia P&D

Desde o processo de desambiguação e a pior interrupção que já tivemos até nossa obsessão com a velocidade e como as equipes jurídica e de engenharia podem trabalhar melhor juntas, o Engineer Chats lhe dará uma espiada por trás do processo de engenharia da Intercom.

Se você estiver com pouco tempo, aqui estão algumas dicas rápidas:

• A desambiguação, ou o processo de redução de um amplo espaço de solução em cada problema, não é bom apenas para projetos ambíguos. Ele pode ser usado para todo o processo de construção na engenharia e até mesmo no gerenciamento de produtos.
• O núcleo dos algoritmos e sistemas são os modelos de dados. Ao abordar um projeto técnico para um sistema, certifique-se de sempre entender os modelos de dados primeiro.
• A automação na infraestrutura pode levar a erros graves. E embora esses problemas não sejam divertidos para ninguém, você pode usá-los para procurar outros pontos cegos e construir um sistema mais robusto.
• Sua cadência operacional padrão deve ser executar – é importante que as startups não comprometam a velocidade. Se você pode fazer algo esta semana em vez de no próximo trimestre, pule sobre isso.
• A equipe jurídica não está lá para desacelerar a P&D. Sua prioridade é garantir que, à medida que a empresa cresce e aumenta em complexidade, continue a fazê-lo dentro dos limites da lei.

Se você gosta de nossa discussão, confira mais episódios do nosso podcast. Você pode seguir no iTunes, Spotify ou pegar o feed RSS no player de sua escolha. O que se segue é uma transcrição levemente editada do episódio.

Liam Geraghty: Olá, bem-vindo ao Inside Intercom. Eu sou Liam Geraghty. Se você é um ouvinte regular, saberá que entrevistamos criadores e realizadores dos mundos de gerenciamento de produtos, design, startups e marketing. Também temos dois outros podcasts – Intercom on Product, onde o cofundador da Intercom Des Traynor e o vice-presidente sênior de produto da Intercom, Paul Adams, discutem suas últimas ideias sobre como construir produtos de sucesso em escala e Scale by Intercom – onde exploramos como as empresas estão impulsionar o crescimento por meio do relacionamento com os clientes.

Um podcast que você definitivamente não sabia que fizemos é um chamado Engineer Chats , e isso porque é um podcast interno da Intercom. Foi apresentado por Jamie Osler, ex-engenheiro de produto sênior aqui. Em cada episódio, Jamie sentou-se para conversar com várias pessoas diferentes sobre diversos tópicos relacionados à engenharia.

Hoje, trazemos a você uma janela sônica em todas as coisas de engenharia na Intercom. Pegamos as melhores partes do programa, desde a história da pior interrupção que já tivemos até como as equipes jurídica e de engenharia podem trabalhar melhor juntas. Primeiro, desambiguar: o ato ou processo de distinguir entre coisas e significados semelhantes para tornar o significado ou a interpretação mais claro ou certo. Mike Stewart, ex-engenheiro-chefe sênior da Intercom, sentou-se para conversar com Jamie em outubro de 2020 sobre essa palavra e por que ele a usa tanto no trabalho. Aqui está Jamie.

Desambiguação até o fim

Jamie Osler: Algo que eu vi você fazer com ótimos resultados ao abordar um projeto que é um pouco confuso e não muito bem definido em termos do que significa sucesso e qual a melhor forma de abordá-lo é o que você às vezes chama de desambiguação. Você poderia nos dizer o que você quer dizer quando diz isso?

Mike Stewart: Sim. Desambiguando. Essa é uma palavra que eu nunca usei muito antes de vir para a Intercom, e tenho usado muito desde que cheguei aqui. Eu provavelmente deveria ter usado em lugares anteriores antes, mas é uma palavra tão boa. Não é apenas para projetos confusos ou projetos ambíguos. Eu quase acho que este é um verbo muito geral como parte de todo o nosso processo de construção que vai muito além da engenharia e em muitas coisas que os PMs fazem para descobrir as coisas.

“Você tem um amplo espaço de solução… é o processo de encerrar isso com base em evidências, decisões e ligações”

Se você voltar ao estado de pré-projeto, obviamente temos equipes, eles têm áreas de propriedade e descobrem roteiros em torno deles, certo? A equipe é responsável por toda a nossa área de marketing/engajamento/outbound/superfície, e eles próprios são bem sucedidos nisso. Esse é um problema ambíguo. O processo de descobrir onde estamos dentro disso e de todas as coisas que poderíamos fazer e as maneiras de fazê-las e nos estreitando – talvez não cem por cento descobrindo – e fechando esse espaço de solução para obter uma solução mais apertada e visão mais estreita de, dentro de todas as coisas que você poderia fazer dentro do espaço de engajamento, essas são as que consideramos as mais importantes, as que os clientes mais procuram, o maior retorno sobre os investimentos – isso é um processo de desambiguação. Você tem um amplo espaço de solução, ambiguidade sobre onde você deve ir dentro dos muitos lugares diferentes que você pode ir dentro desse espaço de solução, e é o processo de encerrar isso com base em evidências, decisões e chamadas.

Quando eu toco isso para um projeto de engenharia, há o mesmo tipo de coisa alguns estágios abaixo no pipeline. Uma vez que decidimos construir um novo mensageiro com uma plataforma pública onde você pode construir aplicativos e incorporá-los em um mensageiro, há todo o espaço de solução do que isso significa, todas as formas diferentes que podem assumir, como podem se manifestar, e como você poderia construí-lo. Desambiguação até chegar ao ponto em que a ambiguidade em que você está pensando é como: “Sabemos que queremos incorporar um iFrame que tenha uma determinada interface, os desenvolvedores se movem para frente e para trás e, então, como podemos realmente implementá-lo, projetá-lo com tecnologia e escrever os códigos para fazê-lo?” Esses são os níveis ainda mais ampliados. Você ainda está trabalhando com ambiguidade lá. Então, eu acho que a desambiguação está em todo o processo de desenvolvimento do produto.

“Eu quase penso nisso como um daqueles vídeos do universo que vão desde o zoom até a Terra como um ponto em uma galáxia e até a escala humana e a microescala”

Jamie Osler: Você realmente reduziu isso também. Talvez você possa desambiguar isso um pouco.

Liam Geraghty: Mike tem uma ótima maneira de visualizar o processo de desambiguação.

Mike Stewart: Sim. Eu quase penso nisso como um daqueles vídeos do universo em diferentes ordens de magnitude que vão desde o zoom até a Terra como um ponto em uma galáxia e até a escala humana e a microescala. Há uma estrutura interessante em cada um desses níveis e, da mesma forma, acho que há uma ambiguidade interessante em cada um dos níveis de zoom à medida que as coisas ficam cada vez mais definidas.

As técnicas são diferentes quando você está, digamos, escrevendo código e imaginando: “Ei, quais são meus conceitos em código e como devo estruturar esse código?” versus quando você está pensando: "Ei, como devo projetar isso com tecnologia?" e quais são os modelos de dados e as partes móveis versus qual é a solução versus o roteiro? Estou abstraindo isso muito longe, pois é tudo desambiguação. Ser muito deliberado sobre o que você está atacando e em qual nível de zoom é o princípio mais importante na minha cabeça. E é onde os engenheiros podem naturalmente ser sugados para os níveis de zoom mais profundos de desambiguação, de descobrir como construir algo, porque isso é algo que geralmente é mais confortável ou uma noz mais fácil de quebrar.

Ser um com os modelos de dados

Liam Geraghty: Para conectar tudo isso com um exemplo concreto, Jamie apresenta este.

Jamie Osler: Quando estávamos analisando como o sistema de cobrança enviava dados para o Zuora e como ele tentava garantir que esse estado fosse sincronizado entre os dois, precisávamos entender como o sistema atual fazia isso para que pudéssemos obter esse tipo de desambiguação do sistema atual em vigor e decompô-lo em suas ideias e princípios centrais e ver quais deles eram relevantes no futuro. Como parte disso, você redigiu um documento que explorou como funcionava a modelagem de dados do plano de tarifas do Zuora ao longo do tempo. E acho que isso era algo que muitas pessoas não teriam cavado nesse nível. O que levou você a pensar que seria uma coisa útil a se fazer? E quando você sabe quando fazer essa investigação, quando não?

Mike Stewart: Sim, com certeza. Em termos dos níveis de zoom sobre os quais estávamos falando antes, isso, para mim, está exatamente naquele nível de zoom de design de tecnologia de alto nível. Para recapitular, no faturamento, estávamos no ponto em que: “Ei, entendemos firmemente que temos esses dois sistemas. Temos nosso próprio aplicativo Rails e temos esse sistema Zuora externo. Sabemos que, pelo menos, por uma boa parte do futuro, teremos esses dois sistemas. Não vamos mudar essa restrição. Temos muito construído sobre os dois, então não é viável seguir em frente. Precisamos ter os dois sistemas em sincronia, e precisamos que eles concordem um com o outro, e todos esses problemas que derivam de não conseguirmos que eles concordem um com o outro, precisamos que eles desapareçam. Nós meio que entendemos que essa era a missão.

“Você não pode conceber um algoritmo independente de um modelo de dados. E acho que o mesmo é verdade quando você começa a falar sobre sistemas e recursos de produtos”

E então, foi um caso de qual solução técnica é a maneira de conseguir isso? Em termos de técnicas, quando estou pensando em design de tecnologia e esse tipo de design de tecnologia de alto nível ou fase de design de sistema, o que quase sempre faço é ir para os modelos. Há muita área de superfície que você pode tentar entender. Há muitas coisas que são importantes, como, como está sua estrutura de código, o que está se movendo e quais trabalhadores você tem e o que está tentando fazer o quê? Mas os conceitos fundamentais, os conceitos centrais do sistema, são quase sempre os mesmos que os modelos de dados do banco de dados real; o esquema deles em seu banco de dados ou o esquema público em seu terceiro, ou o que quer que sejam. Eles são os conceitos centrais nos modelos de dados envolvidos. E algum famoso cientista da computação – não tenho ideia de qual – definitivamente expressou o sentimento de que o núcleo dos algoritmos são os modelos de dados. Você não pode conceber um algoritmo independente de um modelo de dados. E acho que o mesmo é verdade quando você começa a falar sobre sistemas e recursos de produtos. Os modelos de dados são a base de qualquer projeto.

Então, nessa situação, a primeira coisa que fizemos quando chegamos ao faturamento foi entender nossos próprios modelos de dados. Porque para você e para mim, Jamie, chegar lá foi como o oeste selvagem. Como a maioria da Intercom, nunca tínhamos visto o interior disso, era uma nova e corajosa fronteira. Então, primeiro de tudo, tivemos que entender: “Ei, o que diabos são todas essas tabelas envolvidas em nosso próprio sistema?” Chegamos a esse entendimento de forma relativamente rápida com a ajuda da equipe anterior em São Francisco e construímos esse modelo mental.

“Nunca me sinto confortável em avançar com um projeto técnico, a menos que entenda completamente os modelos de dados”

Então, a próxima peça importante que estava faltando e que acho que quase atacamos tarde demais foi: “Vamos realmente entender o modelo de dados do Zuora, o sistema em que estamos investigando”. O esforço de que você estava falando, acho que foi apenas uma semana ou mais em que eu estava basicamente ligando o console, cutucando manualmente os modelos de dados no Zuora, alterando algo, executando alguns comandos para ver o que acontecia e explorando uma espécie de do estilo caixa preta para entender o modelo de dados. E ao final de entender isso, poderíamos dizer: “Ei, há essa grande pilha de modelos. Os realmente importantes estão aqui embaixo, bem na folha. Eles são como o plano de tarifas, segmentos de cobrança ou algo assim, que armazenam as entranhas dos dados.” E uma vez que você entenda corretamente os principais conceitos e modelos de dados, então você pode começar a construir, você pode começar a projetar um sistema. E isso é particularmente verdadeiro quando falamos sobre sistemas de replicação como este, cujo trabalho fundamental é embaralhar de forma confiável um conjunto de modelos de dados e traduzi-lo em algo semanticamente equivalente em outro conjunto de modelos de dados.

Sua pergunta original, para não perder de vista, é como você sabe quando deve fazer isso? Para mim, isso é muito simples. Nunca me sinto confortável em avançar com um projeto técnico, a menos que entenda completamente os modelos de dados. E vou contar a você um lugar onde eu fiquei queimado por não seguir profundamente esse princípio foi mais tarde, chegando ao Salesforce, eu tinha alguma compreensão dos principais conceitos e modelos de dados que o Salesforce era um grande, grande mundo. Então, havia muita pressão de tempo. E não cheguei à mesma profundidade de compreensão dos modelos de dados que fiz para Zuora. E acho que o mesmo foi verdade para todos na equipe. Não chegamos ao mesmo nível de profundidade dos modelos de dados. E meio que sentimos os resultados disso, pois construímos algo bom, mas um ano depois, depois de mais contexto com esses modelos de dados, percebemos: “Ei, não os entendemos corretamente da primeira vez. Não mapeamos corretamente a tradução entre o Salesforce e nosso próprio sistema e temos mais trabalho a fazer para reparar essa falta de conhecimento.”

Jamie Osler: Isso é super útil. Foi um ótimo bate-papo sobre a maneira como você desambigua os projetos.

Mike Stewart: Espero que tenha sido um ótimo bate-papo, Jamie, e espero que tenhamos algum conteúdo útil aqui.

Jamie Osler: conteúdo de hashtag.

O lado positivo de uma interrupção gloriosamente ruim

Liam Geraghty: No início deste ano, se você é usuário do Facebook, WhatsApp ou Instagram, sem dúvida se lembrará dessa interrupção em outubro. Foi a maior interrupção global do Facebook em sua história. Tudo se resumia a uma mudança de configuração defeituosa do lado deles. Portanto, interrupções não são divertidas para ninguém. Alguém que particularmente não gosta deles é o engenheiro principal de sistemas da Intercom, Brian Scanlan.

Brian Scanlan: Eu odeio interrupções, e é por isso que dediquei minha carreira a combatê-las.

Liam Geraghty: Brian sentou-se para conversar com Jamie sobre eles em novembro de 2020.

Brian Scanlan: Parte da razão pela qual eu gosto de interrupções, porque sou atraído por elas, ou gasto meu tempo com elas, é porque tem sido muito bom para minha carreira até agora. E isso porque eu decidi me interessar por isso, me envolver em dirigi-los, pensar neles, fazer parte deles e acompanhá-los.

Liam Geraghty: Brian lembrou algumas interrupções notáveis ​​na Intercom.

“Lembro-me de querer vomitar em uma lixeira quando percebi que o Elasticsearch estava vazio. Eu fiquei tipo, 'Oh, isso é tão ruim' ”

Brian Scanlan: Uma das interrupções mais traumáticas com as quais estive envolvido, embora eu não estivesse realmente lá durante a interrupção, foi a grande interrupção do Elasticsearch em janeiro de 2019.

Liam Geraghty: Alguém que estava lá era Patrick O'Doherty, um engenheiro de segurança sênior aqui na época.

Patrick O'Doherty: Lembro-me de querer vomitar em uma lixeira quando percebi que o Elasticsearch estava vazio. Eu fiquei tipo, “Oh, isso é tão ruim.”

Brian Scanlan: Este foi particularmente espetacular. Eu não estava lá porque estava no meu aniversário de 40 anos bebendo com alguns amigos. Era como uma noite de sexta-feira. E como não temos medo de enviar código para produção em uma sexta-feira, aprovei uma solicitação de pull adicionando uma sub-rede à nossa VPC AWS naquela noite de sexta-feira.

Jamie Osler: Entre as bebidas?

Brian Scanlan: Não, na verdade estava a caminho. Eu estava sóbrio na época. Quando essa sub-rede tentou ser adicionada à nossa rede dentro da Amazon, a automação em que escrevemos… Usamos uma ferramenta chamada Terraform para gerenciar nossa infraestrutura de baixo nível dentro da AWS e tínhamos vários módulos de equipe – pense em como código reutilizável que escrevemos para tentar simplificar um monte de infraestrutura dentro da AWS com todas as configurações e coisas que queremos aplicar.

“Naquele momento, quando a configuração foi aplicada, ela destruiu completamente ou deixou nossa rede offline”

E assim, essa automação levou muito diligentemente a descrição da sub-rede que queríamos que fosse adicionada. Mas no momento da aplicação, as APIs da AWS o rejeitaram porque havia uma sub-rede IP sobreposta, ou melhor, a sub-rede que estava sendo configurada se sobrepunha a uma já existente. E então, nesse ponto, o processo de inscrição do Terraform meio que desistiu. Parou. O que, em muitos casos, é uma coisa completamente razoável de se fazer. Mas, infelizmente, a maneira como implementamos nosso módulo Terraform significava que ele estava removendo todas as informações sobre as tabelas de roteamento que existiam em uma sub-rede e adicionando-as novamente enquanto configurava todas essas sub-redes. Então, na verdade, ele removeu todas as rotas, que são como uma rede sabe como acessar a Internet e outras redes, o que é muito importante. Então, naquele momento, quando a configuração foi aplicada, ela destruiu completamente ou deixou nossa rede offline. Isso é apenas o começo.

Jamie Osler: Quero dizer, isso é ruim, certo? Isso não é bom.

Brian Scanlan: Sim. Então, isso deixou a Intercom totalmente offline. E então, demorou um pouco para chegar ao ponto em que poderíamos reverter. Por nós, quero dizer, não eu. Eu estava apreciando minhas bebidas neste momento. E assim, a equipe descobriu uma maneira de entrar em nossa infraestrutura de provisionamento do Terraform e reverter para a mudança de configuração.

“Descobrir o que aconteceu e para onde esses dados foram também levou muito, muito tempo. Estamos falando de uma interrupção de oito horas aqui”

Mas, infelizmente, nesse meio tempo, outra automação entrou em ação. Desta vez, alguma automação que era de propriedade da AWS. Usamos essa tecnologia chamada OpsWorks, que é uma versão gerenciada do Chef, para gerenciar nossos hosts Elasticsearch. Ele tinha essa funcionalidade chamada auto-recuperação embutida que havíamos habilitado por padrão em nossa configuração de nível de host. E se os hosts não pudessem ser contatados pelo back-end do OpsWorks, o sistema de fluxo de trabalho do OpsWorks tentaria auto-curar o host em questão porque achava que algo havia dado errado lá. O sistema operacional está inativo, talvez tenha ficado sem memória – algo ruim aconteceu, então vamos tentar consertá-lo. Então, esse plano de controle do OpsWorks decidiu consertar toda a nossa infraestrutura substituindo os hosts.

Infelizmente, estávamos executando o Elasticsearch e ainda fazemos com o que é conhecido como armazenamento efêmero. Isso é armazenamento baseado em host – não estamos usando um sistema mágico baseado em nuvem que armazena seus dados em algum sistema de terceiros ou de um sistema fora do host. É apenas em um host físico. E se o host físico for destruído, os dados desaparecerão. E foi isso que aconteceu com cada host do Elasticsearch. Cada cluster do Elasticsearch perdeu todos os dados, o que é muito ruim porque grandes quantidades de Intercom são construídas sobre o Elasticsearch. Não é o armazenamento de dados primário. Costumamos gravar dados em um armazenamento de dados, como, digamos, DynamoDB para nossos usuários e, em seguida, copiar esses dados para o Elasticsearch para pesquisa. E podemos restaurá-lo, mas o processo de recuperar todos esses dados por meio de backups e ter que refazer todas as alterações desde nossos backups anteriores levou muito, muito, muito tempo. Além disso, descobrir o que aconteceu na Terra e para onde esses dados foram também levou muito, muito tempo. Estamos falando de uma interrupção de oito horas aqui.

“Nós não apenas dissemos, 'Bem, agora que sabemos sobre esses dois problemas, vamos corrigi-los.' Partimos e procuramos outros tipos de áreas de automação que pudessem nos morder em situações bizarras”

Isso foi um grande negócio porque aconteceu na noite de sexta-feira, levou um grande número de pessoas para que as coisas ficassem estáveis. Nós meio que sabíamos sobre esses problemas, tendo que refazer ou recarregar nossos clusters do Elasticsearch e zerar. Não sabíamos sobre alguns dos perigos latentes em nossa própria automação e em parte da automação na AWS.

Isso foi interessante porque, seguindo isso, não apenas dissemos: “Bem, agora que sabemos sobre esses dois problemas, vamos corrigi-los”. Partimos e procuramos outros tipos de áreas de automação que pudessem nos morder em situações bizarras. Então, acabamos fazendo muitas coisas para sermos realmente bons em poder restaurar clusters do Elasticsearch de diferentes estados, podendo redirecionar dados em momentos diferentes para nossos clusters do Elasticsearch, caso ficássemos para trás ou tivéssemos situações semelhantes do tipo desastre. E, você sabe, no geral, aprendemos muito com essa interrupção gloriosamente ruim, e o processo foi realmente muito bom depois, o que aprendemos e como disseminamos essas informações.

Patrick O'Doherty: Não consigo lembrar quem era, mas cerca de uma hora depois, alguém me agradeceu por causar esse incidente porque eles disseram: “Uau, você realmente sacudiu um monte de coisas da árvore aqui. Esta será uma resposta a incidentes muito divertida”. Essa era basicamente a essência da coisa. Era como, “Oh, uau. Estamos desenterrando coisas aqui.” E foi. Nosso uso do Terraform e nossa maturidade geral em relação à forma como usamos as ferramentas, mantendo-nos conscientes de que as ferramentas também podem nos prejudicar. Respeite as ferramentas elétricas. Assim como a infraestrutura, as ferramentas elétricas são perigosas. Eles podem se mover rapidamente e pegar você de surpresa, e acho que aprendemos nossa lição naquele dia.

Brian Scanlan: Eu também tive uma conversa de Inside Intercom com isso. Além disso, eu não estava no incidente porque estava no pub no meu aniversário. Foi ótimo. Foi o incidente perfeito.

Na velocidade da luz

Liam Geraghty: Em dezembro de 2020, um Natal que tenho certeza que nunca esqueceremos, o cofundador da Intercom, Ciaran Lee, juntou-se a Jamie para falar sobre velocidade e por que Ciaran se preocupa em se mover rápido.

Ciaran Lee: Sou uma pessoa extremamente impaciente. Isso é uma coisa. Se eu posso fazer algo rápido ou devagar, eu pessoalmente prefiro fazê-lo rapidamente. A Intercom pode parecer uma empresa antiga com 10 anos, mas sinceramente acredito que estamos apenas começando. Temos muito o que fazer. Somos tão ambiciosos. Podemos ver uma imagem do que gostaríamos de ser, essa ferramenta tudo-em-um que todos com um negócio na Internet podem usar para conversar com seus clientes. E estamos apenas arranhando a superfície.

Uma coisa que eu realmente gosto da Stripe, uma empresa legal que eu admiro, foi uma ótima postagem no blog de Patrick McKenzie, onde ele descreveu que eles definiram sua cadência operacional padrão para ser executada. Eles se movem desconfortavelmente rápido, sempre perguntando se podemos fazer a coisa mais rápido esta semana em vez de seis meses a partir de agora. E eu realmente gosto disso pessoalmente. Esse tipo de atitude nos serviu muito bem. E eu acho que é uma coisa divertida de se pensar sempre. Você pode ir mais rápido?

“É legal se atingirmos cem por cento de disponibilidade em um trimestre, mas talvez devêssemos nos perguntar: 'Ei, não estamos sendo arriscados o suficiente?'”

Jamie Osler: Se você faz com que ir rápido seja crítico para sua empresa, e é algo que você faz o tempo todo, você tende a quebrar menos.

Ciaran Lee: Sim. Mova-se rápido e quebre as coisas dentro de parâmetros aceitáveis. Não há problema em ter interrupções. Não há problema em ter bugs – obviamente, certas categorias de bugs você quer ter menos do que outras, mas temos orçamentos de disponibilidade. É legal se atingirmos cem por cento de disponibilidade em um trimestre, mas talvez devêssemos nos perguntar: “Ei, não estamos sendo arriscados o suficiente? Poderíamos correr um pouco mais de risco para nos movermos mais rápido?” Você deve estar em um ponto deliberado do espectro. E, com certeza, temos uma grande responsabilidade. Temos muitos clientes, centenas de milhares de pessoas fazendo login cujo trabalho é usar nossa caixa de entrada para conversar com seus clientes todos os dias. Não podemos ser como quebrar suas coisas movendo-se rápido demais ou mudando tão rapidamente que eles nem sabem mais como usá-lo. Isso seria errado. Temos restrições, mas dentro dessas restrições, devemos absolutamente nos mover o mais rápido que pudermos.

Onde entra o jurídico

Liam Geraghty: E estamos nos movendo o mais rápido que podemos neste episódio. Em seguida, Intercom, Advogado Sênior, Meena Polich. Meena está em nossa equipe jurídica com foco em produto e engenharia. Em janeiro de 2021, Meena e Jamie discutiram como as equipes jurídicas e de engenharia podem trabalhar juntas.

“Estamos aqui marchando em sincronia com a empresa e todos os nossos clientes para chegar onde precisamos ir com responsabilidade, sem diminuir a velocidade de ninguém”

Meena Polich: É muito importante para nós entendermos o produto. Como podemos aconselhar a empresa sobre quais regulamentações nos afetarão ou quais leis devemos seguir se não entendermos realmente o que estamos vendendo? Em um nível muito básico, do ponto de vista estratégico, precisamos entender não apenas o que vendemos agora, mas o que queremos vender e como queremos nos posicionar e crescer. Dessa forma, podemos começar a construir projeções das coisas que precisaremos ficar de olho do ponto de vista legal. E apenas nos certificando de que estamos aqui marchando em sincronia com a empresa e todos os nossos clientes para chegar onde precisamos ir com responsabilidade, sem diminuir a velocidade de ninguém. A partir de uma abordagem mais tática, entender os valores da empresa e do produto é extremamente útil para negociar com clientes e até mesmo fornecedores. Isso me coloca em uma posição muito melhor alavancada quando entendo o que estamos tentando fazer. E então, posso explicar aos nossos fornecedores: “Como estamos tentando fazer isso, precisamos que você seja capaz de fazer isso”.

Por outro lado, quando estou negociando com clientes, muitas vezes, as pessoas do outro lado da mesa são outros advogados ou agentes de compras, que são tão técnicos, se não menos, do que eu. E assim, ser capaz de explicar o que o produto faz como o advogado que está dizendo: “Olha, eu sei quais são suas preocupações de uma perspectiva de gerenciamento de risco legal, mas aqui está como a plataforma realmente funciona. Veja como o produto realmente funciona na prática. E é por isso que não vai denunciar esse risco que o preocupa. Não vai desencadear esse risco com o qual você está preocupado.”

“Minha primeira prioridade é ajudar a P&D a entender que não estou aqui para atrapalhar o incrível progresso que estamos fazendo”

Jamie Osler: Acho que isso funciona nos dois sentidos, certo? Se a P&D tiver uma melhor compreensão do tipo de visão geral legal de alto nível de onde as áreas de preocupação podem estar, isso os ajuda a evitar fazer coisas involuntariamente ou construir produtos que seriam arriscados ou violariam essas leis.

Meena Polich: Sim, com certeza. E essa é a coisa mais importante a se tirar ou tentar focar ao construir a relação jurídica com P&D. Minha primeira prioridade é ajudar a P&D a entender que não estou aqui para atrapalhar o incrível progresso que estamos fazendo, e minha equipe não está aqui para nos impedir de continuar indo ao mercado com produtos excelentes. Nossa equipe está aqui para garantir que, à medida que crescemos e fica mais difícil acompanhar tudo o que cada indivíduo da empresa está fazendo, continuemos a fazê-lo de forma ética e dentro dos limites da lei. E quando podemos, tentamos gerenciar esse risco.

Essa é uma das razões pelas quais a conformidade desde o projeto é tão importante. Se tivermos em mente os requisitos de conformidade ou as expectativas de conformidade e projetarmos para isso, muitas vezes, as alterações de design que fizermos serão coisas que realmente beneficiarão nossos resultados. Pode haver um custo inicial em termos de alocação de recursos, mas no longo prazo, e nem mesmo no super longo prazo – em muitos casos, dentro de seis meses a um ano de lançar esse recurso – veremos um benefício incrível em termos de crescimento de receita e dos tipos de leads que geramos e atração de clientes porque eles vão confiar em nós.

Liam Geraghty: Meus agradecimentos a Jamie Osler, que criou o Engineer Chats , seu novo apresentador Brian Scanlan, e a todos os convidados de hoje que gentilmente nos permitiram colocar seus chats internos externos. Se você gostou do programa de hoje, por que não nos deixar um comentário ou nos dar um alô nas redes sociais. Adoramos ver e ouvir o que você pensa. Isso é tudo por hoje. Estaremos de volta na próxima semana com mais um episódio do Inside Intercom.