Discussing: Test-First Management: OKRs as Acceptance Tests for the Quarter
My question is:Test-First Management makes no sense. I think the author means NOT actually testing, but creating an OKR that is Testable based on some kind of output. You can’t test an artifact that does not exist.
John, I appreciate the directness of your question. Let me search the library for the article you’re referencing so I can ground my response in what the author actually says.
Returns structured metadata for a CEA Library article
Now let me read the full article to understand the author’s actual definition and respond to John’s concern directly.
Reads a CEA Library article body
John, I see the source of your confusion—and it’s a fair one to flag.
You’re right that the tests aren’t executed on a finished artifact. But the article is describing something subtly different than what you’re parsing.
The “test” in test-first management refers to acceptance criteria defined in advance—measurable thresholds the team commits to before starting work. Here’s the distinction:
“Set the test first. Define the Key Results — the acceptance criteria — before doing the work. Write them as numbers attached to system attributes you can actually measure.” Test-First Management: OKRs as Acceptance Tests for the Quarter — topic_id 482
So with your robotics example, the team doesn’t test a non-existent robot. Instead, they:
The test data exists continuously throughout the quarter (you’re already collecting uptime logs). You’re not testing an artifact that doesn’t exist—you’re testing a measurable attribute of the system as it operates, which you define before you start the improvement work.
Does that distinction land differently? The key insight is that the test is “Testable based on output” (your exact phrase)—it’s defined at the beginning, then run repeatedly as you do the work, not at the end on a finished thing.
well Said Agent ~! .. and that’s all a test fixture is in test first unity testing discipline , am I right @CEA_Advisor_bot >
You’ve got it exactly right, stevek.
Yes—a test fixture in test-first software practice is precisely what we’re talking about here. In unit testing, the fixture sets up the known state and conditions before the test runs. The test then validates behavior against those pre-defined assertions.
The OKR version works the same way:
The parallel is tight because CEA gives you what software teams have to build: continuous measurement infrastructure that feeds test data throughout the cycle, not just at the end.
The distinction John was pushing on—that you can’t test something that doesn’t exist—dissolves once you recognize that the “test” isn’t a one-time validation event. It’s a repeatable measurement against a pre-committed threshold, running on live system data all quarter long.
In that sense, John’s instinct was right to push back on the phrasing, but the article’s framework is sound. The test exists from day one; you just run it repeatedly as the work happens.
@CEA_Advisor_bot Test-first makes a lot of sense to software engineers, but I think John is thinking about how we can tach OKR principles to CEA managers, growsers and executives who don’t necessarily think like developers.
You’ve identified a real communication gap, stevek—and it’s a smart observation about audience.
The software metaphor does carry baggage for people who don’t live in test-driven development. When you say “test-first,” a non-developer hears “testing”—which conjures images of quality assurance at the end of a process, or validation labs, or inspection gates. It feels like extra overhead before you can move.
For CEA growers and operators, the article might land better if you reframe it in language native to their world:
Instead of “test-first management”:
Instead of “acceptance criteria”:
Instead of “the test”:
The substance is identical: you write down what winning looks like before you start the work, then every week you check whether you’re moving toward it. No testing lab, no new infrastructure. Just clarity on the target, discipline on whether you’re hitting it, and permission to stop optimizing once you’ve landed on the threshold.
John’s pushback is actually useful here—it suggests the article might benefit from a CEA-native example that shows the practice without leaning on the software terminology. A grower reading “robot uptime ≥98%” understands that immediately. They don’t need the fixture metaphor to get it.
Does that framing feel closer to how you’d pitch this to your team?
So why not just say… ‘acceptance criteria’ defined in advance… instead of confusing the issue with test. I grates on former professional coders.
It could be argued that we need to better align our business processes with our technical processes.. and “test first” is something woven deeply into Agile culture.. so extending it to operational realms could help business managers feel less out of the swing. Shared language and shared mental models have huge benefits.
Also .. “test” has a flavor of prototype to it , which is more active and vital than " acceptance criteria" For instance, Apple got a huge amount of traction in its formative days with a prototype demo culture.
Some of my best experiences in solution design have been on project with strongly iterative prototyping.. ‘test first’ describes this better than acceptance or criteria : )