Sono quasi 4 anni che ormai lavoro in startup. Sono convinto che la startup sia un’ottima scelta per uno studente fresco fresco di laurea, perchè sono ambienti molto dinamici: data la loro natura instabile si è “costretti” ad adattarsi, si impara ogni giorno qualcosa di nuovo e quindi è un’ottima opportunità per crescere personalmente insieme all’azienda.

Siccome ora sto cambiando ambiente lavorativo è giunta l’ora di tirare le somme. In questo post racconterò ciò che ho imparato a lavorare nelle startup, nel mio caso wavein.ch e Cloud Academy.

Il tuo capo vuole soluzioni, non problemi

Nelle startup, i propri superiori sono spesso le stesse persone che hanno scritto il codice prima di te, quindi la tentazione di chiedere aiuto a loro è molto alta. Ma ricorda che ora il loro ruolo è cambiato, quindi hanno mille altre faccende per la testa. Infatti contano su di te per portare a termine il compito che ti è stato affidato. Invece di chiedere aiuto, bisogna chiedere a loro che decisione prendere. Il flusso corretto è che loro ti chiedano di fare X, tu analizzi il problema e porti le soluzioni con pro e contro di ognuna, infine il superiore deciderà la soluzione da intraprendere assumendosi la responsabilità. In questo modo tutti sono felici: tu sai perfettamente cosa fare, il superiore ha perso poco tempo e ha ricevuto solo le informazioni che gli interessavano.

Tieni traccia di ciò che stai facendo

La trasparenza nelle startup è fondamentale: tu ovviamente sai benissimo su cosa stai lavorando, quale bug ti sta facendo impazzire… Ma tutto questo non è così scontato per il resto del mondo. Io usavo YouTrack e Jira come issue tracking system, non c’è niente di peggio che avere giornate di fuoco al lavoro ed avere la board vuota. Questo può essere un problema per te che non sei in grado di mostrare agli altri su cosa stai lavorando, ma sopratutto è un problema per il Product Manager che non potrà mai schedulare correttamente i lavori, non avrà nessuna visibilità sui possibili ritardi e infine non può prioritizzare correttamente i lavori. Stesso discorso vale per i task che sono bloccati: metti sempre nero su bianco su cosa stai lavorando.

Ognuno di noi è diverso

Noi abbiamo un carattere, la propria personalità: per questo motivo ci comportiamo spesso con tutti in egual modo. Ma ci dimenticano che anche gli altri sono tutti diversi: c’è chi è più espansivo, chi si offende facilmente, chi è timido, chi si inalbera per il nulla ecc. Non possiamo comportarci allo stesso modo con tutti indiscriminatamente. E peggio ancora non possiamo pretendere che gli altri debbano adattarsi al nostro carattere, non funzionerà mai!

Secondo me è nostro compito tirar fuori il meglio da ognuno facendo leva sulle qualità di ognuno:

• La persona ama aiutare il prossimo: fatti aiutare! Sicuramente può insegnarti sempre qualcosa.

• Si offende facilmente: cerca di non fare battute inutili, mantieni un profilo più professionale / distaccato.

• La persona si infiamma facilmente e odia “non aver ragione”: se hai già in mente la soluzione ad un problema e vuoi solo una conferma, non spiegargli subito il macro problema. Altrimenti ti darà la sua soluzione e non vorrà più discuterne. Invece cerca di spezzettarlo in piccoli problemi dove le soluzioni sono ovvie e sono quelle che hai adottato tu. Infine tutte queste soluzioni porteranno alla tua soluzione definitiva per logica conseguenza.

  Se questa persona comincia a scaldarsi, non cominciare a mimare il suo tono… Altrimenti è solo un crescere di toni che finirà solo male. Non aver paura di interrompere la discussione senza una soluzione se vedi che non sta portando a niente.

• Ama fare battutacce e piace “insultare amichevolmente” gli altri: stai al gioco! Non prenderti troppo sul serio. Molto spesso se ti prendono in giro apertamente è solo perchè vogliono farsi una risata insieme a te. Se non si è abituati è veramente difficile da digerire inizialmente, ma poi non ci si fa più caso e anzi ci si diverte. Alla fine si capisce quando qualcuno lo fa solo per divertirsi oppure perchè prova rancone nei tuoi confronti.

