CTO: A evolução do papel do Chief Trade-Off Officer

“Pare de tentar fazer todo mundo feliz. Você não é chocolate”

– Anônimo

Como observador distante da arte de ser DJ, acredito que posso facilitar o trabalho deles. Meu plano astuto é substituir todos aqueles controles deslizantes complexos em seus decks de mixagem por interruptores binários. Volume: sim ou não? Graves: ligado ou desligado?

Ridículo? Com certeza, mas essa é a mesma simplificação exagerada frequentemente aplicada à tecnologia. É uma conversa que será familiar para muitos, especialmente para Diretores de Tecnologia (CTOs). Os CTOs vivem no espaço cinzento, compreendendo que eles têm uma variedade de demandas concorrentes que precisam gerenciar, comumente chamadas de “ilidades”, como escalabilidade, acessibilidade e suportabilidade. Os clientes dos CTOs desejam tudo: soluções totalmente confiáveis e altamente flexíveis com custos de operação insignificantes, investimento mínimo de tempo fora da TI e segurança total. Essas demandas são cada vez mais expressas em termos como “a necessidade de ser mais ágil”. A realidade é um pouco mais desafiadora.

Metaforicamente, tenho certeza de que todos adoraríamos uma casa de vinte quartos com uma hipoteca de 5 reais por mês. A realidade é que fazemos trade-offs entre custos e funcionalidades. Simplificando, trade-off significa que mais de uma coisa implica menos de outra. Se eu administrar um restaurante, posso optar por um serviço completo, mas provavelmente haverá um trade-off entre um ticket médio mais alto e a quantidade de clientes atendidos e os custos de pessoal. Não é diferente para o CTO, embora palavras como priorização e governança sejam frequentemente vistas como formas do CTO dizer não.

Embora sempre existam fatores restritivos, como fazer mais com menos e fazer escolhas explícitas que apoiem melhor seu negócio? Alguns dos melhores líderes que conheci, CTOs em particular, entendem que fazer investimentos que maximizem suas habilidades de fazer mais está no centro de suas funções. Como meu colega Gregor Hohpe destacou em seu blog post, mapear as necessidades de negócio atuais e futuras em um plano de tecnologia e, ao mesmo tempo, deixar opções abertas para se adaptar a diferentes futuros é o que a arquitetura representa em última análise. Para quem se lembra das equações integrais da escola, os CTOs tentam continuamente maximizar o valor (área sob a curva) com base em parâmetros como custo, tempo e risco.

Aqui estão algumas coisas que aprendi com esses líderes, lições que não são profundas, mas que muitas vezes se perdem no ruído de lidar com desafios complexos.

Mais alinhamento significa mais autonomia

A palavra autonomia é frequentemente mal interpretada como significando que os líderes se afastam e deixam as equipes tomarem decisões. Há um vestígio de verdade aqui, mas os líderes precisam ser claros sobre as decisões de porta que abre para um lado que somente eles podem tomar e que têm profundas implicações para suas organizações. Todas as outras decisões são transferidas para pessoas mais próximas da ação do dia-a-dia, que podem tomar decisões de menor risco rapidamente e, em seguida, mudar de direção ou continuar dependendo do resultado. Aqui, os líderes se tornam os embaixadores e propagadores da visão e dos resultados de negócio desejados, os guardiões da cultura que unifica uma organização e os destruidores de silos. Meu colega Mark Schwartz escreveu sobre um desses exemplos essenciais para CTOs — centralizar plataformas para permitir mais autonomia — em seu blog post.

Mais princípios, mais velocidade, menos silos

Uma parte fundamental do paradoxo do alinhamento-autonomia reconhece a tendência frequente para satisfazer quando se trata de software: tentar manter todos em sua organização satisfeitos adotando um pouco de todas as suas listas de desejos. O CFO quer que o software seja construído com o mínimo custo; o COO quer que ele seja não disruptivo para a operação da empresa; e o CMO quer uma infinidade de funcionalidades para atrair a todos os grupos de clientes. É um desejo muito humano evitar alienar colegas de trabalho, mas satisfazer todos cria soluções que não satisfazem ninguém.

Uma lição que aprendi nos últimos anos na AWS é o poder dos tenets, ou princípios. São declarações simples que formam a base de qualquer iniciativa ou business case sobre o qual decisões serão tomadas. Eles explicitam para todos como as decisões serão tomadas. Eles formam uma linguagem comum a que todos os participantes podem se referir ao tomar decisões e são a base para uma tomada de decisão mais rápida e alinhada.

Um exemplo de princípio é “Nós construímos para nos diferenciarmos”. Uma descrição pode ser: “Cada linha de código é uma responsabilidade futura. Por isso, optamos por comprar e implementar a versão não modificada de aplicações que não são diferencias, alterando primeiro os processos de negócios. Somos claros sobre o que realmente diferencia nossa empresa, assumindo o controle de nosso destino nessas áreas. Mesmo aqui, usamos padrões e tecnologias que maximizam o trabalho não realizado.”

