Staff Engineer e outras coisas...

Staff Engineer e outras coisas…

A alguns dias atras no meu feed do twitter apareceram algumas pessoas comentando o livro “Staff Engineer: Leadership beyond the management track do Will Larson e falando sobre esse tipo de posição no Brasil.

Eu decidi escrever pra falar um pouco da minha experiencia como Staff Engineer em Dados e Machine Learning para compartilhar algumas das impressões que eu tenho em relação a esse título e algumas mudanças fundamentais entre outras posições de engenharia que eu já tive a oportunidade de ocupar.

Logo de cara eu queria deixar bem claro que não existe uma definição canônica uma definição do que é e o que faz um Staff Engineer e isso depende muito do grau de maturidade organizacional da empresa e principalmente o seu tamanho para compreender esse tipo de carreira mais técnica.

Em outras palavras, esse tipo de posição pode ter uma definição extremamente arbitraria e copiar o que funciona em uma cultura sem entender as idiossincrasias, ao menos eu nunca vi funcionar bem e em alguns casos é problemático.

Outro ponto importante é que o fenômeno de empresas criarem uma trilha técnica paralela a de gerenciamento (management) é relativamente recente até onde eu me lembro e vem atender uma necessidade de consolidar e estabelecer caminhos para a carreira de especialistas técnicos. Ao meu ver isso vem em uma ótima hora dado que elimina uma pressão para empurrar especialistas para uma trilha de gestão (o que é problemático em essência, e disfuncional por natureza) como estabelece novos níveis de expectativa em relação ao impacto e alcance.

Eu penso que com a alta demanda de especialistas em tecnologia, os dias de “promoção prancha do pirata na direção dos tubarões” acabaram; não por conta do fato de que hoje as pessoas simplesmente vão embora de onde elas não se sentem confortáveis, como a carreira de management em tecnologia é ao meu ver superestimada e possuí uma série de desvantagens graves e pouco faladas como bem exemplificado nesse post da sempre necessária Charity Majors no artigo “17 reasons not to be a manager” em que com a finesse que lhe é peculiar, a Charity traz algumas verdades.

Staff Engineer, e aí?

Primeiramente eu penso que dependendo do tamanho da empresa e das necessidades que ela tem, como por exemplo stack de tecnologia não trivial ou mesmo linhas de produtos muito complexas, u times de engenharia muito grande parte das carreiras, em especial em tecnologia vai evoluindo.

As duas melhores definições dentro do que eu tenho vivido junto com a literatura estão no livro do Will Larson em que ele fala dos arquétipos de staff engineer que são o Tech Lead (Líder técnico), arquiteto, solucionador (solver) e faz tudo (Right Hand).

A descrição de cada um dos níveis são:

• O Tech Lead orienta a abordagem e execução de uma determinada equipe. Eles fazem parceria estreita com um único gerente, mas às vezes fazem parceria com dois ou três gerentes dentro de uma área específica. Algumas empresas também têm uma função de gerente técnico, que é semelhante ao arquétipo de líder técnico, mas existe na escada do gerente de engenharia e inclui responsabilidades de gerenciamento de pessoas.

• O Arquiteto é responsável pela direção, qualidade e abordagem dentro de uma área crítica. Eles combinam conhecimento profundo de restrições técnicas, necessidades do usuário e liderança em nível de organização.

• O Solucionador (Solver) se aprofunda em problemas arbitrariamente complexos e encontra um caminho apropriado a seguir. Alguns se concentram em uma determinada área por longos períodos. Outros saltam de hotspot para hotspot conforme guiados pela liderança organizacional.

• O Faz Tudo (Right Hand) estende a atenção de um executivo, emprestando seu escopo e autoridade para operar organizações particularmente complexas. Eles fornecem largura de banda de liderança adicional para líderes de organizações de grande porte.

No meu atual dia-dia eu estou cerca de 40% no Tech Lead, 20% no arquiteto, 20% no solver.

Por inúmeros aspectos ao invés de entrar na distribuição em si, eu vou falar o que mudou ao menos no meu fluxo de trabalho pois além do meu dia-dia ser pouco ortodoxo em termos de fluxo de trabalho, eu acredito que eu posso dar uma dimensão melhor do que “eu faço” do que “porque eu faço”.

