Quando lasciare un team che non ti rispetta come non-CS developer

Background di partenza

Questo è uno degli argomenti più delicati della serie - e uno dei più necessari. La maggior parte dei contenuti sulla transizione tech si concentra sul come entrare nel mercato: studiare, costruire il portfolio, passare il colloquio. Molto meno si parla di cosa succede una volta dentro, quando il team in cui si entra non funziona.

I pattern che seguono sono documentati da community pubbliche - Hacker News, Reddit r/cscareerquestions, DEV.to - e dalle testimonianze anonimizzate che emergono in questi contesti. Sono pattern terzi, non esperienze personali: l'articolo è strutturato deliberatamente su casi aggregati da fonti pubbliche per evitare riferimenti a situazioni specifiche non verificabili.

Il fil rouge che collega i pattern documentati: il problema non è sempre l'azienda, non è sempre il manager, non è sempre la cultura. A volte è il team specifico - la combinazione di persone e dinamiche che produce un ambiente dove un developer non-CS non può crescere, indipendentemente dalla qualità dell'azienda che lo circonda. Questa distinzione - tra problema dell'azienda e problema del team - cambia radicalmente la strategia di risposta.

Perché i developer non-CS sono esposti in modo specifico

I developer non-CS hanno una vulnerabilità specifica: il loro background è visibile. Non si può nascondere di essere ex-giuristi, ex-economisti, ex-filosofi nella stessa misura in cui si può non menzionare di aver studiato informatica. Questo rende i developer non-CS bersagli più facili per certe forme di bias professionale - non necessariamente intenzionale o malizioso, ma sistematico.

Nel thread HN "Ask HN: How did you know it was time to leave your job?" (2021, oltre 500 commenti), una categoria ricorrente di risposte coinvolge proprio i developer provenienti da background non-tradizionali: la sensazione di essere permanentemente a un passo indietro nella valutazione del team, indipendentemente dalla qualità del lavoro prodotto.

Difficoltà tipiche

Prima di arrivare alla decisione di uscire, si attraversa tipicamente un periodo di difficoltà interpretativa: è il team che non funziona, o sono io che non mi sono ancora integrato?

Il problema dell'attribuzione

La difficoltà di attribuire correttamente un problema di team è una delle sfide cognitive più importanti della carriera tech. I segnali di un team problematico e i segnali di una fase di integrazione difficile si assomigliano nelle prime settimane. La differenza si vede solo nel tempo: la fase di integrazione migliora progressivamente; il team problematico no.

Il costo dell'uscita troppo precoce e troppo tardiva

Uscire troppo presto - prima di aver dato al team tempo sufficiente per valutarlo correttamente - produce un record di lavori brevi che può essere difficile da spiegare nei colloqui futuri. Uscire troppo tardi - dopo aver subito mesi di dinamiche disfunzionali - produce burnout, demoralizzazione, e spesso una percezione di sé come developer competente che è difficile da recuperare.

La difficoltà di comunicare il problema

I team problematici per developer non-CS raramente hanno un problema articolato in modo esplicito. Non è che qualcuno dica apertamente "non sei abbastanza tecnico". È che le opportunità di contributo più visibili vanno sistematicamente ad altri. È che le tue proposte tecnici vengono considerate solo dopo che le ha riproposto qualcun altro. È che vieni incluso nelle riunioni operative ma escluso informalmente dalle decisioni architetturali.

Questi pattern sono difficili da articolare e ancora più difficili da documentare. Il rischio è di sembrare paranoici - e di dubitare del proprio giudizio - quando invece si sta riconoscendo un pattern reale.

Cosa ha funzionato (framework di valutazione documentato da community pubbliche)

I pattern che seguono emergono dall'analisi qualitativa delle community citate nelle fonti - non come regole universali, ma come strumenti di riconoscimento per chi sta cercando di capire se il proprio team è un problema temporaneo o strutturale.

1. Il test del "dove sono tra 12 mesi"

