Intercom presenta chats de ingenieros

Le contamos todo acerca de nuestros productos y características y los lanzamientos que nos entusiasman. Ahora, lo llevamos detrás de escena y le presentamos el trabajo de las personas que lo hacen posible.

A lo largo de los años, hemos cubierto mucho terreno en nuestros podcasts. Cada semana, le damos una idea del mundo de la gestión, el diseño, el soporte y el marketing de productos con Inside Intercom; explore cómo los líderes de la industria están utilizando CX para hacer crecer sus negocios con Scale; y mostrarle el mundo del cofundador de Intercom, Des Traynor, y el vicepresidente sénior de productos de Intercom, Paul Adams, mientras comparten sus últimas ideas sobre cómo crear excelentes productos.

Y ahora para algo completamente diferente. Por primera vez, estamos lanzando Engineer Chats , un podcast interno aquí en Intercom sobre todo lo relacionado con la ingeniería. Previamente presentado por Jamie Osler, un ingeniero de producto sénior en Intercom durante más de siete años, ahora le toca al ingeniero principal de sistemas, Brian Scanlan, tomar la batuta y mantener los chats en marcha.

Esta semana, además de Jamie y Brian, también escucharás de:

• Mike Stewart, ex ingeniero principal sénior de Intercom
• Patrick O'Doherty, ex ingeniero de seguridad sénior en Intercom y ahora ingeniero en Oso
• Ciaran Lee, cofundador de Intercom
• Meena Polich, asesora principal de Intercom que respalda la I+D

Desde el proceso de desambiguación y la peor interrupción que hemos tenido hasta nuestra obsesión por la velocidad y cómo los equipos legales y de ingeniería pueden trabajar mejor juntos, Engineer Chats le dará un vistazo detrás del proceso de ingeniería en Intercom.

Si tiene poco tiempo, aquí hay algunos consejos rápidos:

• La desambiguación, o el proceso de reducir un amplio espacio de soluciones en cada problema, no solo es bueno para proyectos ambiguos. Se puede utilizar para todo el proceso de construcción en ingeniería e incluso para la gestión de productos.
• El núcleo de los algoritmos y sistemas son los modelos de datos. Al abordar un diseño técnico para un sistema, asegúrese de comprender siempre primero los modelos de datos.
• La automatización en la infraestructura puede conducir a errores bastante graves. Y aunque estos problemas no son divertidos para nadie, puede usarlos para buscar otros puntos ciegos y construir un sistema más sólido.
• Su cadencia de funcionamiento predeterminada debe ser ejecutarse; es importante que las empresas emergentes no comprometan la velocidad. Si puede hacer algo esta semana en lugar del próximo trimestre, hágalo.
• El equipo legal no está allí para ralentizar la I+D. Su prioridad es asegurarse de que, a medida que la empresa crezca y aumente en complejidad, continúe haciéndolo dentro de los límites de la ley.

Si disfruta de nuestra discusión, vea más episodios de nuestro podcast. Puede seguirlo en iTunes, Spotify o tomar la fuente RSS en su reproductor de elección. Lo que sigue es una transcripción ligeramente editada del episodio.

Liam Geraghty: Hola, y bienvenido a Inside Intercom. Soy Liam Geraghty. Si es un oyente habitual, sabrá que entrevistamos a creadores y hacedores del mundo de la gestión de productos, el diseño, las empresas emergentes y el marketing. También tenemos otros dos podcasts: Intercom on Product, donde el cofundador de Intercom, Des Traynor, y el vicepresidente sénior de productos de Intercom, Paul Adams, analizan sus últimas ideas sobre cómo crear productos exitosos a escala y Scale by Intercom, donde exploramos cómo las empresas están impulsar el crecimiento a través de las relaciones con los clientes.

Un podcast que definitivamente no sabía que hicimos se llama Engineer Chats , y eso se debe a que es un podcast interno en Intercom. Fue presentado por Jamie Osler, un ex ingeniero de producto sénior aquí. En cada episodio, Jamie se sentó a hablar con una variedad de personas diferentes sobre una variedad de temas diferentes relacionados con la ingeniería.

