Selv de beste CTO-ene startet med en "Hello World" (1/2)

Å lære hver dag er en viktig suksessfaktor for enhver gründer, spesielt unge teknologiledere, ettersom de ofte blir ansatt for sine tekniske ferdigheter, men da blir raskt bedt om å gjøre ting de absolutt ikke aner hvordan de skal gjøre: ledelse, rekruttering osv. Selv om de fleste er enige om at det er veldig viktig med fremgang i ofte skiftende miljøer (oppstart), bare få mennesker lykkes med det.

En stor teknologileder må ikke bare lære hver dag, men må også sørge for at teamet hans lærer sammen med ham.

Alle sier det:

For enhver grunnlegger av oppstarten vil jeg gå inn for en sunn dose kontinuerlig personlig utvikling: trenere, rådgivere, mentorer og fagfelle nettverk kan over tid være veldig kraftige verktøy i en grunnleggende verktøysett.
Rory Stirling, Det jeg sliter med som VC
Tallene er klare: For å holde på ansatte - spesielt yngre - må gründere gjøre arbeidsplassen til et klasserom.
Falon Fatemi, ditt oppstarts beste oppbevaringsspill? En kultur for å lære

Alle vet det, men likevel er det så få som faktisk bruker nok tid på å lære og gå videre.

1) Tidstap kontra tidsinvestering

Da jeg begynte å jobbe som utvikler for 7 år siden, tenkte jeg på:

  • Jeg har ikke tid til å tape på å lære hva reaktivitet er
  • hvorfor skulle jeg trenge å lære om serverløs arkitektur, jeg har ikke problemer med ytelsen
  • Lær ledelse? Er det ikke en ferdighet du enten har eller ikke har?
Kreditter: https://imgflip.com/memegenerator

Du kan bare begynne å bruke tid på å lære effektivt når du virkelig har forstått at du faktisk ikke mister tid, investerer du i det. La oss prøve å bruke en analogi: "Time == Money".

Penger / tidsinvestering

Kreditter: Trekk ut

De fleste den første måten å investere penger på er en sparekonto, de tar derfor et lite beløp av det de tjener hver måned, og overfører det til denne kontoen, noe som gjør det "umulig" for dem å bruke dem direkte på kortsiktige produkter. Noen uker, måneder eller år senere kan de endelig bruke pengene på å kjøpe en bil, et hus eller annet som det ville være vanskelig å kjøpe ellers fordi det er umulig å [tjene nok penger, ha god tid] i en uke til [kjøpe en bil, lær Ruby] (i det minste for meg )

Likevel legger folk vanligvis ikke nok [penger, tid] på [sparing, læring] -kontoen fordi:

  • Det er vanskelig å forstå verdien av en langsiktig investering da det er for langt fremover (Hvorfor skulle jeg trenge en [bil, ny ferdighet]?)
  • Det er altfor lett å tenke at du trenger noe nå, bare for å innse senere at du egentlig ikke trenger det (vi trenger alle den siste [videospill, funksjon])

Å bruke for mye [penger, tid] på kort sikt [produkter, produksjoner] forhindrer deg ofte fra å gå gjennom en nødvendig utvelgelsesprosess som hjelper deg å fokusere på prosjekter med høy verdiøkning.

2) Personlige investeringer i læring

Les / lytt

Det kan være åpenbart, men her er noen tips jeg bruker på meg selv når det gjelder å lese (eller lytte til) læringsmateriell:

  • Mål mengden bøker / artikler / blogginnlegg du har lest, og gi deg et mål. Jeg personlig prøver å lese 1 bok annenhver måned og minst 4 artikler (Medium, SO, Quora ...) i uken om teknikk, ledelse eller annet tema jeg synes er nyttig for min progresjon.
  • Organiser deling av lesestoff på teamnivå. Hos Kerala Ventures slår alle sammen og kan legge til artikler i Notion-databasen. Det hjelper oss å bruke mindre tid på å finne fantastiske artikler og mer tid på å lese dem. Forsikre deg om at relevante koder blir brukt på artiklene dine (serverløs, docker, rubin, etc.)

Bestill et spesifikt spor i kalenderen

Den viktigste kampen jeg hadde var mangelen på struktur jeg hadde når det gjaldt læring. Jeg har nå en dedikert spalte i kalenderen min. Jeg pleier å gjøre det på fredag ​​ettermiddag, ettersom det er tiden i uken jeg er for sliten til å være 100% produktiv og det krever vanligvis mindre fokus enn når jeg skal kode. Kalenderen min er 3 timer, men ærlig talt endrer beløpet jeg investerer hver gang.

Den første gangen, jeg bare leste og leste i 3 timer (Gjør ikke det!), Jeg sender nå e-post til folk jeg vil møte, finne og booke interessante møter, lese, tilbringe tid med lagkamerater som jeg kan utveksle med på nye fag ...

3) Teaminvesteringer i læring

Bygg teamkulturen din rundt læring

Kreditter: Trekk ut

De beste teknologiledere har alle en måte å sikre at utviklerne deres fortsetter å lære hver dag.

