«Approccio atipico alla finanza» — cosa succederebbe se i dipendenti gestissero autonomamente i loro guadagni. Conversazione con Flant

In un mondo dove solo il proprio business può renderti veramente ricco, le persone continuano a cercare un lavoro salariato. In primo luogo, non tutti sono felici di essere imprenditori, e bisogna pur vivere. In secondo luogo, sul lavoro tutto è chiaro e sicuro: svolgi il tuo compito, mentre la maggior parte dei rischi è assunta da altri. Da qui nascono conflitti persistenti: i proprietari vogliono che i dipendenti siano motivati come se il lavoro fosse il loro affare; i dipendenti vogliono fare solo ciò per cui vengono pagati, e nient'altro.

Questi rapporti classici hanno delle variazioni — opzioni, percentuali, bonus, che ricordano un po' che proprietari e dipendenti sono sulla stessa barca. Ma ci sono anche situazioni più atipiche.

L'azienda Flant è composta da diversi team di DevOps che gestiscono produzioni chiavi in mano per conto di altri. Sono nati da un gruppo di studenti appassionati e fan di Linux, e ora hanno costruito una struttura di "business all'interno di un business", semplicemente perché è più comodo e onesto. Dima Stolyarov e Sasha Batalov ci hanno raccontato come funziona.

Flant è entrata nella ranking classifica dei migliori datori di lavoro IT del 2018 con una valutazione media di 4.68. Da quanto emerge dalle valutazioni dell'azienda su "Il mio cerchio", i dipendenti credono che l'azienda stia rendendo il mondo migliore e apprezzano Flant per le sfide interessanti, le buone relazioni all'interno del team, le tecnologie moderne e il contatto con il top management.

Un gruppo di studenti appassionati di Linux

Dmitry Stolyarov (CTO) durante la sua presentazione

— (Dima Stolyarov) Ci siamo sempre occupati di Linux e open source, ma abbiamo iniziato con un argomento piuttosto ridicolo, per cui ora ci vergogniamo un po'. Per qualche motivo pensavamo che fosse necessario implementare Linux negli uffici al posto di Windows. Il primo nome dell'azienda era TrueOffice — "ufficio vero". Poi abbiamo capito che a nessuno interessava. Era il 2006, avevo 19 anni. Solo nel 2012-13 è arrivata la consapevolezza su come fare business e quali tecnologie servissero al mondo.

Alexander Batalov (CEO) allo stand dell'azienda durante la conferenza

— (Sasha Batalov) Oltre alla tecnologia, c'è un'enorme area di marketing, vendite ed economia, di cui nessuno ci ha mai insegnato nulla, tranne i corsi all'università, ma non so quanto siano applicabili e utili.

All'inizio pensavamo che tutto questo non fosse necessario, ma poi ci siamo trovati a doverlo apprendere sul campo, leggendo libri, a volte già dopo aver accumulato qualche esperienza. In generale, abbiamo percorso una strada lunga e tortuosa, provando un sacco di cose sbagliate.

— (DS) Ma gradualmente, con l'aumento delle competenze, ci siamo specializzati in Linux e ora ci occupiamo solo di high load, progetti web ad alta richiesta. E quando è arrivato Kubernetes, abbiamo subito capito che era il fondamento di cui avevamo tanto bisogno.

— Perché c'era tanto interesse per Linux? Ideologico o tecnologico?

— (DS) L'azienda ha due fondatori: Dima Shurupov e io. Dima Shurupov era più interessato all'open source, mentre a me piaceva proprio Linux, tecnologicamente, com'è strutturato. Così è emersa una combinazione: a Dima piace l'ideologia, a me la tecnologia. Amo l'open source come idea, ma ho sempre ritenuto più importante l'aspetto tecnologico.

Einstein diceva: «Fai le cose il più semplicemente possibile, ma non più semplicemente». Ecco, Linux è costruito in modo così semplice, affidabile e trasparente che ne godo. A tutti noi piaceva, e siamo passati da un gruppo di studenti a una grande azienda. Ora siamo già 70. Per il settore IT e per servizi specializzati, è abbastanza.

— Com'era tutto ai tempi del gruppo di studenti?

— (DS) Beh, come di solito accade con gli studenti: divertente e vivace.

