O papel de um engenheiro de Staff-plus depende muito do que a equipa precisa e também de quais são os pontos fortes de um engenheiro em particular. Pela minha experiência as responsabilidades de um engenheiro Staff-plus podem mudar com o tempo, mas normalmente o seu foco principal é trabalhar em projectos/esforços que têm valor estratégico para a empresa, enquanto conduzem o design técnico e nivelamento da sua equipa. – Diana Pojar

Anyone que foi encurralada por parentes em uma festa e pediu para explicar o que os engenheiros de software realmente fazem sabe que explicar o trabalho pode ser um desafio. Com o tempo você pode ter criado uma resposta convincente para seus parentes, mas a mente de muitas pessoas fica em branco quando seu colega de trabalho se inclina e pergunta: “O que um engenheiro de software faz?”

A resposta mais fácil é que os engenheiros de software continuam fazendo muito do que os fez ter sucesso como engenheiros seniores: construir relacionamentos, escrever software, coordenar projetos. No entanto, essa é uma resposta enganosa. Eles estão fazendo essas mesmas tarefas, mas enquanto antes eram o núcleo do trabalho, eles se tornaram auxiliares, e eles têm novas prioridades. Sua programação diária varia um pouco por arquétipo, mas há uma base compartilhada em todos os arquétipos: estabelecer e editar direção técnica, fornecer patrocínio e orientação, injetar contexto de engenharia nas decisões organizacionais, exploração, e o que Tanya Reilly chama de ser cola.

Estabelecer direção técnica

Eu me sinto mais impactante quando posso facilitar o estabelecimento de uma visão técnica para uma área e fazer com que as pessoas se movam em direção a essa visão. Penso que todos concordamos que queremos que o nosso código seja melhor arquitectado do que é ou melhorado de alguma forma. No entanto, descobri que muitas vezes as pessoas têm uma vaga sensação de querer melhor sem ter uma ideia clara do que querem. Eu gosto de ajudar o grupo a decidir onde exatamente eles estão tentando chegar (na verdade não faz mal se nunca chegarmos lá) e chegar a um plano de jogo geral de como chegar lá. – Joy Ebertz

Como o Lorax fala pelas árvores em seu popular livro infantil, os engenheiros da equipe falam pela tecnologia de suas empresas. A tecnologia não pode falar por si mesma, e requer defensores eficazes em seu nome. As pessoas que avançam com sucesso na tecnologia são pragmáticas, deliberadas e se concentram mais na tendência de progresso a longo prazo do que em ver cada decisão individual como uma crise de “fazer ou quebrar”. Pode ser útil pensar nisso como sendo um Gerente de Produto em tempo parcial para tecnologia.

Alguns engenheiros de mais de uma equipe são explicitamente contratados para liderar uma área específica como o projeto de API e, em outros casos, eles se encontram editando e alinhando abordagens em uma ampla área. Uma constante em todas as funções é que a realidade de definir a direção técnica é muito mais sobre a compreensão e solução das necessidades reais da organização ao seu redor, e muito menos sobre a priorização de tecnologia e abordagens que você pessoalmente está entusiasmado em aprender. Em funções anteriores você pode ter tentado influenciar decisões em direção a escolhas tecnológicas pelas quais você está motivado, mas em funções seniores você é responsável primeiro pelo negócio e pela organização, e depois você mesmo.

Mentoria e patrocínio

Na minha função atual, eu me sinto energizado quando alguém que patrocinei envia um anúncio de que enviou seu trabalho, ou quando vejo que ajudei a moldar ou mudar o modelo de uma equipe de engenharia de um tópico importante. São essas equipes, não eu, que estão fazendo o dia-a-dia de trabalho duro de construir e apoiar sua tecnologia. Meço meu impacto com base no progresso deles e, mais importante, na direcionalidade desse progresso e no alinhamento do trabalho deles com os objetivos da empresa. – Michelle Bu

Existe uma visão popular de liderança heróica que se concentra em indivíduos extraordinariamente produtivos cujas decisões mudam o futuro da sua empresa. A maioria dessas narrativas são intencionalmente concebidas por equipes de relações públicas para criar uma boa história. É muito mais provável que você mude a trajetória de longo prazo da sua empresa através do crescimento dos engenheiros à sua volta do que através de heroísmos pessoais. A melhor forma de fazer crescer os que o rodeiam é criando uma prática activa de mentor e patrocínio.

