O que significa a engenharia 10X para os gestores de programas técnicos?

Galen Low: Os gestores de programas técnicos não costumam ter de escrever código, mas hoje em dia os engenheiros de software também não — pelo menos não manualmente. Por isso, a questão não é necessariamente saber se os TPM devem saber programar. A questão é: que nível de compreensão é necessário para que os gestores de programas técnicos consigam alterar a forma como acrescentam valor num mundo em que as equipas à sua volta estão a utilizar IA para trabalhar cinco, 10 e, por vezes, 50 vezes mais depressa do que há apenas alguns anos?

Para explorar a forma como o papel de um gestor de programas técnicos está a evoluir na indústria de software atual, convidei um vice-presidente de Entrega e Operações de Engenharia que liderou equipas de TPM em organizações como a Dell e a Google, bem como noutros ambientes de software de crescimento rápido. Juntos, vamos explorar tudo, desde as competências atualmente exigidas aos TPM até à forma como os responsáveis pela entrega podem defender o valor das suas equipas quando há mudanças na liderança.

Também vamos falar sobre a forma como os responsáveis pela contratação podem avaliar candidatos a TPM durante o processo de recrutamento e sobre o impacto que teria o desaparecimento do papel de TPM. Espero que goste do episódio.

Bem-vindos ao Podcast do Digital Project Manager — o programa que ajuda os líderes de entrega a trabalhar de forma mais inteligente, entregar com maior fluidez e liderar as suas equipas com confiança na era da IA. Eu sou o Galen e, todas as semanas, analisamos estratégias do mundo real, tendências emergentes, estruturas comprovadas e, ocasionalmente, uma história de guerra das linhas da frente dos projetos. Quer esteja a orientar grandes projetos de transformação, a gerir fluxos de trabalho de IA ou simplesmente a tentar manter o caos sob controlo, está no sítio certo.

E se tem gostado do que tem ouvido da nossa parte ultimamente, considere seguir-nos onde quer que nos encontre e talvez deixar-nos uma avaliação. Muito bem. Vamos começar.

Hoje estou acompanhado por Satish Menon, um líder de gestão de programas técnicos e operações de engenharia que liderou a entrega em gigantes tecnológicos como a Google e a Dell, bem como em empresas de software como a Tenable, a Cohesity e a Seismic.

Os programas sob a responsabilidade do Satish abrangeram lançamentos de hardware e software, infraestruturas de nuvem e produtos de otimização de centros de dados, contando com a sua capacidade para navegar por decisões da direção executiva, proporcionar liderança organizacional, desenvolver e implementar estratégias operacionais, transformar processos e aconselhar sobre o desenvolvimento de produtos.

Atualmente, o Satish tem ajudado equipas de gestores de programas técnicos a navegar pelo mundo da engenharia de software e da gestão de programas potenciadas por IA, defendendo simultaneamente o valor que o papel de gestor de programas técnicos desempenha nas organizações orientadas pela tecnologia.

Satish, muito obrigado por se juntar a mim hoje.

Satish Menon: Olá, Galen. Obrigado pela oportunidade. Estou muito entusiasmado por estar aqui.

Galen Low: Eis o pequeno roteiro que preparei para hoje. Primeiro, queria colocar-lhe uma questão um pouco controversa sobre a qual os meus ouvintes gostariam de conhecer a sua opinião. Depois, gostaria de utilizar essa questão como uma lente para analisar três aspetos.

Em primeiro lugar, queria analisar a forma como o papel do gestor de programas técnicos está a ser perturbado, especialmente no espaço do software. Pensei que poderíamos falar sobre a forma como os responsáveis de departamentos e os líderes de equipa podem defender o valor dos seus gestores de programas técnicos. E também pensei que poderíamos explorar as implicações da hibridização de funções entre os gestores de equipas de software e os gestores de programas técnicos.

O que lhe parece?

Satish Menon: Excelente. Estou ansioso por começar.

Galen Low: Ótimo. Vamos avançar. Eis a minha pergunta provocadora para começar. Os gestores de programas técnicos dizem que não precisam de saber programar para gerar valor. Entretanto, muitos executivos de tecnologia parecem discordar. Dizem que a IA significa que um gestor de uma equipa de engenharia de software e um gestor de programas técnicos são agora exatamente a mesma coisa.

Por isso, a minha pergunta é: quem tem razão? A IA criou as condições que tornam razoável esperar que os gestores de equipas de software sejam também gestores de programas técnicos e vice-versa?

Satish Menon: Pode concordar comigo que o papel do engenheiro de software passou por uma grande transformação nos últimos tempos, certo?