— (SB) Un'enorme quantità di altruismo, il desiderio di conquistare internet, di scalare vette tecnologiche. Ci immischiavamo in compiti molto complessi — prendevamo a cuore progetti seri (ma molto interessanti!) nel campo dell'integrazione di sistemi, realizzando tutto a prezzo stracciato. Tentavamo di creare i nostri framework, assorbivamo tutte le tecnologie che scoprivamo, e cercavamo subito di applicarle.

— E dal punto di vista commerciale, andava bene?

— (DS) Sì, ma nelle fasi iniziali non avevamo bisogno di nulla. A quei tempi, per me 40 mila rubli erano un guadagno assolutamente normale, mi sembrava di vivere come un re.

— (SB) E io pensavo che con mille dollari si potesse fare qualsiasi sito immaginabile.

— (DS) Nel 2013 non avevamo soldi per assumere liberamente a Mosca. Tutti i conoscenti che potevamo reclutare, li avevamo già presi. Abbiamo deciso di aprire un ufficio a Nizhny Novgorod. Siamo andati lì, abbiamo aperto, abbiamo iniziato a assumere. Poi ci siamo resi conto che vivere con due uffici era difficile, e abbiamo deciso di vivere senza uffici.

Certo, abbiamo fatto molti errori. Solo nel 2016, con mio grande imbarazzo, ho letto Remote. Ho pianto e riso, perché abbiamo percorso la stessa strada. Ogni paragrafo si sovrapponeva alla mia esperienza personale.

— (SB) In ogni paragrafo c'erano le nostre cicatrici.

Cosa fa Flant

Gestiamo produzioni ad alta intensità turn-key. Questo è diverso dal normale outsourcing, perché viviamo con i clienti per molto tempo e interagiamo molto da vicino, le persone ci affidano una delle loro cose più importanti. Il modo in cui lavoriamo influisce molto sul loro business.

Per formare una gestione di alta qualità della produzione, servono 15-20 DevOps, specialisti di database, di Kubernetes, supporto tecnico e così via. Se l'azienda è piccola, dove ci sono solo un paio di decine di sviluppatori, è impossibile. E qui arriviamo noi e salviamo. Per circa 150.000.

In passato avevamo come missione quella di creare un'azienda in cui ci sarebbe stato comodo lavorare, per quanto possa suonare sciocco. Ora che ci siamo riusciti, la missione è rendere tecnologie di livello Google e Facebook accessibili a piccole imprese e startup nelle fasi iniziali.

Le persone possono concentrarsi sul loro prodotto, invece di superare problemi che non dovrebbero affrontare.

Molti ragazzi che vengono da noi sono sorpresi da quanto è vario e quante sono le pressioni. Abbiamo oltre 50 progetti in produzione, più di 70 cluster Kubernetes. Ogni volta si può sempre inventare qualcosa. Ho aperto un disegnatore, ho tracciato un'architettura a microservizi, ho fatto un elenco di 200 tecnologie — e si parte. Ma questo porta sempre a problemi e conseguenze.

La chiave è garantire da un lato la massima stabilità, affidabilità e semplicità, dall'altro un alto livello di innovazione. Ecco, siamo orgogliosi di saperlo fare. Lo facciamo ovunque e a livello massivo, come una sorta di Ikea.

A chi servono i DevOps in outsourcing

— Mi sembra che le grandi aziende preferiscano avere i DevOps in-house.

— (SB) È chiaro che grandi attori come Avito o Badoo possono assumere i loro DevOps. Anche le piccole aziende con enormi investimenti possono farlo — tuttavia possono assumerli, ma non è detto che abbiano la forza per gestirli.

Riteniamo che anche le grandi aziende dovrebbero rivolgersi a esperti che conoscono realmente il settore. Le piccole aziende, il cui business è basato su soluzioni web, devono assolutamente affidarsi a persone esperte. Perché qualsiasi semplice errore in un sistema chiave equivale a una perdita di denaro.

— (DS) Sappiamo che le persone in Russia temono l'outsourcing — sia per esperienze negative che per altre ragioni. Ma i nostri clienti non ci lasciano. Negli ultimi dieci anni, se ne sono andati solo per due motivi: o ci hanno superato (ad esempio, sono stati acquisiti e hanno ristrutturato tutto), o hanno chiuso perché l'idea non ha funzionato.

— E chi viene da voi più spesso — piccole aziende o grandi?

— (DS) Al momento, entrambi. Ma le piccole hanno paura di noi, pensano che noi…

— (SB)… siamo grandi, complessi, inaccessibili e voliamo tra le nuvole.

