Pinpoint first, tool second: do not take a shiny second brain and look for a use - find the pain, build the crudest fix, then evolve
If you hurt your leg you do not research which hospital has the best rating - you get first aid.
Dilip began a second brain without a purpose and abandoned it. The second attempt started from a pain: as one of the older leaders in a young startup, nobody gave him coaching or feedback, and colleagues are all firefighting. He searched for 'a system that can coach me' and it turned out to be a form of second brain. His lesson: people take a solution and attach terms to it ('now I have a second brain, what do I use it for?'); instead say what you want to achieve, build the most brute-force version and refine. Sometimes a second brain is not needed at all. He mocks the tool-choice trap (Claude or Codex? Box or Dropbox? Obsidian or Hermes?) - decision paralysis costs more than a wrong pick, so pick one and begin; his own mistake was to start with Hermes and Telegram (cumbersome) before moving to a plain Claude project where his muscle memory already is. Guardrails he used: a 90-minute timer for research, no token optimisation at the start ('the feedback is more valuable than the tokens'), connect a system only when you feel the pain it solves, and treat effectiveness as self-assessed. He labels these Day 1 and Day 2 talks 'BTS' sessions - behind the scenes of how he thought, not a finished recipe - and says they only fit sprints, not the main programme.
He did not say 'build a second brain for coaching' - he said 'I need a coach' and the system grew into one.
Mindset frame for everything else in the sprint, and a direct answer to participants asking which tool to choose.