• Una persona non gli vai a genio: la cosa peggiore che si possa fare è fare terra bruciata intorno a lui. Devi passare la quotidianità con lui e quindi non serve a nessuno. Invece cerca di evitare il comportamento che gli dà fastidio se qualcuno te lo dice. Altrimenti cerca di comportarti sempre bene con lui: aiutalo e non stargli troppo attaccato, così piano piano capirà che non dovrebbe avere nulla contro di te. Se non funziona… Beh pace, cerca sempre di non dargli dei buoni motivi per odiarti, è l’unica cosa che si può fare in questi casi.

• È timida: non verrà mai a chiederti aiuto o consiglio. Ogni tanto fatti sentire, così che poi si sblocchi anche lui. In questo modo entrambi potete lavorare.

• È uno scaricabarile: “Scusa, potresti farmi questo? So che tu ci hai lavorato poco tempo fa.”, “Io non so niente di sta roba, puoi farmelo tu che so che ne sai?“. Un conto è aiutare, un’altro è fare il lavoro di altri al posto loro. Anche tu hai i tuoi obiettivi, cerca di rimanere focalizzato sui tuoi.

Insomma questi sono solo dei piccoli esempi e comportarsi in modo diverso con persone diverse non significa essere falsi. È secondo me l’unico modo per poter vivere in modo pacifico con numerose persone nella quotidianità lavorativa.

È lecito dire di No

Il lavoro è come l’acqua: fluisce dove viene fatto. Quindi bisogna stare attenti a dire troppi sì, altrimenti finisce che tutto il lavoro si riversa su di te e poi hai due problemi molto seri: rischi il burnout perchè non hai un attimo di respiro ed in più ti accusano di essere il collo di bottiglia! È importante aiutare gli altri, fare del lavoro extra, ma lo è di più finire i propri task assegnati. Per l’azienda è importante rispettare il proprio piano, se fallisci nel rispettare le tempistiche originarie, tutto ciò avrà ripercussioni sul planning e questo avrà una ripercussione negativa su tutta l’azienda. Più si è in pochi e più le conseguenze sono visibili. Quindi non bisogna avere paura a dire ‘No’ a chi ci chiede di fare altro lavoro in più. Prima fai il tuo poi, se avanza tempo, accetta del lavoro extra. Altri ‘No’ che sono portanti sono quelli dal punto di vista tecnico. Non è raro che vengano calati dall’alto dei task che da un punto di vista tecnico o di usabilità non stanno né in cielo né in terra. In questi casi è nostro dovere dire ‘No’ e dare le proprie motivazioni: è lo sviluppatore che può capire le conseguenze di requirement esotici (debito tecnico, logiche fumose già dall’inizio, eccessiva complessità della UX ecc).

Un fallimento è realmente tale se non si impara nulla

Ora dico una cosa che non fa piacere a nessuno. Tutti falliscono in qualcosa: io ho fatto sbagli e ne farò ancora, è impossibile fare tutto perfetto nella propria carriera lavorativa. Diffida da chi ti dice “Io non ho mai fatto errori / Non ho mai fallito / Sinceramente non mi ricordo di miei errori commessi nel passato”. Ti sta solo prendendo in giro oppure sta mentendo a se stesso, perchè noi, soprattutto italiani, odiamo fallire e soprattutto odiamo ammetterlo.

Ma sbagliare è parte integrante dell’apprendimento. L’esperienza non è altro che un insieme di errori che ti sei portato a casa e che sei pronto a non ripetere. È per questo che chi dice di non aver mai sbagliato sta mentendo, significa che o non ha mai fatto niente oppure non ha mai avuto un compito veramente sfidante.

Prima si riconosce un errore, prima è possibile porvi rimedio. Prima si pone rimedio e meno danni si fanno. Se una strada sta portando ad un niente di fatto, oppure sta diventando più difficile del previsto, fermati… Fai un bel respiro, analizza la situazione e vedi se ne vale la pena continuare. Altrimenti è giunto il momento di chiedere un parere ad un collega e poi annunciare il problema al proprio superiore (possibilmente con qualche soluzione in mano). Poi si fanno le dovute correzioni.