— (DS) Certo, passi davanti a un concessionario con una Maybach e non entri, non chiedi il prezzo, perché una Maybach non può costare solo 500 mila rubli.

— Certo che no.

— (SB) Ma non appena appare nel car sharing, puoi permetterti di guidarla.

— (DS) Sì, certamente non siamo una Maybach — siamo Ikea. Anche noi offriamo qualcosa di semplice, affidabile e accessibile. In generale, il numero di aziende che si rivolgono a noi tra le TOP-50 e le piccole aziende è lo stesso. Ma ci concentriamo principalmente sulle piccole imprese e lavoriamo principalmente con loro, cercando di evitare collaborazioni con le grandi.

— Perché?

— (DS) C'è molta burocrazia.

— (SB) In una grande azienda ci sono molti livelli in cui è suddivisa la responsabilità, il feedback è molto lento e spesso le persone iniziano a complicare le cose: "Facciamo delle valutazioni, scriviamo una strategia, un piano per l'anno prossimo, facciamo le cose in modo che sia migliore per la cultura enterprise, così abbiamo lavorato fino adesso". Cominciano a complicare questioni che potrebbero essere risolte con un approccio semplice e diretto, portando il 80% del risultato già domani. Si prendono il percorso lungo dove non si sa nemmeno se funzionerà.

Di conseguenza, invece di pratiche consolidate, reinventiamo continuamente la ruota, e il costo della soluzione tecnologica diventa enormemente più alto. E la qualità non è garantita migliore.

Costo per l'outsourcing

Abbiamo molti progetti su GitHub, contribuiamo attivamente alla storia dell'open source. Non solo ai nostri, ma anche a quelli degli altri. Cerchiamo di condividere gli strumenti che utilizziamo ogni giorno. Crediamo che sia nostro dovere, e ci fa molto piacere farlo.

Tutti i ragazzi in azienda contribuiscono in un modo o nell'altro — con feedback, documentazione o codice. Crediamo che sia il nostro tributo per tutto quel ricco mondo di utilità open source che utilizziamo. E penso che stiamo contribuendo in modo adeguato.

Chiamiamo questo processo la condensazione dell'esperienza. Inizialmente, una persona ha imparato qualcosa, l'ha condiviso con i colleghi e quell'esperienza è diventata folklore. Poi abbiamo scritto la documentazione e successivamente l'abbiamo trasformata in utilità, dimenticando la sua esistenza, perché non ci pensiamo più — tutto viene registrato automaticamente.

La popolarità delle tecnologie e la tossicità degli sviluppatori

— Perché proprio Ubuntu? Cosa avete considerato prima di sceglierla?

— (DS) Eravamo un gruppo di studenti che amava Linux. Abbiamo usato a lungo Gentoo — è una distribuzione basata sul source, che deve essere compilata da zero ogni volta. Quando abbiamo avuto un paio di centinaia di server, l'aggiornamento richiedeva mesi. Inizialmente, abbiamo automatizzato e ottimizzato tutto, ma alla fine ci siamo resi conto che dovevamo cambiare qualcosa e, conoscendo i pro e i contro delle diverse soluzioni, abbiamo semplicemente scelto il più popolare. All'epoca era intuitivo — se era il più popolare, allora si svilupperà meglio e tutti i difetti saranno corretti prima o poi.

C'era un database chiamato Resync DB. Competivano con MongoDB e sono nati più o meno nello stesso periodo. Per molto tempo, Resync era tecnologicamente migliore.

Quando arrivavano gli utenti, cercavano di risolvere i problemi sistemici interni, mentre in MongoDB questi problemi venivano risolti molto meno, ma potevano impostare una condizione if per performare meglio nei test sintetici. Per questo motivo, la popolarità di MongoDB cresceva. Nei casi più semplici si comportavano meglio, ma internamente erano scadenti. Resync DB, d'altra parte, internamente era buono, ma non cresceva in popolarità.

Alla fine, per MongoDB tutto è migliorato, mentre nessuno si ricorda di Resync DB. L'azienda è andata in bancarotta. Ecco, la stessa storia riguarda Ubuntu. Questo sistema operativo ha molta attenzione, quindi abbiamo deciso di usarlo.

— Cosa ne pensi degli ultimi cambiamenti politici, CoC e simili?

