Uratikkaiden pohja

Ohjelmistokehittäjän uratikkaat – valmis pohja

Viisi tasoa juniorista principaliin ja kuusi osaamisaluetta koodin julkaisemisesta tiimin kasvattamiseen.

Ilmainen-paketti · Ei luottokorttia

Nämä uratikkaat on kirjoitettu noin 20–200 hengen tuoteyrityksille: kehittäjät vievät ominaisuudet alusta loppuun, tiimit ovat pieniä, eikä kukaan HR:ssä laadi tehtävärakennetta. Tikkaissa on viisi tasoa uransa alussa olevasta kehittäjästä ihmiseen, joka linjaa koko yrityksen teknistä suuntaa. Ylin taso, Principal Engineer, on asiantuntijataso; kehittäjien esihenkilötyötä kuvaavat erilliset Engineering Managerin uratikkaat.

Jokainen taso määritellään sen mukaan, mitä ihminen tekee, ei työvuosien perusteella. Lue osaamismatriisin riviä vasemmalta oikealle, niin näet, miten yksi odotus kasvaa; lue tason oma osio, niin näet kerralla kaiken, mitä tasolla odotetaan. Käytä tikkaita selittämään, mitä seuraava taso tarkoittaa, jäsentämään itsearviointeja ja check-inejä sekä tekemään ylennysperusteluista vertailukelpoisia tiimistä toiseen.

Pidä tätä lähtökohtana. Nimeä tasot omien nimikkeidesi mukaan, yhdistä tai poista osaamisalueet, jotka eivät sovi yritykseesi, ja kirjoita odotukset omin sanoin ennen kuin julkaiset tikkaat tiimille.

Tasot lyhyesti

Junior kehittäjä
Opettelee koodikantaa ja toteuttaa tarkasti rajattuja tehtäviä ohjauksen tuella.
Vastuualue
Yksittäisiä tehtäviä yhdellä tuotteen alueella, yleensä jonkun kokeneemman pilkkomina.
Kehittäjä
Toteuttaa ominaisuuksia itsenäisesti ja on tiimin luotettava jäsen.
Vastuualue
Pieniä ja keskisuuria ominaisuuksia yhden tiimin alueella lyhyestä suunnitelmamuistiosta tuotantoon.
Senior kehittäjä
Vetää isompia kokonaisuuksia ja nostaa ympärillään olevan tiimin tasoa.
Vastuualue
Projektit, jotka ulottuvat useaan palveluun tai usean ihmisen työhön, sekä yhden tiimin tekniset päätökset.
Staff Engineer
Ratkaisee tiimirajat ylittäviä ongelmia ja ohjaa teknisiä päätöksiä yhtä tiimiä laajemmin.
Vastuualue
Useita tiimejä tai kokonainen tuotealue, myös ongelmat, jotka eivät kuulu millekään yksittäiselle tiimille.
Principal Engineer
Määrittää yrityksen teknisen suunnan ja vastaa sen pitkän aikavälin teknisestä terveydestä.
Vastuualue
Koko kehitysorganisaatio ja yrityksen teknologiastrategia muutamaksi seuraavaksi vuodeksi.

Osaamismatriisi

Jokainen rivi on osaamisalue ja jokainen sarake taso. Lue riviä vasemmalta oikealle, niin näet, miten odotukset kasvavat.

Mitä kukin osaamisalue tarkoittaa

Tekninen toteutus: Vaatimusten muuttaminen toimivaksi, ylläpidettäväksi ohjelmistoksi ja sen vieminen käyttäjille.
Järjestelmäsuunnittelu: Sellaisten rakenteiden, rajapintojen ja kompromissien valinta, jotka kestävät tuotteen kasvun.
Laatu ja luotettavuus: Tuotteen pitäminen oikein toimivana, havainnoitavana ja saatavilla olevana sekä virheistä oppiminen.
Yhteistyö ja viestintä: Tehokas yhteistyö muiden kehittäjien, tuotehallinnan, designin ja muun liiketoiminnan kanssa.
Omistajuus ja tuotevaikutus: Ymmärrys siitä, miksi työ on tärkeää, ja vastuu lopputuloksista eikä vain tehtävistä.
Mentorointi ja tiimin kasvu: Muiden auttaminen kehittymään ja tiimin tekeminen vahvemmaksi kuin yksikään sen jäsen yksin.

