Intercom prezintă chat-uri pentru ingineri

V-am spus totul despre produsele și caracteristicile noastre și despre lansările de care suntem încântați. Acum, vă ducem în culise și vă prezentăm munca oamenilor care o fac să se întâmple.

De-a lungul anilor, am acoperit mult teren pe podcasturile noastre. În fiecare săptămână, vă oferim o perspectivă asupra lumii managementului produselor, designului, asistenței și marketingului cu Inside Intercom; explorați modul în care liderii industriei folosesc CX pentru a-și dezvolta afacerile cu Scale; și vă arată lumea co-fondatorului Intercom Des Traynor și SVP Intercom al Produsului, Paul Adams, în timp ce își împărtășesc cele mai recente gânduri despre cum să construiască produse grozave.

Și acum pentru ceva complet diferit. Pentru prima dată, lansăm Engineer Chats , un podcast intern aici la Intercom despre toate aspectele legate de inginerie. Găzduit anterior de Jamie Osler, un inginer senior de produs la Intercom de peste șapte ani, acum îi revine inginerului principal de sisteme Brian Scanlan să ia ștafeta și să mențină discuțiile.

Săptămâna aceasta, pe lângă Jamie și Brian, veți mai auzi de la:

• Mike Stewart, fost inginer principal principal la Intercom
• Patrick O'Doherty, fost inginer senior de securitate la Intercom și acum inginer la Oso
• Co-fondatorul Intercom Ciaran Lee
• Meena Polich, consilier principal al Intercom, care sprijină cercetarea și dezvoltarea

De la procesul de dezambiguizare și cea mai gravă întrerupere pe care am avut-o vreodată până la obsesia noastră pentru viteză și modul în care echipele juridice și de inginerie pot lucra mai bine împreună, Engineer Chats vă va oferi o privire în spatele procesului de inginerie la Intercom.

Dacă ai puțin timp, iată câteva idei rapide:

• Dezambiguizarea, sau procesul de restrângere a unui spațiu larg de soluții în fiecare problemă, nu este bună doar pentru proiectele ambigue. Poate fi folosit pentru întregul proces de construcție la inginerie și chiar la managementul produsului.
• Miezul algoritmilor și sistemelor sunt modelele de date. Când abordați un proiect tehnic pentru un sistem, asigurați-vă că înțelegeți întotdeauna mai întâi modelele de date.
• Automatizarea infrastructurii poate duce la gafe destul de grave. Și, în timp ce aceste probleme nu sunt distractive pentru nimeni, le puteți folosi pentru a căuta alte puncte moarte și pentru a construi un sistem mai robust.
• Cadența dvs. de operare implicită ar trebui să fie cea de a rula – este important ca startup-urile să nu compromită viteza. Dacă poți face ceva săptămâna aceasta în loc de trimestrul următor, sări peste el.
• Echipa juridică nu este acolo pentru a încetini cercetarea și dezvoltarea. Prioritatea lor este să se asigure că, pe măsură ce compania crește și crește în complexitate, continuă să facă acest lucru în limitele legii.

Dacă îți place discuția noastră, vezi mai multe episoade din podcastul nostru. Puteți urmări pe iTunes, Spotify sau puteți prelua fluxul RSS în playerul dorit. Ceea ce urmează este o transcriere ușor editată a episodului.

Liam Geraghty: Bună, și bun venit la Inside Intercom. Sunt Liam Geraghty. Dacă sunteți un ascultător obișnuit, veți ști că intervievăm creatori și realizatori din lumea managementului de produs, design, startup-uri și marketing. Avem, de asemenea, alte două podcasturi – Intercom on Product, în care co-fondatorul Intercom Des Traynor și SVP Intercom al Produsului, Paul Adams, discută despre cele mai recente idei despre cum să construiască produse de succes la scară și Scale by Intercom – unde explorăm modul în care sunt afacerile. stimularea creșterii prin relațiile cu clienții.

Un podcast pe care cu siguranță nu știai că l-am făcut este unul numit Engineer Chats și asta pentru că este un podcast intern la Intercom. Acesta a fost găzduit de Jamie Osler, un fost inginer senior de produs aici. În fiecare episod, Jamie s-a așezat să discute cu o varietate de oameni diferiți pe o varietate de subiecte diferite legate de inginerie.

