EB-2 NIW for Remote and Distributed Tech Workers

How remote work changes the documentation, not the legal standard

Working from a home office, a co-working space, or a series of countries does not change what a National Interest Waiver petition has to prove. The adjudicator applies the same three-prong framework from Matter of Dhanasar regardless of where the petitioner's laptop happens to be: that the proposed endeavor has national importance, that the petitioner is well positioned to advance it, and that it would benefit the United States to waive the job offer and labor certification requirement. Remote or distributed employment does not create a fourth prong, and it does not lower or raise the evidentiary bar on the three that exist.

What remote work does change is the documentary record needed to establish ordinary, supporting facts that a traditional on-site job makes easy to show: that the petitioner holds the claimed role, works the claimed hours on the claimed project, reports to the claimed employer, and did so from a location where the work was legally authorized. An employer letter alone, written for someone sitting in a single headquarters, often cannot carry that weight for someone who has worked across several time zones, platforms, or legal jurisdictions during the qualifying period.

This article addresses only that documentation layer. It does not address how to argue national importance, positioning, or balance of factors — those remain governed by Dhanasar and by the petitioner's own facts. What follows is a set of procedures for building the evidentiary record that supports those arguments when the underlying work pattern is remote or distributed.

Documenting your employer relationship and role when there is no single office

A single employer letter on company letterhead is often the only exhibit a traditional petition uses to establish job title, duties, and reporting structure. When there is no central office, that one document has to be replaced by several that corroborate each other.

Core substitute documents

• Offer letter or contract stating remote status explicitly, including work location terms.
• Org chart showing your position, reporting line, and direct reports if any.
• Platform contribution records — exported activity logs from Slack, Jira, GitHub, or equivalent systems showing sustained, dated involvement.
• Signed statements from managers in other time zones, each describing your duties and the proportion of your time devoted to the proposed endeavor.

Build a one-page role summary