Passaram de escrever o código eles próprios, o que era o estrangulamento no passado, para utilizar atualmente muita programação por intenção e ferramentas de IA para gerar código a uma velocidade 10 vezes, ou até 100 vezes, superior. E o problema transferiu-se agora para o ciclo de revisão, como o ciclo de revisão dos pedidos de integração. O tamanho dos pedidos de integração aumentou. Assim, a carga passou para a supervisão humana daquilo que a IA gera no software.

Por isso, tal como observamos uma mudança no fluxo de trabalho e na velocidade da engenharia de software e naquilo que os engenheiros de software fazem, também tem de existir uma adaptação semelhante do lado dos TPM. Por exemplo, há três a cinco anos, costumava existir uma grande carga relacionada com o plano, o estado, as dependências, os riscos, a sua mitigação, a qualidade e a monitorização dos erros e da cobertura de testes.

Esses problemas eram tratados manual ou semimanualmente pelos TPM. Depois, há quatro ou cinco anos, começámos a transformar esse processo com o Jira e a Atlassian. Assim que o plano era configurado, o estado começava a surgir automaticamente, e os TPM podiam simplesmente consultar esses painéis e avaliar o que estava vermelho ou amarelo, começando depois a envolver-se na resolução de problemas.

O papel mudou. Já não se tratava apenas de criar um plano, recolher informações sobre o estado, elaborar relatórios e facilitar a mitigação de riscos. Passou a consistir em observar painéis em tempo real que indicavam o estado e, quando surgiam elementos vermelhos ou amarelos, coordenar a resolução dos problemas.

Agora, com a IA, existem ainda mais oportunidades para os TPM. Se analisarmos as ferramentas utilizadas atualmente, temos o Jira, onde o trabalho é acompanhado, o GitHub, onde o código é escrito, e o BrowserStack, onde são geridos os aspetos relacionados com a qualidade e a implementação.

Se conseguirmos triangular os dados destas três ferramentas, ou de outras ferramentas em utilização, obtemos painéis mais ricos, dados mais completos e análises mais aprofundadas dos riscos e dos problemas. O papel do TPM evolui dessa forma. Já não precisamos de identificar manualmente o que está vermelho ou amarelo.

Podemos utilizar a IA para triangular dados entre várias ferramentas e identificar os sinais certos e os aspetos relevantes, descobrindo onde estão os elementos vermelhos e amarelos de forma muito mais eficaz do que antes.

Galen Low: Gosto muito disso. Gosto particularmente da ideia de que o estrangulamento muda, mas de que existem, na realidade, dois estrangulamentos diferentes.

Do lado da engenharia, os programadores passam menos tempo a escrever código manualmente. Trabalham com ferramentas como o Cursor, conseguem trabalhar mais depressa e isso transfere o estrangulamento para a revisão. Quando fala de um gestor de uma equipa de engenharia, isso significa, na realidade, mais revisões para essa pessoa, certo?

O estrangulamento muda. Agora, provavelmente existe mais revisão e mais código para supervisionar, e eles acrescentam valor mantendo o fluxo em movimento e resolvendo rapidamente os problemas relacionados com o código. Mas isso não significa que exista capacidade adicional para assumirem também a gestão de programas técnicos.

Do outro lado, o outro estrangulamento costumava estar relacionado com a recolha de informações e atualizações de estado. Agora, sim, o nosso papel também está a ser perturbado. Estamos a utilizar outras ferramentas, como referiu, o Jira e a IA, e parte desta automatização aproxima-nos da resolução de problemas, em vez de nos deixar sem fazer nada durante todo o dia e, de repente, com capacidade para supervisionar uma equipa de engenharia de software.

Gosto desta perspetiva. A perturbação está a acontecer dos dois lados, mas isso não significa que tudo se transforme numa só função. São duas coisas distintas.

Satish Menon: Existe ainda outro aspeto. Um gestor ou diretor de engenharia de software é responsável por garantir que as suas equipas entregam código de elevada qualidade, seguro, acessível e com o desempenho adequado, mantendo uma boa velocidade.

Estão a melhorar essa velocidade com a IA. Mas, se esperar que sejam também responsáveis pelos aspetos multifuncionais dessa entrega — dependências de outras equipas de software, garantia de uma elevada cobertura de código e de testes, testes de desempenho, testes de integração de sistemas e entrega atempada do produto aos clientes — isso representa uma carga adicional.

Todos esses aspetos multifuncionais têm de ser tratados por alguém. Penso que os TPM, com o apoio de todas estas ferramentas, conseguem fazê-lo de forma muito mais eficiente e rápida, mas é necessário fazê-lo.

Se esperar que os diretores e gestores de engenharia de software façam também esse trabalho, estará a acrescentar-lhes uma carga adicional. É importante utilizar a analogia da segurança rodoviária. Temos entidades que emitem licenças, garantem que os carros estão registados e que as regras de trânsito são conhecidas.