Astăzi, vă oferim o fereastră sonoră în toate aspectele legate de inginerie la Intercom. Am luat cele mai bune fragmente din serial, din povestea celei mai grave întreruperi pe care am avut-o vreodată până la modul în care echipele juridice și de inginerie pot lucra mai bine împreună. În primul rând, dezambiguizarea: actul sau procesul de distincție între lucruri și semnificații similare pentru a face sensul sau interpretarea mai clară sau sigură. Mike Stewart, fostul inginer principal principal la Intercom, s-a așezat să discute cu Jamie în octombrie 2020 despre acel cuvânt și de ce îl folosește atât de mult la serviciu. Iată-l pe Jamie.

Dezambiguizare până la capăt

Jamie Osler: Ceea ce te-am văzut făcând cu rezultate grozave atunci când abordezi un proiect care este puțin lanos și nu foarte bine definit în ceea ce privește ceea ce înseamnă succesul și cum să-l abordezi cel mai bine, este ceea ce uneori numiți dezambiguator. Ne poți spune ce vrei să spui când spui asta?

Mike Stewart: Da. Dezambiguizarea. Este un cuvânt pe care nu l-am folosit niciodată prea mult înainte de a veni la Intercom și l-am folosit atât de mult de când am ajuns aici. Probabil că ar fi trebuit să-l folosesc în locuri anterioare, dar este un cuvânt atât de bun. Nu este nici măcar pentru proiecte lânoase sau proiecte ambigue. Aproape că cred că acesta este un verb foarte general, ca parte a întregului nostru proces de construcție, care trece cu mult dincolo de inginerie și în multe lucruri pe care PM-urile le fac pentru a înțelege lucrurile.

„Aveți un spațiu larg de soluții... este procesul de lichidare bazat pe dovezi și decizii și apeluri”

Dacă te întorci direct la starea anterioară proiectului, evident că avem echipe, au zone de proprietate și își dau seama de foi de parcurs în jurul lor, nu? Echipa este responsabilă pentru întreaga noastră zonă de marketing / implicare / ieșire / suprafață și ei dețin succesul în aceasta. Aceasta este o problemă ambiguă. Procesul de a ne da seama unde ne așezăm în acel și a tuturor lucrurilor pe care le-am putea face și a modalităților în care le-am putea face și de a ne restrânge – poate nu ne dăm seama sută la sută – și de a închide acel spațiu de soluții pentru a deveni mai strâns și Vedere mai precisă a tuturor lucrurilor pe care le puteți face în spațiul de implicare, acestea sunt cele pe care noi credem că sunt cele mai importante, cele pe care clienții le caută cel mai mult, cea mai mare rentabilitate a investițiilor – acesta este un proces de dezambiguizare. Aveți un spațiu larg de soluții, ambiguitate cu privire la unde ar trebui să mergeți în multe locuri diferite în care ați putea merge în acel spațiu de soluții și este procesul de lichidare bazat pe dovezi și decizii și apeluri.

Când joc asta într-un proiect de inginerie, există același fel de lucruri la câteva etape mai jos. Odată ce am decis să construim un nou messenger cu o platformă publică în care puteți construi aplicații și le puteți încorpora într-un messenger, există întregul spațiu de soluții a ceea ce înseamnă asta, toate formele diferite care ar putea lua, cum s-ar putea manifesta, și cum ai putea să-l construiești. Dezambiguizarea până la capăt până ajungeți la punctul în care ambiguitatea la care vă gândiți este de genul „Știm că vrem să încorporam un iFrame care are o anumită interfață, dezvoltatorii se mișcă înainte și înapoi și apoi, cum facem de fapt implementați asta, proiectați-l tehnic și scrieți codurile pentru a face asta?” Acestea sunt nivelurile și mai marite. Încă lucrezi la ambiguitate acolo. Deci, cred că dezambiguizarea este la întregul proces de dezvoltare a produsului.

„Aproape că mă gândesc la acesta ca la unul dintre acele videoclipuri ale universului care trece de la zoom până la pământ ca punct într-o galaxie și până la scara umană și scara micro”.

Jamie Osler: Chiar ai restrâns și asta. Poate ai putea dezambiguiza asta puțin.

