Entrevista: Slack CTO explica a estratégia tecnológica da empresa em sua busca para livrar o mundo do email

Empresa de tecnologia de bate-papo e colaboração no local de trabalho A Slack deverá se tornar uma empresa pública na quinta-feira, com implicações para uma ampla variedade de empresas na região de Seattle e além. A Microsoft é a principal concorrente do Slack com seu serviço de equipes, e o Slack é um grande cliente da Amazon Web Services. E muitas empresas que vendem tecnologias para empresas estarão assistindo à estreia do mercado de ações do Slack para avaliar seu próprio potencial nos mercados públicos.

Então, como o Slack trabalha por trás do mercado? cenas? Neste episódio do Podcast GeekWire, apresentamos uma conversa com o co-fundador do Slack, Cal Henderson, diretor de tecnologia da empresa, gravado durante o recente GeekWire Cloud Summit.

Henderson estava anteriormente com a equipe de engenharia do Flickr como arquiteto chefe de software, escreveu o best-seller da O'Reilly Media, “Building Scalable Websites”, e foi pioneira no uso de APIs da web. Devido às regras regulatórias, ele não foi capaz de abordar diretamente a estréia pendente da empresa como uma empresa pública, mas ele forneceu uma visão dos bastidores da infra-estrutura técnica do Slack e sua abordagem à engenharia, além de sua cultura mais ampla e sua ambições para livrar o mundo do e-mail.

Ouça a conversa acima, continue lendo uma transcrição editada e assista ao vídeo abaixo.

Então você passou por alguns pivôs fascinantes com Stewart Butterfield e equipe. Você fez vários videogames e entrou em outros produtos. Conte-nos sobre sua jornada desde o começo, antes do Flickr, até o Slack hoje.

Cal Henderson: Eu tenho trabalhado com o mesmo grupo de pessoas e co-fundadores para Um par de décadas agora, e o que temos feito e o tipo de ambiente em que estamos trabalhando mudou significativamente ao longo do tempo, mas há definitivamente alguns padrões comuns. Começando em 2001, nós começamos uma empresa para fazer videogames na internet, o que era um momento terrível para fazer videogames na internet, porque não existiam tais coisas naquele momento. Ninguém tinha plugado os dois juntos, e nós falhamos totalmente em fazer isso na época, mas isso se transformou no Flickr, que na época, foi bastante bem sucedido.

Em seguida, avance um pouco depois da aquisição. pelo Yahoo em 2005, e queríamos voltar e tentar fazer a mesma coisa novamente. A internet havia mudado muito nos cinco, seis anos antes: havia muito mais pessoas na web, havia o surgimento das redes sociais e as pessoas estavam acostumadas a interagir umas com as outras on-line. Naquela época também era a ascensão da Zynga, e por um breve momento, parecia que os jogos online também seriam uma fonte real de receita, então era fácil levantar capital na época para fazer jogos.

Nós tivemos este grande plano. Finalmente poderíamos trazer ao mercado essa visão que tínhamos anos antes e que não conseguíamos realizar na época. Desta vez, tínhamos tudo para nós: conseguimos captar recursos, a tecnologia avançou muito, havia muito mais pessoas na internet e as pessoas estavam dispostas a pagar pela internet. Nós falhamos totalmente em executar com tudo o que está acontecendo para nós. Acho que somos muito ruins em criar videogames, no final das contas.

Mas o que fizemos a sorte foi outro pivô em outra coisa. Slack veio a ser porque estávamos trabalhando no projeto do jogo, que foi chamado de Glitch na época e provavelmente ninguém aqui jogou Glitch - é também por isso que ele não existe mais - quando estávamos tentando fazer o jogo, estávamos divididos entre São Francisco e Vancouver. Criamos um conjunto de ferramentas para podermos nos comunicar e colaborar melhor. Passamos quatro anos trabalhando neste jogo, construímos todo o negócio em torno dele. Todo tipo de fluxo de trabalho desde o desenvolvimento até a criação de obras de arte, a construção de níveis, a contabilidade e o suporte ao cliente, incorporamos tudo a essa ferramenta que estávamos construindo.