Vedrai che così facendo nessuno può dirti niente, apprezzeranno la tua capacità di prevedere un possibile danno ancora maggiore, si prende nota di cosa è andato storto così da non ripetere lo stesso errore in futuro e si continua felici di aver evitato un possibile disastro.

L’alternativa a tutto questo? Dire a tutti che è tutto ok, andare avanti sulla propria strada, cercare di tirar fuori il meno peggio, prendere tempo per cercare di tenere in piedi una cosa che è morta, prendere ancora tempo, disperarsi, gettare la spugna e dire che stai lavorando su una cavolata, che non può funzionare, incolpando la donna delle pulizie pur di non assumersi la propria responsabilità… Nessuno lo apprezzerà, anzi capiranno che non possono fare affidamento su di te, quindi evita.

Fallire non è bello, ma succede. Quindi se deve succedere fallo il prima possibile.

Chiedere aiuto è un’arma, non una debolezza

Purtroppo per molti chiedere aiuto è quasi una sconfitta personale, altri non lo fanno per non rubare troppo tempo alla persona che si rende disponibile ad aiutare. Ma chiedere una mano a chi ne sa di più su un determinato prodotto, parte di codice, tecnologia è fondamentale:

• Si raggiunge prima l’obiettivo. Chiedere una domanda e ottenere una risposta richiede pochi minuti. Cercare di capire una parte di codice scritta da altri, cercare una risposta online per un caso molto specifico ci si impiega ore.
• Si capisce realmente il funzionamento della piattaforma. Purtroppo nelle startup la documentazione lascia un po’ a desiderare, quindi molto spesso si finisce a leggere direttamente il codice. Alcune parti possono essere oscure da capire semplicemente perchè non è esplicitata la reale motivazione. Non è raro trovare orribili hack in mezzo al codice per risolvere dei casi specifici che solo una persona conosce… E non è detto che quella persona sia ancora in azienda! Se c’è ti consiglio una cosa, vai a chiedere.
• Si evita di scrivere strafalcioni: ho visto persone che pur di non chiedere o capire il funzionamento di una parte di prodotto, “bypassava” completamente quella parte scrivendone un’altra molto simile. Questo è il male, perchè si creando due parti di codice che coesistono, non si capisce bene il perchè e ovviamente rende il codice non manutenibile. Oppure altri che risolvevano un problema solo in superficie perchè “hey, non tocco il codice scritto da altri!“… Anche questo è il male assoluto: in questo modo si può distruggere l’architettura in poche settimane. Piuttosto si chiede a chi ha scritto il codice e poi si risolve.
• Si impara più velocemente! Anche da un punto di vista personale è molto meglio chiedere aiuto: si impara molto più velocemente e sentire come ragionano altri sviluppatori è il miglior modo per migliorare se stessi…
• Anche tu hai bisogno di aiuto… Cosa? Stai pensando che tu sei il migliore e che non hai niente da imparare soprattutto dai tuoi colleghi? Beh, tutti quelli che la pensano così sono quelli che crescono di meno e rimangono indietro, perchè pensano che non hanno più nulla da imparare e rimangono fermi con la loro conoscenza. Letteralmente chiunque può insegnarci qualcosa, anche la persona più junior in azienda, perchè semplicemente ogni persona ha un proprio, unico, background personale.

Il codice perfetto non interessa a nessuno

Ecco qui una lezione che può fare male a chi esce fresco fresco dall’università. Nel mondo accademico la cosa più importante è scrivere il codice perfetto, avere il codice più astratto possibile per avere un codice che si adatta facilmente a qualsiasi caso d’uso. Nessuno guarda il tuo codice fino all’esame finale e quindi si può lavorare in tutta tranquillità. C’è solo un piccolo particolare… Nel mondo universitario si ha un sacco di tempo a disposizione, nelle startup no. La feature che ti è stata richiesta è bloccante per altri sviluppatori, gli stakeholder vogliono la tua parte pronta e deployata ieri. Quindi non viene valutata la bontà del tuo codice, ma la tua execution. La velocità con cui porti a termine il tuo compito.