Liam Geraghty: Mike are un mod excelent de a vizualiza procesul de dezambiguizare.

Mike Stewart: Da. Aproape că mă gândesc la acesta ca la unul dintre acele videoclipuri ale universului la diferite ordine de mărime, care merge de la zoom până la pământ ca punct într-o galaxie și până la scara umană și scara micro. Există o structură interesantă la fiecare dintre aceste niveluri și, în același mod, cred că există o ambiguitate interesantă la fiecare dintre nivelurile de zoom pe măsură ce lucrurile devin din ce în ce mai definite.

Tehnicile sunt diferite atunci când, să zicem, scrieți cod și vă dați seama: „Hei, care sunt conceptele mele în cod și cum ar trebui să structurez acest cod?” față de când îți dai seama: „Hei, cum ar trebui să proiectez asta?” și care sunt modelele de date și părțile mobile față de care este soluția față de foaia de parcurs? O retrag foarte departe, deoarece totul este dezambiguizare. A fi foarte deliberat cu privire la ceea ce ataci și la ce nivel de zoom este cel mai important principiu din capul meu. Și aici inginerii pot fi absorbiți în mod foarte natural de nivelurile de zoom mai profunde ale dezambiguerii, de a-și da seama cum să construiască ceva, pentru că acesta este ceva care este adesea mai confortabil sau mai ușor de spart.

Fiind una cu modelele de date

Liam Geraghty: Pentru a conecta toate acestea cu un exemplu concret, Jamie îl prezintă pe acesta.

Jamie Osler: Când ne-am uitat la modul în care sistemul de facturare trimitea date către Zuora și cum a încercat să se asigure că starea este sincronizată între cele două, a trebuit să înțelegem cum a procedat sistemul actual pentru a putea obține acest tip de dezambiguizarea sistemului actual în vigoare și defalcarea lui la ideile și principiile sale de bază și a vedea care dintre acestea au fost relevante în viitor. Ca parte a acestuia, ați scris un document care a explorat modul în care a funcționat modelarea Zuora a datelor planului de tarife de-a lungul timpului. Și cred că a fost ceva în care mulți oameni nu ar fi săpat la acel nivel. Ce te-a determinat să crezi că ar fi un lucru util de făcut? Și când știi când să faci acea investigație, când nu?

Mike Stewart: Da, cu siguranță. În ceea ce privește nivelurile de zoom despre care vorbeam înainte, acesta, pentru mine, este exact în acel nivel de zoom de înalt nivel de design tehnologic. Pentru a recapitula, în facturare, ne-am ajuns la punctul în care: „Hei, înțelegem destul de ferm că avem aceste două sisteme. Avem propria noastră aplicație Rails și avem acest sistem extern Zuora. Știm că, cel puțin, pentru o bucată decentă din viitor, vom avea aceste două sisteme. Nu vom schimba această constrângere. Avem multe construite pe cei doi, așa că nu este fezabil să plecăm. Trebuie să avem cele două sisteme sincronizate și trebuie să le punem de acord unul cu celălalt, iar toate aceste probleme care decurg din faptul că nu putem să le punem de acord unul cu celălalt, avem nevoie ca acestea să dispară. Am înțeles cumva că asta era misiunea.

„Nu poți concepe un algoritm independent de un model de date. Și cred că același lucru este adevărat atunci când începi să vorbești despre sisteme și caracteristici ale produsului.”

Și apoi, a fost un caz despre ce soluție tehnică este modalitatea de a realiza asta? În ceea ce privește tehnicile, când mă gândesc la designul tehnologic și la acest tip de design de nivel înalt sau faza de proiectare a sistemului, ceea ce fac aproape întotdeauna este să merg la modele. Există o mulțime de suprafețe pe care poți încerca să o înțelegi. Există o mulțime de lucruri care sunt importante, cum ar fi, cum este structura codului dvs., ce se mișcă și ce lucrători aveți și ce încearcă să facă? Dar conceptele fundamentale, conceptele de bază din sistem, sunt aproape întotdeauna aceleași cu modelele de date din baza de date actuală; schema lor din baza de date sau schema publică din terțul dvs. sau orice ar fi ele. Acestea sunt conceptele de bază în modelele de date implicate. Și un om de știință informatic celebru – nu am idee care – și-a exprimat cu siguranță sentimentul că nucleul algoritmilor sunt modelele de date. Nu puteți concepe un algoritm independent de un model de date. Și cred că același lucru este valabil atunci când începi să vorbești despre sisteme și caracteristici ale produsului. Modelele de date sunt fundamentale pentru orice proiectare.