Mas o que muda como Staff Engineer?

De maneira geral algumas coisas mudaram no meu quotidiano como:

• Compensação: No meu caso eu dei um pouco de sorte de realizar uma transição para uma empresa que já compreendia esse tipo de posição, então as faixas de remuneração já estavam bem estabelecidas e toda a negociação foi mais simples (e.g. pacotes de benefícios, expectativa de retorno, stock options, agenda de vesting, cliff, etc).

• Participação na criação de visão, missão e estratégia de um time: Isso aqui requer algo a parte, mas no meu caso eu tive que começar esse processo do zero e ao menos pra mim foi gratificante pois ao longo do tempo a visão e missão se provaram perenes mesmo depois de mudanças substanciais do mercado, das pessoas, do stakeholders, etc. Sobre a estratégia em si foi algo mais ou menos na linha que o Will Larson colocou: Algo chato demais e que tratou grande parte de temas fundacionais.

• O meu raio de alcance saiu de um time e multiplicou por 5, fora a quantidade de stakeholders que eu tive que começar a conversar diretamente;

• Os projetos mudaram do escopo de um time, e eu passei a ter uma participação cruzada em outros times: Eu posso dizer que isso é um pequeno luxo do cargo em que quase nenhum dia é igual. Em um dia eu estava entendendo configuração de eventos mobile no Segment, no outro lidando com problemas de warmup em instâncias no EC2 e realizando comparações com o Fargate em cenários em treinamento de modelo em batch, no outro resolvendo problema na engine do Hue para o agendamento de jobs, etc.

• Liderança de projetos críticos (mais de um) de abrangência para toda a empresa,

• Absolutamente muito trabalho fundacional: Eu acho que esse depende do grau de maturidade da empresa em relação ao Stack de tecnologia e do time que vai fazer a coisa acontecer. Na minha atual jornada eu me deparei com alguns aspectos chocantes de como a ausência de um trabalho fundacional fundamentado por uma estratégia coerente pode jogar uma empresa 4 a 7 anos em atraso técnico, em que apenas para manter a paridade com a mesma indústria (não estou falando nem de diferencial competitivo usando dados) é algo extremamente difícil. Olhando para trás eu acho que esse foi um dos aspectos que eu mais subestimei e foi uma experiencia reveladora. Aqui eu aprendi que métodos e princípios de engenharia sempre serão mais importantes que a tecnologia. Eu não posso entrar em profundidade aqui, mas em alguns momentos mesmo lidando com recursos de cloud virtualmente ilimitados ou com tecnologias como MapReduce, Scala, containers e por aí vai, tudo parecia feito usando práticas de 2009 (sem nenhum exagero).

• Aumento do poder de decisão individual (agency) ampliação de conhecimentos em detrimento de reports diretos: Eu já senti todos os sentimentos bons e ruins de management e de ter reports diretos então ficar em uma posição que não me demandasse isso me ajudou e muito a ampliar o meu conhecimento técnico em inúmeras coisas que não eram o meu forte na época, em especial em infraestrutura, containers e backend. E isso me deu um estranho poder de decidir as coisas por mim mesmo muitas coisas que por falta de conhecimento as pessoas decidiam por mim.

Principais desafios do cargo

• Número de reuniões aumentou o que me levou a ser mais brutal com o meu calendário: Reuniões é um tema controverso por si só; e em tempos de trabalho remoto e de comunicação assíncrona em que parte de nós viemos de um mundo analógico-digital para um pós-pandemia totalmente digital as reuniões tornaram-se algo que mexe com a saúde mental das pessoas. Para manutenção da minha sanidade mental eu coloco bloqueios de produtividade no meu calendário com rejeição automática, e eu separo um dia específico da semana para as pessoas agendaram qualquer coisa na minha agenda (atualmente são as quintas-feiras).