Mas também temos patrulhas rodoviárias que emitem multas e garantem que as pessoas que violam o sistema são penalizadas através de auditorias aleatórias ou sistemáticas. São necessárias as duas coisas para que um bom sistema funcione. Não podemos limitar-nos a emitir licenças, registar todos os carros e ensinar as pessoas a conduzir em segurança, esperando depois obter bons resultados.

Precisamos de controlos e equilíbrios.

Galen Low: Gosto muito disso porque existe atualmente muita automatização em várias funções, especialmente na gestão de programas técnicos e na engenharia de software. Por vezes, ouço pessoas falarem sobre a automatização através de estruturas em que todas as regras estão definidas e as pessoas só têm de as seguir.

Mas, como diz, isso não é aquilo que os seres humanos fazem bem. Haverá sempre pessoas que encontram problemas, que violam as regras deliberadamente ou que podem não compreender quais são as prioridades. Fundamentalmente, continua a ser necessário alguém para orientar o processo.

Talvez menos do que antes, mas esse papel continua a ter valor. E levanta uma questão importante: são necessárias muitas peças diferentes para entregar um produto de software, e apenas uma parte disso corresponde à qualidade do código. O resto é coordenação multifuncional para garantir que tudo se articula e é entregue no momento certo.

Se estiver distraído a gerir uma equipa de engenheiros de software, a realizar reuniões individuais, a gerir as suas carreiras, a auditar a qualidade do código e a ajudar a resolver problemas técnicos, será muito difícil equilibrar essas prioridades com a entrega.

Talvez possamos afastar-nos um pouco. Na sua carreira, liderou equipas de gestores de programas técnicos em empresas como a Dell e a Google, além de outras grandes empresas de software. Temos falado sobre resolução de problemas. Um líder de uma equipa de software pode resolver problemas técnicos, e o gestor de programas técnicos também resolve problemas, sobretudo porque os relatórios e painéis disponíveis permitem uma abordagem mais proativa.

Mas existe um grande vazio entre as duas funções. Que problemas pode resolver um gestor de programas técnicos sem ter experiência de programação?

Que nível de fluência técnica espera dos seus gestores de programas técnicos? Que conceitos deve compreender qualquer TPM que trabalhe com engenheiros de software e porquê?

Satish Menon: Isso leva-me a um ponto que queria abordar, desenvolvendo parte da conversa que tivemos até agora.

Um gestor ou diretor de software pode gerir projetos totalmente contidos na sua organização. Mas, quando falamos de uma entrega maior, com dependências entre várias equipas, é aí que entra o TPM. Não apenas na coordenação multifuncional entre engenharia, gestão de produto, design, equipas de campo, entrada no mercado e documentação técnica, mas também nas dependências existentes dentro da própria entrega de software e que atravessam várias equipas.

Nunca devemos terminar esta conversa com a ideia de que um gestor ou diretor de software não faz gestão de projetos. Faz, mas gere entregas totalmente contidas na sua organização. Quando existem questões multifuncionais, é muito melhor contar com um TPM que atue a partir de uma posição neutra.

Quanto ao nível técnico necessário, sou a favor de utilizar ou contratar TPM que tenham sido programadores no passado ou que tenham tido uma exposição significativa à programação. Isso permite-lhes compreender a linguagem dos engenheiros, conquistar o seu respeito e colaborar com eles.

É importante compreender o ciclo de vida do código: o que são verificações, confirmações, revisões de pedidos de integração, ciclos de revisão, análise estática, testes unitários, testes de sistema, testes de integração, testes de desempenho e implementação.

É necessário compreender as nuances das diferentes variáveis no ciclo de vida da programação. Se já programou, saberá isso. Mesmo depois de cinco a 10 anos como um bom TPM, ao alcançar funções mais sénior e lidar com assuntos complexos, poderá já não programar regularmente, mas não terá esquecido o ciclo de vida do código.

Deve também compreender o ciclo de vida das atividades exteriores à programação: requisitos, codificação, testes, projetos-piloto, disponibilização geral e a lista de verificação associada ao lançamento.

Outro nível de competência técnica consiste em compreender o produto que está a ser lançado. Já vi TPM que apenas aplicam um processo ao fluxo de trabalho técnico sem saberem exatamente que software está a ser desenvolvido ou o que faz.

Se compreender o produto, terá conversas muito melhores com gestores de produto, designers, engenheiros de software, gestores de sucesso do cliente e engenheiros de sistemas. Terá melhores competências de facilitação e será um parceiro multifuncional, neutro e equilibrado.

