A sua empresa é Engineering-First ou Product-First?

2020 Jan 28

Uma das maiores vantagens que eu tive ao longo da minha carreira foi ter trabalhado em diferentes tipos de empresas atuando com Consultoria ou mesmo em empresas do tipo Holding. Acho que esses tipos de empresa te dão um tipo de exposição que é muito difícil de se encontrar em empresas convencionais (e.g. um negócio com uma única vertical).

Contudo, por mais que estes negócios tivessem dinâmicas diferentes, depois de um determinado tempo atuando em cada uma delas, uma distinção bem clara na qual essas empresas utilizavam a engenharia/tecnologia começava aparecer.

Estas distinções que eu via não era somente dentro do campo estritamente técnico, mas sim dentro do aspecto cultural da organização.

E aqui quando eu falo cultura, eu remeto a definição da Wikipedia que usa a citação direta do Edward B. Tylor no qual ele coloca que a cultura é “todo aquele complexo que inclui o conhecimento, as crenças, a arte, a moral, a lei, os costumes e todos os outros hábitos e capacidades adquiridos pelo homem como membro de uma sociedade”.

Transpondo essa definição para o contexto corporativo, a cultura de uma empresa é determinante na forma na qual as pessoas são contratadas, na avaliação dos comportamentos esperados, estrutura de incentivos e principalmente na forma em que as decisões são tomadas e os rumos estratégicos são decididos.

Estas abordagens que em um primeiro momento podem parecer coisas com baixa relevância, tem um peso muito grande seja para as organizações e principalmente para as pessoas.

Ao final deste post eu pretendo deixar clara a ideia de empresas com abordagens Engineering-First e Product-First, falar um pouco das suas vantagens e desvantagens e do porquê isso é relevante em termos de gestão de carreira [1], [2].

A ideia aqui não é falar que abordagem A é melhor que B; mas sim fazer um paralelo e mostrar um pouco das distinções entre essas abordagens e as vantagens e potenciais desafios.

Engineering-First e Product-First: Duas abordagens

Disclaimer: Diferente do que pode parecer essas abordagens não são excludentes. Isto é, a adoção de uma ou de outra abordagem não significa explicitamente que a organização só faz A ou B. Na verdade as melhores organizações são aquelas que conseguem alternar de forma quase que adaptativa estas duas abordagens dependendo da estratégia e o que deve ser alcançado.

Escrevo isto devido ao fato de que uma coisa comum que eu venho notando em algumas discussões com alguns colegas é que a falta de conhecimento do tipo de empresa que está se entrando juntamente com o fato de falta de autoconhecimento acaba levando a uma espiral de frustrações ao longo do tempo em que sempre os dois lados estão insatisfeitos e com isso levando ao inevitável boreout, pedidos de demissão, stress corporativo e similares.

Em um caso a parte de produto fica frustrada por conta de constantes atrasos e reclamações, seja a parte de engenharia devido a falta de uma correta conceptualização do projeto ou escopos. Isto é, uma situação de eterno atrito.

Desta forma entender os tipos de empresas é o primeiro passo para sair desta espiral de frustrações e atritos. Mas primeiramente vamos a algumas características relativas a cada tipo de abordagem.

Paradigmas e Características

Empresas Engineering-First

Empresas Engineering-First são empresas que têm na sua engenharia e capacidade de inovação tecnológicas as suas principais vantagens comparativas. Geralmente por causa desses fatores algumas destas empresas são muito dominantes chegando às vezes a construírem monopólios quase que invencíveis (e.g. Siemens, Airbus, Google, Facebook, Amazon) devido de que estas empresas usam novos métodos (ou métodos clássicos) de engenharia e tecnologia não para alavancar o seu Core Business mas como forma de sobrevivência.

Geralmente são empresas que trabalham com plataformas/infraestrutura como principais serviços, ou empresas que têm a engenharia no centro do processo de inovação e conceptualização dos produtos. Ou seja, o negócio é voltado para a incorporação de tecnologias de ponta nos produtos ou formas mais eficientes de se fazer algo via otimização.

