Ruoli e titoli del software

Foto di Henry (CC-BY-2.0)

Ho notato molta confusione nel settore su vari ruoli e titoli di software, anche tra fondatori, responsabili delle assunzioni e team building. Quali sono i vari ruoli e responsabilità in un team di software e quali titoli di lavoro tendono a coprire quali ruoli?

Prima di approfondire troppo, vorrei sottolineare che ogni squadra è unica e che le responsabilità tendono a fluttuare o essere condivise tra i diversi membri della squadra. Chiunque può in qualsiasi momento delegare le responsabilità a qualcun altro per vari motivi, molti dei quali validi.

Se la tua squadra non è esattamente ciò che descrivo qui, benvenuto nel club. Sospetto che pochissimi team e ruoli software specifici corrispondano perfettamente a ciò che stiamo per esplorare. Questo è solo un quadro generale che descrive le medie più di qualsiasi ruolo o squadra particolare.

Inizierò con titoli gestionali e mi farò strada attraverso vari ruoli all'incirca per anzianità.

Vorrei anche sottolineare che non dovresti sentirti vincolato dal tuo titolo professionale. Mi piace costruire una cultura ingegneristica che favorisca:

  • Competenze sui titoli
  • Consegna continua oltre le scadenze
  • Supporto per colpa
  • Collaborazione rispetto alla concorrenza

Mi piace premiare l'iniziativa con una maggiore responsabilità e se qualcuno ha le capacità e l'iniziativa per assumere e superare il titolo per il quale è stato assunto, mi piace promuovere piuttosto che rischiare di perdere una stella nascente in un'altra società o squadra.

Ruoli di sviluppo software

  • Ingegnere
  • Amministratore delegato
  • CTO
  • CIO / Chief Digital Officer / Chief Innovation Officer
  • Vicepresidente tecnico / Direttore tecnico
  • Capo Architetto
  • Software Architect
  • Responsabile del progetto di ingegneria / responsabile della progettazione
  • Responsabile tecnico / responsabile tecnico / responsabile team
  • Ingegnere software principale
  • Ingegnere software senior / Sviluppatore software senior
  • Ingegnere del software
  • Sviluppatore di software
  • Sviluppatore software junior
  • Sviluppatore software stagista

Parleremo anche un po 'di come questi ruoli si relazionano con altri ruoli, tra cui:

  • VP of Product Management / Head of Product
  • Responsabile del prodotto
  • Vicepresidente marketing
Nota: a volte i titoli "regista" o "capo" indicano i dirigenti intermedi tra i dirigenti tecnici e la C-Suite. Spesso, i titoli "Chief" indicano un titolo C-suite. I dipendenti di C-suite in genere riportano direttamente al CEO e possiedono potenzialmente molti report nelle organizzazioni che conducono. In aziende molto grandi, quei titoli alternativi spesso ricoprono ruoli simili ai dirigenti di C-suite, ma riportano a qualcuno che è effettivamente l'amministratore delegato di un'unità aziendale più piccola all'interno dell'organizzazione più grande. Diverse unità di business a volte operano come se fossero società separate, complete di propri contabili, funzionari finanziari, ecc. Diverse unità di business possono anche avere VP, ad esempio "Vice President of Engineering, Merchant Operations".

Ingegnere

Il titolo "collega" è l'apice del successo per gli ingegneri del software. In genere viene assegnato in riconoscimento delle persone che hanno apportato contributi eccezionali nel campo dell'informatica e di solito viene assegnato dopo che un ingegnere ha scritto una serie di libri più venduti, ha vinto premi come il Premio Turing, il Premio Nobel, ecc. In altre parole , i borsisti di solito sono già famosi al di fuori dell'organizzazione e l'azienda sta cercando di rafforzare il proprio marchio associandosi più fortemente con persone ammirate e influenti.

A mio avviso, le organizzazioni non dovrebbero cercare di assumere ruoli "compagni". Invece, trova il meglio e il più brillante, assumilo e poi concedi il titolo (e i benefici) se l'ingegnere se lo merita.

Un collega in genere detiene anche un altro titolo in azienda. Spesso un CTO, un architetto, un vicepresidente dell'ingegneria o un ruolo principale, in cui sono in grado di guidare, guidare o servire da esempio e ispirazione per altri membri dell'organizzazione.

Amministratore delegato