Deci, în această situație, primul lucru pe care l-am făcut când am ajuns în facturare a fost să înțelegem propriile noastre modele de date. Pentru că pentru tine și pentru mine, Jamie, aterizarea acolo a fost ca în vestul sălbatic. La fel ca majoritatea Intercomului, nu văzusem niciodată interiorul acestuia, era o nouă frontieră curajoasă. Deci, în primul rând, a trebuit să înțelegem: „Hei, ce dracu sunt toate aceste mese implicate în propriul nostru sistem?” Am ajuns la această înțelegere relativ repede cu ajutorul echipei anterioare din San Francisco și am construit acel model mental.

„Nu mă simt niciodată confortabil să merg mai departe cu un design tehnic decât dacă înțeleg pe deplin modelele de date”

Apoi, următoarea piesă majoră care lipsea pe care cred că aproape că am ajuns să o atacăm prea târziu a fost: „Să înțelegem cu adevărat modelul de date al Zuora, sistemul în care săpăm”. Efortul despre care vorbeai, cred că a fost doar poate o săptămână sau cam așa ceva timp în care practic pornim consola, introducem manual modelele de date în Zuora, schimbam ceva, rulam niște comenzi pentru a vedea ce s-a întâmplat și exploram un fel. de stil cutie neagră pentru a înțelege modelul de date. Și la sfârșitul înțelegerii, am putea spune că „Hei, există acest teanc mare de modele. Cele cu adevărat importante sunt aici jos, chiar la frunză. Sunt ca planul de tarife, segmentele de taxare sau ceva, care stochează curajul datelor.” Și odată ce înțelegeți corect conceptele de bază și modelele de date, atunci puteți începe să construiți, puteți începe să proiectați un sistem. Și acest lucru este valabil mai ales atunci când vorbim despre sisteme de replicare ca acesta, a căror sarcină fundamentală este să amestece în mod fiabil un set de modele de date și să îl traducă în echivalentul semantic într-un alt set de modele de date.

Întrebarea ta inițială, pentru a nu o pierde din vedere, este cum știi când ar trebui să faci asta? Pentru mine, acesta este unul foarte simplu. Nu mă simt niciodată confortabil să merg mai departe cu un design tehnic decât dacă înțeleg pe deplin modelele de date. Și vă voi spune că un loc în care am fost ars de faptul că nu am urmat profund acel principiu a fost, mai târziu, venind la Salesforce, am înțeles oarecum conceptele de bază și modelele de date că Salesforce era o lume mare, mare. Deci, a fost o presiune mare de timp. Și nu am ajuns la aceeași profunzime de înțelegere a modelelor de date ca și pentru Zuora. Și cred că același lucru a fost valabil pentru toată lumea din echipă. Nu am ajuns la același nivel de profunzime al modelelor de date. Și simțim într-un fel rezultatele prin faptul că am construit ceva bun, dar un an mai târziu, după mai mult context cu aceste modele de date, ne-am dat seama: „Hei, nu le-am înțeles corect prima dată. Nu am mapat corect traducerea dintre Salesforce și propriul nostru sistem și avem mai multă muncă de făcut pentru a repara această lipsă de cunoștințe.”

Jamie Osler: Este foarte util. A fost o discuție grozavă despre modul în care dezambiguizați proiectele.

Mike Stewart: Sper că a fost o conversație grozavă, Jamie, și sper că am găsit conținut util aici.

Jamie Osler: Conținut de hashtag.

Partea bună a unei întreruperi grozav de rău

Liam Geraghty: La începutul acestui an, dacă sunteți un utilizator de Facebook, WhatsApp sau Instagram, fără îndoială vă veți aminti de acea întrerupere din octombrie. A fost cea mai lungă întrerupere globală a Facebook din istoria sa. Totul s-a rezumat la o schimbare de configurare defectuoasă din partea lor. Deci, întreruperile nu sunt distractive pentru nimeni. Cineva căruia îi displace în mod deosebit este inginerul principal de sisteme de interfon, Brian Scanlan.