Por fim, deve conseguir escrever os seus próprios scripts, gerar os seus próprios painéis e criar painéis em tempo real, seja no Jira, no Tableau, no Sisense ou noutras ferramentas. Se conseguir criar scripts, gerar painéis, procurar os sinais certos e perceber o que deve ser medido, isso será útil.

Essas também são competências técnicas, mas não significam necessariamente que tenha de escrever código. Essa é a minha opinião, embora as pessoas possam ter perspetivas diferentes.

Galen Low: Gosto muito disso. Não é uma questão binária. Não é verdade que apenas os gestores de programas possam fazer gestão de programas, nem que os gestores de programas desapareçam porque os gestores das equipas de software vão assumir esse trabalho.

Existe claramente um espetro entre essas duas posições, e uma das variáveis é a complexidade. Se estiver apenas a entregar software dentro da sua equipa, sem muitas partes móveis, conhecer muito bem a sua equipa e possuir um sistema sólido, parte da entrega será menos complexa.

Em contraste, os ecossistemas de projetos altamente complexos podem envolver fornecedores, marketing e vários intervenientes do produto. O valor está em articular tudo e navegar pela complexidade para garantir que a entrega acontece.

Também gosto da sua ideia de melhores conversas. Uma compreensão mais profunda e um vocabulário comum permitem colaborar melhor. Existe ainda uma dimensão técnica em praticamente todas as funções, incluindo a de gestor de programas técnicos. É necessário ter sensibilidade para criar um relatório, construir um painel ou automatizar um processo.

Mas isso não significa necessariamente ser alguém que escreve código habitualmente. Quero colocar-lhe duas questões. Para os líderes empresariais que dizem que isso parece bem, mas perguntam qual é o retorno do investimento de uma compreensão mais profunda e de melhores conversas, o que é que isso representa na prática?

Satish Menon: Se tiver melhores conversas, conquistará mais respeito. Com mais respeito, será convidado para discussões estratégicas mais importantes, onde será visto como um parceiro estratégico do lado da execução e como alguém que garante que a estratégia se transforma em bons planos.

Se não conquistar esse respeito, se não possuir o vocabulário e a profundidade necessários, os gestores de produto e de engenharia definirão a estratégia sem si. Não terá lugar à mesa.

Criarão um plano e entregar-lho-ão, dizendo-lhe para o acompanhar. É aí que será colocado. Sem o vocabulário deles, não terá o seu respeito, não será convidado para a mesa e tornar-se-á apenas alguém que acompanha tarefas.

É importante compreender que a vida da engenharia de software não começou com os TPM. Começou com as pessoas da engenharia e com os gestores de produto. Os gestores de produto tinham ideias e as equipas de engenharia colaboravam com eles para as executar.

À medida que as equipas crescem, surgem várias equipas de engenharia e torna-se necessária uma plataforma comum. Caso contrário, a engenharia não consegue escalar. Desenvolve-se uma plataforma comum sobre a qual podem existir vários produtos e criam-se interdependências entre as equipas de engenharia. É nesse momento que se diz: precisamos de um TPM para acompanhar todas as dependências.

A função de TPM surge mais tarde, não no início. Por definição, quando entra como primeiro TPM de uma organização, ser-lhe-á dito o que fazer, como fazer e quais são os resultados esperados. Só gradualmente começará a exercer influência.

Os gestores de produto e de engenharia já conversam, definem estratégias e fazem planos há muito tempo. O TPM é novo. Para ser um parceiro em pé de igualdade, precisa de conquistar respeito e de falar a linguagem deles. É assim que começa a conquistar um lugar à mesa.

Galen Low: Gosto disso porque há duas ideias importantes. Primeiro, provavelmente chegou tarde à festa e precisa de conquistar respeito com humildade, compreendendo como as coisas eram feitas antes da sua chegada. Mas, por outro lado, a sua função é indispensável para a escala.

O valor que traz é funcionar como uma alavanca de crescimento à medida que as coisas se tornam mais complexas, envolvem mais equipas e têm mais riscos. É necessário falar a linguagem de todas as equipas multifuncionais, incluindo a de produto.

Do ponto de vista executivo, um parceiro estratégico é alguém que compreende o que está a acontecer. Não se limita a executar tarefas e a cumprir prazos; garante que o que é lançado está correto, identifica oportunidades e ajuda a entregar mais valor aos clientes.

O gestor de programas técnicos pode defender a visão do que está a ser entregue e a estratégia de entrega, procurando maximizar o valor do produto. Isso pode significar lançar mais cedo, insistir na qualidade ou concentrar-se em encantar o cliente.

Por vezes, as pessoas veem a função como meramente administrativa: assinalar caixas, verificar tickets do Jira e acompanhar gráficos de trabalho restante. Mas isso não entrega tanto valor como compreender melhor os problemas e iterar sobre o plano para alcançar um valor superior ao inicialmente previsto.