Hoy, le traemos una ventana sónica a todo lo relacionado con la ingeniería en Intercom. Tomamos las mejores partes del programa, desde la historia del peor apagón que hemos tenido hasta cómo los equipos legales y de ingeniería pueden trabajar mejor juntos. En primer lugar, desambiguación: el acto o proceso de distinguir entre cosas y significados similares para hacer que el significado o la interpretación sean más claros o ciertos. Mike Stewart, ex ingeniero principal sénior de Intercom, se sentó a hablar con Jamie en octubre de 2020 sobre esa palabra y por qué la usa tanto en el trabajo. Aquí está Jaime.

Desambiguación hasta el final

Jamie Osler: Algo que te he visto hacer con excelentes resultados al abordar un proyecto que es un poco confuso y no muy bien definido en términos de lo que significa el éxito y la mejor manera de abordarlo es lo que a veces llamas desambiguación. ¿Podrías decirnos a qué te refieres cuando dices eso?

Mike Stewart: Sí. Desambiguando. Esa es una palabra que nunca usé mucho antes de llegar a Intercom, y la he usado mucho desde que llegué aquí. Probablemente debería haberlo usado en lugares anteriores antes, pero es una palabra tan buena. Ni siquiera es solo para proyectos confusos o ambiguos. Casi creo que este es un verbo muy general como parte de todo nuestro proceso de construcción que va mucho más allá de la ingeniería y en muchas cosas que hacen los PM para resolver las cosas.

"Tienes un amplio espacio de soluciones... es el proceso de reducirlo en función de la evidencia, las decisiones y las llamadas"

Si regresa al estado previo al proyecto, obviamente tenemos equipos, tienen áreas de propiedad y descubren hojas de ruta a su alrededor, ¿verdad? El equipo es responsable de toda nuestra área de marketing/participación/salida/superficie, y son dueños de tener éxito dentro de eso. Ese es un problema ambiguo. El proceso de descubrir dónde nos ubicamos dentro de eso y de todas las cosas que podríamos hacer y las formas en que podríamos hacerlas y reducirlo, tal vez no descubrirlo al cien por cien, y cerrar ese espacio de solución para obtener un acuerdo más estricto y una visión más estrecha de, dentro de todas las cosas que podría hacer dentro del espacio de participación, estas son las que creemos que son las más importantes, las que los clientes buscan más, el mayor retorno de las inversiones, ese es un proceso de desambiguación. Tienes un amplio espacio de solución, ambigüedad sobre a dónde debes ir dentro de los muchos lugares diferentes a los que podrías ir dentro de ese espacio de solución, y es el proceso de reducirlo en función de la evidencia, las decisiones y las llamadas.

Cuando reproduzco eso en un proyecto de ingeniería, ocurre lo mismo un par de etapas más adelante en el proceso. Una vez que hemos decidido crear un nuevo mensajero con una plataforma pública donde puede crear aplicaciones e integrarlas en un mensajero, existe todo el espacio de solución de lo que eso significa, todas las diferentes formas que podría tomar, cómo podría manifestarse, y cómo podrías construirlo. Desambiguación hasta llegar al punto en el que la ambigüedad en la que está pensando es: "Sabemos que queremos incrustar un iFrame que tenga una determinada interfaz, los desarrolladores avanzan y retroceden, y luego, ¿cómo ¿realmente implementar eso, diseñarlo con tecnología y escribir los códigos para hacerlo? Esos son los niveles aún más ampliados. Todavía estás trabajando a través de la ambigüedad allí. Entonces, creo que la desambiguación está en todo el proceso de desarrollo del producto.

“Casi pienso en esto como uno de esos videos del universo que va desde hacer zoom hasta la Tierra como un punto en una galaxia y todo el camino a través de la escala humana y la escala micro”

Jamie Osler: Realmente también has reducido eso. Tal vez podrías desambiguar eso un poco.

