EB-2 NIW for Indian IT and Engineering Professionals

Why Indian-born IT and engineering petitioners face a distinct filing picture

Immigration law caps the number of green cards issued to natives of any single country at 7% of the total annual employment-based allocation, regardless of that country's share of filings. Because India-born professionals file a disproportionate share of EB-2 petitions relative to that 7% ceiling, demand in the EB-2 India category routinely exceeds supply, producing a backlog measured in years rather than months. This backlog is tracked through a "final action date" — the cutoff published monthly that determines whose priority date (the date USCIS received the underlying petition) is current enough to move to the next visa step.

What this does and does not affect

The per-country cap governs when an approved petitioner can file Form I-485 (adjustment of status) or proceed to consular processing — it has no bearing on whether Form I-140 itself gets approved. USCIS adjudicates the I-140 against the same Dhanasar standard for every petitioner, irrespective of country of birth. A well-documented petition from an India-born engineer is evaluated on identical criteria to one from any other country.

Action item

Before filing, check the current Visa Bulletin at travel.state.gov and locate the EB-2 row under the India column for the final action date. Recheck it monthly if you are already holding a priority date, since it affects timeline planning, not the substance of what you submit with the I-140.

Mapping a technical career onto the three Dhanasar prongs

The Dhanasar framework asks three separate questions, and a technical role has to be translated into each one individually — a job title alone answers none of them.

Prong 1: substantial merit and national importance

Describe the endeavor, not the job. "Improving cloud infrastructure resilience for financial-sector clients" points to national importance; "Senior SRE at [company]" does not. Similarly, semiconductor supply chain work can be framed around domestic chip manufacturing capacity, cybersecurity work around protection of critical infrastructure sectors (energy, healthcare, finance), and AI model deployment around safety, reliability, or sector-wide productivity effects.

Prong 2: well-positioned to advance it

This is where credentials, track record, and prior measurable outcomes attach — degrees, patents, publications, past deployments that succeeded at scale.

Prong 3: benefit of waiving the job offer

Explain why requiring a specific employer's labor certification would undercut the endeavor — for example, work that spans multiple employers, open-source contributions, or independent research that no single job offer captures.

Drafting the endeavor statement

Write one paragraph, separate from any job description, stating the endeavor in outcome terms and naming who benefits beyond the employer — an industry, a sector of users, a regulatory or safety objective, or the public. Avoid internal metrics like promotions or performance ratings; use effects visible outside the company.

Evidence categories specific to software, hardware and systems engineering roles

Public-record evidence

