Intercom presenta le chat dell'ingegnere

Vi abbiamo parlato dei nostri prodotti e funzionalità e dei lanci di cui siamo entusiasti. Ora ti portiamo dietro le quinte e ti presentiamo il lavoro delle persone che lo realizzano.

Nel corso degli anni, abbiamo coperto molto sui nostri podcast. Ogni settimana, ti diamo uno spaccato del mondo della gestione dei prodotti, del design, del supporto e del marketing con Inside Intercom; esplorare come i leader del settore utilizzano la CX per far crescere le proprie attività con Scale; e mostrarti il ​​mondo del co-fondatore di Intercom Des Traynor e dell'SVP of Product di Intercom, Paul Adams, mentre condividono i loro ultimi pensieri su come creare prodotti eccezionali.

E ora qualcosa di completamente diverso. Per la prima volta, stiamo rilasciando Engineer Chats , un podcast interno qui a Intercom su tutto ciò che riguarda l'ingegneria. In precedenza ospitato da Jamie Osler, Senior Product Engineer presso Intercom per oltre sette anni, ora tocca al Principal Systems Engineer Brian Scanlan raccogliere il testimone e continuare le chat.

Questa settimana, oltre a Jamie e Brian, ascolterai anche:

• Mike Stewart, ex Senior Principal Engineer presso Intercom
• Patrick O'Doherty, ex Senior Security Engineer presso Intercom e ora ingegnere presso Oso
• Ciaran Lee, co-fondatore di Intercom
• Meena Polich, Senior Counsel di Intercom a supporto della ricerca e sviluppo

Dal processo di disambiguazione e dalla peggiore interruzione che abbiamo mai avuto, alla nostra ossessione per la velocità e al modo in cui i team legali e ingegneristici possono lavorare meglio insieme, Engineer Chats ti darà una sbirciatina dietro il processo di progettazione di Intercom.

Se hai poco tempo, ecco alcuni suggerimenti veloci:

• La disambiguazione, o il processo di restringimento di un ampio spazio di soluzione in ciascun problema, non è utile solo per progetti ambigui. Può essere utilizzato per l'intero processo di costruzione nell'ingegneria e persino nella gestione del prodotto.
• Il nucleo di algoritmi e sistemi sono i modelli di dati. Quando affronti un progetto tecnico per un sistema, assicurati di aver sempre compreso prima i modelli di dati.
• L'automazione nell'infrastruttura può portare a errori piuttosto gravi. E sebbene questi problemi non siano divertenti per nessuno, puoi usarli per cercare altri punti ciechi e creare un sistema più robusto.
• La cadenza operativa predefinita dovrebbe essere quella di esecuzione: è importante che le startup non compromettano la velocità. Se puoi fare qualcosa questa settimana invece del prossimo trimestre, saltaci sopra.
• Il team legale non è lì per rallentare la ricerca e lo sviluppo. La loro priorità è assicurarsi che, man mano che l'azienda cresce e aumenta di complessità, continui a farlo entro i confini della legge.

Se ti piace la nostra discussione, dai un'occhiata ad altri episodi del nostro podcast. Puoi seguire su iTunes, Spotify o prendere il feed RSS nel tuo lettore preferito. Quella che segue è una trascrizione leggermente modificata dell'episodio.

Liam Geraghty: Ciao e benvenuto in Inside Intercom. Sono Liam Geraghty. Se sei un ascoltatore abituale, saprai che intervistiamo creatori e operatori del mondo della gestione dei prodotti, del design, delle startup e del marketing. Abbiamo anche altri due podcast: Intercom on Product, in cui il co-fondatore di Intercom Des Traynor e l'SVP di Intercom Product, Paul Adams, discutono dei loro ultimi pensieri su come creare prodotti di successo su larga scala e Scale by Intercom, in cui esploriamo come sono le aziende guidare la crescita attraverso le relazioni con i clienti.

Un podcast che sicuramente non sapevi che avessimo realizzato è uno chiamato Engineer Chats , e questo perché è un podcast interno a Intercom. È stato ospitato da Jamie Osler, un ex Senior Product Engineer qui. In ogni episodio, Jamie si è seduto per parlare con una varietà di persone diverse su una varietà di argomenti diversi relativi all'ingegneria.