Liam Geraghty: Mike tiene una gran manera de visualizar el proceso de eliminación de ambigüedades.

Mike Stewart: Sí. Casi pienso en esto como uno de esos videos del universo en diferentes órdenes de magnitud que van desde hacer zoom hasta la Tierra como un punto en una galaxia y hasta la escala humana y la escala micro. Hay una estructura interesante en cada uno de esos niveles y, de la misma manera, creo que hay una ambigüedad interesante en cada uno de los niveles de zoom a medida que las cosas se definen más y más.

Las técnicas son diferentes cuando estás, por ejemplo, escribiendo código y averiguando: "Oye, ¿cuáles son mis conceptos en el código y cómo debo estructurar este código?" versus cuando estás averiguando, "Oye, ¿cómo debo diseñar esto?" y ¿cuáles son los modelos de datos y las partes móviles versus cuál es la solución versus la hoja de ruta? Lo estoy resumiendo mucho ya que todo es desambiguación. Ser muy deliberado sobre qué es lo que estás atacando y en qué nivel de zoom es el principio más importante en mi cabeza. Y es donde los ingenieros pueden verse absorbidos naturalmente por los niveles de zoom más profundos de desambiguación, de descubrir cómo construir algo, porque eso es algo que a menudo es más cómodo o más fácil de romper.

Ser uno con los modelos de datos

Liam Geraghty: Para conectar todo esto con un ejemplo concreto, Jamie presenta este.

Jamie Osler: Cuando observábamos cómo el sistema de facturación enviaba datos a Zuora y cómo intentaba garantizar que el estado estuviera sincronizado entre los dos, teníamos que entender cómo lo hacía el sistema actual para poder obtener ese tipo de desambiguación del sistema actual y desglosarlo en sus ideas y principios centrales y ver cuáles de ellos eran relevantes en el futuro. Como parte de eso, redactó un documento que exploraba cómo funcionaba el modelado de los datos del plan de tarifas de Zuora a lo largo del tiempo. Y creo que eso era algo en lo que mucha gente no habría profundizado a ese nivel. ¿Qué te llevó a pensar que sería algo útil? ¿Y cuándo sabes cuándo hacer esa investigación, cuándo no?

Mike Stewart: Sí, seguro. En términos de los niveles de zoom de los que hablábamos antes, esto, para mí, está justo en ese nivel de zoom de diseño tecnológico de alto nivel. Para recapitular, en la facturación, estábamos en el punto en el que, “Oye, entendemos con bastante firmeza que tenemos estos dos sistemas. Tenemos nuestra propia aplicación Rails y tenemos este sistema Zuora externo. Sabemos que, al menos, durante una buena parte del futuro, vamos a tener estos dos sistemas. No vamos a cambiar esa restricción. Tenemos mucho construido sobre ellos dos, por lo que no es factible mudarse. Necesitamos tener los dos sistemas sincronizados, y necesitamos que estén de acuerdo entre sí, y todos estos problemas que se derivan de que no podemos hacer que estén de acuerdo entre sí, necesitamos que desaparezcan. Entendimos que esa era la misión.

“No se puede idear un algoritmo independiente de un modelo de datos. Y creo que lo mismo es cierto cuando empiezas a hablar de sistemas y características del producto”

Y luego, se trataba de qué solución técnica es la forma de lograr eso. En términos de técnicas, cuando estoy pensando en el diseño tecnológico y este tipo de diseño tecnológico de alto nivel o fase de diseño de sistemas, lo que casi siempre hago es ir a los modelos. Hay mucha superficie que puedes tratar de entender. Hay muchas cosas que son importantes, como, ¿cómo es la estructura de su código, qué se mueve, qué trabajadores tiene y qué intenta hacer qué? Pero los conceptos fundamentales, los conceptos centrales del sistema, son casi siempre los mismos que los modelos de datos en la base de datos real; el esquema de ellos en su base de datos o el esquema público en su tercero, o lo que sea. Son los conceptos centrales en los modelos de datos que están involucrados. Y algún científico informático famoso, no tengo idea de cuál, definitivamente ha expresado el sentimiento de que el núcleo de los algoritmos son los modelos de datos. No se puede idear un algoritmo independiente de un modelo de datos. Y creo que lo mismo es cierto cuando empiezas a hablar de sistemas y características del producto. Los modelos de datos son la base de cualquier diseño.