— (DS) Beh… non c'è nulla di negativo, va tutto bene, è tutto chiaro. Anch'io soffro per il fatto che a volte ferisco le persone. A me, ad esempio, una cosa sembra ovvia, e comincio a infastidirmi terribilmente quando le persone non la capiscono. Mi arrabbio, e si crea una negatività (ma ci sto lavorando).

Linus è molto intelligente, dopo tutto lavora a questo da 30 anni. È chiaro che è una persona brusca, non le manda a dire. La sua cortesia ne risente, e la comunità sta lavorando su questo. Lui comprende tutto e lo ammette.

— Ma, come ho capito dalla reazione nelle discussioni, molte persone supportano l'idea di parlare in modo diretto e brusco, e se a qualcuno non piace — non è zucchero, non si scioglie.

— (DS) No, non è così. Io, essendo una persona che soffre per la mancanza di cortesia, capisco che sia molto male. Questo rovina la comunità. Ci sono persone a cui non importa, ma per la maggior parte delle persone è comunque importante avere un comfort emotivo.

Ecco, nel codice c'è un errore stupido. Si potrebbe dire: «Ragazzi, è brutto che trascuriamo tali cose semplici, dobbiamo correggerle». Oppure si potrebbe dire: «Quale idiota ha fatto questo?!». Una frase. Quella persona che ha commesso questo errore potrebbe anche essere più intelligente ed esperta di te, ma semplicemente non era dello spirito giusto quando ha sbagliato — chissà cosa gli è successo. E per lui sarà un'offesa diretta. A che serve?

Bisogna dire le cose direttamente, ma non bisogna dire «Quale idiota l'ha scritto». Non ha senso nascondere e avvolgere, ma non bisogna ferire le persone.

Perché i DevOps devono chiamarsi ogni giorno?

— (DS) Adesso abbiamo un piccolo ufficio, dove ci sono documenti e un office manager che si occupa di questi documenti.

In azienda ci sono 70 persone. 20 persone fanno parte del team OPS. 30 persone sono tre team DevOps di circa 10 persone ciascuno. Le restanti 20 sono sviluppatori e vendite. 8 sviluppatori, il reparto R&D — 4 persone. Persone non tecniche in tutta l'azienda sono 5-6.

I soldi chiave li guadagnano tre team DevOps. I processi sono gli stessi ovunque — ogni giorno c'è una lunga riunione, che dura un'ora o un'ora e mezza. Ma lì si trattano tutte le questioni tecniche, e i ragazzi decidono cosa fare dopo. E poiché tutti sono in remoto – è un'opportunità per comunicare adeguatamente.

— È davvero necessario ogni giorno?

— (DS) Sì.

— Tutti sono d'accordo su questo?

— (DS) Sì, tutti sono d'accordo e tutti si sentono a proprio agio. Ma in alcuni giorni l'incontro può durare anche 30 minuti. Nonostante la comunicazione molto intensa su Slack, si desidera comunque sincronizzarsi bene e capire cosa è successo ieri. Vogliamo capirci a vicenda, non semplicemente fare clic su compiti.

— (SB) In ogni momento può succedere qualcosa, la situazione può cambiare. È necessaria una continua correzione.

— (DS) Hai una buona barzelletta su questo tema.

— (SB) Sì. Un cardiochirurgo arriva in un centro auto e il meccanico gli dice: «Senti, ci occupiamo della stessa cosa, solo che tu operi il cuore di una persona e io quello di un'auto. Tu guadagni 10.000$ per un'operazione, mentre io per un servizio prendo 100 rubli.

Il chirurgo chiede: «Vuoi anche tu guadagnare 10.000 per una riparazione?» Il meccanico risponde — certo. Il chirurgo si siede in macchina, la avvia e dice — «facciamo il lavoro».

Anche da noi. Nello sviluppo puoi prendere un compito e portare il risultato dopo due settimane. Poi tutto può essere corretto, perché più o meno tre giorni non influenzano nulla.

Nel nostro caso, ogni allerta ignorata o decisione sbagliata riguardo a un allerta può diventare un grande problema. Per evitare ciò, è necessaria una comunicazione stretta, veloce e costante.

È difficile passare al lavoro da remoto?

È difficile gestire le persone da remoto. Ma è difficile finché sei in un ufficio e loro in un altro, e c'è una certa confusione mentale. Sei a Mosca e ti sembra che quelli di Nizhny stiano lavorando male, in modo inefficace. A Mosca vedi gli sforzi delle persone intorno, mentre non vedi quelli dei remote worker. Prendi solo il risultato.