• Soft lead com o dobro das atribuições e usando apenas poder de influência pura e simples: Aqui vai uma dica para quem quer se aventurar como Staff no papel de Lead ou algo do tipo – prepare-se para argumentar e muito e se comunicar com claridade para colocar os seus pontos de vista. Pode parecer besteira, mas para aprender isso de uma maneira mais efetiva eu tive que respeitosamente descartar todos os livros de management de tecnologia e ir para o básico que é uma simplificação sobre a psicologia humana que é o livro “Influence: The psicology of Persuasion” do Robert Cialdini”.

  E eu digo argumentação não no sentido de conflito de ideias (quem me conhece sabe que eu adoro isso, e principalmente quando algum pensamento meu está errado, pois isso refina o meu modelo mental e conjunto de crenças) mas no sentido de explicar e exemplificar coisas que à primeira vista parecem óbvias, mas não são. Se colocar diferenças ambientais, culturais e ética de trabalho tudo fica absolutamente muito mais difícil.

  Algumas vezes algumas discussões são mais surreais do que os quadros do Salvador Dali em relação a como que muitas das vezes um exemplo ou ponto de vista tem que ser transposto de 3, 4 ou 5 formas para uma internalização da outra parte da comunicação. E eu não estou falando para posar como cognitivamente superior ou algo do tipo, até porque eu me considero um generalista mediano que vai demorar alguns anos para ser alguém bom; estou falando de que muitas das vezes o código, a experiência e a realidade são brutais e que muitas das vezes com o esgotamento completo dos argumentos sem uma alternativa pensada da outra parte eu tive que literalmente deixar algumas pessoas falharem. Tão simples quanto isso.

  Óbvio que isso não é ideal e existem mecanismos para evitar catástrofes que podem ser usados, e obvio que existem custos de aprendizado envolvidos. Contudo, até por questões de filosofia de vida eu não aceito coerção nem violência em disputas entre ideias. Imposição de ideias serve apenas para criar mecanismos de poder sobre outras pessoas, manutenção de status quo, e cria um rastro de ressentimento e insatisfação nas pessoas. Isso simplesmente não funciona, e liderança via coerção é apenas uma forma de exercer em outras pessoas um paternalismo não solicitado.

• Pensamento de segunda ordem provavelmente é algo subapreciado, mas de fundamental importância para o trabalho. Se eu tivesse que selecionar um traço desse tipo de cargo que me marcou foi começar a ter a percepção do que é o pensamento de segunda ordem e cadeia de consequências para cada decisão. Uma das maiores críticas que eu tenho sobre a área de tecnologia é que na maioria das vezes as empresas/pessoas navegam em duas formas extremas e opostas de sabotagem mental que são o hipervigilantismo (catastrofismo) ou pensamento simplístico e superficial de primeira ordem que recheado por níveis de hype diversos, com cada extremo alimentando o outro. Ao menos pra mim as perguntas sairam da esfera “Vamos colocar a tecnologia X, Y, Z?” para algo mais parecido como “OK, quais são os tradeoffs que vamos considerar na troca da tecnologia X, Y, Z; quais são os custos e quando vamos recuperar o tempo investido nisso em termos de ergonomia ou grana?”.

• A estratégia nem sempre vai deixar todas as pessoas felizes: Tudo o que eu posso dizer é uma diferença entre o que precisa ser feito e o que o nosso ego deseja fazer. Alinhar o último com o primeiro é uma das melhores avenidas para o aumento da satisfação no trabalho.

• Você depende muito do coachability (treinabilidade) das outras pessoas [NA1] em casos que o cargo demanda um acompanhamento de profissionais em desenvolvimento.

• Resistir a armadinha de ser um consigliere de luxo: Eu tenho um artigo engatilhado chamado “Qual é a maior armadilha de um Staff Engineer?”, mas o espirito do post é que não existe um cargo técnico que não está construindo coisas ao mesmo tempo que não tem nenhum reporte direto. Ponto. Muita gente se deslumbra pelo salário, pelo falso senso de importância por receber convites para reuniões com stakeholders importantes, por fazer “coaching” com colegas menos experientes, definições sobre arquitetura, etc. Tudo isso somado a algumas outras coisas colocam grande parte das pessoas em um senso conforto que em um primeiro momento da uma falsa sensação de produtividade, mas no final é um grande vilão silenciador que causa erosão de habilidades e degradação de conhecimento técnico. Coloque isso ao longo dos anos e é certa a obsolescência técnica para o mercado. Simples assim.

