Sempre gostei de pensar que conhecimento não deveria ser uma coleção de assuntos isolados e mas um conjunto de conexões que construímos e das experiências de construir (e quebrar) coisas ao longo da vida. Algumas dessas conexões surgem por necessidade profissional, outras por curiosidade e muitas acabam sendo úteis em situações que sequer imaginávamos quando começamos a estudar e testar. Consegui falar muito sobre isso para meus alunos e durante o meu primeiro livro “System Design Workbook”, cujo qual considero o lado das “Hard Skills” dessa série de textos que você está lendo agora. Para um Staff Engineer, acredito que essa capacidade de transitar entre diferentes disciplinas, compreender suas relações e conectar pessoas e problemas seja tão importante quanto a própria profundidade técnica. Neste artigo, quero explorar essa relação entre especialização, amplitude e influência técnica, usando o conceito de polimatismo como ponto de partida para discutir o desenvolvimento de um repertório que vai muito além de conhecer tecnologias.

Polimatismo e Polímatas

Eu sempre fui fissurado pela imagem de Leonardo da Vinci por um motivo muito “besta”. Ele é considerado um dos maiores gênios da humanidade, tendo atuado em diversas áreas da ciência ao longo de sua vida e, raramente, alguém sabia com o que, definitivamente, ele trabalhava. Leonardo era engenheiro de guerra do Duque de Milão e, mesmo assim, ficou famoso por todo o resto, menos por isso. Ele marcou o mundo por tudo o que amava e pelo que tinha interesse genuíno, e não necessariamente pelo que o fazia ganhar dinheiro. De certa forma, tenho isso como uma meta de vida. Não para este momento, claro… Sempre tentei imaginar como seria incrível poder contribuir com várias áreas do conhecimento ao mesmo tempo.

Recentemente, li o livro “O Polímata”, de Peter Burke, no qual o autor explica o termo “polímata” como um indivíduo que possui vasto conhecimento em múltiplas disciplinas e enquadra nesse perfil diversas pessoas-chave ao longo da história, como o próprio Leonardo da Vinci e outras figuras como Isaac Newton, Nikola Tesla, Albert Einstein, Santos Dumont, Mário de Andrade e outros. Essas pessoas tiveram contribuições em diversas áreas das “Artes Liberais” ao longo de suas vidas, sendo elas divididas entre o Trivium (Gramática, Lógica e Retórica) e o Quadrivium (Aritmética, Geometria, Música e Astronomia). A figura histórica do polímata costumava estar associada a períodos em que as fronteiras entre as disciplinas eram menos rígidas. Filosofia, matemática, astronomia, medicina, política e artes frequentemente faziam parte de um mesmo campo de investigação intelectual para aqueles que tinham tempo para se dedicar a elas. Dentro da tecnologia, acredito que, neste momento, podemos usar esse arquétipo do polímata para desenhar o perfil de atuação de um profissional Staff dentro de grandes empresas.

Competências de um Staff

As competências esperadas de um perfil Staff ultrapassam, e muito, a execução individual de tarefas complexas. Embora a profundidade técnica continue sendo muito esperada, a responsabilidade passa a envolver problemas muito mais amplos e pouco claros, distribuídos por uma empresa ou organização. O impacto da posição não é medido apenas pelo código que o profissional escreve ou pelos sistemas que projeta, mas pela capacidade de orientar decisões de forma clara, reduzir incertezas em discussões, desenvolver outros profissionais e aumentar a qualidade técnica das escolhas realizadas ao seu redor. Um Staff precisa reconhecer problemas antes que eles estejam completamente definidos e, para isso, precisa ter conhecimento de diversas áreas dentro do que, genericamente, podemos definir como “construir software”.