Foi uma ótima maneira de trabalhar juntos, e nós realmente não pensamos nisso como se estivéssemos criando um produto; só queremos trabalhar e somos desenvolvedores, por isso usamos software para fazer isso. Quando encerramos o jogo e estávamos tentando pensar sobre o que queríamos fazer a seguir, percebemos que, independentemente do que fizemos em seguida, queríamos continuar trabalhando juntos da mesma maneira. Não foi apenas o conjunto de ferramentas; foi a maneira em que estávamos trabalhando juntos. Isso nos tornou muito mais produtivos, fez o trabalho parecer diferente como uma equipe de pessoas espalhadas por diferentes escritórios em todo o mundo, e pensamos que, se gostássemos disso como uma empresa de 40, 50 pessoas na época, talvez outras empresas coisas parecidas achariam essa ferramenta útil também.

É daí que vem o Slack.

TB: Você usou isso por tanto tempo internamente, você quase teve este teste beta privado muito extenso, você era tão estável em termos de até mesmo a interface do usuário de muitas maneiras. Henderson: Nós tivemos o modelo há quase 10 anos agora de essa maneira de se comunicar. Eu acho que há dois conceitos centrais no coração do produto em que nos deparamos. E nenhum deles, isoladamente, era algo totalmente novo. O primeiro deles estava usando canais em vez de usar e-mail. Ou seja, em vez de comunicação um-para-um por padrão, organizar a comunicação, a discussão e o trabalho em torno do tópico, seja tópico ou projeto ou equipe, e é uma ideia muito direta, mas acho que a coisa muda é essa ideia Nós temos usado o e-mail no local de trabalho há cerca de 40 anos, mais ou menos, e tem um monte de suposições embutidas nele. É um meio de comunicação um por um, por padrão; você aborda as pessoas para as quais você está enviando e é um modelo de push. Mudamos para mais de um modelo de recepção com canais em que você escolhe o que deseja se inscrever.

Mas, mais do que isso, quando você entra em uma organização que usa e-mail, começa no primeiro dia com um caixa de entrada, e você tem zero contexto do que aconteceu antes. Se você deixar essa organização ou essa equipe, as informações bloqueadas na sua caixa de entrada acabarão. À medida que o trabalho se torna cada vez mais complexo e mais colaborativo, e as pessoas participam de projetos ou equipes e as deixam ao longo do tempo, a capacidade de ter um registro preservado independente das pessoas envolvidas é enorme.

Então, do outro lado, estão os aplicativos e o aspecto da plataforma. Acho que uma das tendências mais interessantes, que está muito ligada a tópicos relacionados à nuvem, sobre os quais falaremos foi a explosão real de software usado no local de trabalho nos últimos 10 anos. Em um estudo da Netskope, que tem agora dois anos de idade, a empresa média e de grande porte está usando mais de mil aplicativos. Isso é apenas um número insano de diferentes partes do software. Não tenho certeza se poderia nomear mil partes diferentes de software, e essa é a média para uma empresa de médio porte.

Essa é uma grande mudança de uma década ou duas décadas atrás. O que permitiu isso, tenho certeza de que vamos falar sobre isso, mas onde as empresas estão usando mais e mais softwares, onde o trabalho acontece se tornou cada vez mais fragmentado. É como o trabalho dessa equipe acontece neste aplicativo, o trabalho dessa equipe acontece nesse conjunto de aplicativos e esse departamento usa esse conjunto de aplicativos para realizar o trabalho. Isso significa que o trabalho é mais fragmentado. Acho que um dos padrões em que nos deparamos foi, e se pudermos reunir todo esse trabalho juntos na camada de comunicação? TB: Absolutamente. E o Slack agora tem mais de 10 milhões de usuários diários médios, então, é claro, você tem coragem e, como mencionamos, em breve você será uma empresa pública. Vamos falar sobre os desafios técnicos que você enfrentou durante o lançamento de 2013. Que tipo de decisões você tomou naquele momento tecnicamente e o que esse público pode tomar delas? Henderson: Uma delas é que quando começamos a empresa, não acho que tivéssemos uma visão de quão grande poderia ser, de quão aplicável em geral poderia ser, porque quando estávamos construindo para nós mesmos, sabíamos que tínhamos construído um produto que funcionava bem para equipes exatamente como nós, de entre cinco e cem pessoas e, inicialmente, de equipes de engenharia. Programas. Sabíamos que funcionava bem para nós e achamos que funcionou bem para esse caso de uso. Acho que ficou muito claro para nós que funcionou em todas as diferentes funções de trabalho e tamanhos de empresa também.