Entonces, en esta situación, lo primero que hicimos cuando aterrizamos en la facturación fue comprender nuestros propios modelos de datos. Porque para ti y para mí, Jamie, aterrizar allí fue como el salvaje oeste. Como la mayoría de Intercom, nunca habíamos visto el interior de esto, era una nueva y valiente frontera. Entonces, antes que nada, teníamos que entender: "Oye, ¿qué diablos son todas estas tablas involucradas en nuestro propio sistema?" Llegamos a ese entendimiento relativamente rápido con la ayuda del equipo anterior en San Francisco y construimos ese modelo mental.

“Nunca me siento cómodo avanzando con un diseño técnico a menos que comprenda completamente los modelos de datos”

Luego, la siguiente pieza importante que faltaba y que creo que casi llegamos a atacar demasiado tarde fue: "Comprendamos realmente el modelo de datos de Zuora, el sistema en el que estamos investigando". El esfuerzo del que estabas hablando, creo que fue solo una semana más o menos en la que básicamente estaba encendiendo la consola, ingresando manualmente los modelos de datos en Zuora, cambiando algo, ejecutando algunos comandos para ver qué sucedió y explorando una especie de estilo de caja negra para comprender el modelo de datos. Y al final de entender eso, podríamos decir que, “Oye, hay una gran pila de modelos. Los realmente importantes están aquí abajo, justo en la hoja. Son como el plan de tarifas, los segmentos de cargo o algo así, que almacenan las entrañas de los datos”. Y una vez que comprenda correctamente los conceptos básicos y los modelos de datos, puede comenzar a construir, puede comenzar a diseñar un sistema. Y eso es particularmente cierto cuando hablamos de sistemas de replicación como este, cuyo trabajo fundamental es barajar de manera confiable un conjunto de modelos de datos y traducirlo a la cosa semánticamente equivalente en otro conjunto de modelos de datos.

Tu pregunta original, para no perderla de vista, es ¿cómo sabes cuándo debes hacer eso? Para mí, eso es realmente simple. Nunca me siento cómodo avanzando con un diseño técnico a menos que comprenda completamente los modelos de datos. Y les diré un lugar en el que me quemé por no seguir profundamente ese principio fue más tarde, cuando llegué a Salesforce, tenía cierta comprensión de los conceptos básicos y los modelos de datos de que Salesforce era un mundo muy, muy grande. Entonces, había mucha presión de tiempo. Y no fui a la misma profundidad de comprensión de los modelos de datos como lo hice para Zuora. Y creo que lo mismo era cierto para todos en el equipo. No llegamos al mismo nivel de profundidad de los modelos de datos. Y sentimos los resultados de eso en el sentido de que construimos algo bueno, pero un año después, después de más contexto con estos modelos de datos, nos dimos cuenta: “Oye, no los entendimos correctamente la primera vez. No mapeamos correctamente la traducción entre Salesforce y nuestro propio sistema, y ​​tenemos más trabajo por hacer para reparar esa falta de conocimiento”.

Jamie Osler: Eso es muy útil. Esa fue una gran charla sobre la forma en que eliminas la ambigüedad de los proyectos.

Mike Stewart: Espero que haya sido una gran charla, Jamie, y espero que tengamos algún contenido útil aquí.

Jamie Osler: contenido de etiquetas.

El lado positivo de un apagón gloriosamente malo

Liam Geraghty: A principios de este año, si eres usuario de Facebook, WhatsApp o Instagram, sin duda recordarás el apagón de octubre. Fue la interrupción global más larga de Facebook en su historia. Todo se redujo a un cambio de configuración defectuoso de su parte. Entonces, las interrupciones no son divertidas para nadie. Alguien a quien no le gustan especialmente es el ingeniero principal de sistemas de intercomunicación, Brian Scanlan.

