16 August 2026 · Helen Beckford
"Why Did We Decide That?" Nobody Can Remember.
The Issue: Decisions are being made every day. Nobody is writing them down.
Quick question. Can you tell me, right now, why you chose your current software vendor over the other two you considered? Can you tell me why you decided not to build that feature your co-founder suggested three months ago? Can you tell me who agreed to accept the risk of launching without mobile support, and when?
If your answer to any of those is "We discussed it on a call somewhere", you have a problem.
Start-ups move fast. Decisions get made in team meetings, on Slack threads, in passing comments on calls. The pace feels productive. But six months later, when something goes wrong or a new team member joins or an investor asks a difficult question, the context has evaporated. The person who made the decision might not even be in the business anymore.
This isn't just about decisions to do things. The most dangerous gaps are the decisions not to do something. You decided not to build a particular feature. You decided not to invest in a specific area. You decided to accept a risk rather than mitigate it. These "non-decisions" rarely get recorded because nobody thinks to write down what they chose not to do. And then, when the consequences arrive, nobody can remember why.
What I See Every Day: The same decisions being revisited, the same risks resurfacing.
I once had a chief legal officer contact me on behalf of a board asking why a decision had been made not to build a particular solution. They needed the rationale. The project had moved on. The team had changed. But because I keep my RAAIDD log up to date throughout every engagement, I was able to provide the answer promptly. When I leave a client, I provide a thorough handover that includes the RAAIDD log, and I share meeting minutes throughout the engagement. But that's because I hold myself to a high standard. This isn't always the case with contracted staff and/or vendors. Without that log, someone would have been digging through months of meeting minutes trying to piece together context from fragments. That's if the meeting minutes even exist. Yes, AI notetakers mean notes are captured more often than not these days, but it's still not always the same person taking them, the format varies, and finding one specific decision buried across dozens of call transcripts is nobody's idea of a good time.
Here's the pattern I see across almost every start-up and scale-up I work with:
Decisions get made in team meetings but nobody captures them. Even with good minute-taking, it can be incredibly difficult to track down a specific decision weeks or months later. Without good minute-taking? Forget it.
Risks get raised, discussed, and accepted verbally. Then when the risk materialises, nobody can remember that it was flagged, who accepted it, or what the rationale was. This causes tension. People point fingers. The person who raised the risk looks like they didn't push hard enough. The person who accepted it claims they were never told.
Actions get agreed but there's no single place to track them. Who's doing what, by when? Without a central record, things slip through the cracks and the same conversations happen over and over again.
If that sounds familiar, you're not alone. This is one of the most common and most easily fixable problems I see.
What Needs to Happen: One spreadsheet. Three categories. Review it weekly.
You may have come across a RAAIDD log before, or at least some version of it. If not, here's the quick breakdown. If you have, treat this as a reminder of why it matters:
Risks. Something that might happen and would cause a problem if it did.
Assumptions. Something you're treating as true but haven't confirmed.
Actions. Something that needs to be done, by someone, by a specific date.
Issues. Something that has happened and needs to be resolved.
Dependencies. Something you're relying on someone else to deliver before you can proceed.
Decisions. A choice that was made, including the rationale and who made it.
That's six categories, which can feel like a lot when you're already stretched thin. So here's what I'd suggest: start with three. Decisions, Risks, and Actions. People love things in threes, and these three will solve the majority of the pain I've described above. You can introduce the others as your team matures.
The format is dead simple. A single spreadsheet with these columns:
ID, just a number, so you can reference items easily
Date Raised
Meeting Raised, where did this come up?
Type, Decision, Risk, or Action
Description, what is it?
Next / Mitigating Actions, what are we doing about it?
Owner, who is responsible?
Due Date
Status, Open or Closed
Notes, with date and initials when adding updates
That's it. One tab. One spreadsheet. Nothing fancy.
I've been working with a client for eight months using this exact format. In that time, I've captured over 450 items. Before I joined, the team had no central record of who needed to do what by when. Decisions were scattered across calls. Risks were raised and forgotten. Now, when someone asks "why did we decide that?" the answer takes 30 seconds to find.
The habit is simple: after every call, whether it's a team meeting or a vendor call, write down any decisions that were made, any risks that were raised, and any actions that were agreed. Then review the log at least once a week. That weekly review is what turns it from a document nobody looks at into the single source of truth for your project.
Tip of the Week: Build your RAAIDD log in under five minutes.
If you don't have a RAAIDD log yet, use this prompt to create one tailored to your business:
Context: I am a non-technical founder running a start-up/scale-up. I need a simple, lightweight way to track decisions, risks, and actions across my business and vendor relationships. I have never used a RAAIDD log before and I need something my team will actually use, not something that feels like corporate bureaucracy.
Role: Act as an experienced IT delivery consultant who specialises in helping start-ups and scale ups implement lightweight governance that doesn't slow them down.
Action:
Create a RAAIDD log template in a simple spreadsheet format with the following columns: ID, Date Raised, Meeting Raised, Type (Decision / Risk / Action), Description, Next / Mitigating Actions, Owner, Due Date, Status (Open / Closed), and Notes.
Pre-populate the log with 10 example entries that would be common for a start-up working with an external software vendor. Include a mix of decisions, risks, and actions so I can see how each type should be recorded.
For each example entry, make the "Description" specific and realistic enough that I can adapt it to my own situation.
Provide a short guide (5 bullet points maximum) on how to maintain the log: when to update it, how often to review it, and how to make sure the team actually uses it.
Suggest 5 questions I should be asking at the end of every team or vendor call to ensure I'm capturing what matters.
Format: Present the template as a table I can copy into Google Sheets or Excel. Present the maintenance guide and end-of-call questions as separate numbered lists.
Target Audience: The output should be written in plain English that a non-technical founder can understand and implement immediately without any project management experience.
Five minutes to set up. Thirty seconds to update after each call. And when someone asks "why did we decide that?" six months from now, you'll have the answer.
This is the fourth in my series, What Your IT Vendor Isn't Telling You, written for founders and non-IT leaders navigating software delivery without a safety net.
If any of this sounds familiar, I'm happy to give you 20 minutes of my time to talk through whatever you're dealing with. No pitch. This stuff genuinely irks me, and I'd rather you had an experienced pair of eyes on it before it becomes a bigger problem.
Get the next one in your inbox
