Quan escalar l'equip tècnic: 7 senyals clars i 3 antipatrons
"Hire slow, fire fast" és un bon consell — fins que es converteix en una excusa per invertir poc en enginyeria mentre la competència treu features més de pressa que tu.
He vist startups morir lentament perquè el seu equip tècnic no donava l'abast. No és que construïssin malament: és que no construïen prou. El producte s'estanca, els clients es frustren i la competència agafa avantatge. I quan per fi es decideixen a contractar, ja han perdut una finestra de mercat de 6 mesos.
També he vist el cas contrari: startups que contracten 8 enginyers abans de trobar el product-market fit i es cremen el runway pagant sous a un equip que no sap què construir.
Encertar el moment és clau. Aquests són els senyals que indiquen que ha arribat l'hora d'escalar — i els errors que has d'evitar.
7 senyals que necessites escalar el teu equip tècnic
1. El backlog de features creix més ràpid del que el pots reduir
Si sprint rere sprint el backlog es fa més llarg en lloc de més curt, tens un problema de capacitat. No de planificació, no de priorització: de capacitat pura.
Un backlog que creix vol dir que generes més idees validades de les que pots executar. En una startup que ja té product-market fit, això és exactament el que ha de passar. Però si no hi respons amb més capacitat d'execució, estàs deixant escapar oportunitats.
La pregunta clau: quantes features validades pel negoci fa més de 2 mesos que esperen? Si són més de 3, necessites més enginyers.
2. El lead time dels canvis supera les 2 setmanes
Des que algú diu "necessitem això" fins que és a producció. Si aquest cicle supera les 2 setmanes per a canvis de mida mitjana, el teu equip està al límit.
Un lead time llarg no sempre és evident. Es normalitza. "És que això és complex" es converteix en la resposta per defecte. Però si fa un any el mateix tipus de canvi trigava 4 dies i ara en triga 12, el software no s'ha tornat més complex: és el teu equip, que s'ha quedat sense marge.
3. Els teus millors enginyers fan manteniment en comptes de construir
Aquest és un dels senyals més cars. Tens un enginyer senior — algú capaç de dissenyar arquitectura, prendre decisions tècniques crítiques i fer de mentor de l'equip — que dedica el 60% del temps a arreglar bugs, atendre incidències i mantenir sistemes legacy.
Cada hora que un senior dedica al manteniment és una hora que no dedica a construir avantatge competitiu. Si els teus seniors passen més temps apagant focs que creant valor, necessites més gent que absorbeixi la càrrega operativa.
4. Els compromisos amb clients s'incompleixen un cop i un altre
Vas dir al teu client enterprise que la integració estaria llesta al març. Després, a l'abril. Ara ja parles del maig. Cada retard erosiona la confiança.
Si els compromisos tècnics s'incompleixen sistemàticament, no és un problema d'estimació: és un problema de capacitat. El teu equip fa malabarismes amb massa prioritats alhora i cap no avança a la velocitat promesa.
5. Hi ha punts únics de fallada a l'equip
Només una persona sap com funciona el sistema de pagaments. Només una persona pot tocar la infraestructura. Només una persona entén el pipeline de dades.
Això és perillós per dos motius. L'obvi: si aquesta persona marxa, tens un problema seriós. El menys obvi: aquesta persona es converteix en un coll d'ampolla. Cada canvi que toca "el seu" sistema ha de passar per les seves mans, i la seva capacitat és finita.
Si tens més de 2 components crítics que depenen d'una sola persona, necessites redundància. I redundància vol dir més enginyers.
6. El deute tècnic s'acumula sense control
"Ja ho arreglarem més endavant" és una frase vàlida quan la dius un cop. Quan fa 6 mesos que la repeteixes, el deute tècnic s'ha multiplicat: els deploys són més lents, els bugs més freqüents, els canvis més arriscats.
El deute tècnic no es resol sol. I no el pots pagar si l'equip està al 100% de capacitat construint features. Necessites marge — i el marge surt de tenir més gent.
7. Has rebutjat un contracte per falta de capacitat d'enginyeria
Aquest és el senyal més clar de tots. Un client potencial volia una cosa que tècnicament podies construir, però no tenies capacitat per lliurar-la dins el termini exigit. Vas dir que no a ingressos reals.
Els ingressos que perds per falta de capacitat d'enginyeria són el senyal més car que necessites escalar. Cada oportunitat rebutjada arrossega un cost d'oportunitat que va molt més enllà del contracte en si.
3 antipatrons a evitar a l'hora d'escalar
Saber que necessites escalar és només la meitat de la feina. L'altra meitat és fer-ho sense destrossar el que ja funciona.
Antipatró 1: Contractar juniors per estalviar diners
La lògica sembla raonable: un junior costa la meitat que un senior, així que en contracto dos i tinc el doble de capacitat. Doncs no: no funciona així.
Un enginyer junior necessita mentoria constant. Necessita algú que li revisi el codi, li resolgui els dubtes d'arquitectura i li ensenyi les convencions del projecte. Qui ho fa? Els teus seniors. Els mateixos que ja van sobrecarregats.
El resultat net dels primers 3-4 mesos és capacitat negativa: l'equip produeix menys perquè els seniors dediquen el temps a formar en lloc de construir. Amb el temps, el junior esdevé productiu, però si necessites capacitat ara, el que toca és contractar un senior.
Antipatró 2: Contractar abans de tenir product-market fit
Si encara estàs iterant sobre què construir, un equip gran és un llast. Cada pivot vol dir més gent canviant de direcció. Més codi per llençar. Més frustració acumulada.
Abans del product-market fit necessites un equip petit i àgil que pugui iterar de pressa. 2-3 enginyers senior autònoms són més efectius que 8 enginyers que necessiten coordinació constant.
Escala quan sàpigues què construir. No abans.
Antipatró 3: Escalar-ho tot de cop
Passar de 3 a 10 enginyers en un sol mes és el caos garantit. Els processos que funcionaven amb 3 persones es trenquen amb 10. La comunicació informal desapareix. Ningú no sap qui treballa en què. Les code reviews s'amunteguen. L'onboarding queda a mitges perquè no hi ha temps de fer-lo bé.
Escala en passos de 2-3 persones. Afegeix, integra, estabilitza, repeteix. Sobre el paper és més lent; a la pràctica és més ràpid, perquè t'estalvies els mesos de caos que segueixen tota onada de contractacions.
El ritme adequat per escalar
El patró que millor funciona, en la meva experiència:
- Afegeix 1-2 enginyers. Preferiblement seniors, perquè siguin autònoms de seguida.
- Integra'ls durant 4-6 setmanes. Que aprenguin el codebase, els processos, l'equip. Que facin el seu primer deploy significatiu.
- Avalua. Ha augmentat la velocitat de lliurament? La qualitat aguanta? La comunicació continua funcionant?
- Repeteix. Si la resposta és que sí a tot, afegeix-ne 1-2 més.
Aquest ritme et permet passar de 3 a 10 enginyers en 6-8 mesos sense perdre productivitat pel camí. Sembla lent, però és exponencialment més segur que el big bang.
Escalar ràpid sense caos
El problema del ritme gradual és que de vegades no tens 6 mesos. Tens un contracte gran, una finestra de mercat o un competidor que t'escurça distàncies.
És exactament per a això que existeix el model de staff augmentation. En lloc d'un procés de contractació de 3-6 mesos — publicar l'oferta, filtrar currículums, fer 4 rondes d'entrevistes, negociar, esperar que acabi el preavís — pots integrar enginyers senior ja validats en qüestió de dies.
A Conectia, cada enginyer passa una validació tècnica dirigida per un CTO abans d'estar disponible. No reps currículums per avaluar: reps enginyers que ja han estat validats en les competències que necessites.
El Pilot Sprint de 14 dies et permet provar abans de comprometre't. Integres l'enginyer, feu dos sprints plegats i, si l'encaix funciona, endavant. Si no, no hi ha cap compromís a llarg termini.
Això transforma l'escalat: deixa de ser una decisió d'alt risc a llarg termini i passa a ser-ne una de reversible i de baix risc. Exactament el que necessita una startup que ha d'anar de pressa — però que no es pot permetre errors cars.
Reconeixes algun d'aquests 7 senyals al teu equip? Parla amb un CTO — responem en 72 hores amb enginyers senior ja validats, i el Pilot Sprint de 14 dies et permet comprovar l'encaix abans de cap compromís a llarg termini.