Ohjelmistokehittäjä: odotukset osaamisalueittain ja tasoittain
Osaamisalue	Junior kehittäjä	Kehittäjä	Senior kehittäjä	Staff Engineer	Principal Engineer
Tekninen toteutus	Tekee hyvin rajatut tehtävät luettavalla koodilla ja testeillä, pyytää apua oltuaan jumissa muutaman tunnin eikä muutamaa päivää ja korjaa katselmointikommentit ennen yhdistämistä.	Vie ominaisuuden lyhyestä suunnitelmamuistiosta tuotantoon ilman kädestä pitelyä, jakaa sen helposti katselmoitaviin pull requesteihin ja antaa realistisia arvioita tutusta työstä.	Toimittaa projekteja, jotka ulottuvat useaan palveluun tai tekijään, järjestää työn niin, että jotain hyödyllistä julkaistaan aikaisin, ja poistaa riskit ennen kuin ne pysäyttävät tiimin.	Raivaa toimituksen esteitä tiimien välillä: purkaa jaettuja riippuvuuksia, rakentaa työkaluja tai ajaa migraatioita, joita useampi tiimi tarvitsee, ja pitää monen tiimin projektit raiteillaan.	Muovaa tapaa, jolla koko organisaatio julkaisee – julkaisukäytännöt, alustavalinnat, käännös- ja käyttöönottotyökalut – niin, että jokainen tiimi toimittaa nopeammin ja turvallisemmin.
Järjestelmäsuunnittelu	Noudattaa koodikannan olemassa olevia malleja ja osaa selittää, miksi muuttamansa koodi on rakennettu niin kuin on.	Suunnittelee komponentteja olemassa olevan palvelun sisällä, kirjoittaa lyhyen suunnitelmamuistion ei-triviaaleista muutoksista ja vertaa vähintään kahta vaihtoehtoa ennen valintaa.	Vetää useaan palveluun ulottuvien ominaisuuksien suunnittelua, kirjaa kompromissit muiden katselmoitaviksi ja katselmoi muiden kehittäjien suunnitelmia rakentavasti.	Määrittää arkkitehtuuria tiimirajojen yli – jaetut tietomallit, palvelujen väliset rajapintasopimukset, rakenna vai osta -päätökset – ja ennakoi, miten järjestelmän on muututtava seuraavan vuoden tai kahden aikana.	Vastaa yrityksen teknologiastrategiasta: mihin teknologioihin panostetaan, mistä luovutaan ja miten arkkitehtuurin pitää kehittyä liiketoiminnan mukana useiden vuosien aikana.
Laatu ja luotettavuus	Kirjoittaa testit omille muutoksilleen, tarkistaa työnsä ennen julkaisua ja korjaa bugit koodista, jota on itse muuttanut.	Lisää valvonnan ja hälytykset rakentamilleen ominaisuuksille, osallistuu päivystysvuoroihin ja hoitaa rutiininomaiset häiriöt toimintaohjeen (runbook) avulla.	Johtaa tiimin järjestelmien häiriötilanteiden hoitoa, kirjoittaa syyllistämättömiä jälkianalyyseja ja varmistaa, että jatkotoimet todella tehdään.	Tunnistaa järjestelmärajat ylittäviä luotettavuus- ja tietoturvariskejä, asettaa standardeja, kuten testausstrategian ja palvelutasotavoitteet, ja vie korjaukset läpi tiimien yli.	Määrittää, mitä luotettavuus, tietoturva ja laatu tarkoittavat yritykselle, punnitsee niitä nopeutta vastaan yhdessä johtoryhmän kanssa ja on viimeinen eskalaatiopiste vaikeimmissa häiriöissä.
Yhteistyö ja viestintä	Kertoo edistymisestään ja esteistään avoimesti ja kysyy selkeitä kysymyksiä, kun vaatimus on epäselvä.	Selventää vaatimuksia suoraan tuotehallinnan ja designin kanssa, selittää tekniset rajoitteet selkokielellä ja kirjoittaa pull request -kuvauksia, joita katselmoijien on helppo seurata.	Edustaa tiimiä suunnittelussa, neuvottelee laajuudesta ja kompromisseista tuotehallinnan kanssa ja kirjoittaa dokumentteja, jotka kehitysorganisaation ulkopuolisetkin ymmärtävät.	Saa useat tiimit ja toiminnot yhteisen teknisen suunnitelman taakse, ratkoo tiimien välisiä erimielisyyksiä ja selittää teknisiä riskejä johdolle.	On luotettu ääni yritystason päätöksissä, kääntää liiketoimintastrategian tekniseksi suunnaksi ja takaisin sekä edustaa kehitysorganisaatiota tarvittaessa asiakkaille, kumppaneille tai sijoittajille.
Omistajuus ja tuotevaikutus	Ymmärtää tehtäviensä tarkoituksen, tarkistaa, että julkaistu muutos toimii käyttäjille, ja seuraa asiaa, kunnes se toimii.	Omistaa ominaisuuden julkaisun jälkeenkin: seuraa sen käyttöä ja virheitä, korjaa ongelmat ja ehdottaa parannuksia oppimansa perusteella.	Omistaa tuotteen osa-alueen kokonaan, kyseenalaistaa vaatimukset, jotka eivät palvele käyttäjiä, ja ehdottaa työtä, joka vie tiimin tavoitteita eteenpäin.	Löytää tuotealueen vaikuttavimmat ongelmat – myös ne, joihin mikään tiimi ei ole tarttunut – ja varmistaa, että ne ratkaistaan.	Kytkee kehitysinvestoinnit yrityksen tuloksiin ja puhuu suurten panostusten puolesta tai niitä vastaan niiden teknisen ja liiketoiminnallisen vaikutuksen perusteella.
Mentorointi ja tiimin kasvu	Pyytää palautetta ja toimii sen pohjalta sekä kirjaa oppimansa, jotta seuraavan tulokkaan alku on helpompi.	Tekee huolellisia koodikatselmointeja, auttaa uusien tiimiläisten perehdytyksessä ja tekee pariohjelmointia juniorien kanssa koodin vieraammissa osissa.	Mentoroi tavoitteellisesti yhtä tai kahta kehittäjää, antaa palautetta, joka auttaa heitä seuraavalle tasolle, ja osallistuu rekrytointihaastatteluihin.	Kasvattaa senior-kehittäjiä tiimien yli, muovaa haastatteluprosessia ja kehityskäytäntöjä ja on se, jolta muut hakevat neuvoa.	Rakentaa yrityksen teknistä kulttuuria – miten päätöksiä tehdään ja miten tietoa jaetaan – ja kasvattaa seuraavan sukupolven Staff Engineerejä.

