4 ms·

All In – a small tool to check real buyin after decisions

16 points by anticlickwise 9mo ago

anticlickwise 9mo ago
We kept running into the same issue after decisions where everyone agreed in the meeting but execution slowed later. The problem wasn’t disagreement, it was unclear commitment. All In is a small, free tool I built to quickly check whether people actually stand behind a decision or are quietly unsure. After a decision, participants answer a single question independently. You see where support is solid, where it’s weak and where follow up is needed. No accounts, no setup, no facilitation overhead. It’s intentionally simple. Meant to be used right after decisions, before silence turns into delay. Feedback very welcome.
anticlickwise 9mo ago
Maker here. Built this after repeatedly mistaking agreement for commitment in real projects. It’s free and intentionally minimal. Happy to answer questions or hear where this breaks down in real teams.
gus_massa 8mo ago
> Would you actively defend this decision tomorrow if it was challenged? I don't like that words. If I'm one of the proponents, I'll defend it. If I'm against, I may accept and implement that decision, but I'm not going to die in that hill. PS: Just reading this, brings me nightmares from the 2020 Zoom meetings.
- anticlickwise 8mo ago
  Fair point and I agree. The intent isn’t to make anyone “die on a hill” or perform loyalty. What I kept running into was people accepting decisions without really feeling ready to own or back them in execution. That gap usually only showed up later as delays or fuzzy ownership. The wording is one way to surface that but the goal is clarity, not confrontation. Appreciate you calling it out.
hahahahhaah 8mo ago
https://www.cognu.app/all-in/5hlyjtip/results https://www.cognu.app/all-in/5hlyjtip/results
- anticlickwise 8mo ago
  lol. I love this
SebRut 8mo ago
Looks like some useful tools over there. What's missing for me is some data security declaration for where and how long data is stored and how the data is passed to third parties (AI?).
ChrisMarshallNY 8mo ago
I worked for a Japanese company. They had a consensus-based system that was fairly unique (to Americans). Lots of meetings, and pretty “spirited” discussions during those meetings. However, once consensus was reached, everyone fell in behind it, and supported it unequivocally. No “hidden resistance.” One of the drawbacks to consensus decisions, though, is that everyone can agree on a crap decision. There’s even an old fallacy about it, called The Abilene Paradox[0]. [0] https://en.wikipedia.org/wiki/Abilene_paradox https://en.wikipedia.org/wiki/Abilene_paradox
- pstuart 8mo ago
  That approach is not without merit, however, it's still a possible dead end. I see this pattern happen consistently even with really good engineers: * Identify a problem and design a solution for it * Apply the solution and it fixes the problem * Later a problem occurs with the solution, so * Apply a fix for that solution's problem * Later another problem happens somewhere in the "solution chain" and the same repair cycle is applied At a certain point, it's worth revisiting the original problem and its original solution and see if there's a better way to address it (especially with all the lessons ostensibly learned in the solution chain).

16 points by anticlickwise 9mo ago

We kept running into the same issue after decisions where everyone agreed in the meeting but execution slowed later. The problem wasn’t disagreement, it was unclear commitment. All In is a small, free tool I built to quickly check whether people actually stand behind a decision or are quietly unsure. After a decision, participants answer a single question independently. You see where support is solid, where it’s weak and where follow up is needed. No accounts, no setup, no facilitation overhead. It’s intentionally simple. Meant to be used right after decisions, before silence turns into delay. Feedback very welcome.

anticlickwise 9mo ago

Maker here. Built this after repeatedly mistaking agreement for commitment in real projects. It’s free and intentionally minimal. Happy to answer questions or hear where this breaks down in real teams.

gus_massa 8mo ago

> Would you actively defend this decision tomorrow if it was challenged? I don't like that words. If I'm one of the proponents, I'll defend it. If I'm against, I may accept and implement that decision, but I'm not going to die in that hill. PS: Just reading this, brings me nightmares from the 2020 Zoom meetings.

anticlickwise 8mo ago
Fair point and I agree. The intent isn’t to make anyone “die on a hill” or perform loyalty. What I kept running into was people accepting decisions without really feeling ready to own or back them in execution. That gap usually only showed up later as delays or fuzzy ownership. The wording is one way to surface that but the goal is clarity, not confrontation. Appreciate you calling it out.

hahahahhaah 8mo ago

https://www.cognu.app/all-in/5hlyjtip/results https://www.cognu.app/all-in/5hlyjtip/results

anticlickwise 8mo ago
lol. I love this

SebRut 8mo ago

Looks like some useful tools over there. What's missing for me is some data security declaration for where and how long data is stored and how the data is passed to third parties (AI?).

ChrisMarshallNY 8mo ago

I worked for a Japanese company. They had a consensus-based system that was fairly unique (to Americans). Lots of meetings, and pretty “spirited” discussions during those meetings. However, once consensus was reached, everyone fell in behind it, and supported it unequivocally. No “hidden resistance.” One of the drawbacks to consensus decisions, though, is that everyone can agree on a crap decision. There’s even an old fallacy about it, called The Abilene Paradox[0]. [0] https://en.wikipedia.org/wiki/Abilene_paradox https://en.wikipedia.org/wiki/Abilene_paradox

pstuart 8mo ago
That approach is not without merit, however, it's still a possible dead end. I see this pattern happen consistently even with really good engineers: * Identify a problem and design a solution for it * Apply the solution and it fixes the problem * Later a problem occurs with the solution, so * Apply a fix for that solution's problem * Later another problem happens somewhere in the "solution chain" and the same repair cycle is applied At a certain point, it's worth revisiting the original problem and its original solution and see if there's a better way to address it (especially with all the lessons ostensibly learned in the solution chain).