Brian Scanlan: Urăsc întreruperile, motiv pentru care mi-am dedicat cariera combaterii lor.

Liam Geraghty: Brian s-a așezat să discute cu Jamie despre ei în noiembrie 2020.

Brian Scanlan: O parte din motivul pentru care îmi plac întreruperile, pentru care sunt atras de ele sau pentru care îmi petrec timpul cu ele este că până acum a fost destul de bine pentru cariera mea. Și asta pentru că am decis să mă interesez de asta, să mă implic în conducerea lor, să mă gândesc la ei, să fac parte din ei și să le urmăresc.

Liam Geraghty: Brian și-a amintit câteva întreruperi notabile la Intercom.

„Îmi amintesc că am vrut să fiu bolnav într-un coș când mi-am dat seama că Elasticsearch era gol. Am spus: „Oh, asta e atât de rău””

Brian Scanlan: Una dintre cele mai traumatizante întreruperi în care am fost implicat, deși nu am fost de fapt acolo în timpul întreruperii, a fost marea întrerupere a Elasticsearch din ianuarie 2019.

Liam Geraghty: Cineva care era acolo a fost Patrick O'Doherty, un inginer senior de securitate aici la acea vreme.

Patrick O'Doherty: Îmi amintesc că am vrut să fiu bolnav într-un coș când mi-am dat seama că Elasticsearch era gol. Am spus: „Oh, asta e atât de rău.”

Brian Scanlan: Acesta a fost unul deosebit de spectaculos. Nu am fost acolo pentru că eram la băuturile de la aniversarea a 40 de ani cu niște prieteni. Era ca într-o seară de vineri. Și pentru că nu ne este frică de codul de livrare către producție într-o zi de vineri, am aprobat o solicitare de extragere care adaugă o subrețea la VPC-ul nostru AWS în acea vineri seara.

Jamie Osler: Între băuturi?

Brian Scanlan: Nu, de fapt era pe drum. Eram treaz pe vremea aceea. Când s-a încercat să fie adăugată acea subrețea la rețeaua noastră din interiorul Amazon, automatizarea în care am scris... Folosim un instrument numit Terraform pentru a gestiona infrastructura noastră de nivel scăzut din interiorul AWS și aveam o grămadă de module de echipă – gândiți-vă la este un cod reutilizabil pe care l-am scris pentru a încerca să simplificăm o mulțime de infrastructuri în interiorul AWS cu toate setările și lucrurile pe care vrem să le aplicăm.

„În acel moment, când a fost aplicată configurația, ne-a distrus complet sau a luat rețeaua offline”

Și astfel, această automatizare a luat cu multă sârguință descrierea subrețelei pe care doream să fie adăugată. Dar în momentul aplicării, API-urile AWS l-au respins deoarece exista o subrețea IP care se suprapune, sau mai degrabă subrețeaua care era configurată se suprapunea cu una deja existentă. Și astfel, în acel moment, procesul de aplicare Terraform a renunțat. S-a oprit. Ceea ce, într-o grămadă de cazuri, este un lucru complet rezonabil de făcut. Dar, din păcate, modul în care am implementat modulul nostru Terraform a însemnat că elimina toate informațiile despre tabelele de rutare care existau pe o subrețea și le adaugă înapoi în timp ce configura toate aceste subrețele. Deci, de fapt, a eliminat toate rutele, care sunt modul în care o rețea știe cum să ajungă la internet și la alte rețele, ceea ce este destul de important. Deci, în acel moment, când a fost aplicată configurația, aceasta ne-a distrus complet sau a luat rețeaua offline. Acesta este doar începutul.

Jamie Osler: Adică, asta e rău, nu? Asta nu e bine.

Brian Scanlan: Da. Deci, asta a luat Intercomul complet offline. Și apoi, a durat ceva timp până să ajungem la punctul în care ne putem întoarce înapoi. Prin noi, vreau să spun, nu eu. Mă bucuram de băuturi în acest moment. Și astfel, echipa a găsit o modalitate de a intra în infrastructura noastră de furnizare Terraform și de a reveni la modificarea configurației.