Oggi vi portiamo una finestra sonora su tutto ciò che riguarda l'ingegneria in Intercom. Abbiamo preso le parti migliori dello show, dalla storia della peggiore interruzione che abbiamo mai avuto a come i team legali e ingegneristici possono lavorare meglio insieme. Primo, disambiguazione: l'atto o il processo di distinguere tra cose e significati simili per rendere il significato o l'interpretazione più chiaro o certo. Mike Stewart, l'ex Senior Principal Engineer di Intercom, si è seduto per parlare con Jamie nell'ottobre 2020 di quella parola e del perché la usa così tanto al lavoro. Ecco Jamie.

Disambiguazione fino in fondo

Jamie Osler: Qualcosa che ti ho visto fare con ottimi risultati quando ti avvicini a un progetto che è un po' confuso e non molto ben definito in termini di cosa significhi il successo e come affrontarlo al meglio è ciò che a volte definisci disambiguato. Potresti dirci cosa intendi quando lo dici?

Mike Stewart: Sì. Disambiguando. È una parola che non usavo mai molto prima di venire a Intercom, e l'ho usata così tanto da quando sono arrivato qui. Probabilmente avrei dovuto usarlo in posti precedenti prima, ma è una parola così buona. Non è nemmeno solo per progetti lanosi o progetti ambigui. Penso quasi che questo sia un verbo molto generale come parte del nostro intero processo di costruzione che va ben oltre l'ingegneria e in molte cose che fanno i PM per capire le cose.

"Hai un ampio spazio di soluzioni... è il processo di liquidazione basato su prove, decisioni e chiamate"

Se torni allo stato pre-progetto, ovviamente abbiamo dei team, hanno aree di proprietà e individuano delle roadmap intorno a loro, giusto? Il team è responsabile dell'intera nostra area di marketing/coinvolgimento/outbound/superficie e possiede il successo in questo ambito. Questo è un problema ambiguo. Il processo per capire dove ci sediamo all'interno di ciò e di tutte le cose che potremmo fare e i modi in cui potremmo farle e restringerci - forse non capire al cento per cento - e chiudere quello spazio di soluzione per ottenere un più stretto e visione più ristretta di tutte le cose che potresti fare all'interno dello spazio di coinvolgimento, queste sono quelle che pensiamo siano le più importanti, quelle che i clienti cercano di più, il più alto ritorno sugli investimenti: questo è un processo di disambiguazione. Hai un ampio spazio di soluzione, ambiguità su dove dovresti andare all'interno dei molti posti diversi in cui potresti andare all'interno di quello spazio di soluzione, ed è il processo di chiusura basato su prove, decisioni e chiamate.

Quando lo interpreto per un progetto di ingegneria, c'è lo stesso genere di cose un paio di fasi più avanti nella pipeline. Una volta che abbiamo deciso di creare un nuovo messenger con una piattaforma pubblica in cui puoi creare app e incorporarle in un messenger, c'è l'intero spazio delle soluzioni di cosa significa, tutte le diverse forme che potrebbero assumere, come potrebbe manifestarsi, e come potresti costruirlo. Disambigua fino in fondo fino ad arrivare al punto in cui l'ambiguità a cui stai pensando è del tipo: "Sappiamo che vogliamo incorporare un iFrame che abbia una determinata interfaccia, gli sviluppatori si muovono avanti e indietro, e poi, come possiamo implementarlo davvero, progettarlo con la tecnologia e scrivere i codici per farlo? Questi sono i livelli ancora più ingranditi. Stai ancora lavorando sull'ambiguità lì. Quindi, penso che la disambiguazione sia nell'intero processo di sviluppo del prodotto.

"Penso quasi a questo come a uno di quei video dell'universo che va dallo zoom fino alla terra come un punto in una galassia e fino alla scala umana e alla micro scala"

Jamie Osler: Hai davvero ristretto anche questo. Forse potresti chiarirlo un po'.

Liam Geraghty: Mike ha un ottimo modo di visualizzare il processo di disambiguazione.

