Szybkie pytania 🔥 z Opeyemi Folorunsho

Opeyemi Folorunsho jest wiceprezesem ds. badań i rozwoju (R&D) w Moniepoint, gdzie koncentruje się na przekuwaniu zaawansowanych koncepcji technicznych w systemy przynoszące realne korzyści. Jego specjalizacją są systemy rozproszone i infrastruktura, a jego praca znajduje się na styku badań i wdrażania: identyfikuje pojawiające się możliwości, rygorystycznie je weryfikuje oraz buduje platformy, które pozwalają im zaistnieć.

Jego kluczowym przekonaniem jest to, że doskonała kultura inżynierska i myślenie oparte na pierwszych zasadach odróżniają prawdziwe innowacje od podążania za trendami. Z czasem jego fokus ewoluował od budowania systemów do kształtowania ich kierunku, prowadzenia zespołów, wyznaczania wizji technicznej oraz dbania o to, by wysiłki badawcze przekładały się na znaczące rezultaty.

• Wyjaśnij swoją pracę pięciolatkowi.

Wyobraź sobie ogromne miasto-zabawkę, w którym codziennie bawią się miliony ludzi. Moim zadaniem jest wymyślanie lepszych dróg, mocniejszych mostów i sprytniejszych świateł drogowych, zanim miasto stanie się zbyt zatłoczone.

Czasami sam buduję nowe rzeczy. Czasami pomagam innym inżynierom je tworzyć. A czasami spędzam tygodnie na szukaniu lepszego sposobu rozwiązania problemu, którego nikt wcześniej nie rozwiązał. Moja praca polega przede wszystkim na zapewnieniu, że miasto działa dalej, nawet gdy przybywają kolejne miliony osób.

• Jak naprawdę wygląda codzienna praca działu R&D w firmie fintech?

Ludzie często wyobrażają sobie R&D jako naukowców w laboratorium. W rzeczywistości jest to znacznie bliższe inżynierii stosowanej.

Typowy tydzień obejmuje zrozumienie trudnego problemu biznesowego, czytanie artykułów lub dokumentacji technicznej, ocenę istniejących technologii, budowanie prototypów, mierzenie kompromisów oraz decydowanie, czy dany pomysł zasługuje na to, by stać się częścią platformy produkcyjnej.

Niektóre projekty nigdy nie wychodzą poza etap prototypu, ponieważ ich ekonomiczna zasadność nie jest wystarczająca. Inne stają się kluczową infrastrukturą, od której zależą wszystkie zespoły inżynieryjne.

W Moniepoint oznaczało to eksplorowanie technologii takich jak rozproszone bazy danych, przetwarzanie strumieniowe, platformy dla deweloperów, techniki wykrywania oszustw, automatyzacja infrastruktury oraz sposoby upraszczania procesu tworzenia produktów na dużą skalę przez inżynierów.

Celem nie są badania dla samych badań. Chodzi o redukcję niepewności, aby firma mogła podejmować lepsze decyzje inżynieryjne.

• Jak decydujesz, kiedy pomysł jest gotowy, by stać się produktem?

Szukam trzech rzeczy. Po pierwsze, czy faktycznie rozwiązaliśmy trudne problemy techniczne, czy tylko stworzyliśmy dobre demo? Po drugie, czy rozwiązanie redukuje złożoność, zamiast ją dodawać? Prototyp może tolerować spryt. System produkcyjny – nie. Po trzecie, czy rozwiązuje on realny problem, który dotyczy wielu zespołów? Jeśli rozumie go tylko jeden inżynier lub korzysta z niego tylko jeden zespół, prawdopodobnie jest to wciąż faza badawcza.

Przejście następuje, gdy niewiadome stają się wiadome. W tym momencie praca przesuwa się z odkrywania, czy coś jest możliwe, na uczynienie tego niezawodnym, łatwym w utrzymaniu i prostym w użyciu dla innych inżynierów.

• Moniepoint agresywnie skalowało działalność w Afryce. Czego taki wzrost wymaga od strony infrastrukturalnej?

Wzrost zmienia pytania, które zadajesz. Na początku pytasz: „Czy możemy sprawić, by to działało?”. Później pytasz: „Czy to przetrwa dziesięciokrotny ruch, nie budząc nikogo o 3 nad ranem?”.

Działanie na dużą skalę w Moniepoint oznacza projektowanie systemów, które mogą obsłużyć miliardy zdarzeń finansowych, utrzymywać niskie opóźnienia, elegancko recoverować po awariach i nadal działać w różnych regionach oraz przy zmiennych warunkach sieciowych.

Oznacza to również duże inwestycje w platformy wewnętrzne. Wraz ze wzrostem organizacji inżynieryjnej produktywność deweloperów staje się również problemem infrastrukturalnym. Dobre narzędzia, automatyzacja, obserwowalność, systemy wdrażania i standaryzowane platformy pozwalają setkom inżynierów działać szybko bez compromising niezawodności. Infrastruktura nie tylko wspiera już biznes. Staje się przewagą konkurencyjną.

• Jakie jest największe nieporozumienie inżynierów dotyczące tego, jak wyglądają dobre badania?

Wielu inżynierów myśli, że badania polegają na czytaniu artykułów. Nieprawda. Dobre badania polegają na redukcji niepewności.

Czasami oznacza to czytanie prac akademickich. Częściej jednak oznacza budowanie prototypów, zbieranie dowodów, mierzenie wydajności, rozmowy z użytkownikami i bycie gotowym na udowodnienie, że własny pomysł był błędny.

Najlepszym rezultatem w R&D nie jest udowodnienie, że masz rację. To nauczenie się czegoś cennego, zanim firma spędzi miesiące na budowaniu złej rzeczy. Badania powinny ułatwiać przyszłą pracę inżynieryjną, a nie ją komplikować.

• Jaka była Twoja droga do stanowiska VP ds. R&D i co zrobiłbyś inaczej, zaczynając od nowa?

Moja kariera zawsze była napędzana bardziej ciekawością niż tytułami. Naturalnie ciągnęło mnie do trudnych problemów infrastrukturalnych, systemów rozproszonych, baz danych, platform dla deweloperów i tego rodzaju pracy inżynieryjnej, gdzie zrozumienie wnętrza systemu ma realne znaczenie. Z czasem ewoluowało to od samodzielnego rozwiązywania problemów technicznych do pomagania zespołom w identyfikowaniu, które problemy w ogóle warto rozwiązywać.

Gdy przeszedłem do roli lidera, zdałem sobie sprawę, że R&D to nie tylko technologia. To tworzenie procesu, który zamienia niepewność w świadome decyzje. Obecnie duża część mojej roli polega na pomaganiu organizacji w eksplorowaniu nowych pomysłów, przy jednoczesnym zapewnieniu, że te udane mogą zostać przekazane zespołom produktowym i przeskalowane w ramach całego biznesu.

Gdybym zaczynał od nowa, spędzałbym mniej czasu na gonitwie za pojedynczymi technologiami, a więcej na naukę myślenia systemowego, komunikacji i ekonomii. Języki programowania, frameworki i bazy danych przychodzą i odchodzą. Umiejętność rozumowania o złożonych systemach, jasnej komunikacji i zrozumienia wartości biznesowej stojącej za decyzjami technicznymi procentuje przez całą karierę. Te umiejętności miały znacznie większe znaczenie niż jakakolwiek konkretna technologia, której się nauczyłem.