Brian Scanlan: Odio las interrupciones, por eso he dedicado mi carrera a combatirlas.

Liam Geraghty: Brian se sentó a conversar con Jamie sobre ellos en noviembre de 2020.

Brian Scanlan: Parte de la razón por la que me gustan las interrupciones, por las que me atraen o por las que dedico mi tiempo es porque hasta ahora ha sido bastante bueno para mi carrera. Y es que decidí interesarme, involucrarme en dirigirlos, pensarlos, ser parte de ellos y darles seguimiento.

Liam Geraghty: Brian recordó algunas interrupciones notables en Intercom.

“Recuerdo querer vomitar en una papelera cuando me di cuenta de que Elasticsearch estaba vacío. Yo estaba como, 'Oh, esto es tan malo'”.

Brian Scanlan: Una de las interrupciones más traumáticas en las que estuve involucrado, aunque en realidad no estuve allí durante la interrupción, fue la gran interrupción de Elasticsearch de enero de 2019.

Liam Geraghty: Alguien que estaba allí era Patrick O'Doherty, un ingeniero de seguridad sénior aquí en ese momento.

Patrick O'Doherty: Recuerdo querer vomitar en una papelera cuando me di cuenta de que Elasticsearch estaba vacío. Yo estaba como, "Oh, esto es tan malo".

Brian Scanlan: Esta fue particularmente espectacular. No estaba allí porque estaba en mi fiesta de cumpleaños número 40 con unos amigos. Era como un viernes por la noche. Y como no tenemos miedo de enviar el código a producción un viernes, aprobé una solicitud de incorporación de cambios agregando una subred a nuestra VPC AWS ese viernes por la noche.

Jamie Osler: ¿Entre copas?

Brian Scanlan: No, en realidad estaba en camino. Yo estaba sobrio en ese momento. Cuando se intentó agregar esa subred a nuestra red dentro de Amazon, la automatización en la que escribimos... Usamos una herramienta llamada Terraform para administrar nuestra infraestructura de bajo nivel dentro de AWS, y teníamos un montón de módulos de equipo, piense en como código reutilizable que escribimos para intentar simplificar un montón de infraestructura dentro de AWS con todas las configuraciones y cosas que queremos aplicar.

“En ese momento, cuando se aplicó la configuración, había destruido por completo o desconectado nuestra red”

Y así, esta automatización tomó muy diligentemente la descripción de la subred que queríamos agregar. Pero en el momento de la aplicación, las API de AWS lo rechazaron porque había una subred de IP superpuesta, o mejor dicho, la subred que se estaba configurando se superponía con una ya existente. Y entonces, en ese momento, el proceso de solicitud de Terraform simplemente se dio por vencido. Se detuvo. Lo cual, en un montón de casos, es algo completamente razonable. Pero desafortunadamente, la forma en que implementamos nuestro módulo Terraform significó que estaba eliminando toda la información sobre las tablas de enrutamiento que existían en una subred y volviéndolas a agregar mientras configuraba todas estas subredes. Entonces, en efecto, eliminó todas las rutas, que es cómo una red sabe cómo llegar a Internet y otras redes, lo cual es bastante importante. Entonces, en ese momento, cuando se aplicó la configuración, había destruido por completo o desconectado nuestra red. Eso es solo el comienzo.

Jamie Osler: Quiero decir, eso es malo, ¿verdad? Eso no es bueno.

Brian Scanlan: Sí. Entonces, eso dejó a Intercom completamente fuera de línea. Y luego, tomó un tiempo llegar al punto en el que pudiéramos retroceder. Por nosotros, quiero decir, no yo. Yo estaba disfrutando de mis bebidas en este momento. Y así, el equipo descubrió una manera de acceder a nuestra infraestructura de aprovisionamiento de Terraform y retroceder al cambio de configuración.