Mike Stewart: Sì. Penso quasi a questo come a uno di quei video dell'universo a diversi ordini di grandezza che vanno dallo zoom fino alla terra come un punto in una galassia e fino alla scala umana e alla micro scala. C'è una struttura interessante a ciascuno di questi livelli e, allo stesso modo, penso che ci sia un'ambiguità interessante a ciascuno dei livelli di zoom man mano che le cose diventano sempre più definite.

Le tecniche sono diverse quando, diciamo, scrivi codice e capisci: "Ehi, quali sono i miei concetti nel codice e come dovrei strutturare questo codice?" rispetto a quando stai cercando di capire: "Ehi, come dovrei progettare questo?" e quali sono i modelli di dati e le parti mobili rispetto a qual è la soluzione rispetto alla tabella di marcia? Lo sto astraendo molto in quanto è tutta disambiguazione. Essere molto attenti a cosa stai attaccando ea quale livello di zoom è il principio più importante nella mia testa. Ed è qui che gli ingegneri possono essere risucchiati in modo molto naturale dai livelli di zoom più profondi di disambiguazione, di capire come costruire qualcosa, perché è qualcosa che spesso è più comodo o più facile da decifrare.

Essere tutt'uno con i modelli di dati

Liam Geraghty: Per collegare tutto questo con un esempio concreto, Jamie presenta questo.

Jamie Osler: Quando stavamo esaminando come il sistema di fatturazione inviava i dati a Zuora e come cercava di garantire che lo stato fosse sincronizzato tra i due, dovevamo capire come funzionava il sistema attuale in modo da poter ottenere quel tipo di disambiguare l'attuale sistema in atto e scomporlo nelle sue idee e principi fondamentali e vedere quali di questi erano rilevanti per il futuro. Come parte di ciò, hai scritto un documento che esplorava come funzionava la modellazione dei dati del piano tariffario di Zuora nel tempo. E penso che fosse qualcosa in cui molte persone non avrebbero scavato a quel livello. Cosa ti ha fatto pensare che sarebbe stata una cosa utile da fare? E quando sai quando fare quell'indagine, quando non farlo?

Mike Stewart: Sì, certo. In termini di livelli di zoom di cui parlavamo prima, questo, per me, è proprio in quel livello di zoom del design tecnologico di alto livello. Per ricapitolare, nella fatturazione, eravamo al punto in cui: "Ehi, capiamo abbastanza fermamente che abbiamo questi due sistemi. Abbiamo la nostra app Rails e abbiamo questo sistema Zuora esterno. Sappiamo che, almeno, per una buona parte del futuro, avremo questi due sistemi. Non cambieremo questo vincolo. Abbiamo molto costruito su loro due, quindi non è fattibile andare via. Abbiamo bisogno che i due sistemi siano sincronizzati, e abbiamo bisogno che siano d'accordo tra loro, e tutti questi problemi che derivano dal fatto che non siamo in grado di farli concordare tra loro, abbiamo bisogno che quelli scompaiano. Abbiamo capito che quella era la missione.

“Non puoi ideare un algoritmo indipendente da un modello di dati. E penso che lo stesso sia vero quando inizi a parlare di sistemi e caratteristiche del prodotto”

E poi, è stato un caso di quale soluzione tecnica è il modo per ottenerlo? In termini di tecniche, quando penso al design tecnologico e a questa sorta di progettazione tecnologica o fase di progettazione di sistema di alto livello, quello che faccio quasi sempre è andare ai modelli. C'è molta superficie che puoi provare a capire. Ci sono molte cose che sono importanti, come, come è la struttura del tuo codice, cosa si muove e quali lavoratori hai e cosa sta cercando di fare cosa? Ma i concetti fondamentali, i concetti fondamentali del sistema, sono quasi sempre gli stessi dei modelli di dati nel database effettivo; lo schema di questi nel tuo database o lo schema pubblico nella tua terza parte, o qualunque cosa siano. Sono i concetti fondamentali nei modelli di dati coinvolti. E qualche famoso informatico – non ho idea di quale – ha decisamente espresso il sentimento che il cuore degli algoritmi siano i modelli di dati. Non è possibile ideare un algoritmo indipendente da un modello di dati. E penso che lo stesso sia vero quando inizi a parlare di sistemi e funzionalità del prodotto. I modelli di dati sono alla base di qualsiasi progetto.