„De asemenea, a durat mult, mult timp pentru a afla ce s-a întâmplat și unde au ajuns acele date. Vorbim despre o întrerupere de opt ore aici”

Dar, din păcate, între timp, au intervenit și alte automatizări. De data aceasta, unele automatizări care erau deținute de AWS. Folosim această tehnologie numită OpsWorks, care este o versiune gestionată de Chef, pentru a gestiona gazdele noastre Elasticsearch. Avea această funcționalitate numită auto-vindecare încorporată pe care am activat-o implicit în configurația noastră la nivel de gazdă. Și dacă gazdele ar fi incontactabile de backend-ul OpsWorks, sistemul de flux de lucru al OpsWorks ar încerca să vindece automat gazda în cauză, deoarece s-a gândit că ceva nu a mers prost acolo. Sistemul de operare este inactiv, poate a rămas fără memorie – s-a întâmplat ceva rău, așa că haideți să încercăm să o reparăm. Deci, acest avion de control OpsWorks a decis să ne repare întreaga infrastructură prin înlocuirea gazdelor.

Din păcate, rulam Elasticsearch și încă facem ceea ce este cunoscut sub numele de stocare efemeră. Aceasta este stocarea bazată pe gazdă – nu folosim un sistem magic bazat pe cloud care stochează datele dumneavoastră într-un sistem terță parte sau dintr-un sistem din afara gazdei. Este doar pe o gazdă fizică. Și dacă gazda fizică este distrusă, datele dispar. Și așa s-a întâmplat cu fiecare gazdă Elasticsearch. Fiecare cluster Elasticsearch a pierdut fiecare bucată de date, ceea ce este destul de rău, deoarece cantități uriașe de Intercom sunt construite pe deasupra Elasticsearch. Nu este depozitul de date principal. Tindem să scriem date într-un singur depozit de date, cum ar fi, de exemplu, DynamoDB pentru utilizatorii noștri, și apoi să copiem acele date în Elasticsearch pentru căutare. Și îl putem restaura, dar procesul de recuperare a tuturor acestor date prin copii de siguranță și de a trebui să readucem toate modificările de la backup-urile noastre anterioare a durat mult, mult, mult timp. De asemenea, a durat mult, mult timp să-ți dai seama ce s-a întâmplat și unde au ajuns acele date. Vorbim despre o întrerupere de opt ore aici.

„Nu am spus doar „Ei bine, acum știm despre aceste două probleme, să le reparăm”. Am plecat și am căutat alte tipuri de zone de automatizare care ar putea să ne muște în situații bizare”

Aceasta a fost o mare problemă pentru că s-a întâmplat vineri târziu, a fost nevoie de un număr mare de oameni pentru ca lucrurile să se stabilească. Știam oarecum despre aceste probleme, fiind nevoiți să readucem sau să reumplem clusterele noastre Elasticsearch și să ne zgâriam. Nu știam despre unele dintre pericolele latente în propria noastră automatizare și unele dintre automatizările de la AWS.

A fost interesant pentru că, în continuare, nu am spus doar „Ei bine, acum știm despre aceste două probleme, să le reparăm”. Am plecat și am căutat alte tipuri de zone de automatizare care ar putea să ne muște în situații bizare. Așadar, am ajuns să facem o mulțime de lucruri pentru a fi cu adevărat buni în a restabili clusterele Elasticsearch din diferite state, fiind capabili să readucem date în momente diferite în clusterele noastre Elasticsearch în cazul în care rămânem vreodată în urmă sau avem situații similare de tip dezastru. Și, știți, în general, am învățat multe din această întrerupere glorios de proastă, iar procesul a fost de fapt destul de bun după aceea, ce am învățat și cum am diseminat aceste informații.

Patrick O'Doherty: Nu-mi amintesc cine a fost, dar aproximativ o oră mai târziu, cineva mi-a mulțumit că am provocat acest incident, pentru că au spus: „Uau, chiar ai scuturat o mulțime de lucruri din copac aici. Acesta va fi un răspuns cu adevărat distractiv la incident”. Acesta a fost practic esența. Era ca: „Oh, wow. Dezgropăm lucruri aici.” Si a fost. Utilizarea Terraform și maturitatea noastră generală în ceea ce privește modul în care folosim instrumentele, rămânând conștienți de faptul că instrumentele ne pot răni, de asemenea. Respectați uneltele electrice. La fel ca infrastructura, uneltele electrice sunt periculoase. Se pot mișca rapid și te pot prinde prin surprindere și cred că ne-am învățat lecția în acea zi.