Também se espera que um Staff consiga operar em diferentes níveis de abstração. Em determinados momentos, ele precisa se aprofundar em detalhes de implementação, comportamento de runtime, consistência de dados ou gargalos de sistemas distribuídos. Em outros, precisa discutir impacto financeiro, risco operacional, prioridades de produto ou dependências organizacionais em níveis executivos. A dificuldade não está em conhecer todos esses níveis, mas em saber quando alternar entre eles e como conectar uma decisão local às consequências sistêmicas que ela pode produzir. Por isso, as competências de um Staff formam uma combinação entre profundidade técnica, visão sistêmica, comunicação, julgamento, liderança e capacidade de síntese de diversos temas e áreas, como dados, infraestrutura, código, segurança, backend, frontend, filas, eventos, protocolos e afins, em diferentes níveis de profundidade, mas sempre conseguindo conectar pontos-chave para orientar e projetar soluções mais maduras.

Especialização e Amplitude

Especialização e amplitude não devem ser tratadas como caminhos opostos, embora seja bastante fácil cair nessa interpretação. A especialização oferece profundidade, precisão e capacidade de execução dentro de uma determinada área ou tecnologia. A amplitude, por outro lado, permite compreender contextos, dependências e consequências das conexões entre diversos temas. Uma carreira técnica moderna precisa desenvolver as duas dimensões, ainda que em proporções diferentes ao longo do tempo. Para ilustrar essas características, o mercado adotou algumas abstrações lúdicas para representar diferentes perfis profissionais, classificando-os em I-Shaped (Especialização Profunda), Dash-Shaped (Generalista) e T-Shaped (Profissional Generalista-Especialista). O mercado hoje deu diversas outras releituras pra isso, porém irei me ater apenas ao T-Shaped, desconsiderando M-Shaped e afins com objetivo de praticidade.

Nos primeiros estágios da carreira, a especialização costuma ter maior peso para ingressar no mercado, embora também seja necessária certa amplitude. O profissional precisa aprender fundamentos, dominar ferramentas, construir repertório, acumular experiências práticas e desenvolver autonomia para resolver problemas pontuais.

Entretanto, à medida que a responsabilidade do indivíduo aumenta, a profundidade em um tema específico começa a ser insuficiente para trabalhar em contextos mais amplos. Problemas de maior escala envolvem múltiplos sistemas, tecnologias, conceitos, times, objetivos, regras de negócio e, principalmente, restrições. Um especialista que compreende apenas sua própria disciplina pode produzir decisões localmente corretas e válidas, mas sistemicamente inadequadas. E isso é muito perigoso. Ter amplitude permite enxergar e antecipar esses efeitos.

I-Shaped - Especialização Profunda

O profissional I-Shaped possui uma linha vertical profunda, mas pouca amplitude ao redor dela. Ele pode ser extremamente competente dentro de uma disciplina específica, conhecer detalhes muito pouco documentados de uma tecnologia e resolver problemas que exigem alto nível de especialização dentro de um tópico específico.

Um especialista em um tipo específico de banco de dados, como Oracle, PostgreSQL ou SQL Server, por exemplo, pode propor uma solução excelente para otimizar consultas e arquitetar soluções inteiras utilizando apenas as features e capacidades desse banco de dados, mas ignorar implicações relacionadas ao comportamento da aplicação, à experiência do usuário, aos sistemas satélites, aos protocolos, aos contratos de comunicação ou às restrições financeiras da infraestrutura. A solução pode ser tecnicamente correta dentro de uma fronteira muito bem definida e, ao mesmo tempo, inadequada para o sistema, que integra diversos tipos de tecnologias e requisitos ao redor.

Isso não significa que profissionais extremamente especializados tenham menos valor, muito pelo contrário. Em determinados contextos, são justamente eles que conseguem resolver problemas que ninguém mais consegue, pela profundidade em um tema específico. A questão é que profundidade técnica não implica, necessariamente, capacidade de compreender as consequências de uma decisão fora do próprio domínio de conhecimento ou em sistemas complexos.

Para um Staff, essa limitação pode ser especialmente problemática, já que boa parte dos problemas sob sua responsabilidade não respeita as fronteiras entre tecnologias, disciplinas ou times.

Dash-Shaped - Generalismo Excessivo

No outro extremo, temos o profissional Dash-Shaped, caracterizado por uma linha horizontal de conhecimento, com bastante amplitude, mas pouca profundidade em qualquer disciplina específica. Esse tipo de perfil é relativamente mais comum, principalmente entre profissionais júniores, plenos e sêniors nos primeiros anos de carreira, que possuem uma quantidade significativa de tecnologias, padrões e métodos de trabalho à disposição em seu repertório pessoal, mas com baixa profundidade na maioria deles.