Quindi, in questa situazione, la prima cosa che abbiamo fatto quando siamo arrivati ​​alla fatturazione è stata capire i nostri modelli di dati. Perché per te e per me, Jamie, atterrare lì è stato come il selvaggio west. Come la maggior parte di Intercom, non ne avevamo mai visto l'interno, era una nuova frontiera coraggiosa. Quindi, prima di tutto, abbiamo dovuto capire: "Ehi, che diavolo sono tutti questi tavoli coinvolti nel nostro sistema?" Siamo arrivati ​​a questa comprensione in tempi relativamente brevi con l'aiuto del precedente team di San Francisco e abbiamo costruito quel modello mentale.

"Non mi sento mai a mio agio nell'andare avanti con un progetto tecnico a meno che non comprendo appieno i modelli di dati"

Quindi, il prossimo pezzo importante mancante che penso che siamo quasi arrivati ​​ad attaccare troppo tardi è stato: "Capiamo davvero il modello di dati di Zuora, il sistema in cui stiamo scavando". Lo sforzo di cui stavi parlando, penso che sia stata solo una settimana circa di tempo in cui stavo praticamente accendendo la console, inserendo manualmente i modelli di dati in Zuora, cambiando qualcosa, eseguendo alcuni comandi per vedere cosa è successo ed esplorando una sorta di stile black-box per comprendere il modello di dati. E alla fine di capirlo, potremmo dire: "Ehi, c'è questa grande pila di modelli. Quelli veramente importanti sono quaggiù, proprio sulla foglia. Sono come il piano tariffario, i segmenti di tariffa o qualcosa del genere, che memorizzano le viscere dei dati". E una volta che hai compreso correttamente i concetti fondamentali e i modelli di dati, puoi iniziare a costruire, puoi iniziare a progettare un sistema. E questo è particolarmente vero quando parliamo di sistemi di replica come questo, il cui compito fondamentale è mescolare in modo affidabile un insieme di modelli di dati e tradurlo nella cosa semanticamente equivalente in un altro insieme di modelli di dati.

La tua domanda originale, per non perderla di vista, è come fai a sapere quando dovresti farlo? Per me, è davvero semplice. Non mi sento mai a mio agio nell'andare avanti con un progetto tecnico a meno che non comprendo appieno i modelli di dati. E ti dirò che un punto in cui sono rimasto bruciato dal non seguire profondamente quel principio è stato più tardi, arrivando a Salesforce, ho avuto una certa comprensione dei concetti fondamentali e dei modelli di dati che Salesforce era un mondo grande, grande. Quindi, c'era molta pressione sul tempo. E non sono andato alla stessa profondità di comprensione dei modelli di dati come ho fatto per Zuora. E penso che lo stesso valesse per tutti i membri della squadra. Non siamo arrivati ​​allo stesso livello di profondità dei modelli di dati. E in qualche modo sentiamo i risultati in quanto abbiamo costruito qualcosa di buono, ma un anno dopo, dopo avere più contesto con questi modelli di dati, ci siamo resi conto: "Ehi, non li abbiamo capiti correttamente la prima volta. Non abbiamo mappato correttamente la traduzione tra Salesforce e il nostro sistema e abbiamo più lavoro da fare per riparare a questa mancanza di conoscenza".

Jamie Osler: È super utile. È stata una bella chiacchierata sul modo in cui disambigua i progetti.

Mike Stewart: Spero sia stata una bella chiacchierata, Jamie, e spero che qui abbiamo dei contenuti utili.

Jamie Osler: contenuto hashtag.

Il lato positivo di un'interruzione gloriosamente brutta

Liam Geraghty: All'inizio di quest'anno, se sei un utente di Facebook, WhatsApp o Instagram, senza dubbio ricorderai quell'interruzione di ottobre. È stata l'interruzione globale più lunga di Facebook nella sua storia. Tutto si è ridotto a un cambio di configurazione difettoso da parte loro. Quindi, le interruzioni non sono divertenti per nessuno. Qualcuno a cui non piacciono particolarmente è il Principal Systems Engineer di Intercom, Brian Scanlan.