Il primo strumento di valutazione documentato nel thread HN 2021: immagina di restare nel team per altri 12 mesi. Descrivi concretamente dove sarai in termini di: competenze tecniche acquisite, reputazione professionale nel team, opportunità di contributo, e retribuzione. Se la risposta onesta è "probabilmente nel posto esatto dove sono adesso", è un segnale che il team non offre un percorso di crescita.

Questa domanda è più utile della domanda generica "mi piace questo lavoro?" perché è concreta e proiettiva - non valuta la soddisfazione del momento ma la traiettoria.

2. Il pattern delle opportunità di visibilità

Chi ottiene le opportunità di lavoro più visibili nel team? Come vengono distribuite? Se il pattern sistematico è che i developer CS senior ottengono le feature più interessanti, i developer junior CS ottengono i bug secondari, e i developer non-CS ottengono il lavoro di manutenzione e documentazione - indipendentemente dalla qualità del loro lavoro - è un segnale di un problema strutturale di distribuzione delle opportunità.

Questo pattern è documentato in modo ricorrente nel thread Reddit r/cscareerquestions sui team tossici: il problema non è che non ci sia lavoro interessante, ma che non viene distribuito in modo equo. I developer non-CS vengono sistematicamente esclusi dalla distribuzione delle opportunità migliori.

3. Il "background discount" sistematico

Un segnale specifico per i developer non-CS: il "background discount" - la tendenza sistematica dei colleghi o del manager a interpellare i developer CS prima dei developer non-CS su questioni tecniche, anche quando il developer non-CS è il più competente sull'argomento. Jason McDonald su DEV.to (2019) documenta questo pattern come uno dei 10 segnali di un ambiente non developer-friendly.

Il background discount è diverso dalla normale gerarchia seniority: non è che i senior vengano interpellati prima dei junior (normale), ma che i developer CS vengano interpellati prima dei developer non-CS indipendentemente dall'expertise specifica. È un bias di forma, non di sostanza.

4. Il test del feedback di qualità

I team che rispettano i developer non-CS forniscono feedback tecnico di qualità: code review che spiegano il perché delle scelte, non solo il cosa correggere; discussioni architetturali in cui il contributo del developer non-CS viene considerato; feedback sui 1-1 che è specifico e azionabile, non generico.

I team che non rispettano i developer non-CS forniscono feedback di qualità inferiore: code review superficiali o assenti, esclusione informale dalle discussioni tecniche importanti, feedback generici nei 1-1 ("stai andando bene, continua così"). Il feedback superficiale è un disinvestimento nella crescita - indica che il team non sta puntando sul developer non-CS come figura che si svilupperà nel tempo.

5. Il segnale del "impara da soli"

Nei team che funzionano, il onboarding e la crescita professionale sono processi attivi - il team investe tempo nel trasferimento di conoscenza. Nei team che non funzionano per developer non-CS, il messaggio implicito spesso è "impara da soli": documentazione assente, reluctanza nel pair programming, risposte brevi alle domande tecniche.

Questo pattern è particolarmente dannoso per i developer non-CS nei primissimi mesi di un ruolo: è il periodo in cui si ha più bisogno di supporto per compensare il gap di formazione CS, ed è il periodo in cui la mancanza di supporto ha l'impatto più forte sulla crescita.

La conversazione che molti evitano: il confronto diretto con il manager

Prima di arrivare alla decisione di uscire, esiste uno step intermedio che molti developer non-CS saltano - o che rimandano troppo a lungo: la conversazione diretta e onesta con il manager sul proprio percorso di crescita e sul proprio posizionamento nel team.

Perché questa conversazione è difficile per i developer non-CS

I developer non-CS tendono a posticipare questa conversazione più dei loro colleghi CS - per diverse ragioni documentate nelle community. La prima: la sensazione di "non avere abbastanza autorità" per fare richieste esplicite di feedback o di crescita. La seconda: la paura che sollevare la questione del proprio background in modo esplicito renda il problema ancora più visibile. La terza: l'incertezza su come formulare la richiesta senza sembrare aggressivi o instabili.