Satish Menon: Uma das oportunidades que temos atualmente, neste mundo da IA, é que, se tivermos um conceito, podemos produzir rapidamente uma demonstração criada através de programação por intenção. Depois, podemos mostrá-la a três a cinco clientes de confiança, que nos podem dar feedback.

No passado, era necessário escrever muito código antes de ter uma demonstração para apresentar ao cliente. Atualmente, podemos gerar rapidamente uma demonstração. Na Seismic, chamávamos-lhe uma pré-visualização de investigação.

Podemos mostrar o código inicial aos clientes, recolher feedback, aperfeiçoar os requisitos finais e depois consolidar a solução até à disponibilização geral. Os TPM podem desempenhar um papel importante ao garantir este processo de pré-visualização de investigação, permitindo obter mais valor antes da disponibilização geral.

A segunda parte é o valor estratégico. Tudo se torna mais fácil quando existe alinhamento com o executivo da direção sobre a forma como acrescenta valor. Por vezes, chega um novo executivo e as equipas entram num período de incerteza, porque cada executivo tem ideias preconcebidas diferentes.

Pode haver um bom alinhamento sobre o valor esperado, ou pode ser necessário explicar o valor criado e pedir três meses para demonstrá-lo. Por vezes, essa oportunidade não existe. A pessoa quer fazer alterações imediatamente. Temos de aceitar que, por vezes, somos condicionados pelas ideias preconcebidas de quem lidera.

Galen Low: Este segmento é patrocinado pela Fingerprint. Todos os visitantes da sua plataforma parecem iguais à partida. Pode confiar neles ou representam uma ameaça? A Fingerprint reconhece bots, agentes de IA, VPN, manipulação e mais de 100 sinais únicos para fornecer uma classificação de risco duradoura e deteção de ameaças em tempo real. Mesmo quando a atividade humana e a atividade dos agentes se misturam, pode identificar mais rapidamente o tráfego suspeito e criar sites e aplicações mais seguros.

Mais de 6 000 empresas utilizam a Fingerprint todos os dias. Junte-se a elas em fingerprint.com. E agora voltamos ao programa.

Quero regressar à questão da pré-visualização de investigação, mas levantou um ponto muito importante sobre a mudança, especialmente ao nível da liderança. Os executivos precisam de se adaptar rapidamente, mas também foram contratados para trazer as suas próprias ideias e podem querer agir depressa.

Satish Menon: Somos uma função considerada periférica, não central. Quanto mais cedo aceitarmos isso e acrescentarmos valor onde existe um bom alinhamento, mais tranquilos estaremos connosco próprios.

Galen Low: Em alguns casos, existe uma janela muito curta para defender a sua equipa, sobretudo quando lidera a entrega e supervisiona uma equipa de gestores de programas. Como entra na conversa e defende o valor que a sua equipa acrescenta? Como mudou esse argumento no mundo da IA?

Satish Menon: A ideia central da conversa com a nova liderança é a mesma, mas agora tenho de utilizar um padrão diferente. No passado, explicava como tínhamos organizado o trabalho, automatizado os painéis, obtido atualizações de estado e participado na resolução de problemas e mitigação de riscos.

Hoje, tenho de explicar como transformámos esse trabalho para a era da IA, triangulando dados entre vários sistemas e procurando indicadores antecedentes que permitam evitar maus resultados, em vez de reagir depois de estes ocorrerem.

Mostro os indicadores antecedentes, os painéis atuais, a forma como triangulamos vários sistemas, como utilizámos a IA na gestão de programas técnicos para complementar a utilização da IA na engenharia e como adaptámos a equipa a este novo contexto.

Por vezes, há tempo para ter estas conversas em reuniões individuais, reuniões de equipa ou outros contextos. Procuro essa oportunidade assim que sei que está a ocorrer uma mudança. Por vezes resulta e por vezes não. Faz parte.

Galen Low: Algumas batalhas não podem ser vencidas, especialmente quando um executivo está sob pressão para mudar a rentabilidade, os resultados financeiros ou a estrutura da equipa. Mas gosto da ideia de que também existe um papel educativo.

O valor já não está em garantir que pessoas inteligentes fazem coisas. Está em evitar problemas, gerir riscos e garantir bons resultados à velocidade necessária. É muito melhor evitar uma situação desastrosa do que explicar posteriormente que tudo correu mal.

Satish Menon: Uma boa equipa de TPM, com a forma certa de trabalhar nesta era da IA, pode identificar indicadores antecedentes de risco em qualquer programa, execução ou equipa operacionalmente eficiente. Pode alertar para um mau resultado iminente e ajudar a mitigá-lo.