Brian Scanlan: Odio le interruzioni, motivo per cui ho dedicato la mia carriera a combatterle.

Liam Geraghty: Brian si è seduto per parlare di loro con Jamie nel novembre 2020.

Brian Scanlan: Parte del motivo per cui mi piacciono le interruzioni, perché sono attratto da loro o ci dedico il mio tempo è perché finora è stato abbastanza buono per la mia carriera. E questo perché ho deciso di interessarmene, di essere coinvolto nella loro gestione, di pensare a loro, di farne parte e di seguirli.

Liam Geraghty: Brian ha ricordato alcune interruzioni notevoli a Intercom.

“Ricordo di voler stare male in un cestino quando mi sono reso conto che Elasticsearch era vuoto. Ero tipo, 'Oh, è così brutto'"

Brian Scanlan: Una delle interruzioni più traumatiche in cui sono stato coinvolto, anche se in realtà non ero presente durante l'interruzione, è stata la grande interruzione di Elasticsearch di gennaio 2019.

Liam Geraghty: Qualcuno che era lì era Patrick O'Doherty, un ingegnere di sicurezza senior qui all'epoca.

Patrick O'Doherty: Ricordo di aver voluto essere malato in un cestino quando mi sono reso conto che Elasticsearch era vuoto. Ero tipo "Oh, è così brutto".

Brian Scanlan: Questo è stato particolarmente spettacolare. Non c'ero perché ero al mio 40° compleanno con degli amici. Era come un venerdì sera. E poiché non abbiamo paura di spedire il codice alla produzione di venerdì, ho approvato una richiesta pull aggiungendo una sottorete al nostro VPC AWS quel venerdì sera.

Jamie Osler: Tra un drink e l'altro?

Brian Scanlan: No, in realtà era in arrivo. Ero sobrio in quel momento. Quando si è tentato di aggiungere quella sottorete alla nostra rete all'interno di Amazon, l'automazione in cui abbiamo scritto... Utilizziamo uno strumento chiamato Terraform per gestire la nostra infrastruttura di basso livello all'interno di AWS e avevamo un sacco di moduli del team: pensa a è un codice riutilizzabile che abbiamo scritto per cercare di semplificare una serie di infrastrutture all'interno di AWS con tutte le impostazioni e le cose che vogliamo applicare.

"A quel punto, quando la configurazione è stata applicata, aveva completamente distrutto o portato offline la nostra rete"

E così, questa automazione ha preso molto diligentemente la descrizione della sottorete che volevamo aggiungere. Ma al momento dell'applicazione, le API di AWS l'hanno rifiutata perché c'era una sottorete IP sovrapposta, o meglio la sottorete che si stava configurando si sovrapponeva a una già esistente. E così, a quel punto, il processo di richiesta Terraform ha semplicemente rinunciato. Si fermò. Il che, in un mucchio di casi, è una cosa del tutto ragionevole da fare. Ma sfortunatamente, il modo in cui avevamo implementato il nostro modulo Terraform significava che rimuoveva tutte le informazioni sulle tabelle di routing che esistevano su una sottorete e le aggiungeva di nuovo mentre stava configurando tutte queste sottoreti. Quindi, in effetti, ha rimosso tutti i percorsi, che sono il modo in cui una rete sa come raggiungere Internet e altre reti, il che è piuttosto importante. Quindi, a quel punto, quando la configurazione è stata applicata, aveva completamente distrutto o portato offline la nostra rete. Questo è solo l'inizio.

Jamie Osler: Voglio dire, è brutto, giusto? Questo non è buono.

Brian Scanlan: Sì. Quindi, questo ha portato Intercom completamente offline. E poi, ci è voluto un po' per arrivare al punto in cui potevamo tornare indietro. Con noi, intendo, non io. Mi stavo godendo i miei drink a questo punto. E così, il team ha trovato un modo per entrare nella nostra infrastruttura di provisioning Terraform e tornare alla modifica della configurazione.

