Looking at rejection feedback for (OC2), a very consistent pattern is emerging lately, applicants present solid, high effort work like mentoring, building open source projects, public speaking, publishing resources and yet still get rejected.
The decision feedback almost always uses one specific phrase: “lacks recognition and impact, therefore cannot be proven to be sector-advancing.”
To be fair to the assessors, if you check the official Tech Nation guidance for OC2, these are the core elements required for the criterion.
The core issue isn’t that your activities aren’t valuable, it’s just that activity only proves effort, recognition and impact prove sector advancement.
Here is a breakdown of how to think about this when structuring evidence, based on patterns in successful vs. unsuccessful applications I have seen lately.
Understanding “Recognition” for OC2
Recognition means you were explicitly acknowledged as a domain expert or driver of change within the broader tech ecosystem. In strong applications, this recognition usually comes from two main directions:
1. Recognition Before the Activity (Recognition as an Expert)
You were invited or selected to do something because of your established track record or recognised domain expertise.
-
Weak Evidence: An email saying “Thanks for speaking at our design school meet-up.”
-
Strong Evidence: An invitation letter or email explicitly stating: “We are inviting Raphael Olu. to speak as a domain expert because of his pioneering work on X framework, as our students needed insight from an established authority in…”
2. Recognition After the Activity (Recognition for the Output)
You created something, and the ecosystem acknowledged and credited you for it as the architect or creator.
-
Weak Evidence: “I built an open-source tool and made it publicly available.”
-
Strong Evidence: “I built a tool that was officially adopted by Major Platform/Company or integrated into standard industry workflows, with press coverage, official release notes, or citations directly crediting me as the author.”
Usage Metrics vs. Sector Advancement
A common trap applicants fall into is relying heavily on raw adoption metrics such as 13k users, 500 downloads, or 400 mentees just like our case study above.
While high download or usage numbers are valuable, usage on its own is often viewed as passive consumption rather than sector advancement, that is where the proper context of the usage should come to play.
-
Downloads/Users = Scale & Usage
-
Recognition + Shift in Practice = Sector Advancement
For instance, 10,000 downloads shows people are using your tool. But pairing those 10,000 downloads with emails from senior engineering leads stating how your tool changed their team’s workflow or asking you to customise it for their organisation or showing that other prominent projects built upon your codebase, shifts the evidence from just usage to sector advancement.
How to Apply This to Your Application
If you are currently putting together evidence for OC2, ask yourself these three questions before submitting any document:
-
Does this document only show what I did, or does it show how the industry responded to it?
-
Where is the third party validation that credits me directly? (Like media mentions, official partnership announcements, explicit invitation letters, expert correspondence about what I did).
-
If I show metrics (downloads, mentees, views), do I have qualitative proof showing how those numbers created a tangible shift in the field?
Activities gets you on the right direction, but third party recognition and measurable sector impact are what will help you present evidence that truly aligns with OC2.
All the best.