Tutte e tre queste ragioni sono comprensibili - ma producono un ritardo nella raccolta di informazioni essenziali. La conversazione con il manager è il modo più diretto per ottenere due tipi di dati preziosi: (1) come viene percepito il proprio lavoro e il proprio potenziale, e (2) se esiste un piano concreto per la crescita del profilo nel team.

Come strutturare la conversazione

Una struttura documentata tra le testimonianze di community: formulare la richiesta come una conversazione di allineamento, non come una lamentela. "Voglio capire come posso crescere meglio in questo team" è diverso da "sento che non mi viene dato spazio". La prima apre uno spazio di collaborazione - il manager può rispondere con un piano concreto. La seconda chiude la conversazione su un piano difensivo.

Le domande concrete da portare in questa conversazione: Qual è la cosa su cui dovrei concentrarmi per avere più impatto nei prossimi 3 mesi? Quali opportunità di contribuzione più visibile esistono che potrei cogliere? Come viene valutato il contributo del mio background non-CS nel team attuale?

Interpretare la risposta

La risposta a queste domande è già un dato. Un manager che risponde con un piano concreto - nomi di progetto, timeline, criteri di valutazione - sta dimostrando investimento nel profilo. Un manager che risponde con genericità ("stai andando bene, continua così", "ci sono opportunità in arrivo") senza concretezza sta fornendo un segnale che il team non ha un piano per lo sviluppo del profilo.

Il segnale più negativo: un manager che non sa rispondere alle domande sulla crescita del profilo. Non perché stia nascondendo qualcosa - ma perché il profilo non è abbastanza nel radar del team da aver generato una riflessione sulla sua traiettoria. Questo è un segnale strutturale che va preso sul serio.

Il periodo di osservazione post-conversazione

Dopo la conversazione, è utile stabilire un periodo di osservazione - tipicamente 4-8 settimane - in cui si valuta se le cose concrete cambiano. Non le parole - le cose. Se il manager ha detto "ti coinvolgo nel prossimo progetto X" e il progetto X è iniziato senza coinvolgimento, il segnale è chiaro. Se il manager ha detto "cerchiamo di darti più visibilità" e dopo 8 settimane la distribuzione delle opportunità è invariata, il segnale è chiaro.

La distinzione tra intenzione e comportamento è critica in questa fase: quasi tutti i manager hanno buone intenzioni. Non tutti hanno la capacità organizzativa o la volontà di modificare le dinamiche esistenti di un team. Le intenzioni non producono carriere - i comportamenti sì.

Quando la conversazione rivela che non c'è spazio per crescere

Se la conversazione - e il periodo di osservazione post-conversazione - rivela che nel team corrente non c'è spazio per la crescita del profilo non-CS, la decisione di uscita diventa più semplice da prendere. Non perché il team sia necessariamente "cattivo" - ma perché il fit tra ciò che il team può offrire e ciò che il developer non-CS ha bisogno per crescere non è sufficiente.

Questa valutazione è diversa dalla reazione emotiva a un episodio specifico. È il risultato di dati raccolti in modo deliberato su un periodo di tempo sufficiente. La differenza tra queste due modalità di prendere la decisione è enorme: la reazione emotiva porta a dimissioni in momenti di picco che spesso si rimpiangono; la valutazione deliberata porta a dimissioni pianificate con un'offerta in mano e una narrativa chiara del "perché" da raccontare nei colloqui successivi.

Framework cognitivo

Il framework per prendere la decisione di rimanere o uscire si articola in 3 passi.

Passo 1: Distinguere problemi temporanei da strutturali

Un problema temporaneo ha una causa identificabile e una soluzione probabile nell'orizzonte di 2-3 mesi. Un problema strutturale non ha causa identificabile in termini di eventi specifici, e non migliora nonostante sforzi espliciti di miglioramento.

Test pratico: hai avuto conversazioni esplicite con il manager o con colleghi fidati sul problema che percepisci? Se sì, la conversazione ha prodotto cambiamenti concreti? Se no, il problema è probabilmente strutturale - le conversazioni esplicite produttive sono un segnale positivo nei team che vogliono funzionare.

Passo 2: Calcolare il costo di opportunità