“Descubrir qué pasó y adónde fueron esos datos también tomó mucho, mucho tiempo. Estamos hablando de un apagón de ocho horas aquí”

Pero desafortunadamente, mientras tanto, se activó otra automatización. Esta vez, una automatización que era propiedad de AWS. Usamos esta tecnología llamada OpsWorks, que es una versión administrada de Chef, para administrar nuestros hosts de Elasticsearch. Tenía esta funcionalidad llamada reparación automática incorporada que habíamos habilitado de forma predeterminada en nuestra configuración a nivel de host. Y si el backend de OpsWorks no pudiera contactar a los hosts, el sistema de flujo de trabajo de OpsWorks intentaría reparar automáticamente el host en cuestión porque pensó que algo había salido mal allí. El sistema operativo no funciona, tal vez se quedó sin memoria; algo malo sucedió, así que intentemos solucionarlo. Entonces, este plano de control de OpsWorks decidió reparar toda nuestra infraestructura reemplazando los hosts.

Desafortunadamente, habíamos estado ejecutando Elasticsearch y todavía lo hacemos con lo que se conoce como almacenamiento efímero. Eso es almacenamiento basado en host: no estamos utilizando un sistema mágico basado en la nube que almacena sus datos en un sistema de terceros o desde un sistema fuera del host. Está solo en un host físico. Y si el host físico se destruye, los datos desaparecen. Y así, eso es lo que le sucedió a cada uno de los hosts de Elasticsearch. Cada clúster de Elasticsearch perdió todos los datos, lo cual es bastante malo porque una gran cantidad de Intercom se basa en Elasticsearch. No es el almacén de datos principal. Tendemos a escribir datos en un almacén de datos, como, por ejemplo, DynamoDB para nuestros usuarios, y luego copiamos esos datos en Elasticsearch para realizar búsquedas. Y podemos restaurarlo, pero el proceso de recuperar todos esos datos a través de copias de seguridad y tener que volver a manejar todos los cambios desde nuestras copias de seguridad anteriores tomó mucho, mucho, mucho tiempo. Además, averiguar qué pasó y adónde fueron esos datos también tomó mucho, mucho tiempo. Estamos hablando de un apagón de ocho horas aquí.

“No dijimos simplemente, 'Bueno, ahora que conocemos estos dos problemas, solucionémoslos'. Salimos y buscamos otros tipos de áreas de automatización que pudieran mordernos en situaciones extrañas”

Esto fue un gran problema porque sucedió el viernes por la noche, se necesitó una gran cantidad de personas para que las cosas volvieran a estabilizarse. Sabíamos sobre estos problemas, teníamos que volver a conducir o rellenar nuestros clústeres de Elasticsearch y hacer scratch. No conocíamos algunos de los peligros latentes en nuestra propia automatización y parte de la automatización en AWS.

Eso fue interesante porque, después de esto, no dijimos simplemente: "Bueno, ahora que conocemos estos dos problemas, solucionémoslos". Salimos y buscamos otros tipos de áreas de automatización que pudieran mordernos en situaciones extrañas. Entonces, terminamos haciendo muchas cosas para ser realmente buenos en poder restaurar los clústeres de Elasticsearch desde diferentes estados, poder redireccionar los datos en diferentes momentos a nuestros clústeres de Elasticsearch en caso de que alguna vez nos retrasemos o tengamos situaciones similares de tipo desastre. Y, en general, aprendimos mucho de esta falla gloriosamente mala, y el proceso fue bastante bueno después, lo que aprendimos y cómo difundimos esa información.

Patrick O'Doherty: No puedo recordar quién fue, pero aproximadamente una hora más tarde, alguien me agradeció por causar este incidente porque me dijeron: “Guau, realmente sacudiste muchas cosas del árbol aquí. Esta va a ser una respuesta a incidentes realmente divertida”. Esa era básicamente la esencia de esto. Fue como, “Oh, guau. Estamos desenterrando cosas aquí”. Y fue. Nuestro uso de Terraform y nuestra madurez general sobre cómo usamos las herramientas mientras nos mantenemos conscientes de que las herramientas también pueden dañarnos. Respete las herramientas eléctricas. Al igual que la infraestructura, las herramientas eléctricas son peligrosas. Pueden moverse rápidamente y tomarte por sorpresa, y creo que aprendimos la lección ese día.