Brian Scanlan: Am primit, de asemenea, o discuție în interiorul intercomului din asta. De asemenea, nu am fost la incident pentru că am fost la cârciumă de ziua mea. A fost minunat. A fost incidentul perfect.

Cu viteza luminii

Liam Geraghty: În decembrie 2020, un Crăciun pe care sunt sigur că nu îl vom uita niciodată, co-fondatorul Intercom Ciaran Lee s-a alăturat lui Jamie pentru a vorbi despre viteză și de ce lui Ciaran îi pasă să se miște rapid.

Ciaran Lee: Sunt o persoană extrem de nerăbdătoare. Ăsta e un lucru. Dacă pot face ceva rapid sau încet, personal prefer să o fac repede. Interfonul ar putea părea o companie veche care se apropie de 10 ani, dar sincer cred că tocmai am început. Avem atât de multe de făcut. Suntem atât de ambițioși. Putem vedea o imagine a ceea ce ne-am dori să fim, acest instrument all-in-one pe care oricine are o afacere pe internet îl poate folosi pentru a vorbi cu clienții lor. Și noi doar zgâriem suprafața acolo.

Un lucru care îmi place foarte mult de la Stripe, o companie grozavă la care apreciez, a fost o postare grozavă pe blog a lui Patrick McKenzie, în care a descris că și-au stabilit cadența de operare implicită să ruleze. În mod implicit, se mișcă incomod de repede, întrebând întotdeauna dacă putem face lucrul mai repede în această săptămână, în loc de șase luni de acum încolo. Și pur și simplu îmi place asta personal. O astfel de atitudine ne-a servit foarte bine. Și cred că este un lucru distractiv la care să te gândești mereu. Poți merge mai repede?

„Este grozav dacă atingem disponibilitatea sută la sută într-un sfert, dar poate ar trebui să ne întrebăm: „Hei, nu suntem suficient de riscanți?”

Jamie Osler: Dacă faci ca mergerea rapidă să fie critică pentru compania ta și este ceva ce faci tot timpul, ai tendința de a sparge mai puțin.

Ciaran Lee: Da. Mișcă-te rapid și distruge lucrurile în parametri acceptabili. Este în regulă să aveți întreruperi. Este în regulă să ai bug-uri – evident, anumite categorii de bug-uri pe care vrei să le ai mai puțin decât altele, dar avem bugete de disponibilitate. Este grozav dacă atingem disponibilitatea sută la sută pe un sfert, dar poate ar trebui să ne întrebăm: „Hei, nu suntem suficient de riscanți? Ne-am putea risca un pic mai mult pentru a ne mișca mai repede?” Ar trebui să fii într-un punct deliberat al spectrului. Și cu siguranță, avem o mare responsabilitate. Avem o mulțime de clienți, sute de mii de oameni care se conectează, a căror sarcină este să folosească Inbox-ul nostru, să vorbească cu clienții lor în fiecare zi. Nu putem fi ca și cum le-am spart lucrurile mișcându-se prea repede sau schimbându-le atât de repede încât nici măcar să nu mai știe cum să le folosească. Ar fi greșit. Avem constrângeri, dar în cadrul acestor constrângeri, ar trebui absolut să ne mișcăm cât de repede putem.

Acolo unde intervine legalitatea

Liam Geraghty: Și trecem cât de repede putem prin acest episod. În continuare, Intercom, consilier principal, Meena Polich. Meena face parte din echipa noastră juridică, cu accent pe produs și inginerie. În ianuarie 2021, Meena și Jamie au discutat despre modul în care echipele juridice și de inginerie pot lucra împreună.

„Suntem aici într-un fel de marș cu compania și cu toți clienții noștri pentru a ajunge acolo unde trebuie să mergem în mod responsabil, fără a încetini pe nimeni”