1. List job title exactly as it appears on payroll or contract documents.
2. State the reporting line (name and title of manager, and that manager's location).
3. Estimate percentage of working time spent on the proposed endeavor versus other duties, and state how you calculated it (project logs, sprint allocation, hours tracked).
4. Cross-reference each claim to a supporting exhibit.

Worked example

Proving your work location and legal work authorization history

A distributed work history spread across countries or US states needs a single exhibit that reconciles where the applicant actually worked with what legal basis permitted that work at the time. Reviewing officers cannot infer this from a resume; they look for a document that does the cross-referencing for them.

Build the location/timeline table

Create one row per continuous stay in a given location, covering the full qualifying period:

Steps

1. List every address or city where the applicant physically worked, not just the employer's office address.
2. For each row, attach the underlying proof: visa stamp, I-94 record, work permit, residence card, or employer authorization letter.
3. Note any period of unemployment, travel, or unpaid leave explicitly rather than omitting it.
4. Reconcile this table against tax filings, lease agreements, and the employer's own payroll location records before filing.

Gaps between rows, addresses that contradict tax documents, or stretches with no corresponding authorization document are a common source of RFE. If a stay cannot be documented, say so in the table rather than leaving silence for an officer to notice.

Building the independent-contribution record for distributed teams

On a distributed team, most generated output is collective — a shared repository, a shared product, a shared paper. The exhibits in this section must isolate what the applicant personally did within that output.

Filter version-control and review records by author

Export commit logs filtered to the applicant's username (git log --author="name" --since=... --until=...), and pair them with code review approvals showing the applicant as reviewer or author of record. Save exports as dated, machine-generated files rather than screenshots where possible, and note the repository name and date range on each.

Pull individual-attribution records from internal systems

Gather patent or invention disclosure records naming the applicant, internal design documents or RFCs with named authorship, and ticket systems (Jira, Linear) showing tasks assigned to and closed by the applicant. Where a document lists multiple authors, obtain a short dated note from a manager or co-author describing which sections or components were the applicant's own.

Tie metrics to the applicant's specific deliverable

Citation counts, download numbers, or usage statistics should be linked to a component, module, or paper the applicant individually authored, not to the team's overall product. Where metrics are only available at the team level, add a supporting statement specifying the applicant's share of the underlying work, and keep that statement consistent with the role summary and the location/timeline table already built.

Letters of recommendation across distributed teams and time zones

Selecting recommenders

Choose people who can speak to specific, dated work, not just character. A useful mix for a distributed-team record:

1. The direct manager, even if they never shared a physical office — they can confirm reporting line, role, and percentage of time on the proposed endeavor.
2. Two or three cross-functional collaborators based in other countries or regions, who can describe how the applicant's work reached teams they didn't sit with.
3. Independent, external recommenders — users or maintainers who adopted the applicant's open-source project, cited a paper, or built on a published tool, with no reporting relationship to the applicant.

Avoid recommenders who only supply a title and a compliment; each one must be able to name a project, a date range, and an outcome.

Briefing by video call

Schedule a short call with each recommender before drafting. Send them, in advance: the role summary table, the relevant rows of the location/timeline exhibit, and two or three bullet points of what you want the letter to document (dates, deliverables, measurable results). Ask them to write in their own words from their own records — not from a draft you supply.

Letter structure

A usable letter states: how the recommender knows the applicant and across what time period; the specific remote-collaboration arrangement (tools, cadence, time zones); named projects with dates; and quantified outcomes attributable to the applicant specifically, not the team.

File each letter with a dated cover note and keep the sender's full title and contact information on the letterhead.

Assembling the evidence index for a remote-work record

Every exhibit you gather for the documents above belongs in a single tracker, built before you draft the petition letter, not after. It lets you see gaps while you can still fix them, and it gives the officer a map instead of a pile.

Build the tracker

Create a spreadsheet with these columns: exhibit number, document title, date, source, Dhanasar prong supported, and file name. Add one row per document, in the order you plan to submit exhibits.

Keep it consistent

Use the same exhibit numbers in the tracker, the file names, and the petition letter's citations to evidence. Store files in one folder using the naming convention shown above, and update the tracker each time you add or replace a document so the index always matches what is actually in the filing.

Assembling the evidence index for a remote-work record

Before assembling the petition, build a single tracker that lists every exhibit you intend to file. This is the document you will consult while drafting the personal statement and the one an officer can use to find anything quickly.

Set up the columns

Use a spreadsheet with these columns:

1. Exhibit number — the number as it will appear on the tab or cover sheet (Exh. 1, Exh. 2, …).
2. Document title — a plain description.
3. Date — the date the document was created or covers.
4. Source — who issued it (employer, GitHub, a named manager, a journal).
5. Dhanasar prong — which of the three prongs it supports (national importance, well positioned, or benefit of waiver), noting if it supports more than one.
6. File name — the exact file name used in your submission folder.

Worked example

Keep the tracker current as you add or drop exhibits, and use it as the master reference when writing cross-references in the petition letter.

Common RFE triggers specific to remote and distributed work

Certain gaps show up repeatedly in remote-work petitions. Review the list below against your own exhibits before filing.

Unverifiable remote employment

An offer letter stating "remote" with no corroborating record — no Slack history, no calendar invites, no manager statement describing day-to-day supervision — reads as unverified. Pair every claim of remote employment with at least one communication or collaboration artifact tied to the same date range.

Location mismatches

If tax returns, W-2s, or 1099s list an address or state that doesn't match the location/timeline table, expect a request to reconcile the discrepancy. Check every exhibit that carries an address or jurisdiction — pay stubs, lease agreements, visa stamps — against the table, not just the narrative.

Team output presented as individual work

A product launch announcement, a company blog post, or a team dashboard does not establish what one person did. Where a recommendation letter or exhibit describes a team result, confirm it also names the applicant's specific deliverable, commit range, or design document.

Letters that omit the remote arrangement

A letter that never mentions working across time zones, asynchronous collaboration, or distributed reporting lines can read as generic even when the underlying work was remote. Ask recommenders to state explicitly how and from where they worked with the applicant.

Before filing, cross-check every exhibit in the evidence index against the location/timeline table, line by line, and resolve any date, location, or employer that does not match.