Ogni mese in un team disfunzionale è un mese in meno di crescita effettiva. Il costo non è solo la sofferenza nel momento - è il compounding negativo della non-crescita nel tempo. Un developer non-CS che passa 18 mesi in un team che non lo rispetta emerge da quell'esperienza con 18 mesi di experience sulla carta ma meno competenze reali di un developer che ha passato 12 mesi in un team funzionale.

Passo 3: Pianificare l'uscita senza uscire in modo reattivo

La decisione di uscire va pianificata - non eseguita in modo reattivo. Uscire in modo reattivo (dopo un episodio specifico, in un momento di alta tensione) produce spesso scelte subottimali: uscire senza un'altra offerta in mano, senza un portfolio aggiornato, senza referenze preparate. La pianificazione dell'uscita richiede 4-8 settimane: aggiornare il portfolio, riattivare la rete di contatti, iniziare le candidature in modo silenzioso mentre si è ancora nel team corrente.

Alternative all'uscita: strategie per migliorare la situazione dall'interno

Prima di arrivare alla decisione di uscita, esistono strategie che alcuni developer non-CS hanno usato per migliorare la propria situazione dall'interno di un team difficile. Non funzionano sempre - e non ha senso applicarle se il team è strutturalmente disfunzionale - ma in alcuni casi possono cambiare le dinamiche in modo significativo.

Costruire alleanze individuali invece di cercare riconoscimento collettivo

In un team che non rispetta sistematicamente i developer non-CS, cercare riconoscimento collettivo - l'approvazione del team come entità - è spesso più difficile che costruire alleanze individuali. Un singolo collega che diventa un sostenitore del proprio lavoro - che riconosce il contributo della domain expertise in meeting, che chiede il proprio parere su questioni dove il background è rilevante - può cambiare le dinamiche di visibilità in modo significativo.

La strategia per costruire queste alleanze individuali: identificare i colleghi che mostrano interesse genuino per il lavoro prodotto, investire nella relazione con loro, e creare situazioni in cui il contributo specifico del proprio background è visibile a queste persone specifiche. Le alleanze individuali si diffondono più lentamente della cultura collettiva, ma si costruiscono in modo più controllabile.

Fare richieste esplicite di visibilità

Un pattern documentato nel thread HN 2021: in molti team, la distribuzione ineguale delle opportunità non è intenzionale - è il risultato di un default cognitivo. Il manager assegna i progetti più interessanti ai profili che ha mentalmente categorizzato come "senior tecnico" senza riflettere attivamente sulla distribuzione. Fare una richiesta esplicita - "vorrei essere coinvolto nel progetto X per sviluppare queste competenze specifiche" - rompe il default e mette il manager di fronte a una decisione attiva invece di un'assegnazione automatica.

Questa strategia richiede coraggio - molti developer non-CS temono che fare richieste esplicite sembri arrogante o ingiustificato. Ma le testimonianze documentate indicano che nella maggior parte dei team funzionali (o potenzialmente funzionali), le richieste esplicite di crescita vengono accolte positivamente - e che la mancanza di richieste esplicite viene spesso interpretata come soddisfazione con la situazione corrente.

Creare proof of competence visibile

In un team dove il "background discount" è presente - la tendenza a interpellare i developer CS prima dei developer non-CS - una strategia efficace è creare prove di competenza talmente visibili e concrete da non poter essere ignorate. Documentazione tecnica eccellente. Un tool interno che risolve un problema reale del team. Un bug risolto in un'area critica. Questi artefatti sono difficili da svalutare perché sono verificabili indipendentemente dal giudizio soggettivo.

La differenza con l'approccio passivo è che questi artefatti vengono costruiti deliberatamente per essere visibili - non solo utili. La documentazione viene condivisa nei canali team. Il tool interno viene presentato in un demo. Il bug risolto viene comunicato con il suo impatto. La visibilità non è narcisismo - è il meccanismo attraverso cui il lavoro produce effetti sul proprio posizionamento nel team.

Il punto di non ritorno: quando le strategie interne non funzionano

