Jeremy Burton, administrerende direktør i Observe – Intervju-serie

Jeremy Burton, administrerende direktør i Observe, er en erfaren ledere i bedriftsprogramvare med over 20 års ledererfaring fra store teknologiselskaper som Dell Technologies (DELL ), EMC, Oracle (ORCL ) og VERITAS. Han har ledet globale team i produktutvikling, markedsføring og strategisk M&A, og bygget og skalert forretninger innen lagring, sikkerhet og SaaS. Burton var også med på å etablere Oracle Technology Network, som vokste til millioner av medlemmer verden over, og sitter for tiden i styret i Snowflake og som rådgiver for McLarens Formel 1-lag.

Observe, som har hovedkontor i San Mateo, California, er en ny generasjon SaaS-observabilitetsplattform som hjelper SRE, DevOps og ingeniørteam med å undersøke og optimalisere moderne distribuerte systemer. Bygget på Snowflakes data-infrastruktur, samler den inn logger, målinger og sporingsdata i en enkelt, kontekstrik datasett – og lar teamene akselerere hendelsesrespons, finne årsaker og forbedre påliteligheten i komplekse sky-miljøer.

Du har hatt ledende roller i globale gigantene som Dell, EMC og Oracle, og nå leder du en startup med Observe. Hva motiverte deg til å forlate stabilitet og skala for å ta spranget inn i å bygge noe fra bunnen av?

Jeg har vært heldig i min karriere å jobbe for noen fantastiske ledere, inkludert Larry Ellison og Michael Dell. Jeg jobbet med dem 20 eller 30 år inn i deres periode, men det som gjør dem bemerkelsesverdige er at de var der fra begynnelsen. De tok de tidlige produktbeslutningene, etablerte ruter til markedet og satte en kultur for langvarig suksess. Min rolle var å gi inkrementelle forbedringer på toppen av de tiårene av hardt arbeid de allerede hadde gjort. Til slutt nådde jeg et punkt i min karriere hvor jeg ønsket å bevise for meg selv at jeg også kunne bygge en bedrift, ta et produkt til markedsmessig tilpasning, etablere en salgsbevegelse og skape en kultur som jeg trodde kunne trives over lang tid.

Observe stiller seg som en ny kategori innen observabilitet, og integrerer logger, analyser og overvåking i én samlet plattform. Hvordan ser du på denne tilnærmingen som omdefinerer markedet i forhold til etablerte spillere som Splunk og Datadog (DDOG )?

Det store problemet for etablerte verktøy er at de ikke er bygget for skala. I samtaler med kunder har vi sett gang på gang at Splunk og Datadog blir kostnadskrevende når volumet av telemetri vokser, og det er grunnleggende et problem med hvordan etablerte verktøy ble arkitektert.

Observe skiller seg ut ved at vår plattform er bygget på en strømmende data-sjøarkitektur med åpne formater som Apache Iceberg. Det betyr at vi kan kopple fra beregning fra lagring, skalerer elastisk og levere observabilitet til en brøkdel av kostnadene for tradisjonelle systemer. Konkurrenter som Splunk er fortsatt avhengige av monolittiske arkitekturer som krever planlegging for toppkapacitet – og selv nye verktøy som Datadog krever data-nivå, gjennoppvarming og gjennomgang for å holde kostnadene under kontroll.

Vi fokuserer også på en samlet observabilitetsopplevelse. Logger, målinger, sporingsdata og hendelser bor alle i ett sted, med ett enkelt spørrespråk og en kunnskapsgraf som automatisk kartlegger relasjoner mellom tjenester, brukere og hendelser. Den konteksten er det som gjør feilsøking raskere. I motsetning til Splunk og Datadog har separate bakender for logger, målinger og sporingsdata, noe som fører til langsommere analyser.

Til slutt har vi investert tungt i AI-drevet feilsøking. Vår O11y AI SRE kan ta imot naturlig språk, generere hypoteser og guide ingeniører gjennom hendelsesløsning, ikke bare varsle dem. Og det er bygget for å bruke vår kunnskapsgraf, som gir den nødvendige konteksten for nøyaktig feilsøking. Det er et skritt utover det anomalideteksjon eller varsling som de fleste konkurrenter tilbyr i dag.