In ufficio molte comunicazioni avvengono in modo informale — qualcuno dice qualcosa a qualcuno mentre passa sulla cucina. Le persone in un altro ufficio non vedono, non sentono, e il contesto si perde.

Quando eravamo già pronti a rinunciare all'ufficio, tutte le comunicazioni (anche tra i dipendenti nello stesso ambiente) avvenivano attraverso Google Meet. E quando abbiamo organizzato tutta la comunicazione da remoto, ha funzionato al 100%, tutte le barriere di incomprensione sono state rimosse.

Organizzare tutto è difficile, ma se fai tutto nel modo giusto — funziona e non causa alcun disagio.

Come gestiscono autonomamente i loro soldi le squadre?

— Il lavoro a distanza è una questione controversa. A volte le aziende temono di lasciare le persone a casa perché pensano di perdere il controllo su di esse. Ma coloro che lasciano andare, dicono anche che bisogna lavorare in modo completamente diverso.

— (DS) Abbiamo risolto questo problema offrendo di condividere i soldi con i team. La nostra economia e il sistema di incentivazione sono costruiti quasi come una franchigia. Gli stipendi sono abbastanza alti, oltre a lasciare ai ragazzi una parte di denaro libero.

Il team gestisce un insieme di progetti. Sanno quanto guadagna ciascuno di questi progetti. Sanno esattamente la loro quota di questi soldi. Tutti i soldi che rimangono oltre il loro stipendio restano nel team e vengono divisi tra di loro secondo un certo sistema. La motivazione è assolutamente diretta: prendi un progetto per ulteriori 200.000, aumenti di dieci in stipendio. Fai un errore — devi risarcire il cliente.

— (SB) Se inizi a deludere i ragazzi, questo si sente subito. Ti privi della possibilità di ricevere un reddito aggiuntivo. E il nostro sistema risolve completamente il problema del controllo. Ogni persona pianifica la propria giornata e le riunioni quotidiane sono sufficienti per capire chi sta facendo cosa.

— (DS) In condizioni di guerra, i compagni in trincea non mentono.

— Quindi, avete stipendi trasparenti? Tutti sanno quanto guadagna ciascuno?

— (DS) Abbiamo chiuso gli stipendi qualche tempo fa. C'è una differenza regionale. Nonostante ci sforziamo di pagare integralmente gli stipendi di Mosca nelle regioni, c'è comunque un certo dissonanza.

— (SB) Ora tutti sanno quanto denaro c'è in totale per il team. Vedono quale quota dei bonus ricevono.

— (DS) Il team lead di ogni squadra decide quanto guadagneranno i suoi ragazzi e come distribuire i bonus. Ci interferiamo nella questione solo con dei consigli, la decisione rimane sempre al team lead.

Perché le persone hanno paura delle posizioni aperte

Celebrazione del decimo anniversario dell'azienda nel 2018

— 70 persone sono sufficienti per voi?

— (DS) No. Il nostro piano è di assumere almeno 20 ingegneri DevOps nell'arco di un anno. Ma è molto difficile. Abbiamo un buon numero di candidati, tutti sanno in qualche modo di noi. Ma qui la situazione è simile a quella con i clienti. Molti dicono: 'abbiamo paura di lavorare da voi, magari non ce la facciamo'. Ma non consideriamo di avere qui cose super complicate.

Corrispondenza con un candidato

— Come bisogna essere per farcela?

— (DS) Teoricamente, una persona dovrebbe essere sviluppata in modo uniforme nello sviluppo e nell'operazione. Nella pratica, tali persone nel mondo sono rare, per non parlare della Russia. Soprattutto quelli che sono senior in entrambi gli ambiti. Non mi considererei nemmeno tra di loro.

Nelle nostre offerte di lavoro è sempre ben scritto cosa è necessario sapere. Ci lavoriamo molto e cerchiamo di essere concreti.

— Forse le offerte di lavoro spaventano davvero se scritto quanto sia necessario sapere?

— (DS) No-no-no, non crediamo che sia necessario sapere molte cose.

— (SB) Siamo interessati non alle conoscenze, ma al pensiero critico e alla capacità di trovare soluzioni.

— (DS) Ci interessa l'esperienza in Linux, e la verifichiamo con compiti abbastanza semplici — semplicemente un gran numero di compiti. Il nostro test è piuttosto lungo, per un candidato medio dura 8 ore. E alla fine guardiamo come la persona ha affrontato i problemi, come cerca su Google, quale è la sua visione del mondo.

