La trampa del «ja m'ho faig jo»: per què els fundadors tècnics també necessiten equip
El superpoder del fundador tècnic és també la seva trampa més gran. «Això m'ho puc construir jo» és veritat — fins que deixa de ser-ho.
He vist aquest patró desenes de vegades. Un fundador amb talent d'enginyer de debò construeix l'MVP tot sol. Funciona. Arriben els primers clients. I aleshores comença el problema: el producte ha de créixer, però el fundador continua sent l'únic que pot tocar el codi. El que era un avantatge es converteix en un coll d'ampolla.
Si ets fundador tècnic i llegeixes això pensant «a mi no em passarà», continua llegint. Probablement ja t'està passant.
La progressió que ningú no t'explica
La història sempre comença igual:
- Construeixes l'MVP tu mateix. Té sentit. Ningú no coneix la visió com tu, i contractar abans de tenir producte és arriscat.
- Llances la v1. Apareixen els primers usuaris. Hi ha tracció de debò.
- Arriben els clients que paguen. Perfecte. Però ara tens expectatives de servei, no només un projecte paral·lel.
- La realitat s'imposa. Bugs, peticions de funcionalitats, infraestructura que cau a les tres de la matinada, suport tècnic, reunions amb inversors, i la v2 que hauria d'haver estat llesta ahir.
Arribat aquí, la setmana et queda així: dilluns arregles un bug crític; dimarts intentes avançar una funcionalitat nova però t'interrompen tres vegades amb incidències; dimecres, reunions de producte i de vendes; dijous reprens la funcionalitat però ja no recordes on l'havies deixada; divendres despleges amb presses perquè havies promès alguna cosa per al cap de setmana.
No estàs construint. Estàs apagant focs.
El problema del coll d'ampolla
Quan ets l'únic enginyer, totes les tasques són seqüencials. No pots arreglar un bug i construir una funcionalitat alhora. No pots desplegar i atendre el suport tècnic al mateix temps. Tot passa per tu, i tot espera que acabis el que tenies entre mans.
Afegir un segon enginyer no es limita a duplicar-te la capacitat. Desbloqueja el paral·lelisme. De cop, algú pot mantenir producció dempeus mentre tu fas avançar el producte. Algú pot implementar una integració mentre tu dissenyes l'arquitectura del mòdul següent.
Però hi ha una cosa més subtil que la capacitat: el cost de canviar de context és brutal. Cada vegada que passes de «estic arreglant un bug del backend» a «he de preparar la reunió amb els inversors», perds temps — i no són cinc minuts. Són 20-30 minuts per tornar a entrar en l'estat mental de programació profunda. Si canvies de context sis vegades al dia, perds entre dues i tres hores només en transicions.
Un segon enginyer no et dona només més mans. Et retorna blocs de temps sense interrupcions per pensar.
El problema de qualitat que no veus
Aquest és el que fa més mal, perquè és invisible fins que esclata.
Fins i tot els enginyers excel·lents prenen pitjors decisions quan van sobrecarregats. Quan portes dotze hores programant i has de triar entre «la solució neta que demana quatre hores» i «el pedaç ràpid que es fa en trenta minuts», què tries? El pedaç. Sempre el pedaç. Perquè demà hi ha una altra urgència.
La fatiga porta a les dreceres. Les dreceres porten al deute tècnic. I el deute tècnic es va acumulant fins que cada funcionalitat nova triga el triple del que hauria de trigar.
He vist startups on el fundador s'ho havia construït tot sol durant divuit mesos. El producte funcionava, però el codi de sota era un castell de cartes. Quan finalment van contractar enginyers, els dos primers mesos van anar a entendre i estabilitzar el que hi havia abans de poder-hi afegir res de nou.
Si haguessin incorporat ajuda sis mesos abans, s'haurien estalviat aquells dos mesos — i els sis anteriors haurien estat més productius.
El cost d'oportunitat que no estàs calculant
Cada hora que passes escrivint codi és una hora que no dediques a res més. I en una startup en fase inicial, aquest «res més» pot valer molt més que una funcionalitat.
- Aixecar capital: els inversors volen parlar amb tu, no amb el teu equip. Cada setmana que ajornes una ronda perquè «primer vull acabar aquesta funcionalitat» és una setmana de runway que no tens.
- Vendes: en el B2B inicial, el fundador ÉS el millor comercial. Coneixes el producte, el mal de cap del client i la visió. Ningú no ven el teu producte com tu.
- Aliances: acords estratègics, integracions, canals de distribució. Tot demana temps del fundador.
- Estratègia: pensar a tres mesos vista, no només en l'sprint actual. Definir cap a on va el producte, què cal construir i — encara més important — què NO cal construir.
El teu valor com a fundador no és la capacitat d'escriure codi. És la capacitat de prendre les decisions correctes sobre quin codi ha d'existir. Són dues coses molt diferents.
Quan deixar de programar i començar a liderar
No hi ha una data exacta, però hi ha senyals clars:
- Tens clients que paguen i esperen un nivell de servei que tot sol no pots mantenir.
- Les peticions de funcionalitats van més de pressa que tu. El backlog creix més ràpid del que el pots buidar.
- Els caps de setmana treballes en manteniment, no en innovació. Si els dediques a mantenir dret el que ja existeix en lloc de construir el que ve, necessites ajuda.
- Els bugs triguen dies a resoldre's perquè sempre hi ha alguna cosa més urgent al davant.
- No tens temps per pensar. Si fa més d'un mes de l'última vegada que et vas asseure a reflexionar sobre l'estratègia de producte, estàs massa enfonsat en l'execució.
Si et reconeixes en dos o més d'aquests senyals, ja hauries d'estar contractant.
Com delegar sense perdre el control
La por més habitual del fundador tècnic és aquesta: «ningú no ho construirà com ho faria jo». I té part de raó. Ningú no ho farà exactament com tu. Però això no vol dir que ho facin pitjor — només diferent. I, de vegades, millor.
La clau és com delegues:
- Contracta sèniors, no júniors. Un enginyer júnior necessita supervisió constant — que és precisament el que no tens temps de donar. Un sènior entén el context, pren decisions pel seu compte i et fa preguntes intel·ligents en lloc d'esperar instruccions.
- Defineix l'arquitectura abans de delegar. No cal que documentis cada línia de codi, però sí les decisions estructurals: quin stack, per què, com es comuniquen els serveis, on viuen les dades.
- Documenta les decisions, no el codi. Els ADR (Architecture Decision Records) valen més que els comentaris al codi. Explica el PERQUÈ de les decisions, no el QUÈ.
- Al principi, revisa-ho tot. Les dues primeres setmanes, fes code review de cada pull request. No per microgestionar, sinó per calibrar. Quan entenguis com pensa el teu nou enginyer, podràs afluixar la corda.
- Després, confia-hi. Si has contractat bé, deixa que la persona faci la seva feina. Revisa resultats, no procés.
Comença amb un o dos, no amb cinc
No necessites un equip de deu persones per desfer el coll d'ampolla. Comença amb un o dos enginyers sèniors. Prou perquè deixis de ser el punt únic de fallada del producte.
A Conectia veiem aquest patró constantment. Un fundador tècnic ens arriba dient «necessito un equip de cinc» i, quan analitzem la seva situació real, el que necessita és un enginyer sènior de backend que es faci càrrec de la infraestructura i un fullstack que pugui treure funcionalitats amb autonomia. Amb aquests dos perfils, el fundador recupera 20-30 hores setmanals per dedicar-les al que de debò importa.
Cada enginyer que entra a través de Conectia ha estat validat tècnicament per un CTO. No t'enviem currículums perquè els filtris tu — t'enviem persones que ja han passat el filtre que tu mateix faries si tinguessis temps.
El canvi de mentalitat que et cal
Passar de «jo construeixo» a «jo lidero la construcció» no és fer un pas enrere. És el pas que separa els fundadors que escalen dels que s'encallen.
El teu codi no aixecarà una empresa de deu milions d'euros. La teva capacitat de muntar, dirigir i empoderar un equip que escrigui aquest codi, sí.
Deixa de ser l'enginyer de la teva startup. Comença a ser-ne el fundador.
Ets fundador tècnic i tens la sensació que tot depèn de tu? Parla amb un CTO — t'ajudem a incorporar els enginyers sèniors que et desbloquegen, en setmanes, no en mesos.