Kort og godt: vi er kostnadseffektive, vi er samlet og vi er åpne. Disse tre kvalitetene er det kundene konsekvent forteller oss skiller Observe fra etablerte spillere som Splunk og nye etablerte som Datadog.

Du har overvåket milliarder-dollar-operasjoner og nå driver du en startup. Hva lærte du om effektivitet, fleksibilitet eller innovasjon fra store bedrifter som kan overføres – og hva lærte du ikke?

Det er motsigende, men suksessfulle store selskaper gjør noen få ting veldig bra, og de forstår hver enkelt detalj. De som flørter gjør for mye, og alt degenererer til middelmådighet.

I en startup fokuserer du på én ting om gangen og besetter deg med hver enkelt detalj. Det er ikke nok finansiering til å gjøre mer enn det. Som et resultat er det som gjør startups så intense at du kan bokstavelig talt gå ut av forretningen hvis du ikke klarer å løse tingene raskt nok. Derfor må du ta beslutninger raskere, slippe ut raskere, feile raskere og lære raskere. I tillegg må du gjøre alt dette med færre mennesker.

Likevel er den mest frigjørende delen av en startup at du ikke har en etablert produkt, forretningsmodell eller rute til markedet. Det betyr at det er full frihet til å gjøre nye antakelser om alle disse tingene. Det er ikke tilfelle i et stort selskap. For eksempel kan du ikke bryte forretningsmodellen med et nytt disruptivt produkt. Selv om du teknisk sett kunne bygge det, vil CFO-en og Wall Street ikke la deg maksimere dets potensiale. Det er derfor startups vinner ganske ofte når, i teorien, de ikke burde ha noen sjanse.

Du har også vært styremedlem i Snowflake i nesten et tiår. Hva har du lært fra Snowflakes reise som informerer din strategi i Observe?

Snowflake angrep et gammelt problem med en ny arkitektur. De bygget sin teknologi på en enkel, men kraftfull idé og forstyrret et massivt marked som var bogged down av etablerte leverandører. Det er noen lærdommer her: spill i markeder som er massive, og du kan bygge en massiv bedrift. I tillegg må du ha en radikalt annen tilnærming enn etablerte spillere, så kunden kan se enorme fordeler ved å flytte.

Observabilitetsmarkedet vi angriper er massivt, 30 milliarder dollar og vokser. Vi har løst observabilitetsproblemet på en svært unik måte: ved å bruke en data-sjø-basis, elastisk beregning og åpne formater. Dette lover å gi kundene en ordenes størrelse forbedring i både feilsøkingshastighet og totalkostnad.

Du har vært dypt involvert i produktutvikling, markedsføring og storstilte M&A. Hvordan påvirker denne brede bakgrunnen måten du prioriterer vekststrategier i Observe?

I de tidlige dagene av en startup er det ganske enkelt: du bygger et fantastisk produkt og prøver å selge det. Det er vekststrategien. Det sies at min karriere er veldig forvrengt mot bedriftsprogramvare og løsning av komplekse problemer for store bedrifter, så det er kanskje ikke overraskende at Observe er fokusert rett og slett på det!

Basert på min erfaring tror jeg at for å bygge et stort observabilitetsselskap, må du løse problemet for de største selskapene i verden. Disse er problemet med petabyte med data, tusenvis av brukere og tusenvis av applikasjoner. Det er mange observabilitetsselskaper, men svært få kan vinne i den miljøet, og jeg sikrer meg at Observe kan.

Observabilitet har blitt kritisk når moderne distribuerte applikasjoner vokser mer komplekse. Hvor ser du de største utfordringene og mulighetene for bedrifter over de neste 3–5 årene?

Den største utfordringen i dag er skala. Kubernetes, mikrotjenester og nå AI-arbeidsbelastninger produserer datavolumer som overvelder tradisjonelle verktøy. Påliteligheten av disse verktøyene synker når kostnadene skyter i været, og det er enkelt ikke bærekraftig; en ny arkitektur er nødvendig.