Então, eu estava dizendo, para começar, nós definitivamente não criamos pensando que teríamos mais de 10 milhões de usuários ativos diariamente ou além. Para praticamente qualquer tipo de software que qualquer empresa está construindo fora de algumas empresas gigantescas, a coisa mais importante que você precisa fazer é achar que o mercado de produtos se encaixa rapidamente. Não é sobre se isso funciona perfeitamente em todos os eixos possíveis, qual é o mercado total endereçável que veremos nos próximos 20 anos e se basear nisso, porque a primeira coisa que você cria não é a coisa certa. A primeira versão que colocamos nas mãos das pessoas definitivamente não era a coisa certa. Precisávamos ser capazes de repetir isso muito rapidamente.

O foco definitivo nos primeiros dois anos foi encontrar o que se traduziria do que havíamos construído e trabalhado para o que funcionaria para mais pessoas. . Então, interagindo rapidamente, entendendo como as outras equipes funcionavam e quais seriam as frustrações, e realmente aprimorando esse mercado de produtos.

Sou engenheiro, estou muito empolgado com novidades e interessantes e tecnologias excitantes, e estou definitivamente interessado no lado do sistema distribuído em larga escala. Eu acho que pode ser super viciante ir e construir algo para escala massiva, que você nunca verá, e encontrar esse equilíbrio é realmente difícil. Você não quer pintar sozinho em um canto e ser capaz de construir algo que você nunca será capaz de entregar em escala, se você for bem sucedido, mas é a iteração no início que é a chave.

TB: Então você está na nuvem agora. Na verdade, sabemos que você trabalha principalmente no Amazon Web Services. Você teria sido capaz de escalar na medida em que você tem e eficientemente como você tem sem essas tecnologias de nuvem? Henderson: Teria sido muito, muito mais difícil. Quando começamos a primeira empresa e construímos o Flickr, tínhamos nosso próprio data center físico, e precisávamos comprar servidores, e estávamos no Canadá, então tivemos que comprar servidores e depois dirigir até a fronteira para ir e falar com os funcionários da alfândega para tirá-los da alfândega e depois levá-los para o data center, e instalá-los em um CD, e então perceber que não temos cabos de rede suficientes, então vá até a loja e comprar cabos de rede. Isso foi um quarto a um terço de todo o nosso tempo era apenas o trabalho indiferenciado inútil que tivemos que fazer.

O movimento de ter seus próprios servidores físicos para a pequena escala para se mudar para a infra-estrutura como um serviço ou plataforma como serviço foi uma incrível economia de tempo. Ele foi realmente a única coisa que tem impulsionado a capacidade para essa explosão em categorias de software, porque as empresas de nicho de SaaS que simplesmente não podia de existiam há uma década sem AWS, a Google Cloud Platform, Azure agora podem existir porque você simplesmente não tem que coloque esse investimento de capital inicial ou investimento maciço de tempo para poder chegar ao ponto em que você está provando seu produto e encontrando o mercado de produtos adequado. TB: Se você estivesse lançando algo como Slack hoje, o que você faria diferente, considerando os erros que você cometeu naquela época, mas também a evolução da nuvem e das tecnologias disponíveis desde então? Henderson: Eu acho que no primeiro, com certeza, fizemos muitos erros de produto e agora temos muito mais dados. Acho que não faríamos nenhum dos erros que cometemos. Mas eu acho que o lado da nuvem é mais interessante e é isso que mudamos muito mais da infraestrutura como um serviço há 10 anos para mais da plataforma como um serviço, e avançando mais na pilha, e sendo mais serviços hospedados em vez de apenas: “Forneceremos máquinas virtuais com muita rapidez”.

É uma continuação da mesma coisa. É, “O que podemos fazer para evitar fazer o trabalho indiferenciado que todo mundo faz, que não nos faz qualquer particularmente melhor na coisa que está entregando?” Agora usamos Kubernetes, e nós usamos mais alto nível hospedado serviços da AWS , por exemplo. E isso só nos permite passar mais tempo com as coisas que são únicas para nós como um serviço ou uma empresa

TB:. Eu sei que circa 2015, houve um estudo de caso AWS, e você estava confiando pesadamente no EC2 na AWS. Essa ainda é uma parte essencial da sua infraestrutura? Henderson: Oh, definitivamente ainda é uma parte essencial da nossa infraestrutura. Eu definitivamente estava historicamente cético em relação aos serviços de nível superior. Acabamos de começar a adotá-los cada vez mais ao longo do tempo. Seja no lado do data warehouse, acho que foi provavelmente onde fizemos uma grande mudança antes, há algum tempo, para mais serviços hospedados, mas, em termos mais gerais, estamos avançando na pilha. É o mesmo de todos os principais provedores de nuvem.