Le strategie interne hanno un limite temporale. Se dopo 3-4 mesi di applicazione deliberata - conversazione con il manager, costruzione di alleanze, richieste esplicite di visibilità, prova di competenza concreta - la situazione non è migliorata in modo misurabile, la probabilità che migliori nel lungo periodo è bassa. Non impossibile, ma bassa.

Il punto di non ritorno non è un episodio specifico - è il momento in cui i dati raccolti nel periodo di osservazione indicano in modo convergente che il team non sta cambiando. A questo punto, continuare ad applicare le strategie interne è un investimento a basso rendimento atteso. Il tempo e l'energia cognitiva potrebbero essere meglio impiegati nella pianificazione dell'uscita.

Gestire l'uscita senza bruciare i ponti

La gestione dell'uscita da un team difficile richiede attenzione specifica al mantenimento dei rapporti professionali. Il mercato tech italiano è più piccolo di quanto sembri - le persone si reincontrano. Un'uscita gestita professionalmente - con preavviso adeguato, handover completo, tono neutro nelle conversazioni di fine rapporto - preserva la rete professionale anche in situazioni di disaccordo con il team.

Le referenze sono un asset che si costruisce anche nelle situazioni difficili: non dal manager che non ha investito nel tuo sviluppo, ma dai colleghi individuali con cui si è costruita una relazione produttiva. Identificare queste persone prima di uscire e mantenere il contatto post-uscita è un investimento a lungo rendimento nella carriera.

Letture e risorse

• HN thread 2021 - "How did you know it was time to leave?": 500+ commenti con pattern documentati
• Jason McDonald su DEV.to: 10 Signs Your Company Isn't Developer-Friendly - lista di pattern documentati
• freeCodeCamp: How to Deal with a Difficult Tech Team - guida pratica

Se stai pianificando un'uscita, la Guida Studio 6 Mesi può aiutarti a strutturare la preparazione tecnica per il prossimo job search - scaricala dalla cornerstone della serie.

Prossimo passo nella serie

Questo è il penultimo articolo della serie. Il prossimo - e ultimo - è un recap completo: la reading list onesta con le 50 risorse più utili per arrivare a senior come developer non-CS, selezionate dopo 20 settimane di scrittura su questo tema.

Leggi: Reading list onesta: 50 risorse per arrivare a senior come non-CS - l'ultimo articolo della serie, disponibile martedì prossimo.

Vedi anche nella serie:

• Le 5 trappole cognitive del bootcamper - per non sabotare il job search dopo essere usciti da un team
• L'impostor syndrome non finisce mai (ed è normale) - per distinguere la normale difficoltà dall'ambiente disfunzionale
• Torna alla cornerstone della serie - visione completa dei 20 articoli e career matrix 12 percorsi

Il tema del rispetto nel tech: strutturale, non individuale

Vale la pena fare una precisazione importante prima di chiudere l'articolo: il problema del rispetto nei team tech per i developer non-CS è spesso strutturale, non individuale. Non è che singoli colleghi siano "cattivi" - è che le strutture organizzative del team tech (come vengono distribuite le opportunità, come vengono presi i crediti, come vengono valutate le competenze) sono state costruite assumendo implicitamente un certo tipo di developer come norm. Chi non rientra in questa norm - e i developer non-CS spesso non ci rientrano - si trova in svantaggio sistematico anche senza che ci sia una cattiva intenzione specifica da parte di nessuno.

Perché la distinzione strutturale/individuale è importante

Capire che il problema è strutturale, non individuale, ha due implicazioni pratiche. La prima: non aiuta cercare il "colpevole" di una situazione disfunzionale - spesso non c'è un singolo responsabile, ma un sistema che produce risultati iniqui sistematicamente. La seconda: la soluzione a un problema strutturale non è cambiare le persone - è trovare strutture diverse. E le strutture sono, per definizione, proprietà dei team e delle organizzazioni, non delle singole persone.

Questo significa che in certi casi, il modo più efficiente per risolvere un problema strutturale è trovare un'organizzazione con una struttura diversa - non cercare di cambiare la struttura dall'interno, che è un lavoro lungo, incerto, e costoso in termini di energia cognitiva.