Esse é um estágio “confortável”, pois representa o “mais que suficiente” para executar um bom trabalho, mas também pode se tornar uma armadilha quando se busca construir um perfil voltado a uma atuação de Staff, principalmente quando é necessário se tornar uma referência técnica em algum assunto.

Esse perfil consegue participar de fóruns e conversas sobre arquitetura, infraestrutura, desenvolvimento, dados e segurança, mas pode não possuir repertório suficiente para identificar limitações importantes ou questionar determinadas escolhas. Conhecer superficialmente diversos assuntos não significa compreender seus mecanismos, restrições ou modos de falha.

A amplitude continua sendo muito valiosa, de todo modo, principalmente para conectar pessoas e identificar oportunidades. Entretanto, sem uma base técnica suficientemente sólida e sem um tema de referência que sirva para alavancar e conectar os demais, existe o risco de transformar conhecimento em opinião e opinião em decisão arquitetural.

Profissional T-Shaped

O profissional T-Shaped busca equilibrar as dimensões dos dois perfis anteriores. A linha vertical representa profundidade em uma ou mais especialidades, enquanto a linha horizontal representa o conhecimento necessário para compreender outras disciplinas, estabelecer conexões e atuar em problemas que ultrapassam sua área de domínio ou especialidade de referência.

É importante destacar que esse conceito não significa conhecer todas as tecnologias disponíveis ou ser capaz de substituir qualquer especialista de uma organização. A proposta é desenvolver profundidade suficiente para sustentar decisões técnicas e amplitude suficiente para compreender suas consequências em um ambiente mais complexo e diverso.

Um profissional com especialidade em infraestrutura, por exemplo, não precisa ter a mesma profundidade de um engenheiro de banco de dados, mas deveria compreender conceitos como transações, isolamento, replicação e consistência para conseguir discutir decisões de arquitetura distribuída. Da mesma forma, alguém especializado em desenvolvimento backend deveria compreender fundamentos de redes, infraestrutura, segurança e observabilidade para avaliar adequadamente o comportamento de suas aplicações em produção. Em nenhum dos exemplos é necessário entender tudo sobre todos os temas, mas sim ter um grau de compreensão que permita discutir e avaliar o impacto entre diversas disciplinas sobre um mesmo problema.

Conhecimento Central

O conhecimento central é a base de especialização do profissional. É onde está concentrada sua maior profundidade técnica, construída ao longo de anos de estudo, experiência prática, resolução de problemas e exposição a diferentes cenários.

Para um engenheiro especializado em sistemas distribuídos, por exemplo, essa base pode envolver algoritmos de consenso, estratégias de replicação, consistência de dados, tolerância a falhas e mecanismos de escalabilidade. Para alguém especializado em segurança, pode envolver criptografia, autenticação, autorização, modelos de ameaça e proteção de sistemas.

Também é importante compreender que o conhecimento central não precisa permanecer estático durante toda a carreira. A especialidade de um profissional pode evoluir, incorporar novas disciplinas ou até mudar completamente, conforme seus interesses e experiências. Eu mesmo já fiz isso algumas vezes ao longo da minha carreira.

Conhecimento Adjacente

O conhecimento adjacente representa as disciplinas que se relacionam direta ou indiretamente com a especialidade central. São áreas nas quais o profissional não necessariamente possui um domínio tão aprofundado quanto o de seu conhecimento central, mas precisa compreender conceitos, limitações e fundamentos para tomar decisões que possam causar impactos nessas disciplinas ou ser influenciadas por elas.

Um engenheiro especializado em Kubernetes, por exemplo, pode conhecer profundamente o funcionamento do scheduler, os mecanismos de autoscaling e o gerenciamento de recursos. Entretanto, para projetar uma plataforma que suporte aplicações críticas, precisa compreender também conceitos de redes, sistemas operacionais, desenvolvimento de aplicações, persistência de dados e segurança.