Em linhas gerais, aqui a abordagem é a engenharia vai fazer e o produto vai colocar em uma embalagem mais atraente e deixar o sabor mais palatável. Algumas das vezes estas empresas Engineering-First trabalham oferecem plataformas/infraestrutura do tipo missão crítica e produtos de alta complexidade tecnológica que não tem uma interface direta com o cliente final comum.

Essas empresas têm a engenharia/tecnologia em seu core business e uma estagnação ou defasagem tecnológica pode ser a diferença entre a glória e a bancarrota.

Alguns exemplos de empresas Engineering-First poderiam ser a Honda e Mercedes-AMG na parte de motores de Fórmula 1, Huawei na parte de plataformas de telecomunicações, Amazon Web Services no que se refere à parte de infraestrutura e a Airbus na parte aeroespacial.

Essas empresas têm uma cultura de engenharia extrema em que a otimização é levada ao extremo e pequenos ganhos fazem toda a diferença no resultado final, o que de certa maneira coloca uma pressão muito grande no grau de especialização necessário para fazer isso acontecer.

Empresas Product-First

Já as empresas Product-First caracterizam-se por serem organizações em que a tecnologia entra mais como elemento de alavancagem, otimização e escalabilidade para facilitar transações de negócios que não demandam tecnologia de uma maneira direta.

Grande parte das vezes estas empresas são extremamente pragmáticas em relação à tecnologia devido ao fato de que para estas empresas elas têm um problema de ordem maior para ser resolvido e a engenharia seria apenas uma ferramenta/meio para resolver esse problema.

Essas empresas geralmente trabalham centrados no consumidor final desde a conceptualização até a experiência do usuário final, e diferente da abordagem Engineering-First aqui há a inclusão de fatores humanos no resultado final.

Neste caso a engenharia entra nas empresas Product-First apenas para materializar o conceito definido na visão de produto de forma para ou alavancar ou escalar os seus processos de negócios.

Ou seja, a tecnologia pode ser usada para alavancar ou otimizar um processo, mas no final isso tem que fazer parte de um produto específico que irá satisfazer um usuário final, e este é o real Core Business da empresa.

Alguns exemplos de empresas Product-First poderiam ser Apple no que se refere a parte de computadores pessoais, Microsoft em sua linha de vídeo-games, Netflix na parte de distribuição de conteúdo e Spotify como um marketplace entre artistas e ouvintes de música/podcast.

A grosso modo, empresas Engineering-First são baseadas na ultra-otimização, escalabilidade, redundância, e do foco nos seus componentes de engenharia/tecnologia como core business; enquanto as empresas Product-First geralmente trabalham em como colocar a tecnologia para resolver algum tipo de necessidade humana através de produtos que as pessoas gostem e usem, ou seja, neste caso essas empresas usam a engenharia/tecnologia como suporte de suas operações e não como foco principal.

Já que temos uma definição do que são as empresas, eu vou tentar colocar alguns pontos do que eu vi ao longo do tempo em relação às vantagens e desvantagens de se trabalhar em cada tipo de empresa de forma não é exaustiva.

Engineering-First: Vantagens e Desvantagens

· Vantagens

Geralmente este tipo de empresa têm uma abertura bem grande para Research/PoCs para incorporação de novas tecnologias seja como novas formas de solucionar problemas latentes ou para ganhar performance e escalabilidade (e.g. Bell Labs).
Fine-Tuning/Otimização em algumas empresas são usadas como estratégias que se bem definida pode virar uma vantagem competitiva. Aqui não tem segredo: cada pequena otimização pode ter ganhos de escala muito grandes (e.g. aumento de throughput de uma plataforma, eficiência de um algoritmo novo de compactação que reduz necessidade de espaço, redes que têm a redução de latência, etc.)
Tende a atrair engenheiros com um grau de especialização maior em poucos aspectos, mas com um grau de profundidade muito maior (e.g. aqui seria o equivalente ao engenheiro responsável pela liga de titânio que faz parte da construção das blades de um motor de Airbus A320).

· Desvantagens