Il CEO è la posizione della maggior autorità in un'organizzazione. In genere, hanno fissato la visione e la stella polare per l'azienda. Radunano tutti attorno a una comprensione comune del perché l'azienda esiste, qual è la missione e quali sono i valori dell'azienda. Spesso i CEO sono anche il volto pubblico dell'azienda e, in alcuni casi, diventano sinonimi del marchio (ad es. Steve Jobs con Apple, Elon Musk con Tesla / SpaceX, ecc.)

In alcuni casi, gli amministratori delegati sono anche il fondatore tecnico di un'organizzazione software, nel qual caso ricoprono spesso anche il ruolo di CTO e possono avere un vicepresidente responsabile delle operazioni, delle vendite, della strategia e del marketing che aiuta con alcune delle altre responsabilità comuni dell'amministratore delegato .

L'amministratore delegato di una piccola azienda indossa spesso molti cappelli, poiché potresti aver acquisito tutti gli altri ruoli che sono usciti dal titolo di amministratore delegato quando ho detto che alcuni amministratori delegati guidano il team tecnologico.

In ogni caso, se ci sono importanti decisioni organizzative da prendere, non puoi farcela nella catena di responsabilità più in alto rispetto al CEO.

Se sei un amministratore delegato, ricorda che alla fine sei responsabile e che dovresti fidarti del tuo istinto, ma non dimenticare che anche i CEO più famosi hanno mentori e consulenti con cui si consultano regolarmente. Fidati del tuo istinto, ma cerca anche persone intelligenti e perspicaci che ti sfidino a migliorare.

CTO

Come il ruolo di CEO, il ruolo di CTO cambia nel tempo. Alle giovani startup, il CTO è spesso cofondatore tecnico di un CEO visionario o guidato dal dominio. Spesso non sono qualificati per ottenere il titolo in una società più grande e, si spera, crescono in esso man mano che l'azienda cresce. Spesso un CTO di avvio scopre di preferire ruoli di ingegneria più tecnici e di ricollocare in altri ruoli, come Ingegnere Principale, Vicepresidente di Ingegneria o Capo Architetto.

In molte organizzazioni, il ruolo di CTO maturo è rivolto verso l'esterno. Partecipano a riunioni di sviluppo aziendale, contribuendo spesso a creare grandi partnership o vendite. Molti di loro entrano nel circuito delle conferenze e trascorrono molto tempo a evangelizzare le attività di sviluppo dell'organizzazione in tutto il mondo: condividere le innovazioni dell'azienda e scoprire opportunità sul mercato che si abbinano bene con le competenze chiave dell'azienda. I CTO lavorano spesso a stretto contatto con il team di prodotto sulla strategia del prodotto e spesso hanno una controparte interna in ingegneria, come il vicepresidente del reparto tecnico.

I CTO stabiliscono spesso anche la visione e la stella polare del team di ingegneri. Gli obiettivi per cui la squadra deve lavorare.

CIO / Chief Digital Officer / Chief Innovation Officer

Il Chief Innovation Officer (CIO) è come un CTO, ma tipicamente impiegato da una società che normalmente non sarebbe considerata una "società tecnologica". L'obiettivo del CIO è quello di rimodellare la società in una che i consumatori percepiscono come tecnologicamente esperta e innovativa: mostrare al mondo come sarà il futuro del settore, qualunque esso sia. Ad esempio, una catena di supermercati di rimodellamento domestico potrebbe avere un CIO responsabile della collaborazione con aziende tecnologiche per costruire un'app di realtà mista per mostrare agli acquirenti come sarebbe un determinato divano o colore della parete nel loro salotto o usare blockchain e criptovalute per migliorare la sicurezza ed efficienza della logistica della catena logistica.

Da non confondere con un Chief Information Officer (CIO), un titolo che viene generalmente utilizzato in aziende che sono ancora più distaccate dalla tecnologia, interessate a quanto aiuta le loro operazioni principali. A differenza di un Chief Innovation Officer, è più probabile che un Chief Information Officer stia conducendo progetti di integrazione tecnologica e migrazione dei dati rispetto alla creazione di nuove app e cercando di capire come un'azienda possa distrarsi dall'interno. Ci sono Chief Information Officer che agiscono più come Chief Innovation Officer, ma secondo me dovrebbero usare il titolo appropriato.

La maggior parte delle aziende native della tecnologia (sviluppatori di app, ecc.) Non hanno alcun tipo di CIO. Invece, tali responsabilità ricadono sul CTO e sul vicepresidente dell'ingegneria.