“Capire cosa diavolo è successo e dove sono finiti quei dati ha richiesto molto, molto tempo. Stiamo parlando di un'interruzione di otto ore qui"

Ma sfortunatamente, nel frattempo, sono intervenute altre automazioni. Questa volta, alcune automazioni erano di proprietà di AWS. Utilizziamo questa tecnologia chiamata OpsWorks, che è una versione gestita di Chef, per gestire i nostri host Elasticsearch. Aveva questa funzionalità chiamata riparazione automatica integrata che avevamo abilitato per impostazione predefinita nella nostra configurazione a livello di host. E se gli host non fossero contattabili dal back-end di OpsWorks, il sistema del flusso di lavoro di OpsWorks tenterebbe di riparare automaticamente l'host in questione perché ha pensato che qualcosa fosse andato storto. Il sistema operativo è inattivo, forse ha esaurito la memoria: è successo qualcosa di brutto, quindi proviamo a risolverlo. Quindi, questo piano di controllo di OpsWorks ha deciso di riparare la nostra intera infrastruttura sostituendo gli host.

Sfortunatamente, abbiamo eseguito Elasticsearch e continuiamo a utilizzare ciò che è noto come storage effimero. Questo è l'archiviazione basata su host: non stiamo utilizzando un magico sistema basato su cloud che archivia i tuoi dati in un sistema di terze parti o da un sistema esterno all'host. È solo su un host fisico. E se l'host fisico viene distrutto, i dati spariscono. E così, questo è quello che è successo a ogni singolo host Elasticsearch. Ogni singolo cluster Elasticsearch ha perso ogni singolo dato, il che è piuttosto negativo perché enormi quantità di Intercom sono costruite su Elasticsearch. Non è l'archivio dati principale. Tendiamo a scrivere i dati in un datastore, come, ad esempio, DynamoDB per i nostri utenti, quindi copiarli su Elasticsearch per la ricerca. E possiamo ripristinarlo, ma il processo di recupero di tutti quei dati tramite backup e la necessità di riattivare tutte le modifiche poiché i nostri backup precedenti hanno richiesto molto, molto, molto tempo. Inoltre, anche capire cosa diavolo è successo e dove sono finiti quei dati ha richiesto molto, molto tempo. Stiamo parlando di un'interruzione di otto ore qui.

"Non ci siamo limitati a dire 'Beh, ora sappiamo di questi due problemi, risolviamoli'. Siamo andati alla ricerca di altri tipi di automazione che potessero morderci in situazioni bizzarre”

Questo è stato un grosso problema perché è successo alla fine di venerdì, ci sono volute un numero enorme di persone per riportare le cose in modo stabile. In un certo senso sapevamo di questi problemi, dovendo riattivare o ricaricare i nostri cluster Elasticsearch e zero. Non sapevamo di alcuni dei pericoli latenti nella nostra automazione e in parte dell'automazione in AWS.

È stato interessante perché, in seguito a questo, non ci siamo limitati a dire: "Beh, ora sappiamo di questi due problemi, risolviamoli". Siamo andati alla ricerca di altri tipi di aree di automazione che potrebbero morderci in situazioni bizzarre. Quindi, abbiamo finito per fare molte cose per essere davvero in grado di ripristinare i cluster Elasticsearch da stati diversi, essere in grado di reindirizzare i dati in momenti diversi nei nostri cluster Elasticsearch nel caso in cui dovessimo rimanere indietro o avere simili situazioni di tipo disastro. E, sai, nel complesso, abbiamo imparato molto da questa interruzione gloriosamente brutta, e il processo è stato in realtà piuttosto buono in seguito, cosa abbiamo imparato e come abbiamo diffuso queste informazioni.

Patrick O'Doherty: Non riesco a ricordare chi fosse, ma circa un'ora dopo, qualcuno mi ha ringraziato per aver causato questo incidente perché ha detto: "Wow, hai davvero scosso un sacco di cose dall'albero qui. Questa sarà una risposta all'incidente davvero divertente”. Questo era fondamentalmente il succo di tutto. Era come "Oh, wow. Stiamo scavando cose qui". Ed esso era. Il nostro uso di Terraform e la nostra maturità generale verso il modo in cui utilizziamo gli strumenti pur rimanendo consapevoli che gli strumenti possono anche ferirci. Rispetta gli utensili elettrici. Come le infrastrutture, gli utensili elettrici sono pericolosi. Possono muoversi rapidamente e coglierti di sorpresa, e penso che quel giorno abbiamo imparato la nostra lezione.

