Nesta entrevista conversamos com Ishu Anand Jaiswalum líder sênior de engenharia cujo trabalho moldou sistemas de grande escala voltados para o cliente na Apple, incluindo plataformas globais usadas por milhões de pessoas. Com base em mais de 18 anos de experiência, Ishu reflete sobre a mudança da construção de componentes para a propriedade de sistemas completos com impacto real nos negócios. A conversa explora o que quebra em escala, como a confiança e a confiabilidade orientam decisões de alto risco e por que a IA exige um julgamento humano mais forte, e não mais frouxo.

Explore mais entrevistas aqui: Omri Kohl, CEO e cofundador da Pyramid Analytics — Impacto da IA ​​na análise de dados, inteligência de decisão, analistas cidadãos, ROI, escalonamento de IA e tendências emergentes

Ao longo de seus mais de 18 anos de carreira, qual foi o ponto em que sua função passou de construir componentes individuais para ser responsável por sistemas completos com impacto real nos negócios e nos usuários?

Da construção de software à obtenção de resultados

No início da minha carreira, eu acreditava que escrever software correto era a principal responsabilidade de um engenheiro. Se o sistema funcionasse nos testes e atendesse aos requisitos, eu me sentiria confiante para seguir em frente. Essa crença mudou na primeira vez que vi uma pequena decisão técnica surgir como um problema real para pessoas distantes da minha equipe imediata, em regiões e fusos horários, num momento em que não havia chance de revertê-la silenciosamente. Ver isso acontecer deixou claro que a escala transforma escolhas técnicas em consequências duradouras. Essa constatação moldou a forma como penso sobre sistemas e responsabilidade desde então.

Nos primeiros anos da minha carreira, grande parte do meu trabalho centrou-se na construção de componentes fortes. Concentrei-me na correção, nas interfaces limpas e em garantir que as peças individuais se comportassem conforme o esperado. Essa abordagem funcionou quando minha responsabilidade parou no limite de um módulo.

A verdadeira mudança ocorreu em 2014–2015, quando assumi a função de líder de tecnologia e arquiteto da Apple Sales Web. Pela primeira vez, fui responsável pelo sistema como um todo, incluindo decisões de design, confiabilidade durante lançamentos, controles de segurança, preparação para lançamento e coordenação entre equipes com diferentes prioridades e restrições.

Essa responsabilidade mudou a forma como tomei decisões. Parei de perguntar se uma mudança era tecnicamente sólida isoladamente e comecei a perguntar como ela se comportaria globalmente. A integridade do sistema, os modos de falha e os resultados dos negócios tornaram-se as verdadeiras medidas de sucesso.

Você liderou plataformas usadas por milhões de pessoas em organizações globais. Você consegue analisar um sistema de sua propriedade de ponta a ponta, incluindo sua escala, uso, principais riscos e resultados?

Construindo sistemas que os clientes realmente veem

Essa mudança de responsabilidade tornou-se mais visível no meu trabalho no Smart Sign, a plataforma de sinalização digital para lojas da Apple. O sistema foi lançado como parte da iniciativa do décimo aniversário da Apple Store e foi projetado para modernizar a experiência de varejo em todo o mundo.

Liderei o Smart Sign de ponta a ponta, controlando o design da plataforma, o modelo de entrega de conteúdo, a estratégia de implementação e as expectativas de confiabilidade. Este era um sistema voltado para o cliente onde as falhas eram imediatamente visíveis.

O Smart Sign foi implementado globalmente em cerca de 25.000 endpoints de demonstração e entregou conteúdo para cerca de 20 milhões de dispositivos de demonstração. Conteúdo atualizado com frequência, quase em tempo real, com meta de disponibilidade interna de 99,999%. O tráfego atingiu um pico acentuado durante os principais lançamentos de produtos.

Com o tempo, o Smart Sign tornou-se uma parte essencial da forma como as lojas da Apple se mantiveram atuais e consistentes em todo o mundo.

Ao trabalhar nesse sistema, quais foram as concessões mais difíceis que você teve que fazer sob pressão e o que orientou essas decisões?

Escolhendo confiança em vez de velocidade

Com essa visibilidade veio uma pressão constante. Os lançamentos de produtos tinham datas fixas e a expectativa de agilidade sempre esteve presente.

Eu tinha a responsabilidade final de decidir se as atualizações seriam enviadas ou retidas. A velocidade por si só nunca foi o fator decisivo. Conteúdo incorreto ou comportamento instável teriam um impacto imediato em milhares de lojas.

