At the beginning of 2026, my GitHub contribution graph stayed nearly blank for several weeks. A few months later, the same graph showed hundreds of contributions in a single week. In July, this blog published 55 articles in Chinese , while GitHub’s contribution calendar recorded 733 contributions.
Those numbers prove neither quality nor user value, much less a business result. GitHub also makes clear that contributions may include qualifying commits, pull requests, issues, reviews, and other activity; the number cannot simply be relabeled as a commit count. GitHub’s profile contributions reference
But the numbers are enough to overturn one convenient diagnosis: I am capable of acting. High output and going nowhere can exist in the same person. If I keep calling the problem “poor execution,” I will probably build another productivity system and use it to avoid the real gap more efficiently.
The gap is not whether I can do the work. It is who gets to rank that work—and who gets to stop it.
The Same System-Building Skill, Two Outcomes
I am good at making complexity manageable. I split work into states, build workflows, add validators, and automate repetition. That ability has let me complete workloads that would otherwise be difficult for one person. It also keeps generating internally valid tasks: the data model needs compatibility, the workflow needs recovery, the automation needs monitoring, and the monitoring needs another state.
Every task is defensible. Every task has a clear definition of done. Whether anyone needs the original thing can wait until “the infrastructure is ready.”
The contrast between DayPage and this blog’s writing pipeline makes the risk visible. DayPage shipped in roughly seven weeks and became a product I use every day. Real use kept producing friction, and the product had to respond. The blog’s five-layer writing pipeline was designed just as carefully, but its master layer never actually ran. The old directory was eventually retired.
Both systems came from the same ability to build. DayPage entered a short loop with reality. The writing pipeline could renew itself through its own completeness.
When priorities always come from my judgment, I am simultaneously the designer, builder, evaluator, and person who decides whether the project continues. The project can hardly lose. It can always discover one more layer that “should be completed.” The code grows, the documentation improves, and the tests pass. The sense of completion is real. The original problem still has no veto.
That is the most uncomfortable part of the diagnosis: my ability to build systems is both an advantage and perhaps my most sophisticated way of avoiding an external verdict.
I Kept the Authority to Renew the Project
I used to understand outcome ownership as “shipping the thing.” I now think that covers only the first half of the chain. The rest includes who uses it, who refuses it, whether value is exchanged, who bears the cost, and what evidence will stop the project.
A project can always find a reason to continue. The need was real; distribution was the problem. Nobody paid because the market still needs education. Users left, but the next feature will fix retention. Costs are high, but scale will lower them later. Any one of these explanations may be correct. The danger appears when the person offering the explanation also controls renewal: after the result arrives, that person can rewrite the rules and keep the project alive.
The missing piece is therefore not another dashboard. I can still choose, interpret, and replace its metrics. Full outcome ownership does not mean blaming myself for every cause. It means one owner stays accountable across the entire chain—from choosing the problem through use, exchange, cost, and stopping—and gives up the unilateral power to rewrite the rules afterward. Some behavior I do not fully control must be able to change the priority.
If a result can be read but cannot cancel an investment, change the order of work, or end the project, it is not a verdict. It is only information.
Studying Chen Mian changed my comparison from “he works harder than I do” to “we have worked inside different feedback environments.” In a public interview with Xiaojun Zhang, Chen reviewed Liblib’s subsidy competition, product removal, and financing difficulties. He recalled the company having only RMB 4,000 left in the bank and discussed customer acquisition costs and when to increase spending. In another interview, he explained the choice to build a vertical design agent in terms of competition with larger companies, model maturity, and the timing of the product window. Xiaojun Zhang’s interview with Chen Mian Founder Park’s interview with Chen Mian
These retrospective accounts do not prove that every choice he made was right, nor do they offer a formula for success. They show a different relationship between evidence and renewal. Competitive structure, product state, cash balance, and acquisition cost could force the original plan to change. That relationship—not his personality—is what I want to learn.
Markets Can Be Wrong; a Verdict Still Has to Exist
The market is not the only source of truth. Long-term research may produce no income for years. Infrastructure often has to precede demand. Open-source work and personal creation should not be judged by payment alone. Markets chase short-term fashion, and they can reject valuable work because of distribution, timing, or buyer bias.
An external verdict therefore does not mean “make money immediately.” A valid decision rule only needs to meet three conditions: it is agreed before the work begins, applied at the agreed time, and cannot be rewritten unilaterally by the builder afterward. For a personal tool, repeated daily use can impose a constraint outside the architecture. For long-term infrastructure, real load, outside adoption, and maintenance cost can gradually earn veto power.
What I oppose is advance construction with no trigger. If a piece of infrastructure can answer “which signal makes this necessary?” and “how long without that signal means we stop?”, it may be buying a real future capability. If the answer is always “we will need it later,” it looks more like a postponement with no expiration date.
For My Next Project, I Will Give Up Renewal Authority
Before the next project begins, I will write down three questions:
- Who or what has the authority to say no to this project?
- Which observable behavior counts as a result, rather than my interpretation of progress?
- Before that signal appears, which infrastructure and automation must I refuse to expand merely because “we will need them later”?
At this stage, actual use, refusal, payment, or retention must be part of my answer. Before the signal appears, the system stays small. If it does not appear, I return to the problem and the user; I do not use new architecture to grant the old plan another term.
The decision has a concrete cost. I have to let the system remain rough, leave some of the automation that comes most naturally to me unfinished, and allow rejection to cancel a plan I like. Otherwise, the external result is still only advice. Renewal authority has never left my hands.
I do not need to become more capable. I need full outcome ownership.
A real battlefield does not score busyness. It is a place where even my best reason can still lose.
Responses