Muitas escadas de carreira têm uma caixa de verificação obrigatória em torno do mentorship para se qualificarem para uma promoção para uma função de Staff, e o mentorship é uma parte fundamental da função. Partilhar a sua experiência e conselhos, juntamente com um relacionamento contínuo para compreender o contexto do receptor, é um trabalho de alto impacto. Nas funções seniores, o mentorship é apenas o bar para admissões, e os engenheiros mais eficazes do Staff emparelham uma quantidade moderada de mentorship com consideravelmente mais patrocínio: colocando o seu polegar directamente na escala para ajudar a avançar e apoiar aqueles à sua volta. Se você ainda não leu, Lara Hogan escreveu a peça canônica sobre a distinção entre patrocínio e mentorado, Como é o patrocínio?

Propor uma perspectiva de engenharia

Eu tenho um lugar na mesa em discussões de engenharia de nível superior que ocorrem em um nível acima de projetos individuais e equipes. Temos reuniões recorrentes de engenharia de pessoal onde discutimos problemas que abrangem equipes que são de natureza técnica e não técnica. – Dan Na

As organizações eficazes simplificam a tomada de decisões de rotina. Um bom exemplo disso é o processo de revisão de contratos para potenciais clientes empresariais. No início, haverá alguns contratos assinados que as equipes de produto e engenharia não se sentem à vontade para apoiar. Após isso acontecer algumas vezes, o processo incluirá mais partes interessadas nas etapas de revisão, e as horas extras as pessoas certas estarão nos lugares certos na hora certa.

Há uma segunda categoria de decisões, que são sensíveis ao tempo e importantes, e é mais desafiador colocar as pessoas certas na sala antes que essas decisões sejam finalizadas. É frequente que uma reestruturação organizacional ocorra sem um input valioso que teria mudado o resultado. Da mesma forma, é comum que os ciclos de entrevista para papéis pouco frequentes – aqueles em que você pode contratar uma pessoa a cada ano, como executivos ou engenheiros da equipe – não avaliem o candidato em uma dimensão importante. Para algumas empresas até mesmo coisas como planejamento de roadmap se enquadram nesta categoria.

Engenheiros de staff-plus são as pessoas que muitas vezes serão inesperadamente puxadas para dentro da sala onde este tipo de decisão está acontecendo. Isto dá-lhes a oportunidade de injetar contexto e perspectiva de engenharia em uma decisão enquanto ainda é possível mudar o resultado. Estes breves momentos de contribuição em decisões críticas têm um impacto indevido, e permitirão que você mantenha a perspectiva do engenheiro ouvida. São também um momento em que é fácil esquecer que o seu papel nestes momentos é muitas vezes representar os interesses de toda a engenharia, não apenas os seus.

Exploração

No meu papel actual dentro da incubadora estou a passar o dia inteiro a fazer protótipos, mas no meu papel anterior de líder tecnológico fiz muitas coisas diferentes. – Ritu Vincent

A escalada não pode resolver todos os problemas, mas é tão eficaz que muitas empresas lutam para tomar outras abordagens. Esta pode ser uma empresa orientada para o consumidor que luta para apoiar negócios empresariais, ou uma empresa madura que luta para competir com a cadência de lançamento de um concorrente menor. Pode até acontecer que seu negócio atual seja tão valioso que seja difícil priorizar novos negócios, mesmo que a taxa de crescimento do negócio valioso esteja diminuindo.

A longo prazo, as empresas ou aprendem a explorar ou desvanecem-se; este não é um desafio ignorável. A simples designação de uma equipe que domina a escalada em montanha para fazer um trabalho exploratório está longe de ser uma coisa certa, por isso muitas empresas adotam uma abordagem diferente. Elas encontram um casal de indivíduos de confiança com amplas habilidades, alocam alguns recursos e, alguns meses depois, voltam para ver o que descobriram. Um desses engenheiros é muitas vezes um engenheiro de Staff.