Esse princípio ajuda todos em toda posição a entender quais trade-offs estão sendo feitos (construir versus comprar) e por quê. Ele evita a necessidade, que mata a agilidade, de rediscutir cada decisão, estabelecendo princípios compartilhados por todos e tornando a tecnologia e as decisões tecnológicas mais inclusivas.

Mais progresso, menos perfeição

Não é uma frase original, mas “progresso acima da perfeição” serviu-nos bem nos primeiros dias da transformação digital do McDonald’s. Anteriormente, analisávamos e planejávamos todas as contingências possíveis para cada projeto. As iniciativas levavam anos. Até mesmo a decisão de empreender uma iniciativa podia levar uma década ou mais em alguns casos! E quando finalmente colocávamos essas iniciativas em restaurantes, sempre perdemos algo em nosso exaustivo planejamento.

Dedicar tempo ao que os clientes queriam (por exemplo, um aplicativo móvel, entrega em domicílio e uma experiência moderna em um restaurante) e nos princípios subjacentes permitiu que as equipes se concentrassem nos resultados, não em requisitos detalhados. Uma visão fundamentada centrada no cliente ajuda uma organização a eliminar sua própria burocracia e colocar novas ideias nas mãos dos clientes de forma rápida e econômica, permitindo progresso, inovação e diferenciação em mercados competitivos.

Menos abstração, mais opções

Vejo poucas escolhas reais de abstração que criam mais valor do que destroem. Talvez correndo o risco de revelar minha idade, lembro-me da promessa do ODBC (acrônimo em inglês para Conectividade Aberta de Banco de Dados) de abstrair o código do banco de dados subjacente. Parecia ótimo até que você quisesse usar um recurso nativo do banco de dados ou ajustar o desempenho. É semelhante com a nuvem. Ocultar serviços nativos da nuvem dos desenvolvedores por meio de camadas de abstração ou meios similares, restringe as opções que você tem para usar serviços poderosos e em evolução. Eu preferiria ver o tempo gasto entregando valor através de serverless em vez de tentar aumentar os clusters do Kubernetes. A abstração é frequentemente usada como desculpa para evitar a definição de uma estratégia clara, que introduz complexidade e trabalho pesado que distrai da construção de funcionalidades alinhadas ao negócio. Gregor Hohpe escreveu um ótimo artigo sobre uma consequência aqui.

Mais valor, menos tempo

O papel do CTO moderno não se trata de controle, mas de resultados e capacitação. Os CTOs modernos não tentam projetar todos os aspectos da casa comum, impedindo que os construtores construam porque não existe um padrão para um problema recém-descoberto. Em vez disso, eles concentram-se na implementação de arquiteturas, padrões e ferramentas pragmáticas que permitem que os construtores — tecnólogos, não tecnólogos e parceiros — entreguem mais valor com mais rapidez. Padrões e ferramentas podem assumir a forma de APIs que permitem às equipes desenvolver e lançar novas funcionalidades de forma rápida e independente, pipelines de CI/CD que não exigem que cada equipe invente sua própria metodologia de implantação, ou infraestrutura e automação de autosserviço que permitem às equipes criar e desligar suas próprias instâncias do Amazon EC2 com rapidez e segurança. O CTO moderno é um praticante lean, maximizando o trabalho que outros não precisam fazer, concentrando-se em áreas que eliminam o desperdício de tempo e dinheiro. Ao fazer isso, eles contribuem diretamente para reduzir o custo de experimentação e escalabilidade dentro de uma organização.

O papel do CTO está envolto em complexidade, um reflexo das exigências que lhe são feitas e do ritmo de mudança das expectativas e das tecnologias. Essa também é uma das razões pelas quais os CTOs modernos gravitam em torno da nuvem, eliminando de seus pratos uma série de trade-offs tradicionais pré-nuvem, como custo versus confiabilidade, segurança ou alcance geográfico. Agora, os CTOs podem ser como DJs, ajustando os controles deslizantes de suas mesas de mixagem metafóricas para garantir que a tecnologia atenda às demandas dos negócios e dos clientes, em vez de fazer rígidos trade-offs binários.

Ainda não é um trabalho fácil, mas é um que pode analisar mais profundamente as vantagens e desvantagens associadas a pessoas e pessoal, estruturas organizacionais para previsibilidade, eficiência e agilidade, o equilíbrio certo entre autonomia para velocidade e grades de proteção/tomada de decisão centralizada para controle, decisões de seleção de tecnologia e quanta inovação é democratizada. Estou ansioso para compartilhar este ano perspectivas mais aprofundadas sobre esses problemas com meus colegas da equipe de Arquitetura de Soluções.

Phil