Le conoscenze si possono acquisire molto rapidamente, perché abbiamo molti progetti diversi e colleghi esperti che sono sempre disponibili a suggerire. Quindi guardiamo prima di tutto per vedere se i ragazzi capiscono rapidamente e hanno esperienza.

— Oltre al test, come lo individuate?

— (DS) Abbiamo tre fasi. Inizialmente parla il reclutatore, chiedendo di raccontare l'esperienza. Poi quelli che piacciono al reclutatore svolgono un compito di prova. Alla fine parlano i team leader e danno le loro opinioni al reclutatore, e se sono tutte positive — è l'occasione per fare un'offerta.

500 mila rubli per assumere il futuro supereroe

— (DS) Abbiamo un approccio molto atipico verso le finanze, condividiamo con i team e non siamo avari. E poi diamo al team 500 mila rubli per espandere il personale. Cioè, è una sovvenzione affinché possano trovare una persona e insegnarle tutto, mentre si integra.

— 500 mila per persona?!

Per far guadagnare molto denaro al team, devono assumere più progetti. Per questo hanno bisogno di più persone. E per assumere più persone — servono più soldi. Questo è un circolo vizioso. Per rompere questo circolo, diamo soldi per una nuova persona. Finché si integra, possono prendere altri progetti e già con quei soldi pagargli lo stipendio. Cioè, è una compensazione, finché il nuovo non porta denaro.

— E non è troppo per i DevOps? Sono sotto pressione ogni giorno, sempre in condizioni operative, e devono anche occuparsi della gestione finanziaria.

— (DS) Questo è compito del team leader, che non è più del tutto un DevOps. I team leader tendono piuttosto verso il partnership per avere opzioni. Pertanto, riteniamo che sia normale per loro. Gli altri membri del team non ne sono coinvolti.

In parole povere, sanno che se un collega si ritira, il mese successivo riceveranno il suo stipendio. Ovviamente, dovranno lavorare di più. E quando trovano una sostituzione, restituiscono indietro quei soldi.

Quando diamo ai team leader 500.000, non vogliono assumere qualcuno che non sia all'altezza. A volte è più semplice scartare 20 persone e prenderne una. È successo che con l'HR abbiano parlato con 100 persone, 30 di loro hanno seguito un compito tecnico, 20 hanno passato, e tutti tranne uno sono stati scartati dal team leader. È andata così. I team leader temono molto di rischiare. Abbiamo discusso di questo tema e sembrava che tutti avessero capito che era un errore. Molte persone si mostrano in modo diverso durante il colloquio rispetto a come si comporteranno nel lavoro. È quindi necessario dare una possibilità e assumere dei rischi.

— I team leader non abusano della situazione? Ricevi 500.000, non assumi per molto tempo, ricevi altri 500.000.

— (DS) Ricevono i soldi una sola volta. Diciamo: «Avete attualmente dieci persone, ma ne servono undici. C'è un piano di vendita, arriveranno altri progetti e dovete essere pronti. Ecco 500.000 per l'undicesima posizione». Non li riceverai una seconda volta. Se qualcun altro se ne va, è già un problema del team; devono risolvere la questione nei loro budget.

È come giocare a Monopoli.

— (SB) Riteniamo che un team leader debba essere coinvolto nelle finanze. Da noi, le persone ricevono il proprio stipendio dai soldi che guadagnano. E il livello di spesa del progetto è molto importante. Un cliente arriva con una certa infrastruttura, e dopo un anno la sua infrastruttura è dieci volte più grande. E se il team leader non partecipa alle finanze, non sarà in grado di valutare correttamente il costo di manutenzione.

— (DS) A volte, il team combatte per mesi con i problemi del cliente, comprendendo che vengono pagati per questo circa cento mila, e ciò non corrisponde affatto a quanto sta accadendo. E, per quanto possa fare male, devono decidere se alzare il prezzo o separarsi. E i ragazzi prendono queste decisioni da soli. Considerando che lavorano tutti da remoto. E riteniamo che questo sia un nostro grande traguardo. Abbiamo team veramente autonomi e motivati.

— Sì. E da questo sembra che bisogna essere Superman per lavorare qui. Serve sia abilità tecniche, sia autodisciplina, sia conoscenza finanziaria.

