Generalista ou Especialista — bem vindo ao modelo PaintDrip

Antes de começar a cumprir com a promessa feita no último artigo sobre como escalar times de engenharia de forma sustentável e explicar em mais detalhes como trabalhar a maturidade do time e a métrica de qualidade queria atender a uma sugestão do Felipe Teixeira e falar um pouco sobre uma discussão antiga — e muito importante — sobre a opção de carreira mais generalista ou especialista para devs.

Quem me conhece há algum tempo sabe que sou uma pessoa que gosta do equilíbrio — sempre brinco que mesmo respeitando todas as religiões e apesar de não ser muito religioso se eu fosse, escolheria o budismo — pela sua busca pelo equilíbrio com o uso do caminho do meio e da razão.

Os extremos — onde as pessoas normalmente se perdem tanto — são bons para ilustrar. No entanto, na vida real sempre procurei buscar modelos mais equilibrados que tragam resultados mais perenes ao longo do tempo.

O que vou tentar mostrar neste artigo é um método que acredito seja mais eficiente para você crescer enquanto profissional: gerando mais resultado para o seu time, para a sua empresa e consequentemente fazendo com que você tenha mais valor como profissional do futuro.

Para chegar lá vamos passar pelas vantagens e desvantagens de ser especialista ou generalista, como e quando podemos combinar ambos e quais os impactos que um modelo equilibrado na cultura de uma empresa.

Uma coisa importante para conseguir ter um pouco mais de foco vou centrar a discussão no desenvolvimento de software. No entanto, acredito que essa discussão de generalista X especialista é bem mais ampla e se aplica a qualquer área de conhecimento. Um livro muito interessante sobre o assunto é Range — Why Generalists Triumph in a Specialized World que acabou de ser recomendado pelo Bill Gates como um dos melhores livros que leu esse ano.

Bill Gates — um programador que criou a indústria do software — diz em seu post sobre o livro: “My own career fits the generalist model pretty well”

Quero me desculpar pela demora em publicar esse artigo. Quando li o post de Bill Gates, tive que parar e ler o livro. Realmente é um dos mais interessantes que li recentemente. Eu também me identifico muito com o modelo generalista.

Ao longo da minha trajetória sempre achei que diversas experiências diferentes são um diferencial e um estímulo ao aprendizado e à criatividade. O livro tem diversas histórias e estudos fundamentando a visão do autor de forma bastante eloquente. Definitivamente, vale a leitura.

Voltando para o desenvolvimento de software: umas das coisas que sempre me surpreendeu é como desde muito cedo em suas carreiras muitas pessoas devs — e em minha experiência não só no Brasil, já vi na Europa e Ásia também — em ampla maioria tem como ambição se tornar super especialistas em uma disciplina específica da engenharia de software.

Temos uma profusão de especialistas de frontend, mobile, backend, banco de dados, etc. Em muitos casos até especialistas em “sub-disciplinas”: especialistas iOS, android, angular, Postgres, Java, etc. Só deixando claro, eu acredito que ter um bom grupo de ferramentas que se tenha bom conhecimento é essencial, mas em minha visão ser um “super-especialista” em poucas ferramentas não é uma boa escolha de carreira pois é simplesmente contrário a forma como software deve ser construído atualmente.

O mito do super-especialista que é responsável por parte do processo de desenvolvimento de software vem da metáfora da fábrica de software onde cada grupo de profissionais é responsável por uma etapa bem definida do processo: um grupo faz a especificação, outro o design, outro o frontend, outro o backend, outro testa tudo e por último outro coloca em produção.

Atualmente, já acredito que seja bem claro para boa parte das empresas de tecnologia que essa metáfora é falha para o desenvolvimento de produtos de software. No entanto, acho importante ter consciência do porquê. Infelizmente ainda não acho que todas devs tenham essa consciência.

Em minha experiência desenvolver produtos de software com a complexidade atual requer duas coisas em especial: trabalho em equipe e criatividade.

Não é possível que cada um dos times especialistas, por mais especialistas que sejam — entreguem uma “peça pronta” — perfeita, para que o próximo time especialista na “linha de fábrica”, continue parte do processo até que o último time coloque o software em produção e este esteja disponível para o usuário.

Esta abordagem fabril para o desenvolvimento de software causa vários problemas na formação de times de tecnologia. Dois deles em especial são derivados de um “mindset” puramente especialista:

1. handoffs — como cada grupo especialista é responsável por parte do processo e não tem a visão do todo é muito comum termos falhas de especificação, layout e interfaces e termos que voltar a etapas anteriores do processo. Já vi casos que esse processo fazia com que o time tivesse um lead time de meses: o que certamente vai influenciar na saúde do time.
2. Criação de silos — em uma organização em fábrica com times especialistas a tendência é que tenhamos falta de empatia de um time com o outro. Os times não tem nenhum objetivo tangível conjunto e não acabam criando empatia pelos problemas em “outras áreas de expertise”. Uma das coisas que observo quando tenho exposição a times de engenharia de software é como os grupos interagem. Um bom teste para ver como a organização dos times influencia nisso é o que chamo de “teste do almoço”. Em um time com equipes especialistas: frontends almoçam com frontends, backends almoçam com backends, QAs com QAs e assim sucessivamente. Em minha experiência este tipo de dinâmica aliada a falta de conhecimento do trabalho do outro — e consequente baixa empatia — faz com o “cercas virtuais” sejam levantadas, problemas de comunicação apareçam e a qualidade do produto seja baixa.