Vieritä taulukkoa sivusuunnassa nähdäksesi kaikki tasot.

Lataa CSV-tiedostona Avautuu Excelissä, Google Sheetsissä tai Numbersissa.

Junior kehittäjä: mitä odotetaan

Opettelee koodikantaa ja toteuttaa tarkasti rajattuja tehtäviä ohjauksen tuella. Yksittäisiä tehtäviä yhdellä tuotteen alueella, yleensä jonkun kokeneemman pilkkomina.

Tekninen toteutus: Tekee hyvin rajatut tehtävät luettavalla koodilla ja testeillä, pyytää apua oltuaan jumissa muutaman tunnin eikä muutamaa päivää ja korjaa katselmointikommentit ennen yhdistämistä.
Järjestelmäsuunnittelu: Noudattaa koodikannan olemassa olevia malleja ja osaa selittää, miksi muuttamansa koodi on rakennettu niin kuin on.
Laatu ja luotettavuus: Kirjoittaa testit omille muutoksilleen, tarkistaa työnsä ennen julkaisua ja korjaa bugit koodista, jota on itse muuttanut.
Yhteistyö ja viestintä: Kertoo edistymisestään ja esteistään avoimesti ja kysyy selkeitä kysymyksiä, kun vaatimus on epäselvä.
Omistajuus ja tuotevaikutus: Ymmärtää tehtäviensä tarkoituksen, tarkistaa, että julkaistu muutos toimii käyttäjille, ja seuraa asiaa, kunnes se toimii.
Mentorointi ja tiimin kasvu: Pyytää palautetta ja toimii sen pohjalta sekä kirjaa oppimansa, jotta seuraavan tulokkaan alku on helpompi.

