Kerro minulle tiimi- tai projektin epäonnistumisesta, jonka omistajuuden otit.

Question

IT Interview Practice · Accepted Answer

Tämä testaa **vastuullisuutta omien tehtäviesi ulkopuolella** — omistaa jaettu lopputulos sen sijaan, että syyttäisit muita. Käytä "minä" omille toimillesi ja "me" tiimille, mutta älä vältä vastuuta.

## Kuinka lähestyä sitä

```text
1. Describe the failure honestly and your part in it
2. Resist blaming individuals — own the system or the call
3. Explain what you did to recover and to prevent it
4. Show the lasting change
```

## Käytännön esimerkki

```text
S: A feature we shipped tanked a key metric and had to be rolled back.
T: As the senior IC on it, I felt responsible for the outcome.
A: Instead of pointing at the unclear spec, I owned that I hadn't pushed for an
   A/B test. I ran a blameless retro, we added experiment gates for risky
   changes, and I re-launched a tested version.
R: The re-launch moved the metric the right way. Experiment gates are now
   standard for the team.
```

## Hyvä vs heikko

```text
✓ Owns the shared outcome, fixes the system
✗ "The PM gave us bad requirements"
✗ Owning so much it sounds like you alone failed
```

## Miksi se on tärkeää

Jaettujen epäonnistumisten omistajuus — ei vain henkilökohtaisia — on vanhemman tason käyttäytymisen tunnusmerkki.

Järjestelmän korjaaminen ihmisen syyttämisen sijaan on se, mikä todella estää seuraavan epäonnistumisen.

Johtajat etsivät ihmisiä, jotka juoksevat *kohti* ongelmia ja vastuullisuutta, ei niistä poispäin.

Kuinka lähestyä sitä

Käytännön esimerkki

Hyvä vs heikko

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset