Fra nul til en million brugere: hvordan man hurtigt udvikler et vellykket tech-team

Badi-holdet på vores hovedkvarter i Barcelona, ​​Spanien

Badi er en voksende opstart med en klar mission: forbedre byernes levevis ved at forbinde mennesker med delte rum. Vores virksomheds resultater førte til indtil videre $ 45 M VC-finansiering og til WIRED-nominering blandt de hotteste startups i Europa i 2 år i træk.

Som Chief Technology Officer hos Badi har mit hovedfokus været at udforme teknologien og det team, der byggede det fra bunden af.

I de sidste 2,5 år opskalerede vi vores teknologitjenester fra 0 til 1 million brugere. Vi leverede hundreder af millioner månedlige transaktioner med en gennemsnitlig responstid på under 100 ms, mens vi opretholdt en konstant driftstime på 99,9%.

Dette har været muligt takket være en datadrevet tech-strategi og en ingeniørkultur baseret på tillid og ejerskab, hvilket også afspejles i vores ingeniøromsætningsrate, der hidtil har været lig med nul i et meget konkurrencedygtigt tech-økosystem.

Hvordan skal du med succes skalere en virksomhed fra grunden til millioner af brugere som en tech-leder, der arbejder i et hurtigt tempo?

Her er nogle tip til teknologiledere, der arbejder i et miljø, hvor turbo-vækst, kvalitet og eksekveringshastighed er de vigtigste krav.

Teknisk talent

Leje, leje, leje!

Arbejd alene, hvis du bygger din første MVP. Efter dette skal du begynde at ansætte. På enhver anden måde kan du måske finde dig selv fast i en uendelig sløjfe, hvor du aldrig har tid nok til at ansætte, fordi du koder.

Dit team er dit bedste aktiv. Talentsøgning kan tage op til 50% af din tid (ja, du læser godt) i meget tidlige faser af et firma.

Hvis dit oprindelige budget ikke tillader dig at tiltrække erfarne ingeniører, skal du hente juniorudviklere. Mine første ansættelser hos Badi var juniorudviklere friske fra en kodende bootcamp, og jeg kunne ikke have været lykkeligere med dem! Junioringeniører er typisk meget motiverede og begejstrede for deres første job. Du kan ikke forestille dig, hvad de kan opnå med lige den rigtige mængde vejledning.

Tillid og delegeret

Du skal ikke mikromane. Dette er mit motto. Overvåge, men prøv ikke at kontrollere alt. Det er kontraproduktivt, og du har ikke tid til det.

Tøv ikke med at give dit team ejerskab og ansvar. Hvis de mislykkes, lærer de af deres fejl.

De fleste ingeniører er naturligvis tilbøjelige til at tage nye udfordringer og løse komplekse problemer. Du vil blive overrasket over, hvad de kan opnå, når du giver dem din fulde tillid. Dertil kommer, at du også fremmer dit teams faglige vækst, som er et af dine hovedmål som teknisk leder. Dit team vil snart indse det, og de vil være taknemmelige for dig.

Forbliv sulten

At arbejde i tech kræver konstant træning. Dit team har brug for adgang til læringsressourcer samt din støtte og opmuntring til deltagelse af relevante begivenheder.

Dette er ikke valgfrit. Sørg for at afsætte tid og budget til teknisk træning. Når virksomheden vokser, skal du indstille et budget for hver enkelt af dine ingeniører til træning og forretningsrejser.

Tekniske begivenheder er også perfekte spillesteder til netværk og spejder nyt talent!

Teknisk stak og infrastruktur

Tænk på forhånd

En tech-leder forstår fuldt ud forretningsstrategien og konverterer den til højteknologiske specifikationer og krav, der kan udføres af teamet. Denne evne kræver tænkning på forhånd, hvor skalerbarhed er nøglen.

I de første år af en virksomhed er det helt normalt at ændre køreplanen et par gange om året og justere mål. Dit team kan måske ikke lide det, men du skal være klar til det.

Én tilgang til at tackle denne udfordring er at investere tid siden første dag i oprettelsen af ​​en solid teknologisk infrastruktur, der kan understøtte forretningsvækst. Dette kan opnås i dag ved at fokusere indsatsen på at opbygge en modulær skybaseret arkitektur ved hjælp af udbydere som AWS og GCP. Ved at gøre det fra starten, vil du:

  • udvikle dine tjenester i henhold til et distribueret systemparadigme, i modsætning til mono-software-monolit. Dette vil gøre det lettere at identificere flaskehalse og implementere løsninger, når de skaleres op;
  • være i stand til midlertidigt at kaste hardware på problemet. For et par år siden havde vi på Badi vores første tv-annoncekampagne på flere millioner dollars. Ved at øge antallet af tilfælde, der kører vores centrale API og vores DB-smag, sørgede vi for, at vi med succes kunne håndtere højt brugertoppe. Dette var langt fra en ideel situation fra et rent teknisk perspektiv, men alligevel var det helt fint med hensyn til forretningsstrategi.