Vicepresidente tecnico / Direttore tecnico

Mentre i CTO sono spesso rivolti verso l'esterno, il vicepresidente dell'ingegneria è spesso rivolto verso l'interno. Un VP of Engineering è spesso responsabile della creazione del team di progettazione e della creazione della cultura e delle operazioni di ingegneria. Il CTO potrebbe dire al team di ingegneri cosa deve essere fatto su larga scala, ad esempio "essere il principale innovatore nell'interazione uomo / computer". Il VP of Engineering aiuta a promuovere una cultura che gestisce il "come". I migliori vicepresidenti di ingegneria inizialmente si presentano come qualcuno che è lì per aiutare il team a lavorare in modo efficiente, e poi quasi scompaiono. Gli sviluppatori del team collaborano bene, si guidano a vicenda, comunicano in modo efficace e pensano: "Ehi, siamo una grande squadra. Lavoriamo davvero bene insieme! "E forse pensano che sia stato un incidente fortunato.

La verità è che quasi mai accade per caso. Succede perché c'è un vicepresidente dell'ingegneria che monitora costantemente i progressi, il processo, la cultura e il tono delle comunicazioni del team. Stanno incoraggiando gli sviluppatori a utilizzare determinati strumenti, tenere specifici tipi di riunioni in momenti specifici al fine di favorire una migliore collaborazione con meno interruzioni. I migliori vicepresidenti di ingegneria sono stati ingegneri, sia in team disfunzionali, sia in team altamente funzionali. Conoscono i modelli e gli anti-schemi per flussi di lavoro di sviluppo software efficaci.

Lavorano con i responsabili dei responsabili dei prodotti e dei prodotti per garantire che ci sia un buon processo di scoperta dei prodotti (non lo guidano né se ne prendono in carico, assicurandosi solo che qualcuno ci sia e lo faccia bene), e quel prodotto e i prodotti di progettazione vengono adeguatamente rivisti dagli ingegneri prima delle distribuzioni di implementazione. Mi fermerò qui prima di scrivere un libro su tutto il lavoro necessario per condurre operazioni di sviluppo efficaci. Per ulteriori informazioni su questo argomento, consulta Come creare un team di sviluppo ad alta velocità.

Molte startup sono troppo piccole per assumere un vicepresidente a tempo pieno di ingegneria, ma è ancora molto importante acquisire la cultura ingegneristica il prima possibile. Se hai bisogno di aiuto con questo, contatta.

Capo Architetto

Nelle piccole organizzazioni, l'architetto capo potrebbe essere un co-fondatore tecnico con l'autocoscienza per rendersi conto che non vorranno le responsabilità di un CTO man mano che l'azienda cresce. Forse a loro non piace viaggiare o sono semplicemente più interessati alla progettazione del software rispetto ai colloqui della conferenza, allo sviluppo del business e alle chiamate di vendita che si infiltrano nella vita di molti CTO. L'architetto capo può essere responsabile della selezione di stack tecnologici, della progettazione di collaborazioni e interfacce tra i sistemi informatici, della valutazione delle offerte di servizi di calcolo (AWS, Azure, ZEIT Now, ecc.) E così via. Un capo architetto può valutare una vasta gamma di offerte del settore e formulare raccomandazioni pre-approvate o preferite per lavorare con determinati fornitori.

Man mano che l'azienda matura, il capo architetto potrebbe anche aver bisogno di lavorare a stretto contatto con il CTO, e talvolta organizzazioni partner per sviluppare integrazioni tra i servizi. In molte aziende, il CTO funge anche da capo architetto.

Software Architect

Un architetto del software serve a molti scopi di un capo architetto, ma è generalmente responsabile di sezioni trasversali più piccole di funzionalità. Gli architetti lavoreranno spesso con l'architetto capo per implementare la loro fetta della visione architettonica più ampia. Gli architetti del software spesso scelgono stack tecnologici per applicazioni o funzionalità particolari, piuttosto che decisioni a livello aziendale.

Responsabile del progetto di ingegneria / Responsabile del progetto / Responsabile del progetto

Un responsabile di progetto di ingegneria (chiamato anche "responsabile di progettazione" o semplicemente "responsabile di progetto") è responsabile della gestione del flusso di lavoro di un team di progettazione. Alcune grandi aziende hanno sia manager di ingegneria che project manager. In tal caso, il responsabile della progettazione in genere agisce come il vicepresidente della progettazione nell'ambito del team locale, mentre il responsabile del progetto assume le responsabilità qui descritte.