For å gjøre saken verre vil vi over de neste årene se mer kode skrevet, assistert av AI-kodingverktøy, enn på noe tidligere tidspunkt i historien. Den koden er ikke perfekt, og på et tidspunkt vil den feile. Området for vekst ligger i å spørre seg selv: hvordan feilsøker du kode som ingen skrev? Og eller, mens kode-genereringsverktøy kan se på kode og fikse feil, kan de virkelig se på hvordan applikasjonen oppfører seg i produksjon og finne den problematiske koden? Det er en massiv mulighet for observabilitetsleverandører i fremtiden.

Mange teamstruggler med verktøy-sprengning, og bruker separate systemer for logger, målinger og sporingsdata. Hvordan hjelper Observe med å forenkle denne opplevelsen for ingeniør- og DevOps-team i praksis?

I stedet for å jonglere med tre eller fire verktøy, gir Observe kundene en enkelt plattform å bruke. Et selskaps logger, målinger, sporingsdata og varslinger bor alle i samme system og er knyttet sammen av en kunnskapsgraf. Kunnskapsgrafen gir konteksten som lar brukerne bore og vippe sammenhengende over logger, målinger og sporingsdata for å akselerere feilsøking. Dette reduserer mengden tid de må bruke på å hoppe fra plattform til plattform, og lar dem i stedet avdekke et problem uten data-eksport eller kontekstskifte.

Kan du dele et konkrekt eksempel på hvordan Observe har hjulpet en kunde med å løse et stort problem – noe som ville vært vanskelig eller umulig med tradisjonelle observabilitetsverktøy?

Capital One bruker Observe til å presentere status for kritiske kunde-reiser ved å korrelere og berike telemetri-data med relevant forretningskontekst. De tar inn hundrevis av terabyte med telemetri per dag, inkludert logger, målinger, sporingsdata, endringsregistreringer, VPC-flytlogs og AWS-konfigurasjonsdata. Observe gir Capital One en samlet plattform for end-to-end-observabilitet, så utviklere og SRE kan utføre interaktiv hendelsesrespons og feilsøking.

Hva rolle spiller maskinlæring eller AI bak kulissene i Observe, og hvordan hjelper det kundene med å avdekke innsikt raskere eller automatisk detektere problemer?

Maskinlæring har en vaklende historie i observabilitet fordi bedriftsmiljøer er innebredt støyende, og det er svært vanskelig å produsere en modell som ikke resulterer i tusenvis av anomalier. Generativ AI er en svært annen teknologi og vil ha en mye mer profond innvirkning.

Vi tror AI vil endre måten ingeniører samhandler med observabilitetsverktøy. Først og fremst vil de kunne snakke direkte med sine observabilitetsdata i naturlig språk mens de sitter i sin IDE, og halvparten av våre brukere i fremtiden må kanskje aldri logge inn eller lære Observe! For det andre vil AI-agenter være til stede under “fredstid” for å skanne telemetri og se etter potensielle problemer som kan resultere i en hendelse. AI-agenter blir ikke trøtte eller kjede seg, og de kan utføre arbeid som mennesker bare ikke er i stand til å gjøre. Til slutt, under “krigstid”, vil AI-agenter assistere ingeniører og SRE med den kursen de bør følge for å løse problemet.

Din Formel 1-inspirerte ledelsesstil betoner mental styrke og læring fra feil. Hvordan har denne perspektivet formet din tilnærming til å bygge Observe og lede teamet gjennom både seirer og utfordringer?

Suksess i F1 er avlet ved å bruke data til å guide fremtidige beslutninger, både for sjåføren og bilen. Når en F1-bil når slutten av sesongen, er 90% av delene erstattet, og den er 2 sekunder raskere rundt banen.

I Observe må vi ha samme mentalitet for å lykkes. Vi slipper ut, måler, lytter, tilpasser oss raskt. Jeg ville tro at 90% av vårt produkt er forskjellig i dag enn bare noen år tilbake. Denne tilnærmingen krever mye disiplin, og mye ydmykhet, det er ikke lett å høre dårlige nyheter gang på gang. Likevel, hvis du handler på nok dårlige nyheter, forvandler det seg jevnt til gode nyheter, og ARR akselerer. Det er ikke magi, det er logikk!

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Observe.