Chas Talk Eftersnack med Victor Axelsson

Kan du berätta lite om din bakgrund och hur din resa ledde dig till rollen som CTO på Kliently?

Jag jobbade väldigt mycket redan från dag ett när jag började som utvecklare och programmerade en hel del, främst för att jag var extremt fascinerad av hur man med enbart text kunde skapa något som nästan kändes levande. Under de första fem åren hade jag inte en enda dag utan att skriva kod.

Efter några år som konsult och tech lead fick jag min chans att ta nästa steg, en CTO position på Mindler där jag var första ingenjör. Det var lite trial by fire men tillslut blev det ett bra bolag :) När man sen gjort den resan en gång så är det inte svårt att landa ett annat CTO jobb. Jag var fascinerad av Klientlys business model, grundarnas förmåga och att tillgängliggöra juridisk hjälp på samma sätt som Mindler tillgängliggör hjälp för mental ohälsa. Så jag hoppade på och är idag CTO på Kliently. 

Du har arbetat både som konsult och i ledande roller på startups – vad är den största skillnaden mellan dessa roller? 

Jag var nyligen gäst i en podcast där jag pratade om “Taking the leap to CTO”, där kan man få en mer ingående inläsning på ämnet.

Men jag skulle säga att det finns både hårda och mjuka skills man behöver ha för att det ska funka. Plus en massa yttre omständigheter och tur. Här är lite exempel på saker jag personligen behövde arbeta med när jag blev CTO.

Hårda skills:
-Lära sig läsa finansiella dokument, som tex en balans och resultatrapport.
-Lära sig grunderna kring skatter och equity
-Göra budget
-Compliance ansvar
-Rekryteringsprocess och lagkrav (såsom LAS) för att bygga rätt sammansättning av kompetenser och följa lagen.

Mjuka skills:
-Kommunikation- Framförallt att väga mina ord väldigt noga innan officiella uttalanden.
-Lära sig att inte man kan vara omtyckt av alla.
-Lyssna på folks underliggande behov.
-Inte alltid ha svar men visa på beslutsamhet.

Som utvecklare behöver man sällan involvera sig något ytterligare i dessa ämnen de första fyra åren av sin karriär. Som konsult är det egentligen ingen skillnad från att vara utvecklare på produktbolag förutom att det finns lite praktiska saker man behöver göra. Tex, tidsrapportering och att försöka leverera värde så fort man bara kan för att behålla uppdraget. Om man kör många olika uppdrag kommer det bli viktigt att bli bra på att onboarda i nya system snabbt!

Under ditt Chas Talk pratade du en del om tekniska roadmaps. Kan du sammanfatta vad det innebär och vilka de största utmaningarna med att bygga en teknisk roadmap från grunden kan vara, särskilt för någon som är ny i branschen?

Det är viktigt att hitta en bra balans mellan good enough och ett sms lån med 200% ränta. Man behöver tänka igenom vilket som är målet med implementationen och hur man ska veta ifall man lyckats. Validering och mätbarhet måste komma innan man ens börjar med en specifikation. När man sen har mätbara mål så får man bryta ner det i kortare sprintar.

En utmaning om man är junior kan vara att förutse scenarion som en mer erfaren ingenjör har erfarenhet av. Men samtidigt så har mer seniora personer ibland en övertro på en negativ utveckling på saker som inte tidigare fungerat. Så var alltid öppen för input och försök sätta tydliga mål som ni är beredda att revidera om det inte går i rätt riktning.

Under din föreläsning återkom du till rådet 'Tänk snabbt, gör långsamt'. Kan du förklara vad du menar med det och hur det kan appliceras i praktiken?

Jag försöker alltid trycka på att det är superviktigt att inte hoppa direkt in i en lösning utan att ha grundligt tänkt igenom underliggande behov. Utveckling är dyrt så när man väl sätter igång så ska det gå på räls.

Ett exempel: Det går snabbt att göra ett diagram som beskriver en datamodell och upptäcka problem med tex kardinaliteten på en entitet. Men om man istället börjar knacka kod direkt kommer man upptäcka detta mycket senare när någonting inte fungerar. Kanske är man redan live med delar av systemet och behöver göra databas migrationer med bakåtkompatibilitet över flera releaser.

Det går snabbt att diskutera och revidera en kravspec eller diagram (tänka) men att patcha fel i datamodeller eller krypteringskrav (göra) är exempel på aktiviteter som ökar arbetet signifikant på någonting som kunde upptäckts redan under specifikation.

Infrastruktur och DevOps hänger ofta tätt ihop. Vilka är dina bästa tips till studenter som vill förstå och utveckla sina kunskaper inom detta område?

Det är tyvärr svårt att bli riktigt bra på nätverk, infrastruktur och DevOps utan ett företag. Som utvecklare kan man ändå lära sig mycket på egen hand genom att bygga egna appar och system. Men att sätta upp en säker infrastruktur med hög trafikbelastning på en budget runt 100.000 SEK är svårt att göra på kammaren. Så det kan vara bättre att jobba in de teoretiska delarna så mycket som möjligt för best practices och prata med folk som jobbar i en riktig miljö. Då kan man alltid bolla idéer och få insikt i hur det funkar på riktigt.

Det är bra att bevandra sig så mycket som möjligt så man har råd med att spinna upp saker i en riktig miljö. Ofta kan man få behjälpligt med krediter på AWS, Azure och GCP. Sen kan man alltid skala ner storleken för att hålla nere kostnaderna. Sätt upp budget alerts och lär er vad som är billigt och vad som är dyrt. Om man går Kuberneteshållet är det enklare till en början eftersom man kan sätta upp alla världens system på gamla laptops och raspberry pies som många har skräpade hemma. Så bara kör på och testa testa testa!

Vilka är dina viktigaste do's and don'ts för tekniska team, både generellt och ur ett DevOps perspektiv?

-Tänk på att gruppens performance alltid kommer att överväga individuell performance. Satsa på att bygga ett team med bra psychological safety. Rockstar developers är någonting som många (med rätta) ryggar tillbaka från att anställa eller jobba med.

-Tagga upp infrastruktur noga så det går att följa kostnader och sätta budget alerts.

-Keep it simple! Du behöver inte bygga ett system som är dyrt att drifta bara för att det ska klara obegränsat med trafik och datavolymer. De allra flesta system har mycket mindre trafik än vad den är designad för. Förstå noga vilka risker bolaget borde ta med rimliga trade-offs.

-Dokumentera hur saker funkar!