Opowiedz mi o czasem, kiedy namówiłeś swój zespół do przyjęcia twojego podejścia.

Question

Accepted Answer

To testuje **perswazję techniczną**: czy możesz przedstawić argument z dowodami i zaangażować ludzi, pozostając otwarty na możliwość, że się mylisz? Perswazja to nie wygranie sporu.

## Jak to podejść

```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
```

## Pracujący przykład

```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.
```

## Dobre vs słabe

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

## Dlaczego to ważne

Dobre decyzje wymagają poparcia; świetny pomysł, który nikt nie wdraża, nie zmienia nic.

Prowadzenie z kryteriami i dowodami utrzymuje fokus na najlepszym wyniku, a nie na tym, czyjej idei się powiedzie.

Byciem naprawdę otwartym na to, że możesz się mylić, jest to, co sprawia, że ludzie ufają twoim wnioskom następnym razem.