Avoimuus ja läpinäkyvyys – tiimin askelmat luottamukseen

Bloggaus Tänään aamulla keittäessäni toimistolla aamukahvia, minulle tuli hyvin outo olo. Ei – syynä ei ole eilisillan juhlinta (kirjoittaessani tätä on tiistai) eikä edes aamusmoothieen lisätty pakuriuute, vaan se, että kaffenpuruja suodattimeen lisätessäni minulle tuli ahaa-elämys: olemmeko ME Contribytellä avoimia? Mitä se avoimuus oikeasti tarkoittaa? Nämä kysymykset saivat pontta siitä, että oli muutamia asioita, joiden tilannetta en tiennyt – ja ajattelin että ehkä minun pitää kysyä. Ja sitten pysähdyin miettimään, että jos olisimme oikeasti avoimia, niin pitäisikö minun edes kysyä?

Jos minun pitää pyytää tietoa, niin missä on ongelma?

Siinä kahvin valumista odottaessani minulle tuli vielä toinen kysymys – mitä eroa on avoimuudella ja läpinäkyvyydellä (engl.: openness ja transparency). En ollut koskaan oikein pysähtynyt miettimään, mitä näillä sanoilla tarkoitetaan. Tarkoittavatko ne samaa asiaa? Molemmat pyrkivät kyllä siihen, että organisaatiossa olisi enemmän luottamusta, mutta miten nämä käsitteet eroavat; ja miksi Scrumissa käytetään nimenomaan “openness” termiä eikä “transparent” termiä?

Jos ovi on auki, se on avoin. Jos se on lasia, sen läpi näkee.

Kun asiaa tutkii, niin virallisesti termi avoimuus määritellään niin, että se tarkoittaa ehkä yksinkertaisimmillaan sitä, että on vastaanottavainen uusille ajatuksille ja palautteelle. Läpinäkyvyydellä taas tarkoitetaan sitä, että kaikki tieto ja toiminta on saatavilla tai nähtävillä. Termit eroavatkin siis hyvin paljon toisistaan. Jos joku sanoo, että meillä on kaikki avointa, se on ihan eri asia kuin se, että jos sanoo, että meillä on kaikki läpinäkyvää. Avoimuus on asenne ja läpinäkyvyys on tila tai toimintamalli. Tietenkin voi olla myös niin, että termit ymmärtää eri tavalla, ja jos tarkoittaa läpinäkyvyyttä, voi käyttää sanaa avoimuus. Ja ehkä toisinpäinkin.

Avoimuus voi siis tarkoittaa sitä, että tiimi voi kertoa, miten asiat etenee, mitä ongelmia on, ja esimerkiksi antaa ideoiden lentää ja palautetta annettaessa ei tarvitse kenenkään pelätä. Ideoita ei reaktionomaisesti kritisoida eikä kenenkään tarvitse arastella antaa huonoa palautetta tai siis kehotusta parantaa toimintaa. Läpinäkyvyys tarkoittaisi taas sitä, että tiimi pystyy pitämään kaiken työn ja tiedon kaikkien saatavilla ja helposti löydettävissä. Se voi myös tarkoittaa sitä, että kommunikaatiota on paljon, ja suuri osa siitä on “FYI”, eli pyytämättä annettua, tiedottavaa.

Läpinäkyvyys tulee ensin, avoimuus rakentuu sille

Avoimuus on ehkä myös kiinnostusta siitä, mitä muut tekevät. Voi olla niin että tekeminen organisaatiossa on hyvinkin läpinäkyvää, tieto ja tekeminen on kaikkien tiedossa. Mutta voi silti olla niin, että läpinäkyvässä organisaatiossa on ongelmia sen kanssa, että ei ollakaan avoimia.

Toisaalta, voi myös ajatella, että ihmiset voivat kokea ylimenevän liiallisen läpinäkyvyyden keinona kontrolloida omaa tekemistä. Jos tiimin tapana on kertoa kaikesta aina kaikille kaikki, miksi näin tehdään? Onko syynä tiedon jakaminen, vai kenties se, että annetaan muille mahdollisuus reagoida ja kontrolloida tekemistä? Toimiiko tällainen läpinäkyvyys luottamusta lisäävänä vai vähentävänä tekijänä?