Este também nem sempre é um problema de negócios, pode ser qualquer tipo de problema ambíguo e importante que os sistemas da empresa não têm a forma adequada para resolver. Pode estar reduzindo seus custos de infraestrutura em uma ordem de grandeza. Pode ser identificar uma estratégia multi-regiões que leva seis meses em vez de três anos. Pode estar lidando com a súbita percepção de que sua base de dados principal tem apenas três meses de espaço em disco restante e você não pode atualizar para um tamanho maior (na minha experiência, um problema surpreendentemente freqüente em startups de rápido crescimento).

Este é um dos trabalhos mais gratificantes, e os mais arriscados, que as empresas fazem, e é preciso muita confiança organizacional para se confiar neste trabalho, incluindo ter o respeito do negócio de que se você falhar é uma reflexão sobre o problema e não você.

Being Glue

Tanya Reilly escreveu um post maravilhoso, Being Glue, que capta outro elemento central dos engenheiros de Staff de sucesso: fazer o necessário para identificar o trabalho certo e conseguir que ele seja enviado. Não é glamoroso, mas as organizações de alto impacto muitas vezes têm um ou mais Engenheiros de Staff trabalhando nos bastidores agilizando o trabalho mais importante e garantindo que ele seja terminado.

Mas você ainda vai escrever software?

É indelicado terminar qualquer discussão sobre o papel do Engenheiro de Staff sem opinar sobre a primeira pergunta que os Engenheiros de Staff fazem quando se reúnem em uma sala juntos: “Você ainda encontra tempo para escrever software?” A resposta é, claro, depende!

Ras Kasa Williams disse: “Eu ainda contribuo com código regularmente – certamente menos do que o resto dos engenheiros da minha equipa; mas era importante que eu sustentasse o trabalho “mão no teclado” para assegurar que a minha estratégia técnica (e outras decisões a nível macro) fosse informada pelas experiências no terreno do resto da minha equipa.”

Katie Sylor-Miller disse: “Eu sou um arquiteto frontend, mas de longe a principal coisa que tenho escrito ultimamente é SQL, porque eu estou fazendo muita análise de dados. Tenho olhado para as nossas métricas de desempenho para descobrir onde estão as áreas de melhoria, e quais seriam as questões de maior impacto a corrigir para melhorar o desempenho e as métricas de negócios. Vou escrever pequenos pedaços de JS ou PHP aqui e ali, mas é principalmente para ajudar a desbloquear equipes ou para executar pequenos experimentos relacionados ao desempenho”

Silvia Botros disse: “Eu não faço mais codificação para o negócio. Acho que a última vez que tive de puxar o meu terminal foi para refactorizar os meus ficheiros de pontos. Esta é uma decisão intencional do meu chefe, o Arquiteto Chefe. Ele vai verificar conosco a cada trimestre para ter certeza de que não contribuímos com nenhum código que entra em produção”

Joy Ebertz disse: “Quanto mais sénior você conseguir, menos o seu trabalho é sobre código. Claro, ao contrário de um gerente de pessoas, você ainda tem uma inclinação muito técnica e mesmo através do diretor, você provavelmente estará fazendo pelo menos alguma codificação. No entanto, quanto mais alto você conseguir, mais seu trabalho se torna sobre mentoring e crescimento das pessoas ao seu redor (e mais amplamente), construindo sua equipe através da construção da marca de tecnologia pública de sua empresa, notando tendências técnicas maiores que podem ser melhoradas ou corrigidas, ajudando a definir a visão tecnológica para sua equipe ou a empresa e advogando por recursos para projetos de dívida tecnológica”

Mais escreva alguns, alguns escrevam nenhum, mas nenhum escreva tanto quanto eles costumavam escrever no início de sua carreira. Haverá a semana ocasional que é puramente codificada, mas essas não serão a norma, e se elas acontecem com muita frequência é geralmente um sinal de trabalhar em algo confortável ao invés de importante.

Baixo mas gratificante

Um tema unificador em todo o trabalho Staff-plus é que os prazos são simplesmente mais longos. No início da sua carreira é fácil afeiçoar-se ao rápido ciclo de feedback do desenvolvimento de software – escrever, testar, enviar, repetir – e a maior parte do trabalho que você estará fazendo neste nível substitui aquele feedbdack loop por um que leva semanas, meses e anos.

O impacto e o crescimento pessoal vive nesses prazos mais longos, e enquanto todos com quem falei desejavam ter mais tempo para codificar, nenhum deles lamentou a sua transição para as suas funções actuais.