Hvornår skal du ansætte din første udvikler?

Du bruger flere og flere penge på freelancere eller bureau og overvejer, om det er tid til at ansætte din egen udvikler. Kort svar: Ansæt, når der er nok faste opgaver til en fuld stilling året rundt, når den tekniske viden skal blive i virksomheden, og når nogen kan lede og prioritere udviklerens arbejde. Mangler en af de tre ting, er en ansættelse ofte for tidligt.

Her er tegnene, alternativerne og de fejl, jeg oftest ser ved den første tekniske ansættelse. Valget mellem intern udvikler, bureau og freelancer har jeg sammenlignet i intern udvikler, bureau eller freelancer.

Tegn på, at det kan være tid

• Opgaverne er faste. Der er løbende arbejde med temaet, integrationer, data og fejlrettelser hver uge, ikke kun i projekter.
• Ventetiden koster. Små ændringer tager uger, fordi de skal ind i en ekstern partners kø.
• Viden forsvinder. Hver gang en leverandør skifter, skal løsningen forstås forfra.
• Det tekniske er en del af produktet. Konfiguratorer, egne apps eller integrationer er afgørende for forretningen.
• Der er bundet mange penge i ekstern udvikling. Og du kan se, at en del af arbejdet kunne løses hurtigere internt.

Tegn på, at det er for tidligt

• Behovet svinger meget, og der er måneder uden opgaver.
• Opgaverne kræver mange forskellige specialer, som én person ikke kan dække.
• Ingen i virksomheden kan prioritere, give feedback eller vurdere arbejdet.
• Problemet er egentlig manglende retning, ikke manglende hænder.

Er det sidste tilfældet, er en rådgiver ofte det første skridt. Se 5 tegn på behov for en teknisk rådgiver.

Alternativer til en ansættelse

Mange webshops kombinerer: en rådgiver til retning og en fast ekstern udvikler til det daglige, indtil behovet er stort nok til en ansættelse.

Hvilken profil skal du lede efter?

Den første udvikler er sjældent en specialist. Det er en person, der kan:

• arbejde med jeres platform, for eksempel Shopify-temaer i Liquid, apps og API’er.
• forstå forretningen og spørge “hvorfor”, før der bygges.
• træffe tekniske beslutninger alene og forklare dem i almindeligt sprog.
• dokumentere, så viden ikke kun ligger i hovedet på én person.
• sige nej eller foreslå noget enklere, når en idé er dyr i forhold til gevinsten.

Den sidste egenskab er undervurderet. En udvikler, der siger ja til alt, kan bygge en butik, ingen andre kan vedligeholde.

Typiske fejl ved første ansættelse

1. Ansætte for at løse et ledelsesproblem. Hvis ingen ved, hvad der skal bygges, løser en udvikler det ikke.
2. Vælge en for uerfaren profil uden støtte. En nyuddannet udvikler uden nogen at sparre med, træffer beslutninger, der er dyre at rette.
3. Ingen plan for de første måneder. Uden konkrete opgaver og mål går tiden med at finde rundt.
4. Én person med al viden. Kræv dokumentation fra start, så virksomheden ikke bliver afhængig af én medarbejder.
5. Glemme det, der stadig skal købes. Design, specialopgaver og ferieafløsning kan stadig kræve ekstern hjælp.

Sådan rekrutterer du, når du ikke selv er teknisk

1. Beskriv opgaverne, ikke kun teknologierne. Hvad skal personen lave det første år?
2. Bed om eksempler på tidligere arbejde, gerne butikker eller kode, kandidaten kan vise.
3. Lad kandidaten forklare en teknisk beslutning, de har truffet, og hvad de ville gøre anderledes.
4. Brug en lille, betalt prøveopgave, der ligner det rigtige arbejde.
5. Få en erfaren udvikler eller rådgiver med til den tekniske vurdering.

De første måneder

God onboarding er forskellen på en udvikler, der hurtigt bidrager, og en, der bruger måneder på at finde rundt. Sørg for adgange, dokumentation af systemer og integrationer, en ansvarlig at spørge og små første opgaver, der giver et hurtigt indblik i løsningen. Planlæg den tekniske onboarding af udvikleren før første arbejdsdag.

Aftal også, hvordan opgaver prioriteres. Ellers bliver den nye udvikler hele virksomhedens personlige support.

Hvem leder udvikleren?

En udvikler har brug for nogen, der sætter retning og prioriterer. Hvis du ikke selv kan det, kan en ekstern CTO stå for retningen, mens udvikleren bygger. Forskellen mellem modellerne for teknisk ledelse står i ekstern CTO, bureau eller intern CTO.

Hvis du vil have hjælp til at vurdere behovet, skrive stillingsopslaget eller deltage i den tekniske samtale, kan du læse om min rolle som ekstern CTO.