Considerações Finais

Se eu fosse sumarizar a minha experiência como Staff Engineer por enquanto, acho que seria um pouco parecido com uma carreira técnica de uma posição sênior em trabalhos de fundação (i.e. sustentação, suporte e evolução de plataformas), com um pouco mais de coordenação, influência em diversos projetos, e ocasionalmente auxiliando alguns colegas alcançarem o seu potencial [NA1]. Tem colegas que têm uma experiência muito mais voltada para mentoria de colegas menos experientes misturado com algo mais voltado como um arquiteto. A esfera de atribuições e escopo das habilidades pode variar de empresa para empresa, e é algo muito mais esotérico do que científico dado a recência deste tipo de posição e o alto grau de arbitrariedade das exigências.

Referências

• Staff Archetypes

• The Seniority Rollercoaster

Notas

[NA1] - A palavra coaching além das suas mais diversas conotações negativas dos dias de hoje, no meu plano semântico tem dois problemas. O primeiro é que coloca um falso senso de precedência de quem está treinando sobre quem está sendo treinado e penso que isso é errado em profissões de conhecimento, dado que é absolutamente impossível alguém saber tudo. O segundo problema é que sendo um atleta militar medíocre eu posso afirmar que ao menos nos meus anos em tecnologia e trabalho do conhecimento posso começar a afirmar que a grande maioria das pessoas tem uma ótima capacidade de aprendizado mas um baixíssimo nível de treinabilidade.

Elaborando melhor: muitas das vezes quanto mais treinado o indivíduo é menos treinavel ele fica. No meu caso como atleta amador de 100m/200m rasos eu levei acho que uns 2 anos apenas para mudar a forma que eu fazia a saída de bloco que era uma das minhas maiores deficiências. O treinador insistia e falava e tudo mais, mas o fato é que eu tinha que desaprender muitas coisas antes de estar preparado para aprender.

Tive que modificar desde a forma que eu treinava perna, a amarração da sapatilha, a inclinação do corpo em relação ao bloco de partida, etc. Eu só internalizei isso para profissão de conhecimento muito tempo depois que eu li esse livro que fala a respeito da primeira mudança do swing que o Tiger Woods fez depois de ganhar 2 masters e do quão difícil foi isso pra ele.

Colocando em perspectiva o quão difícil é uma mudança de swing para um atleta de alto nível do golf é a mesma coisa se o Roger Federer trocasse o seu backhand de mão única para duas mãos ou se o Messi trocasse o seu chute de curva de esquerda por apenas batidas chapadas.

Nesse ponto a minha evolução não foi porque eu achava o treinador ruim ou porque eu era rebelde ou nada do tipo, simplesmente a forma na qual eu fui condicionado por alguns anos de treinamento me deixaram com algumas limitações que se eu não respeitosamente desaprendesse alguns desses ensinamentos a minha evolução nunca viria.

“Mas OK, e o que isso tem a ver com treinabilidade em profissões do conhecimento?” Em profissões do conhecimento temos formas particulares de trabalhar: linguagens, ferramentas, modos de gerenciamento do trabalho, frameworks de tecnologia e de pensamento, metodologias entre outros e tudo isso começa a fazer parte do nosso sistema operacional, ou modelos mentais e isso é extremamente difícil em profissões de prática em geral. Basta ver as inúmeras flamewars que existem para absolutamente tudo: IDEs, Scrum x Kanban, Java x algo com mais hype, pessoas falando que PHP é ruim, gente passando da barreira do evangelismo em relação ao Clean Code e flertando com a pregação aberta, etc…

Eu não tenho nenhum diploma em ciência cognitiva para afirmar isso, mas ao menos ao meu ver o quanto eu estou disposto a desaprender para abrir espaço para formas novas de se fazer algo, é o que determinao o meu nível de treinabilidade. Depois que eu entender o porque das coisas e começar a ter um determinado nível mínimo de fluência para fazer a coisa andar, ai sim eu uso toda a minha bagagem. Ao menos é a forma que eu vejo essa treinabilidade.