Brian Scanlan: También obtuve una charla de Inside Intercom sobre esto. Además, no estuve en el incidente porque estaba en el pub para mi cumpleaños. Fue grandioso. Fue el incidente perfecto.

A la velocidad de la luz

Liam Geraghty: En diciembre de 2020, una Navidad que estoy seguro que nunca olvidaremos, el cofundador de Intercom, Ciaran Lee, se unió a Jamie para hablar sobre la velocidad y por qué a Ciaran le importa moverse rápido.

Ciaran Lee: Soy una persona extremadamente impaciente. eso es una cosa Si puedo hacer algo rápido o lento, personalmente prefiero hacerlo rápido. Intercom puede parecer una empresa antigua que se acerca a los 10 años, pero, sinceramente, creo que apenas estamos comenzando. Tenemos mucho que hacer. Somos tan ambiciosos. Podemos ver una imagen de lo que nos gustaría ser, esta herramienta todo en uno que todos los que tienen un negocio en Internet pueden usar para hablar con sus clientes. Y solo estamos arañando la superficie allí.

Una cosa que realmente me gusta de Stripe, una empresa genial a la que admiro, fue una excelente publicación de blog de Patrick McKenzie donde describió que configuraron su cadencia operativa predeterminada para ejecutarse. De manera predeterminada, se mueven incómodamente rápido, siempre preguntando si podemos hacer las cosas más rápido esta semana en lugar de dentro de seis meses. Y realmente me gusta eso personalmente. Ese tipo de actitud nos ha servido muy bien. Y creo que es algo divertido en lo que pensar siempre. ¿Puedes ir más rápido?

“Es genial si alcanzamos el cien por ciento de disponibilidad en un trimestre, pero tal vez deberíamos preguntarnos: 'Oye, ¿no estamos siendo lo suficientemente arriesgados?'”

Jamie Osler: Si usted hace que ir rápido sea crítico para su empresa, y es algo que hace todo el tiempo, tiende a romper menos.

Ciaran Lee: Sí. Muévete rápido y rompe cosas dentro de parámetros aceptables. Está bien tener apagones. Está bien tener errores; obviamente, ciertas categorías de errores que desea tener menos que otras, pero tenemos presupuestos de disponibilidad. Está bien si alcanzamos el cien por ciento de disponibilidad en una moneda de veinticinco centavos, pero tal vez deberíamos preguntarnos: “Oye, ¿no estamos siendo lo suficientemente arriesgados? ¿Podríamos arriesgarnos un poco más para movernos más rápido? Deberías estar en un punto deliberado en el espectro. Y seguro que tenemos una gran responsabilidad. Tenemos muchos clientes, cientos de miles de personas que inician sesión y cuyo trabajo es usar nuestra bandeja de entrada para hablar con sus clientes todos los días. No podemos ser como romper sus cosas moviéndonos demasiado rápido o cambiándolas tan rápido que ya ni siquiera saben cómo usarlas. Eso estaría mal. Tenemos limitaciones, pero dentro de esas limitaciones, debemos movernos lo más rápido que podamos.

Donde entra lo legal

Liam Geraghty: Y nos estamos moviendo lo más rápido que podemos a través de este episodio. A continuación, Intercom, asesora principal, Meena Polich. Meena forma parte de nuestro equipo legal y se especializa en productos e ingeniería. En enero de 2021, Meena y Jamie discutieron cómo los equipos legales y de ingeniería pueden trabajar juntos.

“Estamos aquí marchando al unísono con la empresa y todos nuestros clientes para llegar a donde necesitamos ir de manera responsable sin ralentizar a nadie”

