| Criterion | What it looks like in practice | Where it fails |
|---|---|---|
| Original contributions of major significance | A system, standard, library or technique that other people or companies adopted | Fails when the only evidence is that it shipped and worked inside your employer |
| Authorship of scholarly articles | Papers, RFCs, engineering publications with a real review process | Fails on company blog posts and internal design docs |
| Judging the work of others | Peer review for conferences and journals, programme committees | Fails if you only review inside your own company |
| Critical or essential role | A senior role at an organisation with a distinguished reputation | Fails when the organisation's standing is assumed rather than evidenced |
| High remuneration | Pay at the top of the market for your specialism and city | Fails without benchmark data, and equity alone is hard to value |
The problem is not the technical record
Most lead engineers who get refused are not refused for lack of achievement. They are refused because the file describes a system and never explains what the person did to it.
An officer has no way to evaluate a distributed tracing rewrite or a migration off a monolith. Those are meaningful to engineers and opaque to everyone else, including the person reading the file.
So the work has to be translated twice. Once into what changed for the business, and once into who outside the company noticed. The second translation is the one that decides cases.
The same logic applies to the technical description. Assume the reader will not evaluate your architecture, so do not ask them to.
Give them the before and after, the name of the thing you built, and the people who relied on it. The mechanism belongs in an appendix that supports the argument rather than carries it.
None of this requires you to become a writer. It requires 4 sentences per project, written while you remember the details, in a folder you keep.
That is the whole difference between a file that works and one that has to be rebuilt from memory 2 years later.
Adoption is the evidence, not scale
The strongest engineering cases are built on adoption rather than impact. A library other companies depend on. A standard that got ratified. A technique that shows up in other people's architecture. An open-source project with contributors you have never met.
That is because adoption is proof from outside. Somebody with no obligation to you chose to use the thing, and that choice is a document you can collect.
Scale, by contrast, is often unverifiable from outside. A system serving 40 million users says something about your employer and almost nothing about your contribution, and officers have learned to read it that way.
If your work is genuinely internal, the route is to make some part of it external before you need it. Publish the technique.
Speak about the migration. Open-source the piece that is not proprietary. Accept a peer review invitation. Each one converts internal work into external evidence.
There is also a version of this that costs nothing and is almost always skipped: writing down what you did while you are doing it.
Four lines at the end of a project, in a file you keep, describing the problem, the decision you made, who else relied on it and where the evidence lives. Two years of those notes is a file. Nothing else in this article matters as much.
And be realistic about what a file can and cannot fix. If the work was genuinely internal, invisible outside the company, and nobody who has standing in the field can speak to it, no amount of structure will turn that into a case.
Better to learn that in year two, while there is still time to publish something, than to discover it when the deadline arrives.
Which criteria actually fit an engineer
Original contributions is the natural fit, and the standard is third-party adoption. Licences, standards, dependents, citations, and experts who did not work for your employer saying so.
Authorship is the second, but only where there is a real review process. A conference paper or a journal article works. A company blog post does not, and neither does an internal design document, however good.
Judging is the third and the most available. Peer review for conferences and journals is genuinely short of reviewers, and a request with a CV attached succeeds more often than engineers expect.
Critical role is the one people reach for first and should reach for last. It requires the organisation's distinguished reputation to be evidenced before your role inside it is even assessed, so the two halves have to both be documented.
Where engineering files usually break
The first failure is a file that is all internal. Every exhibit is a screenshot of a dashboard, and none of them was produced by anybody outside the company.
The second is technical description without consequence. A page of architecture that never says what it enabled and who else relied on it.
The third is the team voice. Engineering results are collective by nature, so the file has to separate your design decisions from the team's execution, and that separation has to be supported by documents, not by assertion.
The fourth is timing. Judging invitations and published work take months to arrive, and a file assembled in the last six weeks will be thin in exactly the places officers look.
What to do while you still have time
Pick the one piece of your work with the best chance of external adoption and push it outward deliberately. A talk, a paper, an open-source extraction, a public post that explains the technique rather than the outcome.
Accept every peer review invitation you can get, and ask for more. It is the cheapest criterion in the regulation and it compounds.
Collect the documents as they appear. The ratification email, the dependency pull request, the conference acceptance. A folder started 2 years ago is worth more than a scramble in the last month.
Then get a real assessment of which 3 criteria you can meet today. Most engineers can meet one. The plan is about the second and third.
Translating technical work for a non-technical reader
The officer reading your file is not an engineer, and the file will be assessed by somebody who has to understand it in an afternoon. That is not a reason to simplify the substance. It is a reason to state the consequence before the mechanism.
Write the consequence in 1 sentence in plain language, then the mechanism, then the external proof. What problem existed. What you built. Who else used it, and how we know.
For example: the company could not ship more than once a week without outages. You designed the deployment system that made daily releases safe. Three other teams adopted it, and the pattern was written up at a conference and copied by two companies outside your employer.
That paragraph is short, checkable and entirely about you. Most engineering exhibits contain the middle sentence and neither of the other two.
The letters, and who should write them
Letters are not references. They are expert opinion evidence, and their job is to explain the significance of work the officer cannot evaluate alone.
The best letter writers are people who used your work and have standing in the field. A maintainer of a project that depends on your library.
A professor who adopted your method. A conference chair who invited you to review. Each one can say something concrete that nobody inside your company could say credibly.
Two or three are usually enough, and they should not repeat each other. One on adoption, one on the technical significance, one on your standing relative to peers.
Avoid letters from your own executives unless the case genuinely turns on the critical role criterion, and even then, pair them with external voices. A file where every letter comes from the same company reads as a company vouching for itself.
Timing: what the first six months decide
Most engineering files are built in the wrong order. The work happens first, the documentation happens last, and by then the people who would have written the letters have changed jobs.
Start with the letters, not the exhibits. Identify three people outside your employer who could speak to your work, and give them a reason to know it. A letter writer who has to be introduced to your project in the final month will write something general.
Then the external artifacts, in order of durability: a ratified standard or merged open-source contribution outlasts a conference talk, which outlasts a podcast appearance, which outlasts a company blog post nobody can find.
And keep the dates. An officer reading a file assembled in six weeks can see that every invitation arrived in the same quarter, and it reads as a campaign rather than a career. That is the honest version, and it is more useful than encouragement.
Questions this raises
Does my company's reputation help my O-1A?
It can support the critical role criterion, but only in two parts: the organisation's distinguished reputation has to be evidenced, and then your role inside it. A famous employer with no proof of your contribution does very little.
Can open-source work count as an original contribution?
Often, yes, because it comes with built-in third-party adoption: dependents, contributors, forks and usage by companies that have no relationship with you. It is one of the cleanest forms of evidence an engineer can produce.
Do I need published papers?
No. Authorship is one of eight criteria and you only need three. Plenty of approved engineers have no papers at all, and build the case on contributions, judging and critical role instead.
Is a principal or staff title enough on its own?
No. A title is not one of the criteria. What matters is what the role involved and whether that can be documented by somebody other than you and your manager.
Can I file while I am on H-1B?
Yes, and it is usually the better order, because a refused change of status leaves your H-1B in place rather than creating a gap. The timing against travel and your H-1B expiry is the part that needs working out.