Caso contrário, existem consequências para os maus resultados, mas a resposta chega tarde e é dispendiosa.

Galen Low: O papel é agora diferente. Isso deve-se à IA e às mudanças no desenvolvimento de software, mas também à evolução natural das profissões. Como é que o papel do gestor de programas técnicos mudou relativamente a três ou quatro anos atrás? Que áreas e prioridades mudaram? Quais são as suas expectativas relativamente à entrega de valor pelas equipas?

Satish Menon: Os engenheiros de software estão a trabalhar 10 ou 100 vezes mais depressa. Temos de fazer o mesmo.

Temos de deixar de produzir relatórios manuais e recolher estados manualmente. Temos de utilizar painéis automatizados e em tempo real para avaliar os elementos vermelhos e amarelos. Devemos validar os sinais provenientes de uma ferramenta através da triangulação com outras ferramentas que consolidam informações de várias áreas.

Por exemplo, se o Jira indicar que algo está quase concluído, mas a avaliação do GitHub e do Claude não corresponder, isso é um sinal de alerta. Se o ciclo de vida da programação não estiver alinhado com o relatório do Jira, existe um risco que pode ser identificado antecipadamente.

Do mesmo modo, no lado dos testes, devemos consultar o BrowserStack para compreender a qualidade, a implementação na nuvem, os testes e o ambiente de preparação. A análise conjunta destas fontes produz uma avaliação mais rica.

Se não nos adaptarmos a estas mudanças e às novas formas de compreender o estado dos projetos e a entrega de valor, poderemos tornar-nos obsoletos. Mas quem acompanhar a mudança terá mais hipóteses de prosperar.

O mesmo se aplica aos engenheiros de software. Se utilizarem a IA apenas ocasionalmente, quando ficam bloqueados, o seu tempo também será limitado. O código será cada vez mais gerado por IA, com supervisão humana para garantir que faz o que deve e não ultrapassa limites importantes.

Temos de fazer o mesmo do lado dos TPM. Assim, as duas funções acrescentarão valor. Como equipa, engenharia de software e TPM entregarão muito mais depressa, mantendo uma parceria em que ambas as funções aceleram para trabalhar melhor.

Galen Low: Gosto dessa ideia de permitir escala e valor. Não podemos tornar-nos um estrangulamento por estarmos desatualizados, mas também temos de participar ativamente no processo.

Identificar discrepâncias entre sistemas é importante, porque as equipas multifuncionais ainda estão a desenvolver a forma como trabalham em conjunto com as suas ferramentas. Essas discrepâncias podem criar riscos.

Também falámos sobre resolução de problemas. Um gestor de programas técnicos não precisa de ter experiência de programação, mas deve compreender parte do ciclo de desenvolvimento de software para conquistar respeito e ajudar a resolver problemas.

Que nível de problemas espera que os seus TPM consigam resolver? Devem limitar-se a coordenar equipas e a garantir alinhamento, ou espera algo mais profundo?

Satish Menon: Existe um espetro. Quando trabalhei na Google, os TPM eram extremamente técnicos e conseguiam resolver problemas técnicos a um nível mais profundo. Isso é pouco comum na indústria.

Um TPM típico deve conseguir analisar um problema e perceber, por exemplo, que uma equipa está atrasada e precisa de ajuda. Deve reconhecer que existem equipas semelhantes com capacidades relevantes e sugerir a possibilidade de obter apoio dessas equipas.

Se uma equipa de plataformas estiver atrasada e isso afetar o lançamento de um produto, é importante garantir que o trabalho da plataforma é priorizado para que o produto de elevada prioridade seja lançado a tempo.

O TPM deve compreender quem pode ser envolvido para ajudar a resolver o problema e discutir isso com o diretor de engenharia. Se levar ideias originais à discussão, conquistará mais respeito e reduzirá o trabalho de análise que o líder de engenharia teria de fazer.

O objetivo é retirar algum trabalho da sua responsabilidade: reunir as pessoas certas, identificar as fontes de apoio e estruturar a questão e os próximos passos de modo a facilitar a solução.

Não espero normalmente que o TPM diga diretamente a um grupo de engenheiros exatamente o que deve fazer para resolver um problema. Espero que ajude a estruturar o problema e a encontrar os recursos certos.

Galen Low: Existe um tema recorrente: uma compreensão mais profunda cria mais valor. Se souber que outra equipa tem as capacidades certas, está disponível e pode ser parte da solução, pode apresentar essa opção em vez de simplesmente dizer à equipa que o problema é dela e tem de o resolver até sexta-feira.

Pode colaborar e chegar mais depressa a uma solução.

Satish Menon: Se disser apenas que o problema é deles e os responsabilizar por uma data, o seu respeito diminui. Mas se compreender suficientemente o trabalho para propor soluções de 70%, como uma possível distribuição de recursos ou formas criativas de resolver o problema, poderá ajudá-los.