Brian Scanlan: Ne sono uscito anche come un discorso di Inside Intercom. Inoltre, non ero presente all'incidente perché ero al pub per il mio compleanno. È stato fantastico. È stato l'incidente perfetto.

Alla velocità della luce

Liam Geraghty: A dicembre 2020, un Natale che sono sicuro che non dimenticheremo mai, il co-fondatore di Intercom Ciaran Lee si è unito a Jamie per parlare di velocità e perché Ciaran si preoccupa di muoversi velocemente.

Ciaran Lee: Sono una persona estremamente impaziente. Questa è una cosa. Se posso fare qualcosa velocemente o lentamente, personalmente preferirei farlo velocemente. Intercom potrebbe sembrare una vecchia azienda in arrivo tra 10 anni, ma onestamente credo che siamo solo all'inizio. Abbiamo così tanto da fare. Siamo così ambiziosi. Possiamo vedere un'immagine di ciò che vorremmo essere, questo strumento all-in-one che chiunque abbia un'attività su Internet può utilizzare per parlare con i propri clienti. E lì stiamo solo grattando la superficie.

Una cosa che mi piace molto di Stripe, un'azienda interessante a cui ammiro, è stato un ottimo post sul blog di Patrick McKenzie in cui ha descritto che hanno impostato la cadenza operativa predefinita per l'esecuzione. Per impostazione predefinita, si muovono a una velocità scomoda, chiedendo sempre se possiamo fare la cosa più velocemente questa settimana invece che tra sei mesi. E questo mi piace molto personalmente. Questo tipo di atteggiamento ci ha servito davvero bene. E penso che sia una cosa divertente a cui pensare sempre. Puoi andare più veloce?

"È bello se raggiungiamo una disponibilità del cento per cento su un trimestre, ma forse dovremmo chiederci: 'Ehi, non stiamo rischiando abbastanza?'"

Jamie Osler: Se rendi fondamentale per la tua azienda andare veloce, ed è qualcosa che fai tutto il tempo, tendi a rovinarti di meno.

Ciaran Lee: Sì. Muoviti velocemente e rompi le cose entro parametri accettabili. Va bene avere interruzioni. Va bene avere bug – ovviamente, alcune categorie di bug che vuoi avere meno di altre, ma abbiamo budget di disponibilità. È bello se raggiungiamo una disponibilità del cento per cento su un trimestre, ma forse dovremmo chiederci: "Ehi, non stiamo rischiando abbastanza? Potremmo correre qualche rischio in più per muoverci più velocemente?" Dovresti trovarti in un punto deliberato dello spettro. E di sicuro abbiamo una grande responsabilità. Abbiamo molti clienti, centinaia di migliaia di persone che accedono il cui compito è usare la nostra Posta in arrivo, per parlare con i loro clienti ogni giorno. Non possiamo essere come rompere le loro cose muovendoci troppo velocemente o cambiandole così velocemente che non sanno nemmeno più come usarle. Sarebbe sbagliato. Abbiamo dei vincoli, ma all'interno di quei vincoli, dovremmo assolutamente muoverci il più velocemente possibile.

Dove entra in gioco il legale

Liam Geraghty: E ci stiamo muovendo il più velocemente possibile in questo episodio. Successivamente, Intercom, Senior Counsel, Meena Polich. Meena fa parte del nostro team legale con particolare attenzione al prodotto e all'ingegneria. Nel gennaio 2021, Meena e Jamie hanno discusso di come i team legali e ingegneristici possono lavorare insieme.

"Siamo qui a marciare al passo con l'azienda e tutti i nostri clienti per arrivare dove dobbiamo andare in modo responsabile senza rallentare nessuno"