Os sinais que orientaram minhas decisões foram risco de erro, raio de explosão e confiança do cliente. Se uma mudança aumentasse a incerteza, ela não seria concretizada, mesmo sob pressão de cronograma.

Essa disciplina evitou falhas de alta visibilidade durante momentos críticos.

Você trabalhou em plataformas globais de varejo e educação. Que padrões você viu se repetirem à medida que os sistemas foram sendo dimensionados e onde as suposições iniciais falharam?

O que quebra quando os sistemas crescem

O que trabalhar no varejo global e na educação me ensinou é que as suposições tendem a quebrar rapidamente quando você escala.

O tráfego não cresce suavemente. Os picos de uso são mais acentuados do que o esperado. A atualização do conteúdo é mais importante do que o previsto. A complexidade operacional cresce mais rápido que os recursos.

A minha responsabilidade era reconhecer onde os projetos estavam a começar a falhar e ajustar-me precocemente, muitas vezes investindo na resiliência antes que o crescimento forçasse o problema.

Você fez contribuições técnicas originais, incluindo designs patenteados. Que problema desencadeou esse trabalho e o que mudou como resultado?

Quando as soluções existentes param de funcionar

Encontrei falhas repetidas em sistemas de cache baseados em regras sob tráfego intermitente, especialmente durante demanda sincronizada globalmente.

Em vez de continuar ajustando as regras, projetei uma abordagem de cache adaptativo orientada por sinais de demanda real. O objetivo era a estabilidade em condições reais de produção.

Este trabalho abordou falhas observadas em escala e resultou em um depósito de patente. Na prática, reduziu as perdas de cache durante picos de tráfego e melhorou o comportamento do sistema.

A IA agora faz parte de muitos sistemas de produção. Você pode descrever um caso em que a IA mudou o comportamento de um sistema em escala?

Apresentando IA sem perder o controle

À medida que a IA se tornou parte dos sistemas de produção, percebi como o comportamento poderia mudar rapidamente em grande escala.

A IA melhorou a adaptabilidade e a eficiência, mas também introduziu novos riscos se não for controlada. Tratei a IA como um componente controlado, impondo barreiras de proteção, monitoramento e limites claros.

O resultado foi uma melhoria mensurável sem perda de controle.

Privacidade e confiança são frequentemente discutidas em alto nível. Que escolhas concretas de design ou governança você aplicou pessoalmente?

Tornando a confiança uma restrição de design

Tratei a confiança como um requisito de design de primeira ordem. Impulsionei limites de acesso, limitei a exposição de dados e exigi propriedade explícita para fluxos confidenciais.

Esses controles foram incorporados diretamente no projeto do sistema e aplicados a plataformas que atendem milhões de usuários e grandes volumes financeiros.

A confiança foi imposta por design, não por política.

À medida que suas equipes se tornaram mais distribuídas e seniores, quais práticas de liderança pararam de funcionar e quais as substituíram?

Liderando sem Microgerenciar

À medida que as equipes se tornaram mais distribuídas e seniores, as práticas que funcionavam em menor escala pararam de funcionar. A supervisão estreita e a coordenação informal tornaram-se rapidamente fontes de atrito em vez de clareza.

Fui responsável por manter a entrega previsível sem atrasar as equipes. A solução não foi mais controlo, mas sim uma propriedade mais clara. Afastei-me da coordenação ad hoc em direção a responsabilidades explícitas, interfaces bem definidas e padrões operacionais compartilhados nos quais as equipes pudessem confiar de forma independente.

Isso se tornou ainda mais importante em minha recente função de liderança na Intuit, onde as equipes eram altamente distribuídas e operavam em ambientes de produtos complexos influenciados por IA. Nesse cenário, a previsibilidade vinha de expectativas compartilhadas e da clareza de decisão, e não da proximidade ou da sincronização constante.

Ao substituir o microgerenciamento por propriedade e padrões, as equipes conseguiram avançar mais rapidamente sem perder a responsabilidade. A entrega tornou-se mais estável e os caminhos de escalada tornaram-se a exceção e não a norma.

Além das funções de sua empresa, você atua como juiz e revisor. Como isso influenciou seus próprios padrões?

Aprendendo com a avaliação do trabalho dos outros

Servir como juiz e revisor me expôs a uma ampla gama de abordagens técnicas.

A revisão de mais de 100 artigos aprimorou meus padrões e me deixou menos persuadido por soluções que falharam sob restrições realistas.

Essa perspectiva influencia diretamente a forma como eu projeto sistemas.