I project manager in genere si interfacciano sia con i leader di prodotto che con un leader di ingegneria come VP of Engineering, CTO o un middle manager per coltivare e potare gli arretrati di lavoro, tenere traccia dell'avanzamento dei ticket di lavoro, rapporti dettagliati sullo stato di avanzamento (grafici di abbattimento delle pietre miliari, completato vs biglietti aperti, rapporti sui progressi mensili / mensili, ecc.) Puoi considerarli come l'analogo di un responsabile di negozio per una catena di montaggio di produzione. Guardano il piano di lavoro e si assicurano che la catena di montaggio proceda senza intoppi e che il prodotto di lavoro non si accumuli sul pavimento di fronte a un collo di bottiglia.

I migliori Project Manager impiegano anche molto tempo a classificare problemi e bug al fine di analizzare metriche quali densità dei bug per punto di funzione, cosa ha causato la maggior parte dei bug (errore di progettazione, errore di specifica, errore di logica, errore di sintassi, errore di tipo, ecc.) e così via. Questo tipo di metriche può essere utilizzato per misurare l'efficacia di varie iniziative e sottolineare dove è possibile apportare miglioramenti al processo di ingegneria.

I manager di ingegneria tendono a sviluppare una buona comprensione dei punti di forza dei vari membri del team e ad acquisire buone competenze nell'assegnare i biglietti di lavoro alle parti responsabili appropriate, anche se, questo dovrebbe essere uno sforzo collaborativo, alla ricerca di feedback da singoli sviluppatori su quali sono i loro obiettivi di carriera e su cosa vogliono concentrarsi, entro i limiti dell'ambito del progetto disponibile.

Se si verifica una pressione del tempo o si accumulano arretrati di lavoro, il Project Manager dovrebbe collaborare con i responsabili dell'ingegneria e del prodotto per capire la causa principale e correggere la disfunzione il prima possibile.

Ove possibile, i Project Manager dovrebbero essere gli unici a delegare direttamente i compiti ai singoli ingegneri al fine di evitare il problema di più capi. Gli ingegneri dovrebbero avere un'idea chiara di chi riferiscono direttamente e di chi è incaricato di delegare loro. Se sei un diverso tipo di leader di ingegneria e sei colpevole di delegare direttamente agli ingegneri, è probabilmente una buona idea coordinarsi con il responsabile tecnico responsabile del rapporto a cui stai delegando e delegare attraverso di loro in modo che il il lavoro riceve una corretta e coordinata definizione delle priorità e il direttore tecnico è consapevole di ciò su cui ciascun ingegnere sta lavorando attivamente in un dato momento.

In organizzazioni molto piccole, il direttore tecnico è spesso anche direttore tecnico e vicepresidente del settore tecnico (con o senza i titoli corrispondenti). Se sei tu, non preoccuparti del paragrafo precedente.

Una disfunzione comune è che il Responsabile tecnico può iniziare a pensare che, poiché il prodotto non funziona in modo ingegneristico da implementare e i Responsabili tecnici lavorano a stretto contatto con i team di prodotto, il Responsabile tecnico riporta a un Responsabile del prodotto. In ogni caso che ho visto accadere, è stato un errore. Vedere "Evitare disfunzioni ..." di seguito.

Capo tecnico / Capo squadra

Il Tech Lead o Team Lead è di solito il leader di un numero limitato di sviluppatori. Di solito sono ingegneri senior che agiscono come mentori, esempi e guide per il resto del team. Di solito, gli ingegneri riferiscono al project manager o al responsabile tecnico, ma un responsabile tecnico può essere responsabile delle misure di qualità del codice del team, come garantire che vengano condotte revisioni adeguate del codice e che gli standard tecnici del team (come TDD) vengano rispettati accolta.

Progressi di carriera dell'ingegnere

In genere, gli ingegneri possono intraprendere uno dei due percorsi di carriera: passare alla gestione o continuare a scrivere codice. Le posizioni dirigenziali non sono per tutti. Molti ingegneri preferiscono rimanere sul percorso tecnico. Quella progressione può prendere molte direzioni, colpi di scena e svolte, ma potrebbe assomigliare a questa:

Stagista -> Junior Software Developer -> Software Developer / Engineer -> Senior Software Engineer -> Principal Software Engineer -> Software Architect -> Senior Software Architect -> Chief Architect -> CTO -> Engineering Fellow

