Negociação Rápida 🔥 com Opeyemi Folorunsho

Opeyemi Folorunsho é o Vice-Presidente de Investigação e Desenvolvimento (I&D) na Moniepoint, onde se foca em traduzir ideias técnicas profundas em sistemas que geram impacto no mundo real. A sua experiência reside em sistemas distribuídos e infraestrutura, e o seu trabalho situa-se na intersecção entre a investigação e a execução: identificar oportunidades emergentes, validá-las rigorosamente e construir as plataformas que as tornam realidade.

A sua crença fundamental é que uma excelente cultura de engenharia e o pensamento baseado em primeiros princípios são o que separa a inovação real da procura de tendências. Com o tempo, o seu foco evoluiu da construção de sistemas para definir a sua direção, orientar equipas, estabelecer a visão técnica e garantir que os esforços de investigação se traduzem em resultados significativos.

• Explique o seu trabalho a uma criança de cinco anos.

Imagine que tem uma cidade de brinquedos enorme onde milhões de pessoas brincam todos os dias. O meu trabalho é inventar estradas melhores, pontes mais resistentes e semáforos mais inteligentes antes que a cidade fique demasiado congestionada.

Por vezes, construo coisas novas eu próprio. Por vezes, ajudo outros engenheiros a construí-las. E por vezes, passo semanas a descobrir uma maneira melhor de resolver um problema que ninguém resolveu antes. O meu trabalho é, essencialmente, garantir que a cidade continua a funcionar mesmo quando chegam mais milhões de pessoas.

• Como é realmente o dia a dia do I&D numa fintech?

As pessoas imaginam frequentemente o I&D como cientistas num laboratório. Na realidade, está muito mais próximo da engenharia aplicada.

Uma semana típica envolve compreender um problema de negócio difícil, ler artigos ou documentação técnica, avaliar tecnologias existentes, construir protótipos, medir compensações e decidir se uma ideia merece tornar-se parte da plataforma de produção.

Alguns projetos nunca saem da fase de protótipo porque a viabilidade económica não funciona. Outros acabam por se tornar infraestrutura central da qual todas as equipas de engenharia dependem.

Na Moniepoint, isso tem significado explorar tecnologias como bases de dados distribuídas, processamento de fluxos, plataformas para developers, técnicas de deteção de fraude, automação de infraestrutura e formas de simplificar a maneira como os engenheiros constroem produtos à escala.

O objetivo não é a investigação pela investigação. É reduzir a incerteza para que o negócio possa tomar melhores decisões de engenharia.

• Como decide quando uma ideia está pronta para se tornar um produto?

Procuro três coisas. Primeiro, resolvemos realmente os problemas técnicos difíceis ou apenas construímos uma boa demonstração? Segundo, a solução reduz a complexidade em vez de a adicionar? Um protótipo pode tolerar artifícios. Um sistema de produção não pode. Terceiro, resolve um problema real que várias equipas têm? Se apenas um engenheiro o compreende ou apenas uma equipa beneficia dele, provavelmente ainda é investigação.

A transição ocorre quando as incógnitas se tornam conhecidas. Nesse ponto, o trabalho muda de descobrir se algo é possível para torná-lo fiável, mantível e fácil de usar por outros engenheiros.

• A Moniepoint cresceu agressivamente em toda a África. O que exige esse tipo de crescimento do ponto de vista da infraestrutura?

O crescimento muda as perguntas que faz. No início, pergunta: “Conseguimos fazer isto funcionar?” Mais tarde, pergunta: “Isto consegue suportar dez vezes mais tráfego sem acordar alguém às 3 da manhã?”

Na Moniepoint, operar à escala significa desenhar sistemas que possam lidar com milhares de milhões de eventos financeiros, manter baixa latência, recuperar graciosamente de falhas e continuar a operar em diferentes regiões e condições de rede variáveis.

Significa também investir fortemente em plataformas internas. À medida que uma organização de engenharia cresce, a produtividade dos developers torna-se também um problema de infraestrutura. Boas ferramentas, automação, observabilidade, sistemas de implementação e plataformas padronizadas permitem que centenas de engenheiros avancem rapidamente sem comprometer a fiabilidade. A infraestrutura já não está apenas a suportar o negócio. Torna-se uma vantagem competitiva.

• Qual é o maior equívoco que os engenheiros têm sobre o que constitui uma boa investigação?

Muitos engenheiros pensam que a investigação consiste em ler artigos. Não é. Uma boa investigação consiste em reduzir a incerteza.

Por vezes, isso significa ler artigos académicos. Mais frequentemente, significa construir protótipos, recolher evidências, medir o desempenho, falar com utilizadores e estar disposto a provar que a sua própria ideia está errada.

O melhor resultado no I&D não é provar que está certo. É aprender algo valioso antes de a empresa gastar meses a construir a coisa errada. A investigação deve facilitar a engenharia futura, não complicá-la.

• Como foi o seu caminho até VP de I&D e o que faria de diferente se começasse de novo?

A minha carreira sempre foi mais impulsionada pela curiosidade do que por títulos. Naturalmente, gravitei para problemas de infraestrutura difíceis, sistemas distribuídos, bases de dados, plataformas para developers e o tipo de trabalho de engenharia onde compreender o funcionamento interno faz uma diferença real. Com o tempo, isso evoluiu de resolver problemas técnicos eu próprio para ajudar as equipas a identificar quais os problemas que valiam a pena resolver em primeiro lugar.

Ao assumir funções de liderança, percebi que o I&D não é apenas sobre tecnologia. É sobre criar um processo que transforma a incerteza em decisões informadas. Hoje, uma grande parte do meu papel é ajudar a organização a explorar novas ideias, garantindo simultaneamente que as bem-sucedidas podem ser entregues às equipas de produto e escaladas em todo o negócio.

Se começasse de novo, passaria menos tempo a perseguir tecnologias individuais e mais tempo a aprender pensamento sistémico, comunicação e economia. Linguagens, frameworks e bases de dados vão e vêm. A capacidade de raciocinar sobre sistemas complexos, comunicar claramente e compreender o valor de negócio por trás das decisões técnicas acumula-se ao longo de toda a carreira. Essas competências foram muito mais importantes do que qualquer tecnologia específica que tenha aprendido.