Kehittäjä: mitä odotetaan

Toteuttaa ominaisuuksia itsenäisesti ja on tiimin luotettava jäsen. Pieniä ja keskisuuria ominaisuuksia yhden tiimin alueella lyhyestä suunnitelmamuistiosta tuotantoon.

Tekninen toteutus: Vie ominaisuuden lyhyestä suunnitelmamuistiosta tuotantoon ilman kädestä pitelyä, jakaa sen helposti katselmoitaviin pull requesteihin ja antaa realistisia arvioita tutusta työstä.
Järjestelmäsuunnittelu: Suunnittelee komponentteja olemassa olevan palvelun sisällä, kirjoittaa lyhyen suunnitelmamuistion ei-triviaaleista muutoksista ja vertaa vähintään kahta vaihtoehtoa ennen valintaa.
Laatu ja luotettavuus: Lisää valvonnan ja hälytykset rakentamilleen ominaisuuksille, osallistuu päivystysvuoroihin ja hoitaa rutiininomaiset häiriöt toimintaohjeen (runbook) avulla.
Yhteistyö ja viestintä: Selventää vaatimuksia suoraan tuotehallinnan ja designin kanssa, selittää tekniset rajoitteet selkokielellä ja kirjoittaa pull request -kuvauksia, joita katselmoijien on helppo seurata.
Omistajuus ja tuotevaikutus: Omistaa ominaisuuden julkaisun jälkeenkin: seuraa sen käyttöä ja virheitä, korjaa ongelmat ja ehdottaa parannuksia oppimansa perusteella.
Mentorointi ja tiimin kasvu: Tekee huolellisia koodikatselmointeja, auttaa uusien tiimiläisten perehdytyksessä ja tekee pariohjelmointia juniorien kanssa koodin vieraammissa osissa.

Senior kehittäjä: mitä odotetaan

Vetää isompia kokonaisuuksia ja nostaa ympärillään olevan tiimin tasoa. Projektit, jotka ulottuvat useaan palveluun tai usean ihmisen työhön, sekä yhden tiimin tekniset päätökset.

Tekninen toteutus: Toimittaa projekteja, jotka ulottuvat useaan palveluun tai tekijään, järjestää työn niin, että jotain hyödyllistä julkaistaan aikaisin, ja poistaa riskit ennen kuin ne pysäyttävät tiimin.
Järjestelmäsuunnittelu: Vetää useaan palveluun ulottuvien ominaisuuksien suunnittelua, kirjaa kompromissit muiden katselmoitaviksi ja katselmoi muiden kehittäjien suunnitelmia rakentavasti.
Laatu ja luotettavuus: Johtaa tiimin järjestelmien häiriötilanteiden hoitoa, kirjoittaa syyllistämättömiä jälkianalyyseja ja varmistaa, että jatkotoimet todella tehdään.
Yhteistyö ja viestintä: Edustaa tiimiä suunnittelussa, neuvottelee laajuudesta ja kompromisseista tuotehallinnan kanssa ja kirjoittaa dokumentteja, jotka kehitysorganisaation ulkopuolisetkin ymmärtävät.
Omistajuus ja tuotevaikutus: Omistaa tuotteen osa-alueen kokonaan, kyseenalaistaa vaatimukset, jotka eivät palvele käyttäjiä, ja ehdottaa työtä, joka vie tiimin tavoitteita eteenpäin.
Mentorointi ja tiimin kasvu: Mentoroi tavoitteellisesti yhtä tai kahta kehittäjää, antaa palautetta, joka auttaa heitä seuraavalle tasolle, ja osallistuu rekrytointihaastatteluihin.