TB: Desse modo, quais são as tecnologias fundamentais da nuvem, as principais coisas em sua caixa de ferramentas hoje no Slack?

Henderson: Usamos muitos serviços e tecnologias diferentes. Acho que os Kubernetes e os contêineres foram grandes para repensar a forma como tornamos os engenheiros eficientes e produtivos. É o quanto de controle de serviços implantados podemos colocar nas mãos de engenheiros? O modelo do passado era você ter uma equipe de operações, e isso fez a transição para todos, um pouco de DevOps, para mais você não realmente pensar tanto como operações. Parte do software de construção está executando e implantando agora. Acho que reduzir a barreira técnica para sermos capazes de investir, colocando mais ferramentas nas mãos de seus desenvolvedores, e que, sendo a expectativa de “você constrói e apóia esse serviço”, realmente mudou a forma como pensamos TB: Sabemos disso no S1, e sei que você não pode comentar sobre isso, mas sabemos que o Slack gasta um mínimo de US $ 50 milhões por ano com a AWS. Visão geral, em resumo, como você pensa sobre problemas como operar em várias nuvens, bloqueio de fornecedores, custos de troca e todo o conceito de querer permanecer flexível, mas também querer ter o máximo de eficiência? Como você pesa essas coisas nas operações do Slack?

Henderson: Se você pensar sobre isso do ponto de vista da eficiência, o tempo do engenheiro / desenvolvedor é realmente super caro. A ideia de que sintonizaremos a capacidade de iteração rápida e de ciclos de desenvolvimento rápidos sobre qualquer outra coisa é provavelmente o que estamos concentrados. Esse é o verdadeiro diferencial.

Definitivamente, há empresas muito específicas em que talvez não faça sentido usar um provedor de nuvem. Você precisa de um recurso muito particular em grande escala, ou você precisa de algum tipo de serviço ou hardware que não exista na nuvem, mas para praticamente qualquer tipo de negócio de pequena e média escala, faz muito sentido porque seu desenvolvedor os custos são altos e seus custos de oportunidade são os mais altos. É como o que você poderia estar fazendo em vez de pensar em como otimizar os custos de maneira muito pequena? No grande esquema das coisas, você pode estar pensando em como chegar ao mercado mais rapidamente, como fornecer a próxima iteração para seus clientes. TB: E se você dissesse: "OK, AWS, queremos mudar para o Google Cloud ”, o quão tecnicamente factível é isso na realidade? Porque na superfície, parece que muitos desses serviços em nuvem são semelhantes, pelo menos de propósito. Esse tipo de migração é possível, pragmático ou prático? Henderson: Os serviços, ou pelo menos os três grandes serviços, são mais parecidos do que nunca, e cada um deles tem uma coisa especial em que são melhores. ou que eles visam mais. É muito trabalhoso e muito dependente da escala, mas à medida que a sua aplicação, à medida que o seu serviço se torna mais e mais complexo, você fica cada vez mais dependente dos pequenos detalhes operacionais de como esse fornecedor específico funciona ou de como funciona esse serviço específico. É como se, de forma geral, esse serviço de fila fosse o mesmo que esse serviço de fila é o mesmo que esse serviço de fila, mas as características exatas sob carga ou sob condições de falha são coisas que você acaba criando. Então, definitivamente há um custo para fazer isso.

TB: Como você pesa isso em termos do volume de carga de trabalho que você coloca em um único fornecedor?