Parte do trabalho sempre será invisível, e pior: Este mesmo trabalho tende a mover com um grau de incerteza muito maior e com velocidade que pode ser muito menor em termos de ritmo de entrega;
Trabalhar em ambientes voltados para ganhos em otimização pode ser frustrante para quem quer trabalhar com inovações voltadas ao usuário final ou quem está saturado por conta de trabalhar no mesmo assunto por meses com pouco ou nenhum resultado (e.g. gastar 30.000% em pesquisa para ganhar os 3% finais).
Muita otimização pode levar a estagnação tecnológica dado que enquanto buscam-se os parâmetros corretos para algo, algum concorrente pode estar trabalhando em algo completamente novo (e.g. Airbus passando a Boeing com um paradigma totalmente diferente de engenharia)
Pode ser um pesadelo para Product-Engineers dado que como o trabalho em algumas vezes pode ser para fazer algo rodar melhor, o impacto no cliente final pode não ser tão perceptível
Pode trazer algo interessante tecnicamente e em termos de execução, mas pode ser pouquíssimo atrativo ao cliente final (e.g. Concorde, Windows Vista)
Over-engineering aqui pode ser um problema muito grande e quando não há comunicação com os times de produtos, e geralmente leva a desperdícios aumenta o custo de manutenção em um momento no futuro.

Product-First: Vantagens e Desvantagens

· Vantagens

Tem um enorme atrativo para Product-Engineers. Para quem gosta de ver o resultado do seu trabalho no final do dia impactando o usuário final e ter a real visibilidade e impacto do que está sendo feito uma empresa Product-First é o melhor lugar para se estar. Eu já estive em algumas e posso afirmar que ver algo funcionando e as pessoas usando a sua aplicação é algo que vale a pena.
Uma abordagem Product-First consegue capturar o timing do mercado para lançar novas features e /ou defender parte do Market Share, as vezes até ao mesmo tempo. Em alguns cenários de engenharia isso nem sempre é possível, dado que uma empresa Product-First deve ser capaz de adaptar-se em uma velocidade maior às tendências do mercado ou acompanhar os competidores se for o caso de uma competição mais acirrada para ganho ou manutenção de vantagem competitiva (e.g. usar Swift ao invés de Objective-C em projetos de iOS, para soluções de dados serem acessíveis em tempo real, ao invés de usar um SGBD tradicional usar Redis, etc)
Aqui a competição sobe o jogo de todos. Esse é um assunto que ao meu ver é pouco discutido que é como uma competição dinâmica pode elevar o jogo e todos, e para uma empresa Product-First competição (e elevação do seu nível de excelência operacional) é quase uma questão de quem sobrevive no mercado e de quem vai à falência.

· Desvantagens

Em muitas das vezes a otimização de engenharia fica em segundo plano devido a pipelines de produtos muito cheios ou falta de visibilidade do que deve ser feito. Em uma analogia simples, seria como um chef pedir uma reforma na cozinha por causa de condições de trabalho, mas ao mesmo tempo o dono do restaurante está satisfeito que o seu comércio está gerando lucro apesar dos problemas.
Se você gosta de ir a fundo em um tópico técnico (e.g. resolução de cenários técnicos world class) talvez estar em uma empresa Product-First não seja o ideal, pois na busca para a solução ideal talvez a sua empresa já esteja pensando em outro produto, outra implementação e muitas das vezes as soluções tecnicamente melhores perdem prioridade devido ao fato de que coisas novas precisam ser feitas;
Uma continuação do ponto anterior é que se as coisas não têm uma prioridade do ponto de vista de engenharia na concepção inicial, o Débito Técnico vai ser a lei. Isto significa que todo projeto já começa com um débito técnico a ser pago e ao longo do tempo os juros começarão a ser um problema real em caso de potenciais melhorias e manutenções. Isto é um dos pontos cegos mais comuns em projetos, dado que a resolução de um débito técnico muitas das vezes não aparece no backlog de produto, contudo a sua execução pode eliminar problemas latentes no produto que venham a causar um mau maior (e.g. indisponibilidades, vulnerabilidades de segurança).
E já que as empresas Product-First lida com usuários finais em grande parte das vezes, quando as coisas dão errado elas vão acontecer da forma mais trágica possível e a pressão tanto de entrega quanto de ajustar algo errada é quase que permanente quando se trabalha em uma empresa Product-First.

