EB-2 NIW for Software Engineers

USCIS guidance uses a software engineer as its closing example of an endeavor that fails. What separates an endeavor from a job description.

The USCIS Policy Manual closes its discussion of national importance with a software engineer: one "adapting their employer's code for various clients will have difficulty demonstrating the national importance of that endeavor, absent additional broader impacts supported by specific evidence." USCIS Policy Manual, 6 USCIS-PM F.5(D)(3). That is not a bar on software engineers; it is a statement about where the benefit of the work stops. Petitions that clear the first prong describe work whose effects run past the employer's customer list — infrastructure other organizations build on, security work that changes how a class of systems is defended, systems whose design others adopt.

Who This Is For

Who this page is for

Backend, infrastructure, platform, security, and systems engineers weighing an EB-2 national interest waiver — at a large company, at a startup, or on your own. You know what you build; this page is about how USCIS reads it.

It covers the problem specific to this occupation. The three requirements have their own pages.

The example USCIS wrote about your job

Every waiver turns on the three-part test from Matter of Dhanasar, 26 I&N Dec. 884 (AAO 2016): a proposed endeavor with substantial merit and national importance, a person well positioned to advance it, and a balance of factors favoring the waiver. Merit is rarely the difficulty for software work — technology is one of the areas the decision names as capable of showing it.

National importance decides these petitions, and the guidance's illustration of failure comes from this field. It does not say software is unimportant, or that the engineer is unqualified. It says the endeavor as described — customizing one company's code for that company's customers — has no demonstrated reach beyond the parties to those contracts. It is the last of a series that begins with the rule: "Benefits to a specific employer alone, even an employer with a national footprint, are not sufficiently relevant to the question of whether a person's endeavor has national importance." USCIS Policy Manual, 6 USCIS-PM F.5(D)(3).

Your occupation is not your endeavor

An endeavor is more specific than the general occupation. The guidance asks a petitioner for details about what the occupation normally involves and, separately, about the types of work the person proposes to undertake within it. USCIS Policy Manual, 6 USCIS-PM F.5(D)(3). In Dhanasar itself the occupation was engineer; the endeavor was research and development on air and space propulsion systems.

"Software engineer" is an occupation, and so are "staff engineer" and "principal engineer." The officer's analysis focuses on what you will be doing rather than on the job title or occupational classification. Market demand does not fill the gap either: proposing to work in an occupation with a national shortage, or to consult for others seeking to work in one, is expressly insufficient on its own. A petition built on the proposition that the country needs engineers has not yet described an endeavor.

Where does the benefit stop?

This question decides most software petitions, and it has a usable test: describe the work, then ask who is measurably better off if it succeeds. If the answer is your employer and the customers who pay your employer, the first prong is not yet made out. If it includes organizations with no commercial relationship to your employer, you have the start of an argument. The officer is asking whether your own individual endeavor "stands to have broader implications, such as for a field, a region, or the public at large." USCIS Policy Manual, 6 USCIS-PM F.5(D)(3).

The guidance names the alternatives. Where the work is technology built for a company, a petitioner can show widespread interest in adopting or licensing that technology, a novel and important manufacturing or operational process, or how the technology stands to affect the development of similar technology by other companies. Three routes, all evidentiary: someone outside wants it; the method itself is new and consequential; or others build differently because of it.

What distinguishes an endeavor: three composite patterns

These patterns are ours; USCIS does not recognize them by name. Each is a way of satisfying what the guidance asks for, and a composite of how such work is typically documented — never a description of anyone's case. None is a seniority argument.

  • Open-source or shared infrastructure. A component, protocol, or toolchain that organizations outside the employer depend on — the adoption route, where the dependents are not customers and the use is documented in public artifacts. The weak version is an internal system published under a permissive license that nobody has taken up; what carries weight is downstream use.
  • Security research and defensive engineering. Work whose value shows up in systems your employer does not own: a defect class documented and remediated across vendors, a mitigation adopted into a standard or a widely used runtime, guidance that changes how a category of systems is built. This is the novel-and-important-process route.
  • Novel systems with field-level adoption. Architectures, algorithms, or methods first built in one place and then taken up elsewhere through publication, standards work, licensing, or reimplementation — the third route almost verbatim. What makes it work is evidence of the travel: who took it up, and where.

A large employer cuts both ways

Engineers at well-known companies often assume the employer's name does part of the work. It does not. Scale of employer is not scale of endeavor, and a petition leaning on the company's user numbers is making the employer's case instead of the petitioner's.

The same employment helps in the other direction. Where a large platform is the mechanism by which your work reaches systems far outside it, the scale is evidence of reach — but the record must isolate your contribution and trace where it went. Working at a company whose products are everywhere, and working on something whose influence is everywhere, are different showings; only the second is yours. Startup and independent engineers face the mirror image: the work is unambiguously theirs, and the reach needs building out.

Ready to discuss your case?

Schedule a consultation with Loren Locke to see if this visa is the right fit.

Schedule a Consultation
What USCIS Asks

The questions an officer is actually answering

What, specifically, do you build? The officer looks past title to what the person will be doing, and asks whether the petition explains and substantiates how the proposed endeavor meets the national importance standard. A description that would fit any engineer at your level answers neither question. USCIS Policy Manual, 6 USCIS-PM F.5(D)(3).

Who benefits besides your employer? For employed engineers this is usually decisive, and the officer has an express instruction to apply. The record has to identify beneficiaries outside the commercial relationship.

Is the reach documented or asserted? Claims about a system's importance, unaccompanied by evidence of who uses it and what changed, are the recurring failure in the guidance's own examples. Every petition is decided case by case.

Evidence Patterns

What tends to answer those questions

A plain-English statement of the endeavor. Petitioners must "clearly describe in a straightforward manner the person's occupation and proposed endeavor," and even highly technical work should be described so an average person can follow it. An officer who cannot tell what the software does cannot find that it matters. USCIS Policy Manual, 6 USCIS-PM F.5(D)(1) and n.45.

Documentation of use outside the employer — adoption or licensing interest from unaffiliated organizations, contracts or agreements showing potential impact, or records of others building on what was released.

Evidence that the method itself is novel and consequential: a process others have taken up, or a specification whose provisions trace to your contribution.

For the second prong, material about the person: patents, published work and its reception, and evidence that the work has influenced the field of endeavor.

How We Work

How we handle this

Nothing gets collected until the endeavor is written down. For engineers that means separating a body of work from a job — identifying which of the things you have built has traveled, and building around that instead of around title and tenure.

We test the draft against the Policy Manual's own insufficiency examples, the software-engineer sentence first. If a paragraph can be answered by quoting that sentence back, it gets rewritten or dropped.

And when the benefit of your work stops at your employer, you hear it from us before filing, not from an officer in a Request for Evidence.

FAQs

Frequently Asked Questions

Have an attorney read your work the way an officer will

Bring the systems you have built and the evidence of where they are used. We will tell you which of it runs past your employer's customer list, and what the record still needs before anything is filed.

Immigration counsel to Fortune 500 employers at a national firm · Adjudicated 12,000+ visas at the U.S. Consulate, Mexico · Working in U.S. immigration since 2008 Featured in Newsweek, Condé Nast Traveler, Daily Mail