Quindi come si fa a far coesistere il buon codice con velocità di esecuzione? Tramite iterazioni: scrivi il minimo indispensabile per raggiungere l’obiettivo, non complicare le cose con costrutti strani. Scrivere il minimo indispensabile è ben diverso dallo scrivere un brutto codice: continua a seguire le best practice, mantieni il codice più pulito possibile, continua a valutare che più scorciatoie prendi più bisogna sacrificare la manutenibilità. Ma non fasciarti la testa prima del problema, perchè magari quel problema non arriverà mai… E se mai arrivasse, si itera, ma almeno la tua feature originale è già arrivata sul mercato e può essere validata dal cliente.

Raggiungi i tuoi obiettivi, punto

Altra lezione che ho imparato a mie spese e che l’ho ricevuto come un calcio rotante sulle gengive. Appena entrato a Cloud Academy era tutto un mondo nuovo, avevo voglia di fare ed ero veramente carico. Uno dei primi compiti che mi era stato assegnato era l’automatizzazione della generazione dei file statici lato frontend. Mentre lo stavo facendo ho avuto la brillante idea di fare anche una miglioria extra che purtroppo ora non mi ricordo. Ero andato dal mio superiore per mostrargli i miei progressi: dopo aver detto a che punto ero arrivato, gli spiego anche la mia miglioria e cosa potevamo fare in più grazie ad essa. Mentre spiegavo mi ha interrotto bruscamente con un “Ma a me che ca@@o me ne frega?“… Imbarazzo totale, 5 secondi di silenzio… Tutto quello che sono riuscito a dire è stato un “Ah…“.

Io ero abituato a wavein.ch ad avere molto più margine di manovra, ma semplicemente perchè eravamo più piccoli e io ero quasi capo di me stesso. Quindi tutto quello che facevo bene o male andava nella direzione che reputavo giusta. Ma in una startup si hanno dei task “ben definiti”. Se si hanno dei task assegnati bisogna fare quelli e fare il minimo per raggiungere quell’obiettivo. Tutto il resto non è visto di buon occhio, viene visto come tempo perso. Ricorda che il tempo è la risorsa più scarsa in una startup. Quindi occhio con le funzionalità non richieste, anche se per te possono essere un grande miglioramento, per altri potrebbe non interessare “un ca@@o di niente”.

La startup non è una famiglia

La startup non è una famiglia. Bisogna tenerlo bene in mente. Ci piace la meritocrazia, la vogliamo ovunque, ma dobbiamo anche essere in grado di accettare il rovescio della medaglia.

Ora spiego cosa è per me un rapporto lavorativo, nella versione più meritocratica e cinica possibile: io vengo stipendiato per offrire un determinato servizio all’azienda. Tramite il mio servizio, l’azienda acquista del valore. Se il valore generato dal mio servizio è più alto rispetto al mio stipendio, l’azienda ha tutti gli interessi a mantenermi. Più questo delta è alto più l’azienda “mi vuole bene”, se questo delta è troppo marcato io posso chiedere un aumento e l’azienda dovrebbe riconoscermelo. Se non me lo da, ho tutto il diritto di guardarmi in giro per vedere se qualcun’altro riconosce il mio valore. Se invece il delta è negativo significa che all’azienda non gli conviene più darmi lo stipendio e quindi ha tutto il diritto di lasciarmi a casa. C’è infine un’ultima opzione: l’azienda non ha più fondi, quindi comincia a licenziare le persone che hanno un delta meno marcato, ossia sono quelli che generano meno valore all’azienda.

Usando questa versione pulita pulita, meritocratica, cinica quanto vuoi, non si può rimanere “scottati” da un possibile licenziamento. Son cose puramente logiche e razionali.

Però noi non siamo delle macchine e quindi ci sono un sacco di altre variabili in gioco che possono colpire a fondo la sensibilità delle persone: va bene tutta sta storia del delta, ma è meglio licenziare una persona giovane senza figli a carico oppure licenziare una persona con famiglia e 3 figli anche se mi genera meno valore all’azienda? Meglio continuare a lavorare per l’azienda in cui lavoro anche se mi pagano poco, dove mi sono fatto un sacco di amici e mi ci trovo bene oppure cambio lavoro e vado dove mi pagano di più?