Henderson: A coisa em que estou mais concentrado é a velocidade do desenvolvedor. É com que rapidez as pessoas podem interagir nele? Por algum tempo, o GCP como provedor estava à frente na oferta de serviços ML e AL. Então, se eu tiver uma equipe que queira construir algo em torno dessas tecnologias, o GCP será a maneira de fazer isso naquele momento específico. É que a velocidade de entrega de iteração é mais importante do que qualquer outra coisa. TB: Vamos falar sobre AI e ML porque tem sido, obviamente, um tema recorrente e eu acho que é talvez o serviço em nuvem de alto nível mais comum que muitas pessoas falam, usam e implementam. Até que ponto você está usando inteligência artificial e, mais especificamente, aprendizado de máquina no Slack que aqueles de nós que usam o Slack experimentam todos os dias? Henderson: Eu acho que a resposta é ao mesmo tempo interessante e meio chata. que é em muitos dos recursos que você usa, mas eu acho que o que nós começamos a fazer, e o que mais e mais pessoas estão começando a fazer, é usar o ML para personalização em pequena escala. É para tornar algo um pouco mais inteligente e um pouco melhor. É sempre que há uma classificação de algo, seja a classificação dos resultados da pesquisa, ou um canal quando você muda para ele, ou o nome da pessoa no preenchimento automático quando você vai para alguém DM, está certificando que é um pouco personalizado para você sobre o seu comportamento passado e um monte de outros sinais que registramos.

Acho que o efeito que realmente estamos começando a ver do aplicativo ML em uma ampla variedade de produtos está tornando as pequenas interações um pouco melhores. É esse tipo de magia de fundo que você não necessariamente ... Não é como uma coisa grande e chamativa; está tudo ficando melhor.

TB: Você vê isso mudando com o tempo? Em outras palavras, poderia haver um enorme avanço que me permitiria encontrar aquela maldita mensagem que enviei há três dias que estava no canal aqui embaixo enterrada? É aí que eu quero o AI e o ML.

Henderson: Quero dizer, esse é o tipo de sonho de IA que é seu assistente de robô que é melhor que um ser humano, e faz tudo perfeitamente. Eu não acho que nós não vamos chegar lá de forma incremental. Não vai ser nem um pouquinho melhor até que, de repente, é como uma inteligência de nível humano. Isso vai ser uma função de etapa estranha em algum momento, mas eu acho que há um grande ganho incremental que podemos obter ao longo do caminho de apenas tornar as coisas um pouco melhores com o tempo.

Nossas metas, do ponto de vista do produto, são: quanto mais tempo você usa o produto, e quanto mais informações você coloca nele, e quanto mais sinal podemos reunir, melhor ele pode responder a você e entender, como quando você acorda Pela manhã, esta é a primeira pessoa de quem você sempre leu. Isso é provavelmente alguém que é realmente importante para você, é a rapidez com que você responde a eles, estes são os tópicos que você fala, coisas assim, para que possamos personalizá-lo para você. Mas acho que haverá muitas mudanças incrementais ao longo do tempo. TB: Tem sido interessante no lado do varejo, obviamente longe da colaboração corporativa, ver como os concorrentes de varejo da Amazon tomam decisões na nuvem com base em suas preocupações sobre outro setor de seus negócios. É claro que você está em uma situação interessante porque a Microsoft tem o Azure e depois concorre com o Slack via Teams e Office 365. Agora, a Amazon se interessa por aplicativos de colaboração, mas eles ainda não aceitaram diretamente o Slack. Você reconsideraria seu relacionamento com a AWS se Jeff Bezos publicasse um anúncio de página inteira levando o Slack?

Aqui está uma maneira diferente de ver o @SlackHQ na véspera de seu IPO. A @GuillaumeWiatr de @metahelm criou esta visualização do co-fundador da Slack CTO @ iamcal's session no GeekWire Cloud Summit. Ouça o podcast ou assista a um vídeo completo aqui. https://t.co/SwukJFHOz1pic.twitter.com/6L5esy8iIm- toddbishop (@toddbishop) 19 de junho de 2019

Henderson: Você sabe, usamos um pouco do GCP e também um pouco do Azure . Eu acho que nós pensamos sobre isso de forma bastante independente. TB: Você está confiante o suficiente no firewall de negócios da Amazon, como se fosse, basicamente, dar esse salto se a Amazon competisse diretamente com você?

Henderson: Você sabe, eu acho difícil imaginar a Amazon usando a AWS como uma alavanca contra os concorrentes porque é um negócio grande e importante para eles, e isso seria um movimento ousado e estranho.

TB : Você foi contratado por Stewart Butterfield depois de invadir a lista de discussão de sua empresa de videogames. Isso é um apócrifo ou é uma verdadeira empresa? Henderson: Quero dizer, “invadir” é um termo forte. Eles simplesmente não alteraram a senha do administrador padrão. Mas eu estava super interessado neste jogo original em que ele estava trabalhando e estava tentando ganhar todo o poder que pudesse para descobrir mais sobre a empresa. Foi fascinante na época, estava em uma espécie de era antes das APIs da web, e eu estava realmente interessado em construir algum tipo de visualização de dados e ferramentas ao redor do jogo. Eu queria entender como os internos funcionavam para que eu pudesse criar uma API pública sobre ela. Entrar na lista de discussão interna foi definitivamente a maneira de fazer isso. Eu não diria necessariamente que essa é a melhor ideia, mas na época, certamente essa conversa estava indo.