Você recebeu reconhecimento externo pelo seu trabalho. O que foi reconhecido e por que isso importava além da realização pessoal?

Por que o reconhecimento externo é importante

O reconhecimento que recebi estava vinculado a um trabalho específico, não a uma função ou mandato. Revisores independentes avaliaram os sistemas que liderei e as abordagens técnicas que introduzi com base em evidências de escala, originalidade e impacto no mundo real.

O que importava era como essa avaliação era feita. Os revisores eram externos à minha organização e avaliaram o trabalho sem contexto interno ou suposições. Os sistemas e decisões tinham que ser independentes, através de resultados documentados, rigor técnico e comportamento em condições operacionais reais.

Esse tipo de revisão é incomum na engenharia, onde o sucesso é frequentemente julgado internamente e em relação às restrições locais. Neste caso, o trabalho não teria sido reconhecido se não atendesse aos padrões externos de impacto e ao bom julgamento de engenharia.

Para mim, o valor desse reconhecimento foi a validação. Confirmou que os sistemas que construí e as decisões que tomei eram defensáveis ​​para além de uma única empresa ou equipa e que resistiriam a um exame minucioso independente. Esse padrão continua a orientar a forma como abordo a liderança técnica.

Muitos líderes falam sobre influência, mas o impacto é mais difícil de provar. Qual é um exemplo em que seu trabalho continuou a moldar sistemas depois que você se afastou da propriedade direta

Impacto que vai além da propriedade

Para mim, uma das medidas de impacto mais claras é se os sistemas continuam a funcionar de forma previsível após mudanças diretas de propriedade.

Nas plataformas que liderei, incluindo Apple Sales Web, Smart Sign e Apple Teacher, concentrei-me em estabelecer limites arquitetônicos, padrões operacionais e modelos de propriedade claros que não dependessem de tomadores de decisão individuais. Minha responsabilidade não era apenas entregar o sistema, mas garantir que ele pudesse ser sustentado por equipes das quais nem sempre faria parte.

Depois que me afastei da propriedade cotidiana, esses sistemas continuaram a atender grandes bases de usuários globais, a lidar com picos de demanda de maneira confiável e a operar dentro das mesmas expectativas de governança e confiabilidade. As equipes que os herdaram não exigiam contexto especial ou escalonamento contínuo para mantê-los funcionando.

Essa continuidade é a prova mais forte de que o trabalho teve um impacto duradouro. Mostra que os sistemas e padrões foram concebidos para sobreviver a qualquer líder e permanecer eficazes à medida que as organizações e as equipas evoluíram.

Olhando para o futuro, de quais recursos os líderes seniores de engenharia precisarão à medida que a IA se tornar parte das decisões técnicas e de negócios diárias?

O que a próxima geração de líderes precisará

À medida que a IA se torna rotina, o julgamento torna-se mais importante, e não menos. O risco real não é que os sistemas de IA falhem silenciosamente, mas sim que falhem em grande escala de uma forma que torna a responsabilidade pouco clara.

Tenho visto que os problemas mais difíceis não são mais sobre se um sistema pode gerar decisões, mas sobre quem é o dono do resultado quando essas decisões afetam milhões de usuários. A IA acelera resultados, mas também acelera erros.

O papel de um líder sênior de engenharia é definir limites que a IA não pode ultrapassar, impor responsabilidade quando os sistemas se comportam de forma inesperada e garantir que o julgamento humano permaneça firmemente sob controle. Ferramentas podem recomendar. Os modelos podem prever. A responsabilidade ainda pertence às pessoas.

Esta perspectiva foi reforçada no meu trabalho recente na Intuit, onde a IA faz cada vez mais parte das decisões quotidianas de engenharia e de produtos, e onde a clareza de propriedade é tão importante como a capacidade técnica.

Recentemente resumi esses princípios operacionais em um artigo público sobre AI Frontier Networkonde descrevi como a IA deveria ser gerenciada como um acelerador do julgamento da engenharia, e não como um substituto para ele.

Os líderes que permanecerem eficazes não serão os que adotarem a IA mais rapidamente, mas sim os que permanecerem claramente responsáveis ​​pelo seu comportamento.

Reconhecimento Selecionado:

Os prêmios internacionais e o reconhecimento por pares foram avaliados por painéis independentes por contribuições técnicas originais, impacto no sistema em grande escala e liderança em IA aplicada, juntamente com o reconhecimento de melhor revisor por pares em uma conferência internacional sobre IA e segurança.