Apenas os dois problemas acima já deveriam ser o suficientes para evitarmos uma cultura puramente especialista — handoffs e silos podem matar o trabalho em equipe e a produtividade de um time ao longo do tempo.

O processo de criação de software é um processo colaborativo, iterativo e criativo, onde times multifuncionais são essenciais e devem acompanhar cada funcionalidade ser colocada em produção.

Como vimos acima, uma abordagem puramente especialista atrapalha a colaboração e a iteração entre os times. Mas e a criatividade?

Como bem ilustrado no capítulo 1 de Range — sim: de novo o livro que o Bill Gates nos recomendou, gostei muito dele — em atividades onde o problema não tem uma solução já mapeada — ou seja, regras fixas — o pensamento abstrato é crucial para desenvolver soluções. Em Range, David Epstein mostra que nossa habilidade em pensar de forma abstrata é inclusive um de nossos grande diferenciais enquanto espécie e o que nos permite inovar em diversas situações.

Em desenvolvimento de produtos de software não é diferente.

Claro que vários algoritmos e frameworks já estão definidos, e não precisamos reinventar a roda o tempo todo. Certamente temos que nos aprofundar e especializar buscando ter as ferramentas adequadas para aplicar nos problemas do dia a dia.

Não obstante, inovar é um processo que requer nossa capacidade de abstração e de aplicar ferramentas que já conhecemos em novas situações — e uma visão generalista é essencial para isso.

Mas agora vem a famosa pergunta:

Mas como me diferencio? Vou me especializar no que?

Primeiro temos que apresentar o modelo do profissional em T.

É um modelo que já existe há bastante tempo, desde a década de 90. Mas que nos últimos anos tem ficado mais popular no Brasil.

Eu já venho trabalhando esse modelo em meus times há anos, mas nem sempre é fácil pois de alguma maneira ele é contrário a metáfora da fábrica de software e seu foco no super especialista — que ainda está no inconsciente de muitas pessoas devs.

A primeira referência que tive deste modelo veio do booklet de onboarding da Valve — empresa de jogos referência e responsável por clássicos como half life e pela steam — rede de distribuição de jogos.

A figura acima — tirada do booket da steam — mostra de uma forma lúdica a personagem “heavy” com suas habilidades ilustradas no formato em T.

A ideia aqui é ter um conjunto de habilidades e conhecimentos gerais — a parte de cima do T — que permitam com que possamos desenvolver nossas capacidades de empatia e pensamento abstrato de forma a criarmos times mais colaborativos e criativos.

Ao mesmo tempo nos especializamos em alguma área — ou áreas — desta forma podemos nos aprofundar e aportar esse conhecimento específico ao time — o corpo do T.

Esse modelo — para mim — é um salto quântico em relação ao modelo puramente especialista. Mas, ao implementá-lo ao longo do tempo percebi que muitas pessoas acabavam caindo novamente na abordagem hiper especialista. Era como se ao longo do tempo o “heavy” fosse se modificando como na imagem abaixo.

E, é claro, que desenvolvendo uma cultura com o padrão da imagem acima vamos acabar ao longo do tempo caindo no hiper-especialista novamente e, em seus problemas.

Quando estava na OLX, estávamos enfrentando um desafio cultural parecido com o descrito acima e ao buscar referências que nos ajudassem a implantar uma cultura mais T-shape — o Guilheme Cirne encontrou a analogia de uma “PaintDrip Person”, idealizada pelo Kent Beck, o pai do XP e do TDD.

A imagem acima é literalmente o slide que usei em um dos all hands em 2018, explicando o modelo ao time.

Neste modelo, Kent faz uma série de observações sobre as características desenvolvidas por uma boa pessoa dev e mostra que ela está sempre explorando e desenvolvendo seus interesses ao longo do tempo.

Ele ilustra a carreira dessa pessoa ao longo do tempo como se fosse uma pincelada de tinta em uma parede — como no slide acima. Nesta analogia, cada gota de tinta escorrendo é um projeto onde a dev tem que se aprofundar em uma tecnologia. A profundidade com que ela se desenvolve — ou que a gota escorre — depende da necessidade do projeto ou do time. Desta forma, essa dev vai seguindo a sua carreira, explorando novos caminhos e se especializando a medida que seja necessário para ajudar o seu time.

Confesso que não só acho esta analogia precisa como artisticamente bonita.

[ pausa poética 😀 ]

O aprendizado que tivemos quando implementamos este modelo foi que não basta apenas ter bons exemplos como: Kent Beck, Steve Wozniak ou Bill Gates — olhando no detalhe a Microsoft ainda contrata o perfil que ele descreve em seu review sobre Range.

É necessário também tomar uma decisão consciente de favorecer uma cultura de exploração.

É necessário dar incentivos de forma explícita ao time. Passa por colocar essa característica paintdrip no plano de carreira e ter o reforço, suporte e exemplo da liderança.

Agora já estou entrando um pouco no assunto do artigo de formação de times prometido aqui. Vamos deixar mais detalhes de como inserir esse modelo na cultura para nossa próxima conversa.

Enquanto o próximo artigo não chega espero que este modelo — e um pouco da explicação de onde vem o perfil hiper-especialista — tenha te ajudado. Agora é só ir enchendo o balde de tinta e apontando o pincel que tem muita exploração e coisa para aprender em sua carreira.