TB: Isso é ótimo. Eu ia lhe perguntar se você recomendaria essa tática aos candidatos a emprego hoje. Henderson: Você sabe, bem, eu acho que o equivalente agora, como a indústria amadureceu bastante, são programas públicos de recompensa de bugs. e é definitivamente assim que acabamos conhecendo muitas pessoas no espaço de segurança da informação. TB: Sim, absolutamente. Quando você está contratando para a equipe de engenharia do Slack, quais são as principais habilidades, experiência ou, talvez mais importante, a mentalidade que você está procurando nas pessoas que está contratando?

Henderson: Ah, essa é uma boa pergunta. Eu acho que isso mudou muito ao longo do tempo porque nós passamos de uma empresa de quatro pessoas para mais de 1.500 pessoas hoje, então as pessoas que você contrata na primeira semana são muito diferentes das pessoas que contratamos no ano 10 da empresa neste momento.

Uma das coisas em que realmente nos concentramos, tanto por causa do produto como pela forma como pensamos em construir software, é ser colaborativo como um atributo de candidatos que nós olhe para. Como o trabalho em geral tornou-se cada vez mais complexo, tanto pelas pressões externas variáveis ​​dos mercados e tecnologias em movimento mais rápido do que nunca, quanto pelas pressões internas de diferentes expectativas em torno do relacionamento das pessoas com o local de trabalho, cada vez mais trabalho se tornou trabalho em equipe. À medida que mais e mais trabalhadores se tornam trabalhos de conhecimento, e outros trabalhos foram automatizados, especialmente em nossa indústria, o mito do programador solitário que vai para o porão e martela um teclado por um mês, e sai com algum tipo de de gem perfeito de software, é tão longe da realidade do desenvolvimento em larga escala hoje. É um esporte de equipe que a colaboração é realmente essencial. TB: Em termos de tecnologia pura, dois, três anos fora, há coisas específicas em que você aposta ou pensa quando está fazendo essas entrevistas, trazendo as pessoas e construindo o produto? Henderson: Sim. Eu acho que a taxa de mudança tem realmente aumentado, especialmente nos últimos cinco anos, em tecnologia. Muitos dos padrões de como as pessoas constroem hoje, seja em qualquer camada da pilha, mudaram completamente nos últimos cinco anos. A Slack não é uma empresa muito antiga, com certeza, mas quando olhamos, digamos, nosso principal cliente web que a maioria dos nossos clientes usa, a tecnologia que construiríamos com a de hoje simplesmente não existia quando começamos a construir a empresa. .

Temos um grande foco em garantir que estamos usando tecnologia moderna, mas não necessariamente de ponta, porque isso é extremamente impactante quando olhamos para o recrutamento. É como qual é o conjunto de habilidades que a maioria das pessoas, digamos, desempenha nas funções de engenheiro de front-end, com qual tecnologia elas trabalharam e o que elas podem trazer para a organização? Se estamos usando coisas totalmente únicas em maneiras totalmente únicas de trabalhar e construir com as quais ninguém está familiarizado, isso apenas torna o recrutamento e a integração muito mais difíceis.

Então, enquanto estamos definitivamente, por um lado, olhando para onde as tendências da tecnologia estão indo, estamos muito focados no que tem sido largamente adotado nos últimos dois anos que podemos adotar também. TB: Agora, é claro que o Slack também é uma plataforma . Ao pensar sobre a API do Slack, que tipos de aplicativos você gostaria de ver criados no Slack no futuro? Estou pensando particularmente nas lacunas que você gostaria de ver e nas coisas que os desenvolvedores dessa audiência podem aproveitar.

Henderson: Sim. Quando eu penso pessoalmente em como eu uso o Slack para fazer o trabalho, eu acho que os melhores usos da plataforma têm sido em torno de como você pode pegar um software que você já usa para uma determinada vertical, para alguma tarefa específica que você e torná-lo um pouco melhor, usando-o com o Slack, torná-lo um pouco mais eficiente, torná-lo um pouco mais preciso, torná-lo um pouco mais rápido, torná-lo melhor.