Her er noen tips du kan bruke til små team uten å ha den strukturen et større selskap kan trenge:

  • Oppfordre teamet ditt til å bestille en spalte i kalenderne deres
  • Organiser (en eller to ganger i måneden) teamsamtaler der hver dev snakker om noe han nylig har lært
  • Uttrykk tydelig til teamet ditt at alt læringsmateriell er og vil bli betalt av selskapet (Bøker, tenne, "virkelig interessante" konferanser, abonnement på e-læringsplattformer). De vil vanligvis ikke spørre, så spør etter dem. Jeg gjentok det gang på gang til teamet mitt til den første utvikleren bestemte meg for å be meg om en bok, lese den og bli en av de beste utviklerne mine. Åh, og hvis det ikke er en selskapspolitikk ennå, vil jeg gjerne høre tankene dine om hvorfor det ikke skulle være!
  • Ha et lite bibliotek (eller noen tenner) på kontoret
  • Belønne læringsinitiativer!
  • Bruk kodevurderinger og parprogrammering. (Jeg tar mer tid på å snakke om disse metodene rett nedenfor)

Kode anmeldelse

Kreditter: Trekk ut

Fagfellevurdering er evalueringen av en kodekode av en utvikler som ikke skrev den. Hvis du ikke gjør det ennå, bør du absolutt gjøre det.

For å forstå hva en god gjennomgangsprosess ville være: Den perfekte kodevurderingsprosessen

For å forstå rollen til anmelderen og innsenderen: Retningslinjer for kodegjennomgang

3 hovedmål oppnås ved å sørge for at hver kode blir vurdert av en jevnaldrende:

  1. Anmelderen lærer ved å lese koden til en medutvikler
  2. Koderen lærer ved å få kommentarer fra anmelderen
  3. Koden utfordres av en annen utvikler som kan bringe en ny tilnærming og fokusere på ting som lesbarhet, vedlikeholdbarhet, etc.
  4. https://help.github.com/no/articles/about-pull-request-reviews (Jeg Github btw, et av verktøyene du kan bruke)

Jeg tror det hovedsakelig er to regler som bør brukes når du bruker fagfellevurdering:

  1. Bruk den aldri som en måte å få koderen til å tro at kodingsevnen hans ikke er tilstrekkelig. Det er et lærings- og et kvalitetsverktøy, ikke en diskusjon eller en ledelseskanal.
  2. Forsikre deg alltid om at hver og en av utviklerne dine vurderer, at den verken er forbeholdt seniorutviklere eller juniorutviklere. Til og med juniorutviklere kan dele noen gode innsikter når de gjennomgår, og til og med seniorutviklere kan lære mye å lese koden til en juniorutvikler.

Par programmering

Det rette fyrhåret er sååå kult. Kreditter: Trekk ut

For dere som ikke vet hva parprogrammering er ennå: Par programmering.

Og her er noen råd for implementering av et sunt parprogrammeringsmiljø:

  • Bestill et spor for parprogrammering i kalenderne!
  • Parprogrammering bremser deg definitivt, det er en naturlig avveining mellom kvalitet og hastighet, så pass på å ikke legge for mange spor.
  • Jeg anbefaler personlig å tilpasse frekvensen til teamnivået ditt, sørge for at hver utvikler kan gjøre en økt med parprogrammering i uken, men at hver seniorutvikler ikke har mer enn 2 i uken. Gjennomsnittlig økt er opp til deg, men 2 timer er et godt utgangspunkt.
  • Gjør ditt beste for å gjøre nivåene av parprogrammerere heterogene, husk at det også er et læringsverktøy.

Skål

Jeg har nettopp lest denne artikkelen, og jeg elsket den: De beste utviklerne er oppdratt, ikke ansatt

Hvis du vil gå lenger, er her den andre artikkelen min: Selv de beste CTO-er startet med Hello World (2/2)

Youhou!や っ た! Dette var min første medium historie, den første av (håper jeg), en serie som har ett mål: Å reflektere over mine feil som teknisk sjef og gi innsikt til de neste, og skape debatt om å bygge et flott miljø for teknologteam å utvikle seg (se hva jeg gjorde der) . Jeg vil dele det jeg lærte de siste årene, som frilanser, deretter som CTO hos Inch, og for tiden som CTO på Kerala Ventures. Takk til alle gründerne jeg møtte de siste månedene, og som hjalp meg å forstå mer og mer om disse temaene. Forresten, Kerala er ansettelse

Historiene mine er hovedsakelig skrevet for enhver teknisk sjef som leder et team på 1 (omg, jeg trenger å gjøre alt her) til 20 (omg, hvorfor trenger jeg (tror jeg) fremdeles trenger å gjøre alt her) utviklere. Hvorfor ?

Det er en anstendig mengde bøker, arrangementer, samtaler og trenere for administrerende direktører, men vi hører veldig lite om kampen for å være CTO. Jeg får det til, å snakke om feil vi gjorde å lære på jobben er ikke glamorøs, det er faktisk ganske flaut og vondt å tenke på. Men en del av denne øvelsen er terapeutisk, den andre vil forhåpentligvis hjelpe nåværende eller fremtidige CTO-er. Å bygge tillit som CTO

Om Kerala Ventures

Kerala-teamet er sinnssykt fokusert på å gi massiv støtte til sine gründere innen teknologi, drift og ansettelser (se first20.club). Vi har en unik kunnskap om å utvikle startups fra bunnen av til "enhjørninger" (Lafourchette, Doctolib, se historien vår)

Kerala Ventures investerer fra 100 til € 1,5 millioner i gode gründere