[Episódio 1] Um dia na vida de um tech lead na ThoughtWorks: Robin Doherty

Conheça o Robin

Robin mora e trabalha no pequeno escritório da TW na Austrália, em Charters Towers, North Queensland.

Ele gosta de cozinhar banquetes para seus amigos e família (muitas vezes na churrasqueira) e ir a festivais locais (pense em queimaduras, sujeira e música country ruim) e a pubs. Robin é apaixonado por tecnologia e gatos. Um dia, ele construirá um robô que converte o comportamento felino em demandas faladas. Aí seu gato Duncan dominará o mundo de verdade.

Robin trabalha na ThoughtWorks Austrália como Regional Security Champion/Lead Security Architect / Tech Lead / desenvolvedor. Ele fornece garantia e assistência em segurança da informação com práticas seguras de entrega de software para todos os nossos times de entrega de software e atua como um serviço de consultoria interna nas questões de segurança para os consultores da ThoughtWorks. Ele também é responsável pelo desenvolvimento das habilidades de segurança dentro da ThoughtWorks Austrália.

Robin também é uma pessoa desenvolvedora de software no time Identity da ThoughtWorks, um time distribuído globalmente que é responsável pelo serviço de identidade da TW.

O que um tech lead faz na prática?

Ter um papel ativo na produção de software com as mãos à obra é essencial, e o trabalho do tech lead não é “fazer o serviço duro”. Você não quer uma pessoa isolada com conhecimento técnico em seu time – isso te dá um fator de barramento de 1, o que é ruim. Então o papel do tech lead inclui programar como qualquer outra pessoa desenvolvedora no time.

O tech lead também tem um papel de liderança do time técnico, o que é bem mais difícil de definir. Inclui ter responsabilidade pelo desenvolvimento profissional de outros membros do time e responsabilidade pela força da solução, tanto em termos de adequação com o problema a ser resolvido e sua força técnica. Isso significa que a função do tech lead envolve muita comunicação (e, espera-se, influência) tanto dentro do time como fora, com stakeholders, outros times técnicos e outras partes da organização.
 

Como é um dia típico?

Meus dias raramente são “típicos”, porque meu papel atual é bem incomum. Na verdade, eu tenho dois papéis, e ambos envolvem colaboração com membros do time em fusos horários distantes, então meu dia de trabalho é bem diferente da maioria das pessoas da ThoughtWorks.

Qual a parte mais desafiadora do seu trabalho?

A parte mais desafiadora de qualquer trabalho na indústria do software é um clichê – são as pessoas. Isso é verdade especialmente no trabalho de tech lead. Na maioria das vezes, quando estou trabalhando em um projeto de um cliente, meu trabalho é interagir com outras pessoas. Eu raramente fico sozinho escrevendo código no computador. Como eu disse antes, eu sempre programo com um par, e até aqui a comunicação é tão importante quando a expertise técnica. Eu estou sempre me comunicando com outros membros do meu time e com pessoas fora dele. Mesmo o código que eu escrevo é comunicação – a coisa mais importante do código é que ele seja entendido e fácil de as outras pessoas lerem. Às vezes, é comunicação técnica, outras não. Ser um bom comunicador (o que inclui ser um bom ouvinte) o tempo todo é desafiador e há sempre espaço para melhorar.

Como você é avaliado?

Eu sou avaliado pelo cliente sob a óptica do sucesso do projeto. Isso normalmente significa entregar uma solução robusta e resolver os problemas certos. Os times conseguem isso quando sua cultura e maneira de trabalhar são eficazes. Infelizmente, para alguém de fora, essa eficácia é difícil de ser observada e é muito mais fácil influenciar negativamente do que positivamente. O benefício de se entregar software (valor de negócio) incrementalmente é que o “sucesso” (ou a falta dele) é visível para os stakeholders, o que facilitar melhores tomadas de decisão.

Eu foco em construir e manter uma boa cultura de equipe e nutrir as habilidades certas no time, e quando eu consigo fazer isso bem, temos sucesso em todas as medidas.