Staff Engineer: mitä odotetaan

Ratkaisee tiimirajat ylittäviä ongelmia ja ohjaa teknisiä päätöksiä yhtä tiimiä laajemmin. Useita tiimejä tai kokonainen tuotealue, myös ongelmat, jotka eivät kuulu millekään yksittäiselle tiimille.

Tekninen toteutus: Raivaa toimituksen esteitä tiimien välillä: purkaa jaettuja riippuvuuksia, rakentaa työkaluja tai ajaa migraatioita, joita useampi tiimi tarvitsee, ja pitää monen tiimin projektit raiteillaan.
Järjestelmäsuunnittelu: Määrittää arkkitehtuuria tiimirajojen yli – jaetut tietomallit, palvelujen väliset rajapintasopimukset, rakenna vai osta -päätökset – ja ennakoi, miten järjestelmän on muututtava seuraavan vuoden tai kahden aikana.
Laatu ja luotettavuus: Tunnistaa järjestelmärajat ylittäviä luotettavuus- ja tietoturvariskejä, asettaa standardeja, kuten testausstrategian ja palvelutasotavoitteet, ja vie korjaukset läpi tiimien yli.
Yhteistyö ja viestintä: Saa useat tiimit ja toiminnot yhteisen teknisen suunnitelman taakse, ratkoo tiimien välisiä erimielisyyksiä ja selittää teknisiä riskejä johdolle.
Omistajuus ja tuotevaikutus: Löytää tuotealueen vaikuttavimmat ongelmat – myös ne, joihin mikään tiimi ei ole tarttunut – ja varmistaa, että ne ratkaistaan.
Mentorointi ja tiimin kasvu: Kasvattaa senior-kehittäjiä tiimien yli, muovaa haastatteluprosessia ja kehityskäytäntöjä ja on se, jolta muut hakevat neuvoa.

Principal Engineer: mitä odotetaan

Määrittää yrityksen teknisen suunnan ja vastaa sen pitkän aikavälin teknisestä terveydestä. Koko kehitysorganisaatio ja yrityksen teknologiastrategia muutamaksi seuraavaksi vuodeksi.

Tekninen toteutus: Muovaa tapaa, jolla koko organisaatio julkaisee – julkaisukäytännöt, alustavalinnat, käännös- ja käyttöönottotyökalut – niin, että jokainen tiimi toimittaa nopeammin ja turvallisemmin.
Järjestelmäsuunnittelu: Vastaa yrityksen teknologiastrategiasta: mihin teknologioihin panostetaan, mistä luovutaan ja miten arkkitehtuurin pitää kehittyä liiketoiminnan mukana useiden vuosien aikana.
Laatu ja luotettavuus: Määrittää, mitä luotettavuus, tietoturva ja laatu tarkoittavat yritykselle, punnitsee niitä nopeutta vastaan yhdessä johtoryhmän kanssa ja on viimeinen eskalaatiopiste vaikeimmissa häiriöissä.
Yhteistyö ja viestintä: On luotettu ääni yritystason päätöksissä, kääntää liiketoimintastrategian tekniseksi suunnaksi ja takaisin sekä edustaa kehitysorganisaatiota tarvittaessa asiakkaille, kumppaneille tai sijoittajille.
Omistajuus ja tuotevaikutus: Kytkee kehitysinvestoinnit yrityksen tuloksiin ja puhuu suurten panostusten puolesta tai niitä vastaan niiden teknisen ja liiketoiminnallisen vaikutuksen perusteella.
Mentorointi ja tiimin kasvu: Rakentaa yrityksen teknistä kulttuuria – miten päätöksiä tehdään ja miten tietoa jaetaan – ja kasvattaa seuraavan sukupolven Staff Engineerejä.

Näin sovitat uratikkaat omaan käyttöösi

