La Trampa del 'Ho Construeixo Jo': Per Que els Fundadors Tecnics Tambe Necessiten Equip
El superpoder del fundador tecnic es tambe la seva trampa mes gran. "Puc construir aixo jo mateix" es veritat — fins que deixa de ser-ho.
He vist aquest patro desenes de vegades. Un fundador amb talent real per a l'enginyeria construeix l'MVP sol. Funciona. Arriben els primers clients. I llavors comenca el problema: el producte necessita creixer, pero el fundador segueix sent l'unic que pot tocar el codi. El que va comencar com un avantatge es converteix en un coll d'ampolla.
Si ets fundador tecnic i estas llegint aixo pensant "a mi no em passara" — segueix llegint. Probablement ja t'esta passant.
La progressio que ningu t'explica
La historia sempre comenca igual:
- Construeixes l'MVP tu sol. Te sentit. Ningu coneix la visio com tu, i contractar quan no tens producte es arriscat.
- Llances la v1. Els primers usuaris arriben. Hi ha traccio real.
- Comencen els clients de pagament. Genial. Pero ara tens expectatives de servei, no nomes un side project.
- La realitat et colpeja. Bugs, feature requests, infraestructura que cau a les 3 de la matinada, suport tecnic, reunions amb inversors, i la versio 2 que hauria d'estar llesta per ahir.
En aquest punt, la teva setmana es veu aixi: dilluns arregles un bug critic, dimarts intentes avancar en una feature nova pero t'interrompen tres vegades amb incidencies, dimecres tens reunions de producte i vendes, dijous reprens la feature pero ja no recordes on la vas deixar, divendres fas deploy amb presses perque vas prometre alguna cosa per al cap de setmana.
No estas construint. Estas apagant focs.
El problema del coll d'ampolla
Quan ets l'unic enginyer, cada tasca es seqüencial. No pots arreglar un bug i construir una feature al mateix temps. No pots fer deploy i atendre suport tecnic simultaneament. Tot passa per tu, i tot espera que tu acabis l'anterior.
Afegir un segon enginyer no simplement duplica la teva capacitat. Desbloqueja el paral·lelisme. De sobte, algu pot mantenir produccio mentre tu avances en producte. Algu pot implementar una integracio mentre tu dissenyes l'arquitectura del seguent modul.
Pero hi ha alguna cosa mes subtil que la capacitat: el cost del context switching es brutal. Cada cop que canvies de "estic arreglant un bug al backend" a "he de preparar la reunio amb l'inversor" perds temps — i no son cinc minuts. Son 20-30 minuts per tornar a entrar en l'estat mental de programacio profunda. Si canvies de context sis cops al dia, perds dues o tres hores nomes en transicions.
Un segon enginyer no nomes et dona mes mans. Et retorna blocs de temps continu per pensar.
El problema de qualitat que no veus
Aquest es el que mes mal fa, perque es invisible fins que explota.
Fins i tot enginyers excel·lents prenen pitjors decisions quan estan sobrecarregats. Quan portes 12 hores programant i has de triar entre "la solucio neta que porta 4 hores" i "el pedac rapid que porta 30 minuts", quina tries? El pedac. Sempre el pedac. Perque dema tens una altra cosa urgent.
El cansament porta a dreceres. Les dreceres porten a deute tecnic. El deute tecnic s'acumula fins que cada feature nova tarda el triple del que hauria.
He vist startups on el fundador ho va construir tot sol durant 18 mesos. El producte funcionava, pero el codi per sota era un castell de cartes. Quan finalment van contractar enginyers, els primers dos mesos se'n van anar en entendre i estabilitzar l'existent abans de poder afegir res de nou.
Si haguessin incorporat ajuda sis mesos abans, haurien estalviat aquells dos mesos — i els sis anteriors haurien estat mes productius.
El cost d'oportunitat que no calcules
Cada hora que passes escrivint codi es una hora que no passes fent altres coses. I en una startup primerenca, aquestes "altres coses" poden valer molt mes que una feature.
- Fundraising: els inversors volen parlar amb tu, no amb el teu equip. Cada setmana que posposes una ronda perque "primer vull acabar aquesta feature" es una setmana de runway que no tens.
- Vendes: en B2B early-stage, el fundador ES el millor venedor. Coneix el producte, el dolor del client i la visio. Ningu ven el teu producte com tu.
- Partnerships: aliances estrategiques, integracions, acords de distribucio. Tot requereix temps del fundador.
- Estrategia: pensar a tres mesos vista, no nomes a l'sprint actual. Definir cap a on va el producte, que construir i — mes important — que NO construir.
El teu valor com a fundador no es la teva capacitat d'escriure codi. Es la teva capacitat de prendre les decisions correctes sobre quin codi hauria d'existir. Son dues coses molt diferents.
Quan deixar de programar i comencar a liderar
No hi ha una data exacta, pero hi ha senyals clars:
- Tens clients que paguen i esperen un nivell de servei que no pots mantenir sol.
- Les feature requests superen la teva capacitat. El teu backlog creix mes rapid del que tu pots reduir-lo.
- Treballes caps de setmana en manteniment, no en innovacio. Si el teu cap de setmana se'n va en mantenir l'existent en lloc de construir el nou, necessites ajuda.
- Els bugs triguen dies a resoldre's perque sempre hi ha alguna cosa mes urgent al davant.
- No tens temps per pensar. Si l'ultima vegada que et vas asseure a reflexionar sobre estrategia de producte va ser fa mes d'un mes, estas massa ficat en l'execucio.
Si et reconeixes en dues o mes d'aquestes senyals, ja hauries d'estar contractant.
Com delegar sense perdre el control
La por mes comuna del fundador tecnic es: "ningu construira aixo com jo ho faria". I te part de rao. Ningu ho fara exactament com tu. Pero aixo no vol dir que ho faran pitjor — nomes diferent. I de vegades, millor.
La clau esta en com delegues:
- Contracta senior, no junior. Un enginyer junior necessita supervisio constant — que es exactament el que no tens temps de donar. Un senior enten context, pren decisions per si mateix i et fa preguntes intel·ligents en lloc d'esperar instruccions.
- Defineix l'arquitectura abans de delegar. No necessites documentar cada linia de codi, pero si les decisions estructurals: quin stack, per que, com es comuniquen els serveis, on viuen les dades.
- Documenta les decisions, no el codi. Els ADRs (Architecture Decision Records) son mes valuosos que els comentaris al codi. Explica el PER QUE de les decisions, no el QUE.
- Revisa tot al principi. Les primeres dues setmanes, fes code review de cada pull request. No per microgestionar, sino per calibrar. Un cop entenguis com pensa el teu nou enginyer, pots afluixar corda.
- Despres, confia. Si vas contractar be, deixa que la persona faci la seva feina. Revisa resultats, no proces.
Comenca amb un o dos, no amb cinc
No necessites un equip de deu persones per desbloquejar el teu coll d'ampolla. Comenca amb un o dos enginyers senior. Suficient perque puguis deixar de ser l'unic punt de fallada del producte.
A Conectia veiem aquest patro constantment. Un fundador tecnic arriba dient "necessito un equip de cinc" i quan analitzem la seva situacio real, el que necessita es un senior backend engineer que es faci carrec de la infraestructura i un fullstack que pugui executar features de forma autonoma. Amb aquests dos perfils, el fundador recupera 20-30 hores setmanals per dedicar al que realment importa.
Cada enginyer que entra a traves de Conectia ha estat validat tecnicament per un CTO. No t'enviem CVs perque tu facis el filtre — t'enviem persones que ja han passat el filtre que tu faries si tinguessis temps de fer-lo.
El canvi de mentalitat que necessites
Passar de "jo construeixo" a "jo lidero la construccio" no es un pas enrere. Es el pas que separa els fundadors que escalen dels que s'estanquen.
El teu codi no construira una empresa de 10 milions d'euros. La teva capacitat de reunir, dirigir i empoderar un equip que construeixi aquest codi — si.
Deixa de ser l'enginyer de la teva startup. Comenca a ser el fundador.
Ets fundador tecnic i sents que tot depen de tu? Parla amb un CTO — t'ajudem a incorporar els enginyers senior que et desbloquegen, en setmanes, no en mesos.