Meena Polich: Per noi è davvero importante capire il prodotto. Come possiamo eventualmente consigliare l'azienda su quali normative avranno un impatto su di noi o quali leggi dobbiamo seguire se non comprendiamo effettivamente cosa vendiamo? A un livello molto basilare, da un punto di vista strategico, dobbiamo capire non solo cosa vendiamo ora, ma cosa vogliamo vendere e come vogliamo posizionarci e crescere. In questo modo, possiamo iniziare a costruire proiezioni delle cose che dovremo tenere d'occhio dal punto di vista legale. E solo assicurandoci di essere qui in una sorta di marcia a passo serrato con l'azienda e tutti i nostri clienti per arrivare dove dobbiamo andare in modo responsabile senza rallentare nessuno. Da un approccio più tattico, comprendere i valori e il prodotto dell'azienda è estremamente utile per negoziare con i clienti e persino con i fornitori. Mi mette in una posizione di leva molto migliore quando capisco cosa stiamo cercando di fare. E poi, posso spiegare ai nostri fornitori: "Dato che stiamo cercando di farlo, abbiamo bisogno che tu sia in grado di farlo".

Al contrario, quando sto negoziando con i clienti, molte volte, le persone dall'altra parte del tavolo sono altri avvocati o agenti di approvvigionamento, che sono tecnici, se non meno, di me. E così, essere in grado di spiegare cosa fa il prodotto come l'avvocato che sta dicendo: "Senti, so quali sono le tue preoccupazioni dal punto di vista legale della gestione del rischio, ma ecco come funziona effettivamente la piattaforma. Ecco come funziona effettivamente il prodotto nella pratica. Ed è per questo che non svelerà questo rischio di cui sei preoccupato. Non scatenerà quel rischio di cui sei preoccupato.

"La mia prima priorità è aiutare la ricerca e lo sviluppo a capire che non sono qui per far deragliare gli incredibili progressi che stiamo facendo"

Jamie Osler: Immagino che funzioni in entrambi i modi, giusto? Se la R&S ha una migliore comprensione del tipo di panoramica legale di alto livello di dove potrebbero essere le aree di interesse, li aiuta a evitare di fare cose o costruire prodotti involontariamente rischiosi o in violazione di tali leggi.

Meena Polich: Sì, assolutamente. E questa è la cosa più importante da cui prendere o cercare di concentrarsi mentre si costruisce il rapporto legale con la ricerca e lo sviluppo. La mia prima priorità è aiutare la ricerca e lo sviluppo a capire che non sono qui per far deragliare gli incredibili progressi che stiamo facendo e il mio team non è qui per impedirci di continuare ad andare sul mercato con prodotti eccellenti. Il nostro team è qui per assicurarsi che, man mano che cresciamo e diventa più difficile tenere sotto controllo tutto ciò che fa ogni individuo nell'azienda, continuiamo a farlo in modo etico e continuiamo a farlo entro i confini della legge. E quando possiamo, cerchiamo di gestire quel rischio.

Questo è uno dei motivi per cui la conformità in base alla progettazione è così importante. Se teniamo presente i requisiti di conformità o le aspettative di conformità e progettiamo in base a questi, molte volte, le modifiche al design che apportiamo saranno cose che andrebbero effettivamente a vantaggio dei nostri profitti. Potrebbe esserci un costo iniziale in termini di allocazione delle risorse, ma nel lungo periodo, e nemmeno nel super lungo periodo – in molti casi, entro sei mesi o un anno dall'uscita di quella funzione – vedremo un vantaggio incredibile in termini di crescita dei ricavi e dei tipi di lead che abbiamo generato e di attrazione dei clienti perché si fideranno di noi.

Liam Geraghty: Ringrazio Jamie Osler, che ha creato Engineer Chats , il suo nuovo host Brian Scanlan e tutti gli ospiti di oggi che ci hanno gentilmente concesso di mettere all'esterno le loro chat interne. Se ti è piaciuto lo spettacolo di oggi, perché non lasciarci una recensione o darci un grido sui social. Ci piace vedere e sentire cosa ne pensi. Questo é tutto per oggi. Torneremo la prossima settimana con un altro episodio di Inside Intercom.