In alternativa, per quegli ingegneri interessati a un ruolo di leadership delle persone, una progressione potrebbe assomigliare a questa:

Stagista -> Sviluppatore software junior -> Sviluppatore software / Ingegnere -> Responsabile team / Responsabile tecnico -> Responsabile ingegneria / Responsabile progetto -> Responsabile ingegneria senior -> Direttore ingegneria -> Vice direttore ingegneria

Evitare disfunzioni nella direzione tecnica

IMO, VP of Engineering, CTO, VP of Product e VP of Marketing dovrebbero riferire direttamente al CEO. Ognuno di loro deve essere responsabile del proprio processo. I CTO rivolti verso l'esterno non dovrebbero avere rapporti diretti (se lo fanno, di solito significa che stanno riempiendo sia il CTO che il VP dei ruoli di ingegneria). Invece, i leader dell'ingegneria riferiscono al vicepresidente dell'ingegneria. Questo per evitare la disfunzione dei due capi, ma anche perché questi ruoli sono fondamentalmente diversi: uno incentrato sul cliente e su come l'organizzazione si adatta al resto del mondo e l'altro incentrato sulle operazioni interne quotidiane. Sono due set di abilità selvaggiamente diversi, con priorità talvolta contrastanti.

Ho visto molte disfunzioni nella leadership ingegneristica a causa della confusione su quali leader ingegneristici sono responsabili di cosa e tende ad essere una ricetta per il disastro. Qualunque cosa sia giusta per la tua organizzazione, assicurati che le responsabilità e la catena di autorità siano chiare, al fine di evitare che gli ingegneri si sentano divisi tra due o tre "capi" diversi.

Allo stesso modo, in un'organizzazione di dimensioni sufficienti, prodotto e ingegneria devono essere due team guidati separatamente. Quello che intendo con ciò è che i product manager dovrebbero possedere la roadmap del prodotto. Dovrebbero essere evangelisti per gli utenti e dovrebbero essere realmente collegati agli utenti, spesso interagendo con loro 1: 1 e imparando a conoscere i loro flussi di lavoro e i loro punti di dolore in modo molto approfondito. Dovrebbero essere esperti su ciò di cui il mercato ha bisogno e dovrebbero avere molta familiarità con i punti di forza e le capacità dell'azienda per soddisfare tali esigenze.

Detto questo, il VP of Engineering (o chiunque ricopra quel ruolo) deve essere responsabile della consegna e del ritmo di produzione. Mentre i responsabili di prodotto dovrebbero possedere la tabella di marcia, i responsabili della progettazione devono essere responsabili di prendere quelle priorità della tabella di marcia, adattarle alla capacità di progettazione e riferire sui tempi. I team di prodotto e marketing avranno forti opinioni su quando qualcosa dovrebbe essere spedito, ma solo la direzione tecnica ha una buona valutazione della possibilità o meno di tali scadenze di consegna dati i requisiti della roadmap. Il team di ingegneri ha bisogno dell'autorità non solo di respingere i tempi, ma nella maggior parte dei casi, di possedere completamente i tempi, collaborando con il CEO, i prodotti e i team di marketing per capire le priorità, comprendere le esigenze strategiche dell'azienda e quindi aiutare a modellare una cadenza di sviluppo in grado di soddisfare tali esigenze senza imporre scadenze che alla fine compromettono la capacità dell'azienda di fornire prodotti di qualità a un ritmo affidabile.

I team con le migliori prestazioni in cui sia mai stato coinvolto si sono iscritti all'approccio senza scadenze. Costruiamo ottimi prodotti senza annunciarli in anticipo, quindi lasciamo che i team di marketing promuovano il lavoro già fatto. In alternativa, quando lavori in vista pubblica, la trasparenza è un'ottima soluzione. Invece di stipare un limite per rispettare una scadenza arbitraria, condividi attivamente i tuoi progressi, con i grafici di esaurimento dei biglietti, una visione chiara del lavoro rimanente, dei progressi, del ritmo e dell'ambito rimanente e cambiamenti nel tempo che possono indicare un creep dell'ambito. Quando condividi informazioni dettagliate sui progressi compiuti e condividi la filosofia secondo cui non possiamo promettere una data di consegna, ma possiamo condividere con te tutto ciò che sappiamo sui nostri progressi, le persone possono vedere da sole il lavoro e il ritmo.