Luottamusportaikon askelmat

Ehkä voisi ajatella, että tietyntasoinen läpinäkyvyys tarvitaan, jotta voitaisiin mennä todella arvokkaaseen ja avoimeen tiimityöhön. Ja lopputulos, kolmas askelma mihin näillä päästään, on lisääntynyt luottamus.

Mutta voi olla myös, että liiallinen läpinäkyvyys haittaa tiimiä, tulee liikaa taustahälinää ja ihmisille olo, että ei enää pysty keskittymään tärkeään, ja enkö saa hoitaa mitään ilman että kerron siitä muille. “Läpinäkyvyysaskelma” on liian korkea.

Mutta todelliseen luottamukseen ei kuitenkaan riitä pelkkä avoimuus, vaan tarvitaan myös sopivasti läpinäkyvyyttä. Eli liian vähän läpinäkyvyyttä, niin avoimuusaskelma on liian korkea.

Pitäkääpä oman luottamusportaikon askelmanne sopivan korkuisina! Avoimin terveisin Agile-rakennustarkastaja Arto

Lisätietoja

Yritysprofiili Contribyte kotisivut

Tagit

Jos tarjontatagi on sininen, pääset klikkaamalla sen kuvaukseen

Siirry yrityksen profiiliin Contribyte kotisivut Yrityshaku Referenssihaku Julkaisuhaku

Contribyte - Asiantuntijat ja yhteyshenkilöt

Henri Hämäläinen

Toimitusjohtaja, tuotekehityksen valmentaja


	Henri on Contribyten toimitusjohtaja ja organisaatioiden valmentaja. Hän on 15 vuoden aikana saanut toimia kymmenien eri organisaatioiden valmentajana ja muutoksen auttajana. ..
	henri.hamalainen@contribyte.fi 050 487 3291

Harri Pendolin

Johtava konsultti, tuotejohtamisen valmentaja


	Harri on "tuotemies" henkeen ja vereen. 20 vuoden työuraan mahtuu niin tuotepäällikkönä toimimista isossa yrityksessä, kuin kahdeksan vuotta yrittäjänäkin, mutta aina ..
	harri.pendolin@contribyte.fi 040 582 08 65

Lasse Mikkonen

Teknologiajohtaja, tuotekehityksen valmentaja


	Lasse on Contribyten perustajajäsen, joka nykyisin vastaa yrityksen käyttämistä työkaluista sekä portfoliosta. Hänellä on 20 vuoden kokemus ohjelmistokehityksestä sekä ..
	lasse.mikkonen@contribyte.fi 040 543 9845

Contribyte - Muita referenssejä

Contribyte - Muita bloggauksia

Digitalisaatio & innovaatiot blogimedia

Blogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä

Marras 25

Telian tutkimus: Suomalaiset pitävät maatamme mobiiliteknologian edelläkävijänä, mutta turvallisuus huolettaa

Hiljattain Suomen mobiiliverkkojen laatu sai mainetta kansainvälisessä tutkimuksessa.

Marras 24

IT-ammattilaisen tulee satsata oman osaamisen kehittämiseen, sanoo tietoturva-asiantuntija Benjamin Särkkä – ”Uutta opittavaa tulee koko ajan kiihtyvää tahtia”

Upload tarjoaa ensi vuonna laajan kattauksen IT-alan koulutuksia.

Marras 23

Mitä tarkoittaa junior developer ja senior developer?

Määritelläänkö juniorin ja seniorin ero kokemusvuosissa vai osaamistasossa?

Siirry blogiin

Etusivu Yrityshaku Pikahaku Referenssihaku Julkaisuhaku Blogimedia

Hae it-yrityksiä
osaamisalueittain:

Avoimuus ja läpinäkyvyys – tiimin askelmat luottamukseen

Lisätietoja

Tagit