Come identificare organizzazioni con strutture più inclusive

Esistono segnali che un'organizzazione ha strutture più inclusive per developer non-CS, identificabili prima ancora di candidarsi. I più affidabili: (1) la composizione pubblica del team mostra diversità di background (visibile su LinkedIn) - non solo diversità demografica, ma diversità di percorsi formativi; (2) le job description menzionano esplicitamente background non-tradizionali come plus invece di come eccezione accettata; (3) l'azienda ha blog o contenuti pubblici dove developer con background non-CS raccontano la propria esperienza. Questi segnali non sono garantiti - ma sono più affidabili dell'assenza di red flag nel processo di hiring.

Il paradosso dell'adattamento unilaterale

Un pattern che emerge dalle testimonianze delle community: i developer non-CS tendono a investire in modo sproporzionato nell'adattamento alla cultura del team, cercando di diventare il più possibile simili ai developer CS. Questo adattamento è parzialmente utile - capire le norme culturali del settore tech e operarci fluidamente è una competenza necessaria. Ma l'adattamento unilaterale ha un costo: riduce la differenziazione che rende il profilo non-CS prezioso.

Il bilanciamento ottimale - documentato nelle testimonianze dei career-changer più efficaci - è adottare le norme operative del team tech (comunicazione tecnica, code review culture, uso degli strumenti) mantenendo attiva la prospettiva non-CS come contributo distintivo. Non "diventare come un developer CS" - ma "operare fluidamente come un developer CS portando qualcosa che i developer CS non hanno".

La questione del tempo: quanti mesi sono sufficienti per valutare un team?

Una domanda ricorrente: quanto tempo ci vuole prima di poter valutare se un team rispetta o non rispetta i developer non-CS? La risposta più onesta è: 4-6 mesi per i team piccoli (dove le dinamiche sono più visibili rapidamente), 6-9 mesi per i team grandi (dove le strutture informali richiedono più tempo per emergere).

Nei primi 1-3 mesi, è normale una fase di onboarding in cui il developer non-CS ha meno visibilità - non perché il team non lo rispetti, ma perché non lo conosce ancora abbastanza da dargli contribuzioni di alto valore. La valutazione diventa significativa solo quando la fase di onboarding si è conclusa e le dinamiche del team funzionante diventano visibili.

Cosa ho imparato scrivendo questo

Questo articolo è stato il più difficile da scrivere della serie - e non per ragioni tecniche. Il vincolo che mi sono imposto fin dall'inizio è stato chiaro: nessun riferimento a situazioni personali specifiche, nessuna storia da ambienti lavorativi concreti che io possa avere vissuto direttamente. Solo pattern terzi documentati da fonti pubbliche.

Questo vincolo è stato utile nella misura in cui mi ha costretto a cercare la struttura del problema invece di raccontare una storia specifica. La struttura è più utile della storia: la storia di qualcuno con un team tossico specifico è interessante ma non necessariamente trasferibile. Il framework per valutare se un team è disfunzionale è trasferibile indipendentemente dal contesto specifico.

Ho imparato che la letteratura pubblica su questo tema è ricca ma spesso mal categorizzata. La maggior parte degli articoli su "team tossici" o "quando lasciare il lavoro" è scritta da una prospettiva generica - senza considerare le vulnerabilità specifiche dei developer che arrivano da background non-CS. Ho cercato di colmare questa lacuna specifica.

Se vuoi condividere - in forma anonima o con un pseudonimo - la tua esperienza con un team che non ti ha rispettato come developer non-CS, e come l'hai gestita, scrivimi a federico@federicocalo.dev. Le storie anonimizzate sono le più utili - perché sono quelle che possono diventare pattern.

Ti rispondo. Sempre.

Se stai iniziando ad usare strumenti come Claude Code per compensare il gap di formazione formale, ho raccolto in una serie dedicata il workflow agentico che uso quotidianamente sul portfolio: Claude Code Workflow: Superpowers + GSD framework. È il sistema che mi permette di gestire 19 fasi parallele senza un team di sviluppo dietro.