vem à mente é a maneira que usamos o Google Docs para uma tonelada de coisas internamente. Se estou compartilhando uma planilha, uma apresentação ou um documento, ele está no Google Docs. Se você compartilhar um documento do Google por e-mail, colará um URL e alguém receberá o URL. Tanto faz. Se você colá-lo no Slack, retiraremos o título e mostraremos a primeira página da fila para que você saiba qual é o conteúdo do documento. Mas, o que é mais importante, se eu enviar o URL para um documento do Google, o Slack me dirá que ainda não dei sua permissão. você gostaria que eu consertasse isso agora antes de você abrir? Acho que isso provavelmente me salvou coletivamente cerca de 500 horas nos últimos cinco anos, e isso por si só torna o Google Docs mais agradável.

Henderson: Ou usamos o JIRA para rastreamento de problemas. Toda vez que eu digito um número de caso do JIRA no Slack, em vez de apenas ser o número do caso, nós piscamos para o JIRA e retiramos o título e o status. É pensar sobre o software que você usa todos os dias, como ele pode se tornar mais eficiente, um pouco melhor, no contexto da discussão quando você está trabalhando com outras pessoas. Como você pode enriquecer esse uso desses aplicativos?

TB: É interessante porque isso realmente traz de volta a visão original de Stewart e sua visão original quando você lançou a empresa, fazendo do Slack o hub, trazendo esses recursos para o Slack, em vez de simplesmente operar de forma independente em outro aplicativo.

Henderson: Sim, acho que é realmente o contexto de reunir todos os diferentes aplicativos que você usa para fazer um trabalho e trazê-los para um único lugar.

TB: Sim. Uma última pergunta aqui e estamos sem tempo, infelizmente, mas você é muito público sobre o fato de ser daltônico. E você fala sobre isso no seu site, IAmCal.com. Eu imagino que isso deve lhe dar um grau real de empatia com os usuários de tecnologia em geral e com a questão da acessibilidade em geral. Como isso influenciou sua vida, sua carreira como engenheiro, e o que você poderia transmitir a esse público sobre isso? Henderson: Essa é uma ótima pergunta. Um grande número de pessoas, especialmente homens nos EUA, é daltônico, como um em cada oito tem alguma forma de daltonismo, então é estranho não ser uma deficiência, porque muitas pessoas têm esse tipo de coisa. Mas eu acho que o principal resultado é que todo mundo com quem trabalho está cansado de me ouvir dizer que eu não posso dizer a diferença entre duas linhas em um gráfico.

Mas eu acho que é esse tipo de realização que há um monte de coisas extras que vão para o design de software em escala para as pessoas usarem para torná-lo mais acessível, e especialmente com o produto que construímos, o Slack não funciona a menos que todos em sua equipe possam usá-lo. Não funciona se você tem alguém que é daltônico e não pode realmente ler qualquer texto, ou alguém com baixa visão, ou alguém sem nenhuma visão e precisa usar um leitor de tela, ou alguém usando dispositivos auxiliares, ou isso não é uma deficiência, mas alguém usa o Linux. Acho importante pensar em todos esses aspectos porque estamos criando um aplicativo que precisa funcionar para todos ou não funciona para ninguém.

TB: Certo. Que 10 milhões precisam se tornar exponencialmente maiores nos próximos anos. TB: O que você gostaria de transmitir a essa multidão de líderes de negócios, tomadores de decisão de negócios e desenvolvedores, além de engenheiros que não temos? Ainda falamos sobre, como uma observação final aqui, Cal? Henderson: Eu acho que voltar para a parte da nuvem que falamos um pouco é que quando você está no início de fazer software ou produto empresa iniciante, a coisa mais importante a fazer é otimizar a velocidade de iteração e encontrar o mercado de produtos em primeiro lugar. É fácil ser influenciado por tecnologia interessante em escala, ou tecnologia interessante no limite, ou o que poderia ser distante no futuro, mas realmente otimizando para isso, como você pode obter esse loop iterativo rapidamente e alavancar os provedores e a tecnologia? que estão disponíveis para ajudar a acelerar isso é o que vai fazer a diferença entre você gastar muito tempo em algo que não dá certo, como fizemos algumas vezes com videogames, e encontrar esse mercado de produtos encaixar e iniciar esse crescimento.

Via: Geek Wire