Reduzir gestores não acelera, por si só, o desenvolvimento de software. O que pode encurtar o caminho entre uma ideia e um produto é remover aprovações redundantes, diminuir dependências entre equipes e dar às pessoas que constroem o produto autonomia para decidir. É essa diferença que importa ao avaliar os planos atribuídos a John Ternus para a Apple.
Segundo o Observador.pt, que cita informações da Bloomberg, o novo CEO quer tornar a empresa mais eficiente, reforçar o foco em engenharia, reduzir alguns cargos de gestão intermédia, controlar custos e rever o calendário de lançamentos. São objetivos coerentes com problemas conhecidos em organizações grandes, mas ainda são intenções reportadas — não resultados comprovados. A execução é que dirá se haverá mais velocidade ou apenas uma hierarquia diferente.
Menos gestores na Apple: o que isso pode mudar para as equipes de engenharia
Em uma empresa com muitos produtos, equipes e dependências, uma decisão simples pode atravessar vários níveis: uma equipe propõe uma mudança, outra avalia a compatibilidade, uma liderança prioriza, uma área de negócio aprova e, por fim, alguém define quando o trabalho pode ser lançado. Cada etapa pode ter uma justificativa legítima. O problema surge quando ninguém consegue explicar que risco concreto uma aprovação adicional está controlando.
Reduzir níveis hierárquicos pode encurtar esse percurso. Mas há uma armadilha: gestores também coordenam trabalho, resolvem conflitos de prioridade e protegem equipes de interrupções. Se a empresa elimina essas funções sem redistribuí-las, os mesmos problemas não desaparecem. Apenas passam a consumir o tempo de engenheiros e líderes técnicos.
Por isso, eu não avaliaria uma reorganização pelo número de cargos removidos. Olharia para indicadores operacionais: tempo entre a primeira alteração e a entrega, tamanho das filas de revisão, frequência de trabalho bloqueado por dependências e proporção de lançamentos que precisam de correções urgentes. Se esses números melhorarem sem aumentar defeitos e sobrecarga, a estrutura provavelmente está ajudando.
Gestão intermédia não é sinônimo de burocracia
Uma camada de gestão pode ser burocrática quando repassa informações sem tomar decisões, exige aprovações duplicadas ou cria metas incompatíveis entre equipes. Também pode ser essencial quando coordena áreas com prioridades concorrentes, cuida do desenvolvimento profissional e mantém uma visão de conjunto que uma equipe isolada não tem.
Em software, não basta dizer “vamos dar autonomia”. Uma equipe precisa conhecer os limites da decisão: quais interfaces pode alterar, que requisitos de privacidade deve cumprir, que orçamento tem e quem responde por incidentes. Sem essas fronteiras, autonomia vira conflito ou cada grupo cria uma solução incompatível com o restante da plataforma.
Foco em engenharia pode reduzir o tempo de lançamento?
O relato atribuído à Bloomberg associa maior foco em engenharia a um ciclo de desenvolvimento mais curto. A hipótese faz sentido quando o atraso está em decisões técnicas, integração ou dependências entre times. Não resolve, porém, problemas de pesquisa de produto, validação de mercado, certificação, fabricação ou disponibilidade de componentes. Cada gargalo pede uma intervenção diferente.
É fácil confundir velocidade com mais código produzido. Linhas de código, quantidade de tarefas fechadas e horas trabalhadas são métricas fracas: incentivam atividade visível, não necessariamente entrega de valor. Uma equipe pode fechar muitos tickets enquanto acumula mudanças esperando revisão, testes ou aprovação de lançamento.
Eu começaria acompanhando o fluxo completo. Quanto tempo uma mudança espera por revisão? Quantas vezes volta por falhas? Quanto trabalho fica bloqueado por uma API de outra equipe? Essas perguntas ajudam a distinguir falta de capacidade de engenharia de um processo com filas e dependências excessivas.
Métricas úteis sem transformar desenvolvimento em competição
Indicadores como tempo de ciclo, frequência de implantação, taxa de falha em mudanças e tempo para recuperar um serviço ajudam a discutir desempenho operacional. Não devem ser usados para comparar pessoas ou classificar equipes sem contexto. Uma equipe que mantém um componente crítico e estável pode ter um ritmo de deploy diferente de outra que trabalha em uma aplicação independente.
Também é importante medir qualidade e sustentabilidade junto com velocidade. Se o tempo de entrega cai, mas aumentam incidentes, retrabalho ou horas extras, a organização não ficou mais eficiente. Apenas transferiu o custo para depois do lançamento — ou para a saúde das equipes.
Uma mudança no calendário de lançamentos exige engenharia de release
O Observador.pt também menciona a possibilidade de alterar o calendário de lançamentos, que tradicionalmente inclui apresentações na primavera e um evento de setembro associado a novos iPhones. Mudar datas pode ajudar a distribuir o trabalho e reduzir picos de pressão, mas calendário não é apenas marketing. Ele afeta planejamento de capacidade, integração de sistemas, testes, documentação, suporte e coordenação com parceiros.
Um lançamento concentrado cria uma data comum e pode simplificar a comunicação. Em contrapartida, concentra risco: um componente atrasado pode pressionar várias equipes ao mesmo tempo. Lançamentos mais distribuídos podem reduzir esse pico, mas aumentam o número de ciclos de preparação e exigem processos de atualização, monitoramento e suporte mais consistentes.
Na prática, equipes de software usam técnicas como feature flags, implantação gradual e releases independentes para separar a entrega técnica da ativação pública de uma funcionalidade. Isso reduz o risco de colocar uma mudança disponível para todos de uma só vez. Não elimina a necessidade de testes; muda a forma de controlar a exposição.
Na Prática: como medir se uma equipe realmente ficou mais rápida
Se eu estivesse avaliando uma reorganização de engenharia, começaria com uma área pequena e um período de referência. Antes de mexer na estrutura, registraria o tempo de ciclo e os bloqueios. Depois, faria uma alteração delimitada — por exemplo, remover uma aprovação redundante para mudanças de baixo risco — e observaria o efeito por algumas semanas.
- Defina o fluxo: escolha um tipo de mudança comparável, como correções de baixa criticidade. Não misture uma alteração de texto com uma migração complexa de dados.
- Registre o tempo: meça os dias entre o início efetivo do trabalho e a entrega. Separe tempo de execução de tempo parado à espera de revisão ou dependências.
- Acompanhe a qualidade: conte reversões, defeitos relevantes e correções urgentes depois da entrega.
- Identifique bloqueios: anote se a espera veio de aprovação, revisão, ambiente de testes, decisão de produto ou dependência externa.
- Compare com cautela: avalie tendências em várias semanas. Uma entrega excepcionalmente rápida não prova que a mudança organizacional funcionou.
Uma análise simples pode calcular a mediana e o percentil 85 do tempo de ciclo. A mediana mostra o caso central; o percentil 85 ajuda a enxergar mudanças que ficam presas por mais tempo. O exemplo abaixo recebe os tempos em dias. Em produção, eu separaria os dados por tipo de trabalho e equipe, para evitar comparações enganosas.
from statistics import median
from math import ceil
def resumir_tempo_ciclo(dias):
if not dias:
raise ValueError("Informe ao menos um tempo de ciclo.")
if any(valor < 0 for valor in dias):
raise ValueError("Os tempos não podem ser negativos.")
ordenados = sorted(dias)
indice_p85 = ceil(0.85 * len(ordenados)) - 1
return {
"mediana_dias": median(ordenados),
"percentil_85_dias": ordenados[indice_p85],
"amostras": len(ordenados),
}
tempos = [2, 3, 3, 4, 5, 8, 13]
print(resumir_tempo_ciclo(tempos))Esse cálculo não prova que uma reorganização causou a mudança. Ele fornece um sinal para investigar. Se o percentil 85 cair, mas as falhas aumentarem, a equipe pode estar entregando mais rápido à custa de testes ou revisão. Se o tempo total continuar alto e a espera por aprovação cair, talvez o gargalo esteja em dependências técnicas, e não na hierarquia.
Erros Comuns ao tentar acelerar o desenvolvimento
- Cortar gestores antes de mapear decisões: primeiro identifique quem aprova, por que aprova e qual risco está sendo controlado. Remover nomes do organograma sem redesenhar responsabilidades cria lacunas.
- Tratar todo atraso como falta de engenheiros: contratar mais pessoas não resolve automaticamente filas de revisão ou arquitetura acoplada. Em sistemas interdependentes, mais equipes podem até aumentar o custo de coordenação.
- Medir velocidade por volume de tarefas: tickets menores ou mal definidos podem fazer o indicador parecer melhor sem encurtar o tempo até o usuário receber uma melhoria.
- Ignorar dívida técnica: uma entrega apressada pode aumentar o custo de cada mudança seguinte. O ganho imediato desaparece quando manutenção e correções passam a consumir a capacidade da equipe.
- Impor autonomia sem limites claros: equipes precisam saber quais decisões são locais e quais afetam segurança, privacidade, compatibilidade ou contratos entre serviços.
- Confundir calendário frequente com entrega contínua: lançar mais vezes não significa lançar melhor. Sem automação, observabilidade e possibilidade de reversão, cada lançamento pode ampliar o risco operacional.
O que a estratégia pode significar para desenvolvedores
Para quem programa, uma estrutura mais enxuta só será perceptível se reduzir espera e interrupções. Menos reuniões não ajudam quando as decisões continuam sem dono. Mais foco em engenharia também não ajuda se a equipe recebe prazos rígidos sem espaço para testes, manutenção e revisão de arquitetura.
Ao avaliar uma mudança semelhante na própria empresa, eu perguntaria: quem decide prioridades quando duas equipes disputam capacidade? Quem responde por uma interface compartilhada? Qual é o caminho para lançar uma correção urgente? E como a organização detecta que uma mudança piorou a confiabilidade? Respostas concretas valem mais do que um organograma simplificado.
No caso da Apple, os planos descritos ainda devem ser lidos com cautela. Segundo o Observador.pt, Ternus assumiu o cargo em 1 de setembro, sucedendo Tim Cook, que liderou a empresa por mais de 15 anos, depois de ter sido nomeado em abril e de trabalhar durante anos na área de engenharia. O contexto torna plausível uma atenção maior ao desenvolvimento de produtos, mas não permite concluir que haverá uma transformação bem-sucedida.
FAQ: mudanças na gestão da Apple e desenvolvimento de software
Menos gestores tornam uma empresa de tecnologia mais rápida?
Não necessariamente. A redução pode eliminar aprovações redundantes, mas também pode criar problemas de coordenação se responsabilidades e autoridade não forem redistribuídas. O resultado depende de onde estavam os gargalos.
Qual métrica mostra se uma equipe de desenvolvimento ficou mais eficiente?
O tempo de ciclo, combinado com frequência de entrega, falhas e tempo de recuperação, oferece uma visão melhor do que contar tarefas ou linhas de código. A métrica precisa ser analisada com contexto e não usada para ranquear indivíduos.
Um calendário de lançamentos mais distribuído reduz o risco?
Pode reduzir a concentração de trabalho e pressão em uma única data. Ao mesmo tempo, exige processos sólidos de testes, implantação, monitoramento e suporte para manter vários ciclos de lançamento com qualidade.
Como um desenvolvedor pode aplicar essa ideia em uma equipe pequena?
Mapeie as etapas entre começar uma mudança e entregá-la, registre onde ela fica bloqueada e teste a remoção de uma espera específica. Acompanhe qualidade e tempo de ciclo antes e depois, sem assumir que toda demora é burocracia.
Minha leitura é que o ponto decisivo não será quantos cargos a Apple elimina, mas se consegue reduzir dependências sem perder responsabilidade técnica. Em engenharia, eficiência sustentável vem de decisões claras, fluxo visível e qualidade incorporada ao processo — não de simplesmente pedir que as equipes trabalhem mais depressa.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.