Pode dizer: “Eis uma ideia que tive, mas vocês são responsáveis por isto. Se for útil, utilizem-na; caso contrário, encontrem outra solução.” As pessoas passam a valorizar o facto de trazer sugestões.

Galen Low: Gosto da expressão “soluções de 70%”. Apresentar algo parcialmente desenvolvido, que não é final mas constitui um ponto de partida.

Inicialmente, interpretei a sua referência à pré-visualização de investigação como se os TPM fossem criar o protótipo através de programação por intenção. Mas não era isso que queria dizer.

Satish Menon: Não. Isso é mais uma questão de processo. Não quis dizer que os TPM criariam demonstrações para clientes através de programação por intenção.

Os gestores de produto e os engenheiros sénior são os responsáveis por essa programação. Os TPM coordenam o processo, garantem que existem boas demonstrações para os clientes e recolhem requisitos adicionais. Limitam-se a supervisionar o processo e o fluxo de trabalho.

Galen Low: Todos estão a trabalhar mais depressa, sobretudo no lado da engenharia de software, mas a colaboração continua a ser valiosa. Os silos não desaparecem simplesmente porque as equipas são mais eficientes.

A pré-visualização de investigação não acontece sem a engenharia. Existe mais colaboração porque os programadores não se limitam a escrever código manualmente, os gestores de programas têm ferramentas e painéis mais eficientes e os gestores de produto podem criar rapidamente protótipos.

Tudo isso reduz o risco da entrega.

Satish Menon: Vi pré-visualizações de investigação criadas através de programação por intenção feita por engenheiros, com base em ideias de gestores de produto ou de pessoas de design de produto.

Quando alguém tem uma ideia interessante, pode criar rapidamente um protótipo. Já não estamos limitados a apresentar apenas uma demonstração baseada num design do Figma. Ultrapassámos essa fase.

Galen Low: Como aborda as decisões de contratação? Prefere contratar um antigo programador que se tornou um excelente gestor de programas ou um gestor de programas experiente que nem sabe o que é um pedido de integração?

Satish Menon: Como disse antes, os TPM que já programaram tendem a ser melhores TPM. Contudo, existem exceções. Já vi TPM que aprenderam a linguagem da programação através de uma colaboração prolongada com programadores.

Avalio o resultado, não apenas o currículo. Quero saber se conseguem falar eficazmente a linguagem dos engenheiros, dos gestores de produto e dos designers. A forma como chegaram a esse ponto é menos importante do que o resultado.

Atualmente, porém, as oportunidades para entrar na gestão de programas de software sem experiência de programação são muito reduzidas. No passado, um gestor de programas de hardware podia entrar num projeto de software, colaborar com os programadores e aprender como o software funcionava.

Hoje, essa oportunidade é menor. A tolerância para alguém que precisa de formação no trabalho é muito baixa. Procuram-se pessoas prontas a trabalhar. É uma dinâmica de mercado infeliz, mas é a realidade.

Galen Low: É uma perspetiva muito realista e corresponde ao que se ouve no mercado. Não significa que, se não souber o que é um pedido de integração, não conseguirá emprego. Mas deve estar preparado para se formar e procurar todas as oportunidades para falar essa linguagem e colaborar com equipas multifuncionais.

Satish Menon: Há 15 anos isso seria possível. Atualmente, não.

Galen Low: A fasquia é mais alta porque a colaboração é maior. A pressão para entregar também é maior. Não podemos abrandar nem cometer erros. Espera-se que sejamos rigorosos a uma velocidade 10, 50 ou 100 vezes superior.

Quem entra deve conseguir fazer parte da equipa, participar no diálogo e adaptar-se rapidamente. Mesmo sem uma formação técnica, é importante fazer esse trabalho antes ou durante a integração.

Satish Menon: Algumas empresas e responsáveis de contratação utilizam apenas perguntas situacionais não técnicas. Eu não faço isso. Em todas as entrevistas, crio um conjunto específico de perguntas para avaliar a fluência técnica nas áreas que considero importantes.

Adapto as perguntas ao candidato, garantindo que estão dentro daquilo que deveria ter feito e conhecer tecnicamente, com base no currículo e nos produtos que lançou.

Utilizo perguntas de fluência técnica para determinar objetivamente o nível do candidato, numa escala de zero a 10, tanto relativamente ao mercado vertical em que trabalhou como ao fluxo de trabalho geral de um engenheiro de software.

Depois, faço perguntas situacionais sobre as competências interpessoais e a inteligência emocional do candidato. Também adapto o painel de entrevistadores para avaliar diferentes aspetos. Aprendi esta metodologia objetiva de entrevistas na Google, onde descobri uma forma muito científica de contratar.

