Costruire i team sulla carta. Credo fermamente che questo errore sia incredibilmente controintuitivo. Spiegarlo nei momenti di formazione è sempre una sfida, poiché solitamente viene compreso solo dopo averlo sperimentato in prima persona, non prima.
Creare team per ogni iniziativa non funziona mai
C’è una ragione per cui una startup viene inizialmente gestita dai fondatori con un numero molto limitato di persone. Nei primi giorni, devono capire tutto, cambiare rapidamente direzione, crescere, affinare i processi, ecc. Proprio come nell’evoluzione, i cambiamenti avvengono spesso lentamente a livello microscopico prima di accelerare esponenzialmente in strutture complesse.
Nelle organizzazioni in fase di scaleup, tuttavia, c’è una cattiva abitudine di creare team completamente funzionali per ogni nuova iniziativa fin dal primo giorno, spesso con persone che non hanno mai lavorato insieme o, peggio, sono nuovi assunti.
Nella mia esperienza, questo approccio NON funziona MAI. Invece, assumerei le prime due persone, permettendo loro di amalgamarsi, iniziare a prototipare o partire in piccolo, sostituire chi non funziona e poi aggiungere gradualmente nuovi membri al team. Vediamo alcuni esempi:
Esempio 1: perché assumere tre persone se non hai certezze?
Supponiamo che tu decida di aggiungere una nuova fonte di lead sfruttando eventi e fiere, pianificando di partecipare a 30 fiere in tre anni. Pianificare 10 eventi ogni anno è un errore. Invece, dovremmo considerare una “scala di avvio”.
Il responsabile degli eventi potrebbe gestire 4 eventi nel primo anno da solo, poi assumere qualcuno per aiutare nel secondo anno con 10 eventi, e infine costruire un team completamente funzionale nel terzo anno per gestire più eventi.
Perché assumere tre persone dal primo giorno quando non hai abbastanza volume, una metodologia o la certezza che il progetto-eventi avrà successo?
Esempio 2: come affrontare lo sviluppo di un’innovazione
Un altro esempio riguarda l’innovazione. Supponiamo che tu abbia un’idea per un nuovo modulo che mira a un mercato adiacente e richiede conoscenze che la tua azienda non possiede.
L’errore sarebbe assumere un team di 7 persone (PM, Frontend, Backend, Full Stack, QA, UX/UI, Product Marketing) dal primo giorno e iniziare a sviluppare.
Io lo affronterei diversamente: darei al nuovo PM (l’unico assunto) il compito di socializzare con gli stakeholder interni, parlare con i clienti, allocare alcune ore disponibili di UX/UI da un altro team per iniziare a costruire wireframe e mockup per i test, poi assumere un sviluppatore full-stack per costruire un MVP, e gradualmente inserire il resto del team.
C’è poca attenzione quando si costruisce un team da zero
Le aziende sono molto attente quando analizzano i rischi delle operazioni di acquisizione di team (acqui-hire), ma non lo sono quando costruiscono team da zero. Paradossalmente, un’acquisizione porta un team che ha già dimostrato di funzionare bene insieme; quando si costruisce un team completamente funzionale in un giorno, non si ha questa garanzia.
IMHO, creare (e annunciare) che stai costruendo un team da zero per sviluppare la prossima Tecnologia-All’Avanguardia è ottimo per le PR ma non per il business.