Observe que essas disciplinas não são independentes. Uma aplicação pode apresentar problemas de latência que aparentemente indicam limitações de infraestrutura, quando, na realidade, a causa está relacionada à concorrência de transações, ao gerenciamento de conexões ou ao comportamento de uma dependência externa.

O Kubernetes, por exemplo, é uma excelente porta de entrada para ampliar o repertório técnico e explorar conhecimentos adjacentes. Por ser uma “plataforma para construir plataformas”, possui mecanismos de integração com storage, exposição de APIs, mecanismos de segurança, diversas formas de escalar aplicações e clusters, gerenciar redes, expor e consumir serviços internos e externos, além de recursos para observabilidade e gerenciamento de aplicações. Ter uma especialização sólida em Kubernetes e Engenharia de Plataforma pode abrir caminhos para diversas outras áreas adjacentes que você precise suportar.

A amplitude permite formular hipóteses melhores e evita que o profissional interprete todos os problemas a partir de sua própria especialidade ou que atribua, de forma espúria, problemas a camadas que ele não conhece. Essa dimensão também é importante para a colaboração. Quanto maior o repertório adjacente, maior a capacidade de estabelecer conversas produtivas com especialistas de outras áreas, compreender suas restrições e identificar pontos de integração, exatamente o que se espera de um perfil Staff+.

Conhecimento Humano

Independentemente do seu grau de profundidade técnica em uma especialidade ou nas demais áreas adjacentes, conforme a responsabilidade de um engenheiro aumenta, cresce também sua dependência da colaboração com outros profissionais e áreas. Problemas deixam de ser resolvidos exclusivamente por decisões individuais e passam a exigir alinhamento, negociação, comunicação e construção de consenso entre uma gama maior de pessoas. É aí que entra a capacidade de compreender pessoas, organizações e seus mecanismos de decisão.

Um Staff pode identificar uma solução tecnicamente excelente e, ainda assim, não conseguir implementá-la porque desconsiderou restrições de outros times, critérios de segurança, prioridades de negócio, limitações financeiras ou simplesmente não conseguiu comunicar adequadamente seus argumentos.

O conhecimento humano envolve desenvolver repertório sobre comunicação, liderança, negociação, comportamento organizacional, gestão de conflitos e capacidade de ensinar. Não se trata apenas de falar bem ou produzir apresentações, mas de compreender como pessoas com diferentes responsabilidades interpretam problemas e tomam decisões, para então adequar o discurso ao público certo.

A capacidade de traduzir complexidade técnica em decisões compreensíveis para diferentes públicos é uma competência fundamental para ampliar a influência de um Staff. E talvez aqui exista uma das maiores mudanças de perspectiva da carreira: perceber que estar tecnicamente correto não significa, necessariamente, conseguir produzir o melhor resultado possível.

Conhecimento Exploratório e Científico

A última dimensão está relacionada à curiosidade e à construção de conhecimento fora das necessidades imediatas do trabalho. É aqui que gosto de recuperar a ideia do polimatismo apresentada no início deste artigo.

Existe uma diferença entre estudar determinado assunto porque ele é necessário para resolver um problema e estudá-lo simplesmente porque existe interesse genuíno em compreendê-lo. Embora as duas formas tenham valor, a segunda frequentemente permite construir um repertório que não está limitado às demandas atuais da carreira.

Uma coisa que definitivamente não foi muito boa para minha saúde mental ao longo dos anos foi ter uma ideia constantemente presente na cabeça: “Se eu estou estudando para resolver um problema que tenho hoje, eu já estou atrasado”. Aquele papo de que o bom lenhador sempre afia seu machado pensando no dia seguinte, e não quando a árvore já está à sua frente. Isso definitivamente me causou bastante ansiedade, mas, de certa forma, também sou grato por pensar assim.

Estudar matemática, economia, psicologia, filosofia, física ou qualquer outra disciplina pode parecer distante da engenharia de software em um primeiro momento (e em um segundo também, mas não em todos os exemplos citados, claro). Entretanto, diversos conceitos utilizados em tecnologia possuem fundamentos desenvolvidos nessas áreas, uma vez que somos muito bons em nos apropriar de conceitos de outras ciências e ressignificá-los para a nossa área. Teoria das filas, probabilidade, teoria dos grafos, teoria dos jogos e métodos de otimização são exemplos de conhecimentos que podem ser aplicados a problemas de engenharia.

