motto:
Mies, katsoessaan likaisia lapsia, sanoo vaimolleen: no, pestäänkö nämä vai synnytetäänkö uusia?
Leikkauksen alla on toinen osa tiimimme johtajan sekä RAS:n tuotekehitysjohtajan Igor Marnatin artikkelista ohjelmoijien motivoinnin erityispiirteistä. Artikkelin ensimmäinen osa löytyy täältä -
Artikkelin ensimmäisessä osassa kosketin Maslowin pyramidin kahta alempaa tasoa: fysiologisia tarpeita, turvallisuuden, mukavuuden ja pysyvyyden tarpeita ja siirryin seuraavalle, kolmannelle tasolle, nimittäin:
III - Tarve kuulumiseen ja rakkauteen
Tiesin, että italialaista mafiaa kutsutaan nimellä "Cosa Nostra", mutta olin erittäin vaikuttunut, kun sain tietää, kuinka "Cosa Nostra" käännetään. "Cosa Nostra" italian kielestä käännettynä tarkoittaa "yrityksemme". Nimenvalinta on motivaation kannalta erittäin onnistunut (jätetään ammatti syrjään, tässä tapauksessa meitä kiinnostaa vain motivaatio). Ihminen haluaa yleensä olla osa tiimiä, tehdä jotain suurta, yhteistä liiketoimintaamme.
Armeijassa, laivastossa ja kaikissa suurissa puolisotilaallisissa kokoonpanoissa kuulumisen ja rakkauden tarpeen tyydyttäminen on erittäin tärkeää. Ja kuten näemme, mafiassa. Tämä on ymmärrettävää, koska täytyy pakottaa ihmisiä, joilla on vähän yhteistä, jotka eivät alun perin muodosta samanhenkistä ryhmää, jotka kokoaa yhteen asevelvollisuus (ei vapaaehtoisesti), joilla on eri koulutustaso, erilaiset henkilökohtaiset arvot. , kirjaimellisesti omistaa elämänsä kuolemanvaarassa johonkin yhteiseen tarkoitukseen, uskoa elämäsi asetoverillesi.
Tämä on erittäin vahva motivaatio; useimmille ihmisille on erittäin tärkeää tuntea kuuluvansa johonkin suurempaan, tietää olevansa osa perhettä, maata, tiimiä. Armeijassa univormut, erilaiset rituaalit, paraatit, marssit, bannerit ja niin edelleen palvelevat näitä tarkoituksia. Suunnilleen samat tekijät ovat tärkeitä mille tahansa joukkueelle. Symbolit, yritysbrändit ja yritysvärit, varusteet ja matkamuistot ovat tärkeitä.
On tärkeää, että merkittävillä tapahtumilla on oma näkyvä ilmentymä, johon ne voidaan yhdistää. Nykyään on melko normaalia, että yrityksellä on omat tavarat, takit, t-paidat jne. Mutta on myös tärkeää korostaa tiimiä yrityksen sisällä. Julkaisemme usein T-paitoja julkaisun tulosten perusteella, jotka jaetaan kaikille julkaisuun osallistuville. Jotkut tapahtumat, yhteiset juhlat tai aktiviteetit koko tiimin kanssa ovat toinen tärkeä motivaatiotekijä.
Ulkoisten ominaisuuksien lisäksi monet muut tekijät vaikuttavat tiimiin kuulumisen tunteeseen.
Ensinnäkin yhteisen tavoitteen olemassaolo, jonka kaikki ymmärtävät ja jonka tärkeydestä jaetaan. Ohjelmoijat haluavat yleensä ymmärtää, että he tekevät hienoa asiaa, ja he tekevät tämän hienon asian yhdessä, tiiminä.
Toiseksi, tiimillä tulee olla viestintätila, jossa koko tiimi on läsnä ja joka kuuluu vain sille (esim. chat messengerissä, säännölliset tiimisyncapit). Työasioiden lisäksi epävirallinen kommunikointi, joskus keskustelu ulkoisista tapahtumista, valo offtop - kaikki tämä luo yhteisöllisyyden ja tiimin tunnetta.
Kolmanneksi korostan hyvien suunnittelukäytäntöjen käyttöönottoa tiimissä, halua nostaa standardeja verrattuna yhtiössä hyväksyttyihin. Toimialalla hyväksyttyjen parhaiden lähestymistapojen toteuttaminen ensin tiimissä ja sitten koko yrityksessä antaa tiimille mahdollisuuden kokea olevansa jollain tavalla muita edellä, tiennäyttäjänä, mikä luo yhteenkuuluvuuden tunnetta viileään tiimiin.
Yhteyden tunteeseen vaikuttaa myös tiimin osallistuminen suunnitteluun ja johtamiseen. Kun tiimin jäsenet ovat mukana keskustelemassa projektin tavoitteista, työsuunnitelmista, tiimistandardeista ja suunnittelukäytännöistä sekä haastattelevat uusia työntekijöitä, he kehittävät osallistumisen tunnetta, yhteisomistusta ja vaikuttamista työhön. Ihmiset ovat paljon halukkaampia toteuttamaan itsensä tekemiä ja ääneen antamia päätöksiä kuin muiden ehdottamia, vaikka ne olisivat käytännössä sopusoinnussa.
Syntymäpäivät, vuosipäivät, merkittävät tapahtumat kollegoiden elämässä - yhteinen pizza, pieni lahja tiimiltä antavat lämpimän osallistumisen ja kiitollisuuden tunteen. Joissakin yrityksissä on tapana antaa pieniä muistomerkkejä 5, 10, 15 vuoden työstä yrityksessä. Toisaalta en usko, että tämä motivoi minua niin paljon uusiin saavutuksiin. Mutta ilmeisesti melkein jokainen on iloinen siitä, että he eivät ole unohtaneet häntä. Tämä on yksi niistä tapauksista, joissa tosiasian puuttuminen demotivoi ennemmin kuin sen läsnäolo motivoi. Samaa mieltä, voi olla aika sääli, jos LinkedIn muistutti sinua aamulla ja onnitteli sinua 10-vuotispäiväsi johdosta työpaikallasi, mutta yksikään kollega yrityksestä ei ole onnitellut tai muistanut sinua.
Tärkeä asia on tietysti joukkueen kokoonpanon muutos. On selvää, että vaikka jonkun tiimin jäsenen saapumisesta tai lähtemisestä ilmoitettaisiin etukäteen (esimerkiksi yrityksen tai tiimin uutiskirjeessä tai tiimikokouksessa), se ei motivoi ketään erityisesti uusiin saavutuksiin. Mutta jos eräänä kauniina päivänä näet vieressäsi uuden henkilön tai et näe vanhaa, se voi olla yllätys, ja jos lähdet, suorastaan epämiellyttävä. Ihmisten ei pitäisi kadota hiljaa. Varsinkin hajautetussa tiimissä. Varsinkin jos työsi riippuu kollegasta toisesta toimistosta, joka yhtäkkiä nousi ja katosi. Tällaisista hetkistä kannattaa ehdottomasti ilmoittaa joukkueelle erikseen etukäteen.
Tärkeä tekijä, jota englanniksi kutsutaan omistus ("omistuksen" kirjaimellinen käännös ei täysin heijasta sen merkitystä). Tämä ei ole omistajuuden tunne, vaan pikemminkin vastuun tunne projektistasi, se tunne, kun yhdistät itsesi emotionaalisesti tuotteeseen ja tuotteen itseesi. Tämä vastaa karkeasti merijalkaväen rukousta elokuvassa "Full Metal Jacket": "Tämä on kiväärini. Tällaisia kiväärejä on monia, mutta tämä on minun. Kiväärini on paras ystäväni. Hän on elämäni. Minun on opittava omistamaan se samalla tavalla kuin omistan elämäni. Ilman minua kiväärini on hyödytön. Olen hyödytön ilman kivääriäni. Minun täytyy ampua kivääri suoraan. Minun täytyy ampua tarkemmin kuin vihollinen, joka yrittää tappaa minut. Minun täytyy ampua hänet ennen kuin hän ampuu minut. Olkoon niin…".
Kun ihminen työskentelee tuotteen parissa pitkään, hänellä on mahdollisuus kantaa täysi vastuu sen luomisesta ja kehittämisestä, nähdä kuinka toimiva asia syntyy "ei-mitään", kuinka ihmiset käyttävät sitä, syntyy tämä voimakas tunne. Tuotetiimit, jotka työskentelevät yhdessä pitkään yhdessä projektissa, ovat yleensä motivoituneempia ja yhtenäisempiä kuin lyhyeksi ajaksi kootut tiimit, jotka työskentelevät kokoonpanolinjatilassa, siirtyen projektista toiseen ilman täyttä vastuuta koko tuotteesta. , alusta loppuun.
IV. Pätemisentarve
Myös ystävällinen sana miellyttää kissaa. Kaikkia motivoi tunnustus tekemänsä työn tärkeydestä ja myönteinen arvio. Keskustele ohjelmoijien kanssa, anna heille säännöllistä palautetta, juhli hyvin tehdystä työstä. Jos sinulla on suuri ja hajautunut tiimi, säännölliset kokoukset (jota kutsutaan yksitellen) sopivat tähän täydellisesti; jos tiimi on hyvin pieni ja työskentelee yhdessä paikallisesti, tämä tilaisuus tarjotaan yleensä ilman erityisiä tapaamisia kalenterissa (vaikka määräajoin). yhdelle on kaikki se on edelleen tarpeen, voit vain tehdä sen harvemmin). Tätä aihetta käsitellään hyvin manager-tools.com-sivuston johtajille tarkoitetuissa podcasteissa.
Kulttuurierot kannattaa kuitenkin pitää mielessä. Jotkut amerikkalaisille kollegoille tutut lähestymistavat eivät aina toimi venäläisten kanssa. Länsimaiden ryhmien päivittäisessä viestinnässä hyväksytty kohteliaisuus vaikuttaa aluksi liioitellulta venäläisistä ohjelmoijista. Venäläisille kollegoille tyypillinen suorapuheisuus saattaa kokea töykeyden muiden maiden kollegoille. Tämä on erittäin tärkeää etnisten ryhmien viestinnässä, tästä aiheesta on kirjoitettu paljon, tällaisen tiimin johtajan on muistettava tämä.
Ominaisuusesittelyt, joissa ohjelmoijat näyttävät sprintin aikana kehitettyjä ominaisuuksia, ovat hyvä käytäntö tämän tarpeen toteuttamiseksi. Sen lisäksi, että tämä on erinomainen tilaisuus selvittää tiimien välisiä viestintäkanavia, esitellä tuotepäälliköitä ja testaajia uusiin ominaisuuksiin, se on myös kehittäjille hyvä tilaisuus esitellä työnsä tuloksia ja ilmoittaa tekijänsä. No, ja hio julkisen puhumisen taitojasi tietysti, mikä ei ole koskaan haitallista.
Erityisen ansioituneiden työtovereiden merkittävää panosta olisi hyvä juhlistaa todistuksilla, muistomerkeillä (ainakin hyvällä sanalla) yhteisissä tiimitapaamisissa. Ihmiset arvostavat tällaisia todistuksia ja muistomerkkejä yleensä erittäin paljon, ottavat ne mukanaan muuttaessaan ja yleensä huolehtivat niistä kaikin tavoin.
Merkittävämpää, pitkäaikaisempaa panosta joukkueen työhön, kertynyttä kokemusta ja asiantuntemusta käytetään usein arvosanajärjestelmää (jälleen voidaan vetää analogia armeijan sotilasarvojärjestelmän kanssa, joka lisäksi alisteisuuden varmistamiseen, palvelee myös tätä tarkoitusta). Usein nuoret kehittäjät työskentelevät kaksi kertaa enemmän saadakseen uusia tähtiä olkahihnoilleen (eli siirtyvät nuoresta kehittäjästä kokopäiväiseksi kehittäjäksi jne.).
On tärkeää tuntea ihmisten odotukset. Jotkut ovat todennäköisemmin motivoituneita korkeasta arvosanasta, mahdollisuudesta tulla kutsutuksi esimerkiksi arkkitehdiksi, kun taas toiset päinvastoin suhtautuvat välinpitämättömästi arvosanoihin ja arvonimikkeisiin ja pitävät palkankorotusta yrityksen tunnustuksena. . Kommunikoi ihmisten kanssa ymmärtääksesi, mitä he haluavat ja mitä he odottavat.
Tunnustuksen osoitus, tiimin korkeampi luottamus voidaan antaa antamalla enemmän toimintavapautta tai osallistumista uusille työalueille. Esimerkiksi saatuaan tietyn kokemuksen ja saavuttanut tiettyjä tuloksia, ohjelmoija voi sen lisäksi, että hän toteuttaa ominaisuuksiaan spesifikaation mukaisesti, työstää uusien asioiden arkkitehtuuria. Tai osallistu uusille alueille, jotka eivät välttämättä liity suoraan kehittämiseen - testausautomaatio, parhaiden suunnittelukäytäntöjen käyttöönotto, julkaisuhallinnan auttaminen, konferensseissa puhuminen jne.
V. Kogniation ja itsensä toteuttamisen tarve.
Monet ohjelmoijat ovat keskittyneet erilaisiin ohjelmointitoimintoihin elämänsä eri vaiheissa. Jotkut ihmiset haluavat tehdä koneoppimista, kehittää uusia tietomalleja, lukea paljon tieteellistä kirjallisuutta työskentelyä varten ja luoda jotain uutta tyhjästä. Toinen on lähempänä virheenkorjausta ja olemassa olevan sovelluksen tukemista, jossa sinun on kaivettava syvälle olemassa olevaa koodia, tutkittava lokeja, pinottava jäljitys ja verkon captchas päivien ja viikkojen ajan ja kirjoitettava melkein mitään uutta koodia.
Molemmat prosessit vaativat paljon älyllistä työtä, mutta niiden käytännön tuotos on erilainen. Ohjelmoijien uskotaan olevan haluttomia tukemaan olemassa olevia ratkaisuja, vaan he ovat motivoituneita kehittämään uusia. Tässä on viisauden siemen. Toisaalta motivoitunein ja yhtenäisin tiimi, jonka kanssa olen koskaan työskennellyt, oli omistautunut tukemaan olemassa olevaa tuotetta, löytämään ja korjaamaan virheitä tukitiimin ottamisen jälkeen. Kaverit elivät kirjaimellisesti tälle työlle ja olivat valmiita lähtemään ulos lauantaisin ja sunnuntaisin. Käsittelimme kerran innokkaasti toista kiireellistä ja monimutkaista ongelmaa, joko 31. joulukuuta iltana tai 1. tammikuuta iltapäivällä.
Useat tekijät vaikuttivat tähän korkeaan motivaatioon. Ensinnäkin se oli alalla iso nimi yhtiö, johon tiimi liittyi (katso "The Need for Affiliation"). Toiseksi, he olivat viimeinen raja, heidän takanaan ei ollut ketään, tuolloin ei ollut tuotetiimiä. Heidän ja asiakkaiden välillä oli kaksi tukitasoa, mutta jos ongelma tavoitti heidät, ei ollut minnekään perääntyä, kukaan ei ollut heidän takanaan, koko yhtiö oli heidän puolellaan (neljä nuorta ohjelmoijaa). Kolmanneksi tällä suurella yrityksellä oli erittäin suuria asiakkaita (maiden hallitukset, auto- ja lentoyhtiöt jne.) ja erittäin suuria laitoksia useissa maissa. Tämän seurauksena aina monimutkaiset ja mielenkiintoiset ongelmat, yksinkertaiset ongelmat ratkaistiin aiempien tasojen tuella. Neljänneksi tiimin motivaatioon vaikutti suuresti sen tukitiimin ammattitaito, jonka kanssa he olivat vuorovaikutuksessa (siellä oli erittäin kokeneita ja teknisesti päteviä insinöörejä), ja olimme aina varmoja heidän laatimiensa tietojen laadusta ja heidän tekemästään analyysistä. , jne. Viidenneksi, ja tämä on mielestäni tärkein kohta - joukkue oli hyvin nuori, kaikki kaverit olivat uransa alussa. He olivat kiinnostuneita tutkimaan suurta ja monimutkaista tuotetta, ratkaisemaan heille uusia vakavia ongelmia uudessa ympäristössä, he pyrkivät ammattitaitoisesti vastaamaan ympäröivien tiimien, ongelmien ja asiakkaiden tasoon. Projekti osoittautui erinomaiseksi kouluksi, kaikki tekivät myöhemmin hyvän uran yrityksessä ja heistä tuli teknisiä johtajia ja ylimpiä johtajia, yksi heistä on nyt tekninen johtaja Amazon Web Servicesissä, toinen muutti lopulta Googlelle ja kaikki heistä muistaa tämän projektin edelleen lämmöllä.
Jos tämä tiimi koostuisi ohjelmoijista, joilla on takanaan 15-20 vuoden kokemus, motivaatio olisi toinen. Ikä ja kokemus eivät tietenkään ole sataprosenttisesti määrääviä tekijöitä, vaan kaikki riippuu motivaation rakenteesta. Tässä nimenomaisessa tapauksessa nuorten ohjelmoijien tiedon- ja kasvuhalu tuotti erinomaisia tuloksia.
Yleensä, kuten olemme jo useaan otteeseen maininneet, sinun on tunnettava ohjelmoijasi odotukset, ymmärrettävä, ketkä heistä haluaisivat laajentaa tai muuttaa toiminta-alaansa, ja otettava nämä odotukset huomioon.
Maslow'n pyramidin takana: tulosten näkyvyys, pelillistyminen ja kilpailu, ei paskaa
Ohjelmoijien motivaatiossa on vielä kolme tärkeää asiaa, jotka on ehdottomasti mainittava, mutta niiden vetäminen Maslowin tarpeiden malliin olisi liian keinotekoista.
Ensimmäinen on tuloksen näkyvyys ja läheisyys.
Ohjelmistokehitys on yleensä maraton. T&K-työn tulokset näkyvät kuukausien, joskus vuosien kuluttua. On vaikea mennä tavoitteeseen, joka on kaukana horisontin takana, työn määrä on pelottavaa, tavoite on kaukana, epäselvä ja näkymätön, "yö on pimeä ja täynnä kauhuja." On parempi katkaista tie siihen osiin, tehdä polku lähimpään puuhun, joka on näkyvä, tavoitettavissa, ääriviivat ovat selkeät, eikä se ole kaukana meistä - ja mennä tähän läheiseen päämäärään. Haluamme ponnistella useita päiviä tai viikkoja, saada ja arvioida tulos ja jatkaa sitten eteenpäin. Siksi työ kannattaa jakaa pieniin osiin (sprintit ketterissä palvelevat tätä tarkoitusta hyvin). Olemme saaneet osan työstä valmiiksi - äänittäneet sen, hengitämme ulos, keskustelimme siitä, rankaisimme syyllisiä, palkitsimme viattomia - voimme aloittaa seuraavan syklin.
Tämä motivaatio on jossain määrin samanlainen kuin mitä pelaajat kokevat pelatessaan tietokonepelejä: he saavat ajoittain mitaleja, pisteitä ja bonuksia suorittaessaan jokaisen tason; tätä voidaan kutsua "dopamiinimotivaatioksi".
Samalla tuloksen näkyvyys on kirjaimellisesti tärkeää. Luettelon suljetun ominaisuuden tulisi muuttua vihreäksi. Jos koodi kirjoitetaan, testataan, vapautetaan, mutta ohjelmoijan visuaalisessa tilassa ei ole muutosta, hän tuntee olevansa epätäydellinen, valmistumisen tunnetta ei ole. Yhdessä versionhallintajärjestelmämme tiimissä jokainen korjaustiedosto kävi läpi kolme peräkkäistä vaihetta - koontiversio koottiin ja testit läpäisivät, korjaustiedosto läpäisi koodin tarkistuksen, korjaustiedosto yhdistettiin. Jokainen vaihe oli visuaalisesti merkitty vihreällä rastilla tai punaisella ristillä. Kun yksi kehittäjistä valitti, että koodin tarkistus kesti liian kauan, kollegoiden piti nopeuttaa, korjaustiedostot roikkuivat useita päiviä. Kysyin, mitä tämä oikeastaan muuttaa hänen kannaltaan? Loppujen lopuksi, kun koodi on kirjoitettu, rakenne on koottu ja testit ovat läpäisseet, hänen ei tarvitse kiinnittää huomiota lähetettyyn korjaustiedostoon, jos kommentteja ei ole. Kollegat itse tarkistavat ja hyväksyvät sen (jos taaskaan ei ole kommentteja). Hän vastasi: "Igor, haluan saada kolme vihreää punkkiani mahdollisimman pian."
Toinen kohta on pelillistäminen ja kilpailu.
Yhtä tuotetta kehitettäessä suunnittelijatiimimme tavoitteena oli saada näkyvä asema jonkin avoimen lähdekoodin tuotteen yhteisössä ja päästä kolmen parhaan joukkoon. Tuolloin ei ollut objektiivista tapaa arvioida jonkun näkyvyyttä yhteisössä; jokainen suuri osallistuva yritys saattoi väittää (ja väitti ajoittain) olevansa ykkönen, mutta osallistujien panoksia ei ollut todellista vertailla. keskenään arvioidakseen sen dynamiikkaa ajoissa. Näin ollen joukkueelle ei ollut mahdollista asettaa tavoitetta, jota voitaisiin mitata joissakin papukaijoissa, arvioida sen saavutusastetta jne. Tämän ongelman ratkaisemiseksi tiimimme on kehittänyt työkalun yritysten ja yksittäisten osallistujien panoksen mittaamiseen ja visualisointiin . Motivoinnin näkökulmasta se osoittautui vain pommiksi. Se ei ollut vain insinöörit ja tiimit, jotka seurasivat jatkuvasti edistymistään sekä kollegoidensa ja kilpailijoidensa edistymistä. Myös yrityksemme ylin johto ja kaikki suuret kilpailijat aloittivat päivänsä stackalyticsilla. Kaikesta tuli hyvin läpinäkyvää ja visuaalista, jokainen saattoi tarkkailla edistymistään, verrata kollegoihinsa jne. Tavoitteiden asettamisesta on tullut kätevää ja helppoa insinööreille, esimiehille ja työryhmille.
Tärkeä seikka, joka nousee esiin mitä tahansa kvantitatiivista mittausjärjestelmää toteutettaessa, on se, että heti kun olet ottanut ne käyttöön, järjestelmä pyrkii automaattisesti priorisoimaan näiden kvantitatiivisten mittareiden saavuttamisen laadullisten mittarien kustannuksella. Esimerkiksi suoritettujen koodien tarkistusten määrää käytetään yhtenä mittareista. On selvää, että koodin tarkistus voidaan tehdä eri tavoilla, voit viettää useita tunteja monimutkaisen korjaustiedoston perusteelliseen tarkasteluun ja tarkistamiseen testien avulla, suorittamalla se omalla penkilläsi, tarkistamalla asiakirjoja ja saada plus yhden arvostelun karmaasi, tai klikkaa sokeasti pari tusinaa parissa minuutissa, anna jokaiselle +1 ja saat plus kaksikymmentä karmaa. Oli koomisia tapauksia, joissa insinöörit napsautivat korjaustiedostoja niin nopeasti, että he antoivat +1 automaattisille korjauspäivityksille CI-järjestelmästä. Kuten myöhemmin vitsailimme, "menkää, mene, jenkins". Sitoumuksissa oli myös paljon ihmisiä, jotka kävivät koodin läpi koodin muotoilutyökaluilla, editoivat kommentteja, vaihtoivat pisteet pilkuiksi ja pumppasivat siten karmaaan. Asian käsittely on melko yksinkertaista: käytämme maalaisjärkeä ja kvantitatiivisten mittareiden lisäksi myös olennaisia, laadullisia. Tiimin työn tulosten käyttöaste, ulkopuolisten osallistujien määrä, testin kattavuuden taso, moduulien ja koko tuotteen vakaus, mittakaava- ja suorituskykytestauksen tulokset, ydinarvioijan olkapään saaneiden insinöörien määrä hihnat, projektien hyväksyminen ydinprojektiyhteisöön, suunnitteluprosessin eri vaiheiden kriteerien noudattaminen - kaikki nämä ja monet muut tekijät on arvioitava yksinkertaisten kvantitatiivisten mittareiden ohella.
Ja lopuksi kolmas kohta - Ei paskaa.
Kehittäjät ovat erittäin älykkäitä ihmisiä ja erittäin loogisia työssään. He viettävät 8-10 tuntia päivässä pitkien ja monimutkaisten loogisten ketjujen rakentamiseen, joten he näkevät niissä haavoittuvuuksia lennossa. Kun he tekevät jotain, he, kuten kaikki muutkin, haluavat ymmärtää, miksi he tekevät sen, mikä muuttuu parempaan suuntaan. On erittäin tärkeää, että tiimillesi asettamasi tavoitteet ovat rehellisiä ja realistisia. Huonon idean myyminen ohjelmointitiimille on huono idea. Idea on huono, jos et itse usko siihen, tai äärimmäisissä tapauksissa sinulla ei ole sisäistä eri mieltä ja sitoutumista (en ole samaa mieltä, mutta teen sen). Otimme kerran yrityksessä käyttöön motivaatiojärjestelmän, jonka yhtenä elementtinä oli sähköinen palautejärjestelmä. He sijoittivat paljon rahaa, veivät ihmisiä Amerikkaan koulutukseen, yleensä he sijoittivat täysillä. Kerran koulutuksen jälkeisessä keskustelussa yksi esimiehistä sanoi alaisilleen: ”Ajatus ei ole huono, näyttää toimivan. Itse en anna sinulle sähköistä palautetta, mutta sinä annat sen ihmisille ja vaadit sitä heiltä." Siinä se, mitään ei voi enää toteuttaa. Idea ei tietenkään päättynyt mihinkään.
Lähde: will.com