• Open-source contributions: export GitHub/GitLab profile stats (contribution graph, stars, forks, merged pull requests) and include repos where the petitioner is a maintainer or top contributor. Screenshot the contribution history with dates visible.
• Patents: pull PDFs directly from USPTO Patent Public Search or the relevant foreign patent office (e.g., India's IP India portal); include the granted patent, not just the application, where possible.
• Publications and citations: list IEEE/ACM papers with DOI links, and generate a Google Scholar citation report showing citation counts and h-index at time of filing.
• Talks and standards work: conference program listings, recorded talks, or standards-body meeting minutes showing named participation.
• Membership grades: IEEE Senior Member or equivalent elevation letters, which document independent peer evaluation.

Internal, employer-held evidence

Architecture design docs, incident postmortems, and performance benchmarks rarely leave the company. To use them:

1. Identify the specific measurable outcome (uptime improvement, latency reduction, cost savings, throughput gains).
2. Ask a supervisor or technical lead to write a letter quantifying that outcome and stating the scope of deployment (number of users, systems, or regions affected).
3. Attach a redacted version of the underlying document as a supporting exhibit where confidentiality allows, cross-referenced in the letter.

Quantified, attributable claims carry more weight than descriptions of general duties.

Building the recommendation letter set: who to ask and what to specify

Petitions in this profile typically include several letters, commonly a mix of direct supervisors, cross-functional collaborators (product managers, architects on adjacent teams), and independent experts — professors, standards-body members, or engineers at other companies who have never worked with the petitioner directly. The independent group matters because it demonstrates recognition beyond the petitioner's own reporting chain.

What each letter needs to state

1. The reviewer's own credentials and role — title, years in the field, why they are positioned to judge this work.
2. How they know the petitioner's work — direct supervision, code review, joint standards committee, citation of published research, conference co-attendance.
3. Specific, quantified claims tied to the endeavor statement: systems handling a stated request volume, latency reductions by a stated percentage, a patent's claims and how they were used, a paper's citation count. Avoid adjectives like "brilliant" or "exceptional" standing alone — pair every claim with a number, a system name, or a dated event.

Avoiding the template trap

Draft an outline of facts for each letter separately rather than sending one boilerplate letter to all recommenders for signature. Reviewers should write in their own voice, using their own sentence structure and vocabulary. Officers compare letters across a filing, and near-identical phrasing, paragraph order, or unusual turns of phrase repeated across supposedly independent recommenders is a recognized RFE trigger.

Assembling the personal statement and matching it to Form I-140 and ETA-9089-style labor market data

Structure of the statement

Write the personal statement as a narrative arc, not a resume in prose: (1) origin of technical focus, (2) specific problem or gap in the field, (3) the petitioner's contribution, (4) evidence that the contribution reaches beyond one employer, (5) forward-looking plan tied to the endeavor statement drafted earlier. Each section should point to specific exhibits by number, so the reader (the officer) can verify claims without hunting.

Using labor-market data without a labor certification

An NIW petition waives the PERM process, so there is no ETA-9089 to file — but the underlying labor-market context PERM would have documented can still support the national-importance prong. Cite the O*NET-SOC code matching the occupation (e.g., 15-1252.00 for Software Developers, 17-2199.xx or 15-1299.xx for various systems/engineering roles) and reference Department of Labor data on employment projections or prevailing wage levels for that code. Use this to describe the field's scale and demand, not to argue personal eligibility for a wage level.

Where to find current codes and data

Look up current O*NET-SOC codes and descriptions at onetonline.org. For prevailing wage and occupational outlook figures, use the Department of Labor's Foreign Labor Certification Data Center (flcdatacenter.com) and the Bureau of Labor Statistics Occupational Outlook Handbook — both are updated periodically, so pull the current version at filing time rather than relying on cached figures.

Organizing the exhibit index and filing packet

An exhibit index is the single document that lets an officer locate every piece of evidence without hunting through hundreds of pages. Petitioners who skip it, or who bury exhibits inside long, unlabeled PDFs, force the adjudicator to search — and evidence that cannot be found quickly is effectively evidence that does not exist for the purposes of a fast review.

Why structure matters here specifically

Dhanasar petitions rely on evidence pulled from many different sources: code repositories, patent filings, conference papers, internal memos, and letters. Because this evidence does not arrive in one uniform format, the burden falls on the petitioner to impose order on it. A reviewer should be able to open the index, see which prong a given exhibit supports, and jump directly to the right page.

Set the packet's logic before assembling pages

Before printing or merging PDFs, decide:

1. A stable exhibit-lettering or numbering scheme that will not need to change once letters are drafted.
2. Which prong (or prongs) each exhibit is meant to support.
3. Which documents require certified translation before they can be included.
4. Where duplicate evidence (e.g., a patent cited in both a letter and its own exhibit) will be cross-referenced rather than reproduced.

The next section works through this as a concrete table and file-naming convention.

Organizing the exhibit index and filing packet

Build the exhibit index first

Draft the index before scanning a single document. It becomes the map an officer uses to move through the packet, and it forces you to notice gaps.

File naming

Use a consistent scheme: Exhibit_A_Patent_US1234567.pdf, Exhibit_B_Letter_Iyer.pdf. Avoid generic names like scan001.pdf — reviewers and you both lose time reconciling those against the index.

Assembly order

1. Cover letter summarizing the petition and listing exhibits
2. Form I-140
3. Evidence exhibits, in index order
4. Personal statement
5. Recommendation letters
6. Translations and certifications for any Indian-issued documents (degree certificates, experience letters), each translation accompanied by the translator's certification of accuracy and competency per current USCIS instructions — verify requirements on uscis.gov before filing.

Common RFE triggers for this applicant profile and how to preempt them

A small set of recurring problems accounts for most RFEs issued to this profile.

Genericity

A personal statement that could belong to any software engineer or hardware designer — no named technology, no specific deployment, no measurable outcome — reads as interchangeable. Every claim should trace back to a specific project, system, or publication also present in the exhibit index.

Adjective-only letters

Letters stating the petitioner is "brilliant," "exceptional," or "a key contributor" without a number attached (users served, latency reduced, systems deployed, papers cited) invite scrutiny. Each letter should contain at least one quantified, verifiable claim.

Missing translation certifications

Indian university transcripts, degree certificates, and experience letters submitted in English translation without the translator's certification of accuracy and competence are a frequent, entirely avoidable RFE cause. Confirm every translated document carries a signed certification page.

Thin independent evidence

A record built almost entirely from employer-supplied letters and internal documents, with no citations, patents, independent reviewers, or professional recognition from outside the petitioner's chain of command, draws questions about whether the record reflects the petitioner's individual standing.

Conflating company success with individual role

Evidence describing the employer's revenue, market share, or product adoption without isolating the petitioner's specific contribution leaves the individual's role unclear.

Final check

Before filing, go through the exhibit index prong-by-prong and confirm each of the three Dhanasar prongs is supported by more than one independent exhibit type.