O mais interessante é que nem todo conhecimento adquirido precisa ter uma aplicação imediatamente identificável. Em muitos casos, sua utilidade aparece muito tempo depois, quando encontramos um problema que pode ser interpretado a partir de algo que já estudamos.

Também existe uma dimensão científica importante nesse processo. Aprender a formular hipóteses, buscar evidências, conduzir experimentos e questionar conclusões fortalece nossa capacidade de avaliar problemas técnicos sem depender exclusivamente de experiências anteriores ou opiniões consolidadas.

O objetivo não é transformar todo engenheiro em um pesquisador acadêmico, até porque isso seria insuportavelmente chato. Significa compreender que o conhecimento técnico evolui por meio da investigação, da experimentação e da disposição para questionar, sem apego, aquilo que acreditamos saber.

Amplitude e Influência Técnica

Até aqui, discutimos diferentes formas de construir conhecimento. Entretanto, existe um “abismo não óbvio” muito importante entre possuir um repertório técnico amplo e conseguir transformar esse repertório em influência dentro de uma organização. É comum que um perfil mais “Solver”, como descrito por Will Larson na literatura sobre Staff Engineering, possua conhecimentos sobre diversas tecnologias e consiga resolver problemas técnicos com excelente qualidade, mas continue sendo visto exclusivamente como um “ótimo sênior”, com impacto local, pois resolve apenas os problemas que chegam até ele de forma direcionada. O impacto de um Staff exige um passo adicional nessa direção: orientar decisões e melhorar a capacidade de execução de outras pessoas.

Imagine uma discussão sobre a necessidade de escalar determinado serviço. Um engenheiro especializado em infraestrutura pode propor adicionar capacidade computacional de maneira horizontal ou vertical, enquanto alguém especializado em bancos de dados pode sugerir mudanças no armazenamento ou na distribuição das consultas entre shards. Um profissional com visão mais ampla consegue explorar outras possibilidades e integrar mais de uma alternativa: será que o problema é realmente de capacidade? Existe alguma restrição de concorrência? O modelo de consistência exige determinadas operações síncronas? A aplicação está utilizando os recursos de maneira eficiente? Qual é o custo de cada alternativa?

Essa amplitude também muda a maneira como o profissional exerce influência. Em vez de depender exclusivamente da autoridade concedida por um cargo ou do domínio de uma tecnologia específica, ele passa a contribuir com diferentes grupos por meio da clareza técnica, da capacidade de síntese e da compreensão das restrições envolvidas.

Ganchos de Conhecimento

Uma das coisas que considero mais interessantes no aprendizado é perceber que os conhecimentos raramente permanecem isolados. Conforme desenvolvemos repertório em diferentes disciplinas, começamos a reconhecer conceitos semelhantes, relações inesperadas e problemas que compartilham fundamentos. Gosto de pensar nessas conexões como ganchos de conhecimento: pontos de associação que permitem relacionar algo que já conhecemos a uma ideia nova, facilitando a compreensão de conceitos e a construção de repertório.

Por exemplo, alguém que compreende conceitos de hashing pode encontrar aplicações desses fundamentos em estratégias de particionamento de dados, distribuição de carga e arquitetura celular. Um profissional familiarizado com teoria das filas pode utilizar esse conhecimento para interpretar a saturação de recursos, o comportamento de sistemas assíncronos e as estratégias de controle de admissão.

Quanto maior o repertório, mais oportunidades temos de estabelecer essas conexões. Entretanto, acumular conhecimento não garante que elas aconteçam automaticamente. É necessário exercitar a capacidade de comparar conceitos, questionar semelhanças, identificar diferenças e buscar aplicações em novos contextos.

Talvez essa seja uma das características mais valiosas de um profissional Staff: não necessariamente conhecer mais do que todos os especialistas ao seu redor, mas conseguir relacionar conhecimentos, pessoas e problemas que, individualmente, poderiam permanecer desconectados.