O que faz um bom tech lead?

Conscientemente desenvolver e exercitar suas habilidades de comunicação e influência. Elas são necessárias para a maior parte do trabalho.

Construir um entendimento amplo e profundo do projeto e do software. É um mito que você deve ser uma pessoa que enxerga o todo ou que só enxerga os detalhes. Um tech lead precisa ser ambas.

Entender as pessoas no seu time, deixá-las usar suas habilidades efetivamente e incentivar seu desenvolvimento profissional. Direcione o tipo certo de trabalho para as pessoas certas (as faz feliz e isso torna seu time bem-sucedido).

Construa uma cultura de equipe forte. É mais fácil falar do que fazer. Um começo é dar o exemplo de como você quer os membros do time se comuniquem entre si. Eu acho que uma forte cultura de feedback é importante para que times cresçam juntos e isso é algo que digo explicitamente e tento me colocar nisso.

Como você equilibra as responsabilidades ligadas ao código com as não ligadas?

O desafio é muitas vezes assegurar que eu tenho tempo suficiente reservado para manter meu pensado fundamento no código. Até onde isso é necessário e os métodos para fazer isso podem variar de projeto para projeto e de time para time. Dependendo do cliente, projeto ou time, eu tento reservar uma parte do meu tempo (30%-60%) para essa finalidade.

Eu encontrei nas “horas principais de pareamento” uma maneira útil de conseguir isso e, algumas vezes, é melhor bloquear certas horas do dia para esse propósito. Eu sempre pareio. É importante para mim ouvir outras perspectivas e ser parte do conhecimento compartilhado dentro do time – fazer de uma única pessoa um ponto de falha de qualquer parte do código é uma receita para o desastre, especialmente quando essa pessoa tem um papel que requer um horário flexível.

É importante lembrar que ser um tech lead não significa ser o programador mais competente ou informado. Se você é forçado a assumir esse papel, meu conselho é começar a trabalhar urgentemente em seu plano de transição – descobrir uma maneira de possibilitar que os membros do time à sua volta assumam mais responsabilidades, para que você não se torne indispensável (o que é estressante e improdutivo).

Em seu projeto atual, qual tecnologia te empolga mais?

Eu gosto de trabalhar com qualquer tecnologia que ajude a mim ou meu time a entregar um software melhor de maneira mais rápida. Sou um grande fã da Clojure por isso e, atualmente, o Serverless (o paradigma e o framework) está me economizando muito tempo e esforço.

Mais do que qualquer tecnologia, eu me empolgo em resolver problemas que são interessantes para mim. Nesse momento, estou trabalhando em gerenciamento de dispositivo para a ThoughtWorks. Estou curtindo o desafio de fazer de maneira transparente e que respeita a privacidade. O código será open source, pelo menos internamente, e permitiremos que ThoughtWorkers vejam um conjunto limitado de dados coletados de seus laptops.

Meu papel é me dividir 50% em Identity e 50% em Segurança da Informação e, neste projeto, estou desenvolvendo algo para Identity que será realmente útil para Segurança da Informação – eu sou meu próprio cliente feliz. Como um ThoughtWorker, estou feliz de ser capaz de confiar que minha privacidade não é invadida e, da perspectiva da Segurança da Informação, é importante ser capaz de dizer aos nossos clientes com certeza de que sim, nós reforçamos a segurança em nossos laptops – criptografia, com senhas fortes, antivírus e firewall.

Como você equilibra seu papel como consultor com o de tech lead?

Os melhores tech leads são excelentes consultores. Ser um tech lead demanda excelência na comunicação e influência, assim como a consultoria. Eu vejo isso como uma papel só e não dois.

Eu amo ser consultor porque...

Eu gosto de variedade, aprender coisas novas (rapidamente) e trabalhar em equipe. Trabalhar em clientes diferentes, em indústrias diferentes, em diferentes tipos de projetos, com diferentes tecnologias e pessoas significa que raramente um dia será igual ao outro.