Design dine systemer med skalerbarhed i tankerne.

Overvåg dine tjenester

Der er forskel mellem chance og held. Du kan ikke kontrollere tilfældet (så ikke bekymre dig om det), men du kan forme din held.

I de sidste 2,5 år på Badi havde vi et konstant gennemsnit på 99,9% oppetid. Ikke dårligt til en opstart! Årsagen til denne præstation var den datadrevne strategi, vi fremmede, som består af avanceret overvågning af alle tjenester og kontinuerlig analyse af deres opførsel over tid.

Ved at bruge produkter som NewRelic, Dynatrace eller Datadog kan du indsamle kvantitative data om ydeevnen for dine systemer. Du kan derefter optimere dine tjenester og forudsige potentielle flaskehalse. Ved at bruge NewRelic, for eksempel, var vi i stand til at identificere en vigtig hukommelseslækage, der påvirkede vores API og løse den, før den blev et reelt problem.

Det kan være dyrt at overvåge dine tjenester og infrastruktur, men det er en investering med et højt afkast, der bør være en del af din teknologistrategi. Når alt kommer til alt, løser vores job problemer, inden de faktisk opstår.

Jo enklere, jo bedre

Hvor mange gange har vi været fristet til at prøve den nyeste programmeringssprog, ramme eller databasemotor til at sende vores nye produkt? Før du gør det som teknisk leder, er det din pligt at tage et skridt tilbage og adskille din naturlige spænding fra de faktiske forretningskrav.

Forsøg ikke at opbygge et rumskib, hvis det, du virkelig har brug for, er en cykel!

Selvom tænkning på forhånd er en nødvendig færdighed for enhver teknisk leder, så undgår man at overarkitere.

Mit yndlingsvalg? Forsendelse af den mest enkle løsning, og senere skal du bygge oven på den.

En kollega spurgte mig engang, hvorfor jeg valgte en MySQL-database til kernetjenesterne på Badi i stedet for et “mere moderne” ikke-relationelt modstykke. Jeg gik simpelthen efter den mest optimale løsning, her er hvorfor:

  • vores vigtigste forretningslogik inkluderede brugere, værelser og billeder. En bruger kan have N-rum og et værelse N-billeder… Der er intet mere relationelt end det;
  • MySQL har eksisteret i over 20 år, det er et solidt valg, og det har en god ydelse med lidt optimering krævet op til hundreder af millioner poster;
  • som et plus kræver de fleste analyse- og datavisualiseringsværktøjer SQL-baserede forespørgsler. En relationel DB gør livet lettere for datavidenskabsmænd og BI-enheder i de tidlige stadier af et firma (til sidst bygger du dem et datavarehus).

Selvom vi altid bør prøve de nyeste teknologier, så lad os ikke bruge dem på et produktionsniveau, bare fordi de er smarte. Sørg for, at du har en forretningssag i den virkelige verden, der rent faktisk kan drage fordel af dem.

Teknisk gæld

Den første regel om teknisk gæld er… du taler om teknisk gæld.

At opbygge solid teknologi i en virksomhed kræver den rigtige balance mellem kvalitet og leveringshastighed. Dette indebærer ofte en afvejning, og der er ingen skam i det.

Det er OK at akkumulere teknisk gæld op til en vis grad, så længe du og dit team er fuldt ud klar over det og har en konkret plan for forbedring på kort og mellemlang sigt.

I nogle tilfælde kan bevidst at akkumulere nogle teknisk gæld endog være en del af din forretningsstrategi.

En af de tidlige tekniske udfordringer hos Badi var for eksempel oprettelsen af ​​et internt chat-system, der giver brugerne mulighed for at kommunikere i realtid. Dette var en af ​​kernefunktionerne i vores produkt, der var direkte forbundet med de vigtigste KPI'er i virksomheden. Vi havde begrænset tid (mindre end 1 måned!) Og ressourcer (2 backend-udviklere). Efter nogle indledende tanker besluttede vi at bruge Actioncable, websocket-integrationen, der kommer ud af boksen med rammerne, der driver vores API (RoR).

Denne tilgang ville præsentere nogle fremtidige begrænsninger med hensyn til samtidighed og latenstid. Vi var alle klar over dem, og det var netop derfor, vi allerede havde en plan om til sidst at opbygge en avanceret mikroservice til vores chat, muligvis ved hjælp af Node.js eller Go.

Ved at vælge Actioncable kunne vi sende vores første websocket-drevne chat-system på kun to uger. Det var ikke den bedste chatimplementering, vi kunne have bygget; det var dog hurtigt og rimeligt godt for tiden, og det bidrog direkte til at lukke en finansieringsrunde på $ 10M i serie A. Ikke dårligt!

En teknisk leder skal altid være i stand til at finde den rigtige balance mellem skalerbarheden af ​​løsningen og forretningsstrategi.

Budget

Bed om mere $$$