A causa di obiettivi diversi, spesso in competizione tra loro, prodotto, marketing e ingegneria devono essere ruoli separati che riportano direttamente al CEO, dove nessuno di loro può dettarsi a vicenda. Se la tua squadra sente la pressione del tempo per fare gli straordinari o crunch per ottenere alcuni risultati chiave prima di un termine ultimo, significa che qui c'è una disfunzione. O i responsabili dell'ingegneria segnalano alle persone sbagliate o il team manca di un leader ingegneristico forte che capisca la futilità delle stime del software e la necessità di un rapporto collaborativo tra ingegneria e prodotto al fine di garantire la flessibilità delle spedizioni scalate MV-back per raggiungere obiettivi di consegna.

Il prodotto deve essere proprietario del processo di rilevamento continuo. L'ingegneria dovrebbe essere proprietaria del processo di consegna continua. Il marketing dovrebbe lavorare a stretto contatto con il team del prodotto per garantire che la messaggistica del prodotto in tutto il mondo sia puntuale. Il tutto dovrebbe combaciare come una pipeline, creando un ciclo di feedback positivo che scorre uniformemente. Come una catena di montaggio, il collo di bottiglia più lento nel processo deve impostare il ritmo per il resto del processo, altrimenti porterà a un backlog sempre crescente che si accumula così tanto che gli elementi di backlog diventano obsoleti e la gestione del backlog diventa completa lavoro temporaneo.

I team di prodotti che pensano che l'ingegneria non stia tenendo il passo dovrebbero concentrarsi innanzitutto sulla qualità dei risultati finali dell'ingegneria. Abbiamo effettuato un'adeguata revisione del design? Un ingegnere ha avuto la possibilità di fornire un feedback costruttivo prima del trasferimento? L'80% dei bug del software è causato da errori di progettazione o UX di progettazione e molti di questi possono essere individuati prima che il lavoro venga consegnato a un team di ingegneri. Dopo aver perfezionato il processo con precisione, chiediti se hai davvero esplorato abbastanza a fondo lo spazio di progettazione del prodotto. Hai creato un UX e lo hai chiamato fatto o hai provato più varianti? La creazione e il test delle variazioni sui flussi di lavoro degli utenti è uno dei contributi più preziosi che un team di prodotti può offrire. Hai un gruppo di utenti o clienti fidati con cui puoi eseguire test prototipo A / B?

Una delle maggiori disfunzioni dei team di software è che il team di prodotto sta producendo prodotti scadenti (a volte poco più di alcuni modelli affrettati e con errori) e non riesce a farli funzionare da clienti o ingegneri prima di consegnarli . Questa disfunzione provoca un accumulo di rilavorazioni e arretrati tecnici che spesso vengono incolpati dai team di ingegneri.

Assicurati che la delega delle responsabilità abbia un senso, che non stai facendo pressioni eccessive sui tempi di progettazione e che hai un ottimo team di prodotti impegnato in un processo di scoperta del prodotto collaborativo, lavorando con utenti reali per costruire il miglior prodotto.

Responsabili tecnici, non ti sto liberando. Se queste disfunzioni esistono nel tuo team, è tua responsabilità affrontarle con i prodotti, il marketing e la leadership aziendale e i requisiti di punta per le dispense ingegneristiche. È anche tua responsabilità proteggere il ritmo produttivo della tua squadra, andare a fare pipistrello per risorse aggiuntive se la tua squadra è sotto pressione per produrre più di quanto la tua attuale capacità sia in grado di gestire, per riferire chiaramente sul ritmo di lavoro e sull'arretrato e per dimostrare il lavoro completato e assicurati che il tuo team stia ricevendo il dovuto credito per l'ottimo lavoro svolto.

Non dare la colpa, ma dimostra che la tua squadra sta facendo il suo meglio.

Eric Elliott è un esperto di sistemi distribuiti e autore dei libri "Composing Software" e "Programmazione di applicazioni JavaScript". Come co-fondatore di DevAnywhere.io, insegna agli sviluppatori le competenze di cui hanno bisogno per lavorare in remoto e abbracciare l'equilibrio tra lavoro e vita privata. Crea e fornisce consulenza a team di sviluppo per progetti crittografici e ha contribuito alle esperienze software per Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC e i migliori artisti discografici tra cui Usher, Frank Ocean, Metallica e molti altri.

Gode ​​di uno stile di vita remoto con la donna più bella del mondo.