Ho conosciuto persone che hanno vissuto malissimo il licenziamento perchè si sentivano “traditi” dall’azienda. Ma secondo me c’è poco da arrabbiarsi: a nessuno piace licenziare persone, la scelta su chi poi bisogna licenziare penso sia una cosa che angoscerebbe chiunque.

Io ho vissuto sulla mia pelle cosa vuol dire essere licenziati dall’oggi al domani. Ciononostante sono rimasto in ottimi rapporti con chi mi ha licenziato perchè, essendo in una startup, sapevo benissimo che i soldi non crescono sugli alberi: ho capito le reali motivazioni e quindi sono riuscito efficacemente a dividere il rapporto lavorativo dall’amicizia. Sono due cose che insieme coesistono, ma non sono certo la stessa cosa.

Con questo non sto dicendo che non si possono fare amici al lavoro. Anzi al lavoro si conoscono persone stupende e nascono delle amicizie che vanno avanti anni anche fuori dal lavoro. Sto solo dicendo che io non ho un posto di lavoro perché sono amico di qualcuno, ma perché sto generando valore all’azienda ed essa è in grado di riconoscermi questo valore generato. Se si tiene in mente questo aspetto secondo me è più facile accettare un licenziamento.

Non esasperare l’ambiente lavorativo

“Possibile Natali che tu non ti arrabbi mai?“. In realtà mi arrabbio anche io, ma semplicemente cerco di non mostrarlo. Passiamo una buona parte della giornata al lavoro e quindi è importante che manteniamo l’ambiente il più calmo possibile, anche se l’incazzatura è sempre dietro l’angolo. In questi anni ho imparato fondamentalmente queste due cose:

• Arrabbiarsi è inutile. Purtroppo capita di vedere persone che pretendono di aver ragione solamente urlando o mostrandosi visibilmente irritati. La cosa importante è mantenere comunque la calma, attendere qualche secondo prima di rispondere e, se proprio la situazione non si calma, è meglio concludere la conversazione e rinviarla quando i toni sono più calmi… Anche perchè il problema non si risolve in queste situazioni.
• Con la forza non si ottiene niente: nessuno ti farà un favore/task sotto costrizione, bisogna motivare le persone, non obbligarle. Ho avuto la fortuna di vedere tre tipologie di leadership: chi ti costringe, chi ti “minaccia” e chi invece ti motiva a farle. I risultati migliori ovviamente di ottengono con l’ultima. Esasperare l’ambiente lavorativo per ottenere qualcosa non è mai una soluzione, magari può funzionare nel breve termine, ma nel lungo periodo può solo far nascere un problema ben più grave: far schizzare il turnover alle stelle. Il problema è che costringere o minacciare una persona è semplice, motivare non lo è affatto. Ed è per questo che è importante scegliere bene i vari leader in azienda… Non tutti sono in grado di farlo.

La formazione personale è fondamentale

Pensavi che una volta finito gli studi potessi dire addio allo studio? Beh, nell’informatica è solo l’inizio! L’IT è una continua evoluzione, se si rimane fermi anche solo due anni si è tagliati automaticamente fuori. Per molti questa è una condanna, ma per me è la parte più interessante del lavoro. Non si smette mai di imparare e si può vedere in modo tangibile una continua evoluzione nel proprio lavoro e in noi stessi… Il lavoro ripetitivo alla fine annoia! Per formarsi c’è solo l’imbarazzo della scelta: dalle piattaforme e-learning, piccoli progetti, ai meetup organizzati da gente appassionata che veramente ci mette l’anima in ciò che fa.

Conclusioni

Spero che questo post possa essere d’aiuto a chi ha paura di iniziare una carriera lavorativa, specialmente in una startup. È sicuramente una buona palestra per apprendere velocemente, ma sono certo che può un po’ spaventare a chi non ci ha mai lavorato.

Se siete giovani non vi posso consigliare altro che lavorare in questi ambienti: ci si diverte, si conoscono persone veramente stupende che condividono la tua stessa passione e non ci si annoia mai!

Alla prossima!