Meena Polich: Este foarte important pentru noi să înțelegem produsul. Cum putem consilia compania cu privire la reglementările care ne vor afecta sau ce legi trebuie să respectăm dacă nu înțelegem de fapt ce vindem? La un nivel foarte elementar, din punct de vedere strategic, trebuie să înțelegem nu numai ce vindem acum, ci și ce vrem să vindem și cum vrem să ne poziționăm și să creștem. În acest fel, putem începe să construim proiecții ale lucrurilor pe care va trebui să le urmărim din perspectivă juridică. Și doar să ne asigurăm că suntem aici, într-un fel de marș cu compania și cu toți clienții noștri pentru a ajunge acolo unde trebuie să mergem în mod responsabil, fără a încetini pe nimeni. Dintr-o abordare mai tactică, înțelegerea valorilor companiei și a produsului este extrem de utilă pentru negocierea cu clienții și chiar cu furnizorii. Mă pune într-o poziție mult mai eficientă atunci când înțeleg ce încercăm să facem. Și apoi, le pot explica vânzătorilor noștri: „Pentru că încercăm să facem asta, avem nevoie de tine pentru a putea face asta.”

Dimpotrivă, atunci când negociez cu clienții, de multe ori, cei de cealaltă parte a mesei sunt alți avocați sau agenți de achiziții, care sunt la fel de tehnici, dacă nu mai puțin, ca mine. Așadar, fiind capabil să explice ce face produsul în calitate de avocat care spune: „Uite, știu care sunt preocupările tale din perspectiva managementului riscului legal, dar iată cum funcționează de fapt platforma. Iată cum funcționează de fapt produsul în practică. Și de aceea nu va reduce riscul de care vă îngrijorează. Nu va declanșa acel risc de care ești îngrijorat.”

„Prima mea prioritate este să ajut cercetarea și dezvoltarea să înțeleagă că nu sunt aici să deraieze progresul uimitor pe care îl facem”

Jamie Osler: Cred că asta funcționează în ambele sensuri, nu? Dacă R&D are o mai bună înțelegere a tipului de imagine de ansamblu juridică la nivel înalt a zonelor de îngrijorare, îi ajută să evite să facă lucruri neintenționate sau să construiască produse care ar fi riscante sau care ar încălca acele legi.

Meena Polich: Da, absolut. Și acesta este cel mai important lucru pe care trebuie să îl eliminați sau pe care să încercați să vă concentrați în timp ce construiți relația juridică cu R&D. Prima mea prioritate este să ajut R&D să înțeleagă că nu sunt aici pentru a deraia progresul uimitor pe care îl facem, iar echipa mea nu este aici pentru a ne împiedica să continuăm să intrăm pe piață cu produse excelente. Echipa noastră este aici pentru a ne asigura că, pe măsură ce creștem și devine mai greu să urmărim tot ceea ce face fiecare individ din companie, continuăm să facem acest lucru în mod etic și continuăm să facem acest lucru în limitele legii. Și când putem, încercăm să gestionăm acest risc.

Acesta este unul dintre motivele pentru care conformitatea prin proiectare este atât de importantă. Dacă ținem cont de cerințele de conformitate sau așteptările de conformitate și proiectăm în funcție de acestea, de multe ori, modificările de proiectare pe care le facem vor fi lucruri care ne-ar beneficia de fapt. Poate exista un cost inițial în ceea ce privește alocarea resurselor, dar pe termen lung, și nici măcar pe termen foarte lung – în multe cazuri, în decurs de șase luni până la un an de la eliminarea acestei funcții – vom vedea un beneficiu incredibil. în ceea ce privește creșterea veniturilor și tipurile de clienți potențiali pe care le-am generat și atragerea clienților pentru că aceștia vor avea încredere în noi.

Liam Geraghty: Mulțumirile mele lui Jamie Osler, care a creat Engineer Chats , noului său gazdă Brian Scanlan, și tuturor invitaților de astăzi care ne-au permis să le punem discuțiile interne externe. Dacă ți-a plăcut emisiunea de astăzi, de ce să nu ne lași o recenzie sau să ne lași un strigăt pe rețelele sociale. Ne place să vedem și să auzim ce credeți. Asta e tot pentru azi. Vom reveni săptămâna viitoare cu un alt episod din Inside Intercom.