Sovita tasot omiin nimikkeisiisi
Jos nimikkeesi ovat Developer I, II ja III, nimeä tasot uudelleen, mutta pidä yksi taso jokaista todellista vastuun kasvun askelta kohden. Useimmat alle 100 kehittäjän yritykset eivät vielä tarvitse Principal-tasoa: jätä se pois, kunnes joku oikeasti tekee sitä työtä.
Pidä osaamisalueita viidestä seitsemään
Jos niitä on yli seitsemän, kukaan ei lue niitä; jos alle neljä, hyvin erilaiset ihmiset näyttävät samanlaisilta. Yhdistä osaamisalueet, jotka arvioit aina yhdessä, ja lisää uusi vain, jos se muuttaisi jotain todellista päätöstä.
Kirjoita odotukset havaittavaksi toiminnaksi
Kysy jokaisen solun kohdalla, pystyisikö esihenkilö näyttämään siitä esimerkin viimeisen kuuden kuukauden ajalta. Korvaa sanat kuten ”vahva” tai ”syvällinen” sillä, mitä ihminen oikeasti tekee, esimerkiksi ”johtaa tiimin palveluiden häiriötilanteiden hoitoa”.
Testaa oikeilla ihmisillä ennen julkaisua
Pyydä kahta tai kolmea esihenkilöä sijoittamaan tiiminsä jäsenet luonnokseen. Siellä, missä he ovat eri mieltä, sanamuoto on monitulkintainen: korjaa se, julkaise tikkaat ja sovi, että ne käydään uudelleen läpi kuuden kuukauden kuluttua.

UKK

Kysymyksiä näistä uratikkaista

Montako tasoa ohjelmistokehittäjän uratikkaissa pitäisi olla?

20–200 hengen yrityksessä tyypillisesti neljästä kuuteen. Jos tasoja on vähemmän, ylennykset ovat harvinaisia ja valtavia; jos enemmän, kahden tason ero on liian pieni kuvattavaksi. Tässä pohjassa on viisi: Junior kehittäjä, Kehittäjä, Senior, Staff ja Principal.

Pitääkö kehittäjän ryhtyä esihenkilöksi voidakseen kasvaa?

Ei. Nämä ovat asiantuntijapolun uratikkaat: Staff- ja Principal-tason kehittäjien vastuu ja vaikutusvalta kasvavat ilman ihmisten johtamista. Käytä niitä Engineering Managerin uratikkaiden rinnalla, jotta esihenkilöksi siirtyminen on urapolun vaihto eikä ylennys.

Miten kehittäjien uratikkaita käytetään ylennyspäätöksissä?

Ylennä ihmisiä, jotka jo toimivat johdonmukaisesti seuraavalla tasolla, älä niitä, jotka ehkä pystyisivät siihen. Pyydä henkilöä ja hänen esihenkilöään keräämään konkreettisia esimerkkejä tavoitetason jokaisesta osaamisalueesta, ja vertaa jokaista tapausta samaan matriisiin, jotta päätökset pysyvät johdonmukaisina tiimistä toiseen.

Miten kehittäjien uratikkaat liittyvät check-ineihin ja 1:1-keskusteluihin?

Käytä niitä säännöllisten check-inien runkona: henkilö arvioi itsensä nykyistä tasoaan vasten, esihenkilö tekee saman, ja näiden kahden arvion erot muutetaan muutamaksi konkreettiseksi kehitystoimenpiteeksi tuleville kuukausille.

Kuinka usein kehittäjien uratikkaita pitäisi päivittää?

Käy ne läpi kerran tai kaksi vuodessa ja aina, kun yrityksen rakenne muuttuu – esimerkiksi kun perustatte alustatiimin tai alatte rekrytoida Staff Engineerejä. Kirjoita solu uudelleen, jos arvioinnit kompastuvat siihen kerta toisensa jälkeen.

Rakenna nämä uratikkaat LadderKitiin – ilmaiseksi

Määritä tasot ja taidot tiimillesi, arvioi ihmisiä niitä vasten check-ineissä ja pidä ylennyspäätökset johdonmukaisina.

Aloita ilmaiseksi Tutustu demoon Ei rekisteröitymistä