Kerro minulle ajasta, jolloin vakuutit tiimisi omaksumaan lähestymistapasi.

Question

Accepted Answer

Tämä testaa **teknistä vakuuttamista**: voitko esittää väitteen todisteilla ja saada ihmiset mukaan, samalla kun pysyt avoimena sille, että olet väärässä? Vakuuttaminen ei ole väittelyn voittaminen.

## Miten lähestyä sitä

```text
1. State the problem and the criteria for a good solution first
2. Present options fairly, including the team's preferred one
3. Back your choice with data, a spike, or a small benchmark
4. Invite critique — adjust if they find a real flaw
```

## Toimiva esimerkki

```text
S: The team planned to build a custom job queue; I thought we should use an
   existing tool.
T: I had to make the case without dismissing their work.
A: I listed our actual requirements, built a one-day spike with the off-the-shelf
   tool, and showed it met every need with far less code to maintain.
R: The team agreed, and we shipped two weeks earlier. I noted the one case where
   their concern was valid and we documented the workaround.
```

## Hyvä vs. heikko

```text
✓ Evidence + fair comparison + open to critique
✗ "I argued until they gave up"
✗ Pushing your idea with no proof
```

## Miksi sillä on merkitystä

Hyvät päätökset tarvitsevat hyväksynnän; loistava idea, jonka kukaan ei omaksu, ei muuta mitään.

Kriteereillä ja todisteilla aloittaminen pitää huomion parhaassa tuloksessa, ei siinä, kenen idea voittaa.

Todellinen avoimuus sille, että olet väärässä, on se, mikä saa ihmiset luottamaan johtopäätöksiisi seuraavalla kerralla.