33 ore, 8 milioni e una lezione scomoda: cosa insegna il “quasi-ribaltone” in Automattic

Automattic è una di quelle aziende che, per chi lavora nel frontend, spesso resta sullo sfondo: la incontri indirettamente attraverso WordPress.com, WooCommerce, Tumblr, o più banalmente perché WordPress alimenta ancora una fetta enorme del web. Proprio per questo, quando succede qualcosa ai suoi vertici non è solo gossip da tech industry: è un segnale su come potere, governance e infrastruttura possano intrecciarsi in modi poco rassicuranti.

Nelle ultime settimane l’azienda ha vissuto un episodio surreale per velocità e costo: un tentativo di sostituire il fondatore alla guida, concluso in poco più di un giorno con il ritorno del fondatore stesso e una conseguenza immediata — oltre 8 milioni di dollari in buonuscite dovute a due dirigenti rimossi dopo appena 33 ore.

Al di là dei dettagli, la storia è utile perché porta a galla tre temi che impattano chiunque costruisca prodotti sul web: (1) cosa significa davvero “il board conta più del CEO”, (2) quanto può valere il controllo del voto, (3) perché possedere un’infrastruttura critica cambia il peso di ogni decisione.

---

1) Il board può “licenziare” un CEO… ma non sempre può cambiarne il destino

In moltissime aziende tech la regola implicita è semplice: il board of directors sta sopra al CEO. Se il CEO prende decisioni ritenute dannose (strategie legali aggressive, gestione reputazionale disastrosa, scelte che deprimono la valutazione), il board ha leve per intervenire.

Nel caso Automattic, il board ha effettivamente provato a rimuovere il fondatore dalla carica di CEO, promuovendo il CFO al ruolo di CEO e presentando pubblicamente il passaggio come ordinato e condiviso.

Fin qui, scenario “da manuale”. Il punto è che il manuale cambia completamente quando la struttura dei voti è sbilanciata.

---

2) Se controlli la maggioranza del voto, un “cambio di CEO” può durare quanto un deploy annullato

Il dettaglio che trasforma una crisi in un boomerang è questo: il fondatore detiene una quota enorme del potere di voto (si parla dell’84%). In pratica, anche se il board vota la rimozione, chi controlla il voto può:

• sostituire i membri del board;
• nominare un board allineato;
• farsi reintegrare rapidamente.

È esattamente il tipo di architettura di governance che rende possibile un rientro “lampo”. E qui c’è una lezione che va oltre Automattic:

nelle aziende con voto concentrato, gli organi di controllo possono essere reali solo finché il controllore principale lo accetta.

Per chi lavora nel prodotto, questo ha una conseguenza pratica: la stabilità decisionale non dipende solo da processi e organigrammi, ma dalla distribuzione del potere contrattuale.

---

3) Quando in 33 ore si firmano buonuscite: gli incentivi contano più delle intenzioni

La parte economicamente più significativa dell’episodio è anche la più istruttiva: durante la finestra in cui due dirigenti hanno gestito l’azienda, sarebbero stati preparati accordi di uscita che prevedevano condizioni estremamente favorevoli in caso di licenziamento (stipendio annuale, copertura sanitaria, vesting immediato delle azioni).

Risultato: al ritorno del fondatore e al conseguente licenziamento dei due dirigenti, l’azienda si ritrova con un conto da oltre 8 milioni.

Non è solo una cifra impressionante: è un promemoria su come, nelle crisi, gli incentivi e le tutele contrattuali diventino una variabile di primo livello. Quando i ruoli cambiano rapidamente, chi ha il tempo (e l’autorità temporanea) di firmare cose, spesso lo fa.

Per un team tecnico questo si traduce in un punto molto concreto: nelle fasi di instabilità al vertice, la probabilità di decisioni irreversibili (contratti, policy, licenze, accessi, deleghe) sale.

---

4) Open source, controllo operativo e “punto singolo di influenza”

C’è poi un livello ancora più delicato: l’ecosistema WordPress non è solo un prodotto, è una rete di distribuzione.

Quando parliamo di update, plugin e temi, la dipendenza non è astratta: migliaia di installazioni “tirano” componenti e aggiornamenti da snodi centrali. Se una parte di questa infrastruttura critica è legata a decisioni e proprietà personali, il rischio non è teorico.

Questa tensione (open source vs controllo operativo) esiste da anni in tanti progetti: puoi avere codice aperto e comunità attiva, ma se:

• la governance è fortemente centralizzata;
• le leve operative (accessi, canali, infrastrutture, domini) sono in poche mani;

…allora il sistema è tecnicamente aperto, ma politicamente fragile.

Per chi sviluppa prodotti su WordPress (o su qualunque piattaforma/marketplace), la domanda pratica è sempre la stessa:

• quanto è sostituibile la dipendenza?
• esiste un piano B per aggiornamenti, distribuzione, continuità operativa?

---

Implicazioni pratiche per chi fa frontend e lavora con WordPress (o con piattaforme simili)

Non serve fare doomscrolling sulla governance per trarne valore. Basta trasformare l’episodio in checklist operative:

1. Riduci il lock-in della supply chain: dove possibile, pipeline di deploy e aggiornamenti sotto controllo del team (mirror, policy di pinning, staging robusto).
2. Gestisci aggiornamenti come change management: niente auto-update “ciechi” su produzione senza canary/staging, soprattutto per plugin critici.
3. Traccia dipendenze e criticità: sapere quali plugin sono “core business” e chi li mantiene è risk management, non paranoia.
4. Piano di emergenza: backup reali, procedure di rollback testate, alternative documentate.

---

Sintesi: il costo reale non sono gli 8 milioni

L’episodio colpisce per la cifra e per la rapidità — 33 ore possono bastare per bruciare milioni — ma la lezione più utile è un’altra: la tecnologia non vive in un vuoto.

Governance, controllo del voto e proprietà delle infrastrutture determinano quanto un ecosistema sia prevedibile. E per chi costruisce interfacce, ecommerce, contenuti e prodotti sopra piattaforme dominanti, prevedibilità significa una cosa sola: rischio misurabile.

Quando quel rischio cambia improvvisamente, non lo risolvi con un nuovo framework: lo risolvi con architettura, processi e un minimo di strategia di indipendenza.