Galen Low: Pode dar-nos um exemplo de uma pergunta situacional que avalie conhecimentos técnicos de um determinado tipo de candidato?

Satish Menon: Se alguém afirmar que trabalhou num ambiente de software como serviço e otimizou o ambiente de lançamento para acelerar a entrega, perguntarei o que diferencia a entrega de software como serviço da entrega no local, que atalhos foram utilizados e porquê.

Farei perguntas detalhadas e perguntas de seguimento para compreender até que ponto a pessoa conhece realmente a entrega de software como serviço e o funcionamento do produto.

Se alguém disser que lançou um produto na Disney ou na Salesforce, pesquisarei os produtos dessa empresa e perguntarei sobre as funcionalidades que lançou. Deve conseguir explicar o que foi lançado, qual era o ponto de partida, o que foi entregue e que mudança isso trouxe para os clientes.

Também colocaria perguntas básicas sobre o ciclo de vida do software no lado da programação, sobre DevOps, sobre a diferença entre um ambiente de preparação e um ambiente de produção e sobre os controlos que impedem a introdução de vulnerabilidades de segurança.

Quero perceber se a pessoa compreende como funcionam o software, a nuvem e os conceitos relacionados.

Galen Low: Começámos esta conversa com a ideia de expectativas desalinhadas relativamente aos gestores de programas técnicos. Alguns executivos gostariam que o papel de TPM e o de gestor de uma equipa de engenharia de software fossem combinados.

Apresentou vários bons argumentos para explicar por que razão isso não deveria acontecer. Mas, olhando para o futuro, imaginemos que essa função híbrida se torna a estrutura dominante no desenvolvimento de software. Qual seria o impacto e o que significaria isso para líderes como o senhor, que defendem a separação das duas funções?

Satish Menon: Como comunidade, devemos concentrar-nos naquilo que conseguimos controlar. O que não conseguimos controlar está fora das nossas mãos.

Podemos estar à frente no que diz respeito às capacidades que as ferramentas atuais permitem e ao valor que ainda podemos acrescentar à entrega de produtos. Devemos pensar em termos multifuncionais, multiequipa e interdisciplinares.

O nosso maior valor está na interseção de várias funções que se juntam para entregar um produto. Primeiro, temos várias equipas de engenharia. Depois, engenharia e garantia de qualidade. Depois, engenharia, garantia de qualidade, DevOps e documentação técnica.

A seguir, temos a colaboração entre o que é entregue pela organização de produto e as equipas de campo, gestores de sucesso do cliente, engenheiros de vendas, apoio ao cliente e serviços premium. Existem ainda eventos de lançamento, mensagens de marketing e outras funções que contribuem para o panorama multifuncional.

É aí que existe a oportunidade de atuar como orquestrador. Também devemos pensar em várias empresas e parcerias: uma empresa pode lançar algo em conjunto com o produto de um parceiro, exigindo gestão de programas entre empresas.

Devemos pensar de forma cada vez mais ampla sobre a evolução das ferramentas, o que elas permitem fazer e o que continua nas nossas mãos. No mundo atual, isso significa utilizar painéis automatizados em tempo real, triangular dados entre ferramentas, utilizar IA e envolver-nos no produto e na resolução de problemas.

Depois, devemos pensar em problemas multifuncionais cada vez maiores.

Galen Low: Gosto muito disso. Estamos no centro da coordenação. Se retirarmos essa função do centro e a concentrarmos apenas na engenharia de software, perderemos todo esse valor.

É a escala, a complexidade, os diferentes parceiros, equipas e disciplinas que justificam a existência de uma função separada para conduzir e orquestrar esse valor. Mas é necessária uma compreensão profunda. Não podemos limitar-nos a assinalar caixas e aplicar estruturas a produtos que não compreendemos.

Temos de compreender o valor, perceber como o produto é construído e garantir que é entregue de forma significativa e impactante.

Satish, muito obrigado pelo tempo que passou comigo hoje. Foi um prazer. Para quem gostou do que partilhou, onde pode encontrar mais informações sobre si?

Satish Menon: Basta procurar o meu perfil no LinkedIn.

Galen Low: Mais uma vez, muito obrigado.

Satish Menon: Gostei muito da nossa conversa, Galen. Muito obrigado pela oportunidade.

Galen Low: Muito bem, pessoal. É tudo por este episódio do Podcast do Digital Project Manager. Se gostou desta conversa, subscreva o programa onde quer que o ouça. E, se quiser ainda mais conhecimentos práticos, estudos de caso e guias, crie uma conta gratuita em thedigitalprojectmanager.com.

Até à próxima. Obrigado por nos ouvir.