Uanset hvor hårdt du arbejder med din økonomiafdeling for at planlægge et budget, i virksomheder i tidlige faser (især i det første år) kan du måske indse halvvejs i kvartalet, at dit budget er stramt.

Hvis du ved nøjagtigt, hvad du har brug for for at vokse hurtigere (f.eks. En ny service, ekstra talent osv.) Og din eneste hindring er manglen på budget, skal du ikke tænke to gange og bare bede om flere penge.

Du får ikke altid de ekstra udgifter, men alligevel vil du i det mindste skabe et fremtidig behov.

Hos Badi indså jeg snart, at vi havde brug for en ekstern QA-tjeneste til at skaffe beta-test til vores mobile apps. Vores team plejede at sidde sammen og teste vores produkt hver fredag ​​i et par timer. Dette var ikke effektivt hovedsageligt på grund af den begrænsede tid, vi havde, og det lille antal enheder, vi ejede.

Skift til en ekstern QA-service var den rigtige ting at gøre for at øge holdets produktivitet og forbedre den samlede produktkvalitet. Flere titals reelle brugere testede vores apps i weekenden ved hjælp af en heterogen pool af enheder, og de rapporterer systematisk fejl via vores problemsporingssoftware.

For et firma, der havde en samlet finansiering på $ 1M på det tidspunkt, var denne QA-tjeneste temmelig dyr. Du kan sandsynligvis forestille dig udtrykket af vores finansdirektør da jeg uventet bad om 50 til 100.000 ekstra til det. Jeg fik ikke pengene først. Vi var dog i stand til at sikre dem et par måneder senere.

Resultaterne af denne nye investering blev snart tydelige, og siden da blev udgifter til test og QA simpelthen taget for givet af alle, ingen spørgsmål blev stillet.

Dine ikke-tech-kammerater læser ikke dit sind. Når du har brug for noget, skal du bede om det.

Bed om rabatter

Nogle tredjeparts tjenester og SaaS tilbyder startprisfastsættelsesplaner, mens andre ikke gør det. Under alle omstændigheder skal du altid henvende dig til salgschefer og bede om rabatter.

Hver gang jeg mener, at prisfastsættelsen af ​​en ny tjeneste, jeg vil vedtage, er for høj, anmoder jeg om et hurtigt opkald, hvor jeg præsenterer mig selv og mit firma. Herefter forklarer jeg, hvor meget jeg ville elske at bruge deres produkt, og hvorfor. Derefter beder jeg eksplicit om mulige rabatter.

Du vil blive overrasket over, hvor mange udbydere er villige til at tilbyde en rabat, gratis kredit eller ikke-standard / skjult prisplaner, i det mindste i nogen tid. Efter min erfaring var 8 ud af 10 leverandører mere end villige til at sænke deres pris, når de blev spurgt. I nogle tilfælde sparede vi op til 75% fra de oprindelige omkostninger i løbet af det første år.

Når alt kommer til alt er det en win-win-situation for begge parter: hvis din virksomhed vokser, vil de tjenester, du bruger, også være.

Det er ingen skam at bede om rabatter eller gratis kreditter. Dette vil også bevise for din økonomiafdeling, at du rent faktisk ønsker at spare virksomhedens penge og således styrke din troværdighed yderligere, når du anmoder om et højere budget i fremtiden.

Professionelle forhold

Vær empatisk

Empati og følelsesmæssig intelligens er de vigtigste færdigheder, som enhver leder skal have.

Vær empatisk med dit team og med dine kolleger. Dette er den bedste måde at skabe klarhed i kommunikation på ethvert niveau såvel som at overtale andre til at følge din vejledning og anbefalinger.

Empati er muligvis ikke naturlig for nogle mennesker i starten. Det er bare et spørgsmål om at sætte dig selv i en andens sko og prøve at forstå, hvad den anden person føler, og hvorfor.

Beher dig kunsten at være empati, og du vil have en god karriere som leder.

Vær en del af det lokale teknologisamfund

Vær aktiv i det lokale tech-samfund ved regelmæssigt at deltage i begivenheder og meetups.

Hver større by er vært for dagligt en bred vifte af teknologirelaterede begivenheder, som ofte følges af netværkssessioner. Du møder nye mennesker, deler ideer og indhenter nye og gamle kolleger. Under sådanne begivenheder kan du muligvis også opdage nyt talent at ansætte.

I vores by arrangerer vi et møde kaldet “CTOs & co”. Vores samfund tæller mere end 1 tusinde medlemmer og samler fagfolk i det lokale tech-økosystem, der hjælper hinanden ved at udveksle ideer og tip. Der delte jeg for første gang vores erfaring med at opbygge et vellykket tech-team fra bunden af.

konklusioner

Arbejde handler om at have det sjovt at gøre de ting, du nyder mest. Succesfulde resultater inspirerer mennesker og skaber obligationer. Uanset hvor hektiske dine dage er, skal du altid tage lidt tid på at fejre vigtige milepæle med dit team.

Holdet på Badi fejrer de første millioner brugere