Meena Polich: Es muy importante para nosotros entender el producto. ¿Cómo podemos asesorar a la empresa sobre qué regulaciones nos afectarán o qué leyes debemos seguir si en realidad no entendemos lo que estamos vendiendo? En un nivel muy básico, desde un punto de vista estratégico, necesitamos entender no solo lo que vendemos ahora, sino también lo que queremos vender y cómo queremos posicionarnos y crecer. De esa manera, podemos comenzar a construir proyecciones de las cosas que vamos a necesitar vigilar desde una perspectiva legal. Y simplemente asegurándonos de que estamos aquí marchando al unísono con la empresa y todos nuestros clientes para llegar a donde necesitamos ir de manera responsable sin retrasar a nadie. Desde un enfoque más táctico, comprender los valores y el producto de la empresa es extremadamente útil para negociar con los clientes e incluso con los proveedores. Me coloca en una posición mucho mejor aprovechada cuando entiendo lo que estamos tratando de hacer. Y luego, puedo explicarles a nuestros proveedores: "Debido a que estamos tratando de hacer esto, necesitamos que puedan hacerlo".

Por el contrario, cuando estoy negociando con los clientes, muchas veces, las personas del otro lado de la mesa son otros abogados o agentes de adquisiciones, que son tan técnicos, si no menos, que yo. Entonces, ser capaz de explicar lo que hace el producto como el abogado que dice: “Mire, sé cuáles son sus preocupaciones desde una perspectiva de gestión de riesgos legales, pero así es como funciona realmente la plataforma. Así es como funciona realmente el producto en la práctica. Y es por eso que no va a alertar sobre este riesgo que le preocupa. No va a desencadenar ese riesgo que te preocupa”.

“Mi primera prioridad es ayudar a I+D a comprender que no estoy aquí para descarrilar el increíble progreso que estamos logrando”

Jamie Osler: Supongo que esto funciona en ambos sentidos, ¿verdad? Si I+D tiene una mejor comprensión del tipo de visión general legal de alto nivel de dónde podrían estar las áreas de preocupación, les ayuda a evitar hacer cosas sin querer o construir productos que serían riesgosos o que violarían esas leyes.

Meena Polich: Sí, absolutamente. Y eso es lo más importante en lo que hay que olvidarse o en lo que hay que tratar de centrarse al construir la relación jurídica con la I+D. Mi primera prioridad es ayudar a I+D a comprender que no estoy aquí para descarrilar el increíble progreso que estamos logrando, y mi equipo no está aquí para impedir que sigamos saliendo al mercado con productos excelentes. Nuestro equipo está aquí para asegurarse de que, a medida que crecemos y se vuelve más difícil estar al tanto de todo lo que hace cada individuo en la empresa, sigamos haciéndolo de manera ética y dentro de los límites de la ley. Y cuando podemos, tratamos de gestionar ese riesgo.

Esa es una de las razones por las que el cumplimiento desde el diseño es tan importante. Si tenemos en cuenta los requisitos de cumplimiento o las expectativas de cumplimiento y diseñamos para ellos, muchas veces, los cambios de diseño que hagamos serán cosas que realmente beneficiarán nuestro resultado final. Puede haber un costo inicial en términos de asignación de recursos, pero a largo plazo, y ni siquiera a muy largo plazo (en muchos casos, dentro de los seis meses a un año de sacar esa característica), veremos un beneficio increíble. en términos de crecimiento de los ingresos y los tipos de clientes potenciales que generamos y la atracción de clientes porque confiarán en nosotros.

Liam Geraghty: Mi agradecimiento a Jamie Osler, quien creó Engineer Chats , su nuevo anfitrión Brian Scanlan, y a todos los invitados hoy que amablemente nos permitieron poner sus chats internos en externos. Si disfrutó del programa de hoy, ¿por qué no nos deja una reseña o nos saluda en las redes sociales? Nos encanta ver y escuchar lo que piensas. Eso es todo por hoy. Volveremos la próxima semana con otro episodio de Inside Intercom.