— (SB) Da noi puoi diventare Superman. Ma anche i team leader che sanno farlo sono partiti come normali ingegneri. Bastano uno o due anni per diventare un supereroe di questo tipo.

— I team leader partner sono cresciuti da ingegneri normali. Possono essere assunti direttamente per una posizione del genere?

— (DS) Non è mai successo da noi, tutti sono cresciuti come ingegneri. Ma stiamo considerando l'idea di unirci a una piccola azienda che diventerà semplicemente un altro nostro team. Vorremmo provare una cosa del genere.

— Puoi prendere una persona se è un buon ingegnere, ma non è abbastanza organizzato per il livello di tali team?

— (DS) Non temiamo le persone disorganizzate, abbiamo un flusso costante di compiti. Si capisce molto rapidamente se si può aiutare una persona a organizzarsi. Se racconta ogni giorno cosa ha fatto, senza fare niente di concreto, si sentirà in imbarazzo.

Quando vedi che tutti sono sulla stessa barca e remano, ti senti a disagio a lasciare l'ancora. In tali condizioni, anche le persone disorganizzate diventano organizzate. E se no, non lo saranno.

Non tolleriamo affatto la superficialità — né nelle persone, né nelle cose, né in noi stessi. E venendo qui, le persone si sviluppano molto rapidamente, tre volte più veloci che altrove. Qui davvero si accumula esperienza e competenze al ritmo di un anno ogni tre.

Non ci piacciono affatto i mid-level superficiali. Dal nostro punto di vista, un mid può già fare molte cose. Dico come stanno le cose — il mercato del DevOps è estremamente frastagliato. Ci sono mid che si considerano junior. Ci sono junior che si considerano senior. Una persona che arriva da noi comprende molto rapidamente il proprio livello reale.

Ciò non significa che non assumiamo junior — li prendiamo con piacere e ne assumeremo ancora di più. Stiamo già creando un team speciale chiamato 'DevOps-Accelerator' e assegneremo progetti a cui possiamo rischiare, dove il cliente è disposto a farci correre dei rischi. Probabilmente nascerà anche un servizio speciale per questo. Qualcosa come 'Flant-Light'.

— Vorreste diventare una grande corporation?

— (DS) Ci piacerebbe, ma con una condizione. Non vogliamo perdere la nostra cultura. Cresceremo di certo, ma mantenere la cultura tecnica e di lavoro è anche più importante dello sviluppo stesso.

La vita è una sola, comunque non si possono guadagnare tutti i soldi del mondo e si desidera viverla accanto a persone buone. Siamo categoricamente contrari alla burocrazia e alla simulazione di lavoro utile. Abbiamo relazioni assolutamente orizzontali. È possibile esprimere anche il proprio pensiero alla direzione in modo molto diretto: l'essenza è più importante delle formalità.

— (SB) Ma per questo è necessario avere argomenti molto solidi.

— (DS) Sicuramente! E il lavoro a distanza è necessario, perché viviamo così, vediamo il mondo in questo modo. Dima Shurupov vive in Thailandia, io in Germania. Sasha Batalov a Mosca, il direttore delle risorse umane a Tyumen.

Riteniamo che vivendo su questo pianeta, si desideri vivere la vita, osservandola. Vivere in condizioni in cui andare a lavoro è sgradevole — non è necessario. Ecco perché vogliamo che si desideri andare al lavoro. Conflittare a lavoro — è sicuramente sgradevole, quindi facciamo in modo che non ci siano conflitti. Abbiamo discussioni e battaglie, ma non conflitti.

— Non pensa che diventare grandi significhi non solo fornire servizi, ma anche produrre. Che non basta vivere la vita e vedere il pianeta, ma è necessario anche lasciare qualcosa?

— (DS) È una questione molto delicata per noi, perché siamo un'azienda di servizi. Ma facciamo molto software, e in sostanza il nostro prodotto sono servizi con un'efficacia completamente diversa. Non abbiamo mai venduto ore o persone a nessuno. I clienti venivano sempre e chiedevano — "è possibile acquistare cento ore"? No, non è possibile, non vendiamo ore.

Noi vendiamo risultati. Il risultato è che alleviamo il dolore, risolviamo un problema. E noi risolviamo non come ci hanno detto, ma come sappiamo fare. Il nostro prodotto è la nostra esperienza. E sicuramente faremo soluzioni pronte, prodotti SaaS, ci sono molte idee. Ma non c'è fretta. Davanti abbiamo molti decenni.

Fonte: habr.com