Mas isso realmente importa?

Bem dentro do que eu vivi no ambiente corporativo, importa e muito. Grande parte dos erros que eu cometi na minha carreira estão intimamente relacionados com o fato de uma falta de identificação da minha parte de que tipo de empresa eu estava entrando. Este fato me levou grande parte das vezes em uma estrada de frustrações, boredom/boreout com fricções extremas dentro do ambiente corporativo (todas em âmbito respeitoso).

Duas situações para exemplificar o meu ponto.

A primeira foi quando eu estava em uma empresa Engineering-First com a mentalidade de Product-Engineer. Na época eu era analista de BI onde eu era responsável pela parte de tuning do banco de dados e do DWH; mas o que eu realmente queria fazer era participar do processo de precificação dos ativos da empresa e fazer um trabalho menos voltado a rotinas operacionais de otimização e monitoramento; mas sim realizar modelagem matemática para prever os preços dos derivativos que eu colocava dentro do meu banco de dados.

A segunda foi quando eu cheguei em uma empresa Product-First com uma mentalidade de como se eu estivesse em uma empresa Engineering-First. Ao mesmo tempo em que eu fazia algumas análises mais complexas do negócio, consultava benckmarks técnicos e até mesmo implementava algoritmos de alguns papers da nossa plataforma, a empresa queria simplesmente deixar uma solução muito ruim (em termos de débito técnico) e mover para o próximo projeto (e isso com eles totalmente satisfeitos com o resultado da péssima implementação em termos técnicos).

E por que eu estou colocando isto? Pelo simples motivo de que estar na empresa errada no momento errado da sua carreira pode ser algo que não vai apenas desperdiçar o seu potencial de carreira: isso pode literalmente escalar para doenças mentais com consequências quase que imprevisíveis.

Óbvio que em muitas das vezes não tem como escolhermos o nosso emprego, mas se eu tivesse que deixar uma recomendação eu diria saiba o tipo de engenheiro que você é no momento e procure uma empresa que tenha uma abordagem que tenha o máximo de intersecção com os seus interesses.

Considerações Finais

Ambos os paradigmas têm as suas vantagens e desvantagens e essas características não são totalmente excludentes.

Contudo, é muito difícil encontrar organizações que operam bem usando as duas abordagens em paralelo. Dessa forma se eu tivesse que deixar uma dica essa seria algo como no aforismo grego conhece a ti mesmo como engenheiro. Isso por si só vai levar a melhores decisões de carreira ao longo do tempo e com sorte evitar todo tipo de frustrações.

Dedicado especialmente ao Daniel “Oz” Santos que passou comigo grande parte dos apuros descritos nestas duas abordagens (i.e. vivemos as desvantagens das duas abordagens por mais de 3 anos) e para o Rodolfo Zahn pelas conversas que deram origem a este post.

Links úteis

How to cultivate an engineering first culture — from a coders perspective

Product engineers

The Over-Engineering Problem (and How to Avoid It)

Notas

[1] - Existe um terceiro tipo de abordagem que eu venho notando que são as empresas Research/Experimentation-First, mas isso é tema para um outro momento.

[2] - Este post não tem como ponto principal falar de projetos em si ou de negócios específicos, mas sim discutir essas duas abordagens que a meu ver definem bem o mercado para engenheiros, cientistas de dados, e demais profissionais de dados. Este argumento pode ser estendido para outras áreas, mas aqui eu vou falar especificamente para o público da parte de dados e IT no geral.

[3] - E como vocês já sabem eu fui alfabetizado no pior sistema educacional do mundo e a minha mente fala muito mais rápido que os meus dedos e a vontade de revisar isso é tão alta quanto uma folha de papel deitada, então relevem todos os erros cometidos.