Software Engineers/Leaders' Guide to the O-1A Visa (2026)

TL;DR

• The O-1A is a nonimmigrant visa for individuals with extraordinary ability in the sciences, education, business, or athletics. Computer science and software engineering fall squarely within the sciences category. The visa has no annual cap, no lottery, no degree requirement, and no prevailing wage obligation. Initial validity is three years with unlimited extensions.

• Many senior and staff-level engineers are closer to qualifying than they assume. The mental barrier is the phrase "extraordinary ability," which engineers typically associate with Nobel laureates or academic researchers. The actual standard is closer to: are you in the small percentage at the very top of your field, with documented evidence that others recognize this? For engineers at the staff, principal, or distinguished level who have built things with documented scale and impact, the answer is often yes.

• The four criteria most engineering O-1A cases are built around are: original contributions of major significance, critical or leading role at a distinguished organization, high salary or remuneration, and judging the work of others. Published material and awards round out stronger cases.

• The single most common failure in engineering O-1A petitions is confusing employer prestige with individual distinction. Working at Google, Meta, or Microsoft does not establish extraordinary ability. What USCIS evaluates is what the specific engineer did and what measurably changed because of their individual contribution. The petition must isolate your work from your team's work.

• Open source contributions are among the most powerful evidence available for engineering O-1A cases because the evidence is publicly verifiable: GitHub star counts, fork numbers, download metrics, production adoption by named organizations, and maintainer status are all accessible to USCIS without relying solely on the petitioner's characterization.

• Engineers working primarily on proprietary closed-source systems face a documentation challenge but not a disqualifying one. Architecture documents, system performance metrics, patent filings, executive letters describing specific decisions and their outcomes, and sanitized technical case studies can all establish individual contribution to systems at scale.

• USCIS applies the Kazarian two-step framework. At Step 1, USCIS evaluates whether evidence exists that at least three criteria are satisfied. At Step 2, USCIS evaluates the totality of evidence to determine whether it establishes sustained national or international acclaim at the very top of the field. Clearing Step 1 does not guarantee Step 2.

• Premium processing guarantees a USCIS response within 15 business days at $2,965 (effective March 1, 2026).

Why Software Engineering Is a Legitimate O-1A Field

USCIS explicitly includes computer science and software engineering within the sciences category. This is not a workaround or an interpretation: it is the regulatory position, and adjudicators are accustomed to evaluating engineering O-1A visa petitions.

The tech industry also produces exactly the evidence the O-1A framework rewards. Engineers at senior levels routinely command compensation well above national medians. Open source contributions create publicly verifiable adoption records. Conference presentations at recognized venues establish recognized expertise. And the scale of systems built by senior engineers, measured in users, transactions, latency improvements, and cost reductions, provides the quantified individual impact that USCIS uses to evaluate extraordinary ability claims.

What the O-1A does not reward is a strong resume at a prestigious employer. An impressive career at a well-known company, a long list of shipped features, and positive performance reviews describe a large population of competent engineers. 

What distinguishes extraordinary ability at the top of the field is evidence that the specific engineer is recognized above this general population: independent validation of individual contribution from outside the employer, adoption of technical work by others beyond the immediate team, and documentation of outcomes that are remarkable rather than merely good.

This distinction between competent senior engineer and extraordinarily able engineer is the central challenge of the engineering O-1A. The engineers who qualify have typically spent five or more years building things whose impact can be documented specifically and independently. Those who do not yet qualify have typically built important things but not yet documented them in a form USCIS can evaluate.

The Attribution Problem: The Unique Challenge for Engineers

Every O-1A category has a specific challenge. For researchers, it is establishing that their specific work had major significance rather than contributing to a team effort. For engineers, this problem is amplified: almost all significant engineering work is team-based, and the default documentation of that work names the product or system, not the engineer who designed its core architecture.

USCIS evaluates individual achievement, not team success. A petition that documents the success of a system without isolating the specific engineer's contributions to that system fails the individual attribution test even if the system itself is remarkable.

The documentation tools for establishing individual attribution in engineering are different from those in research:

• Commit history and pull request records establish specific code contributions to specific systems. A GitHub export showing the engineer as the primary committer to a critical component over a sustained period is objective evidence of individual technical work.

• Design documents and technical proposals bearing the engineer's name establish authorship of the architectural decisions that drove the system's design. These documents exist in most engineering organizations and are generally accessible to the engineer even for proprietary systems.

• Patent filings name inventors individually. A patent on a novel approach developed by the engineer, even if assigned to the employer, names that engineer as an inventor and establishes individual intellectual authorship of the technical innovation.

• Expert-opinion letters and peer letters from people who worked with the engineer but are now at other organizations can describe, from their independent vantage point, the specific technical decisions the engineer made and why those decisions were significant. A former colleague who now leads engineering at a different company explaining that the system design they encountered while working together changed how they approach distributed systems is independent evidence of individual contribution.

• Executive and leadership letters from the engineer's management chain, while less independently credible than external letters, can document what specific decisions were the engineer's, what authority they had, and what changed because of their individual work. These letters are more credible when they describe specific decisions and outcomes rather than general performance.

The Eight Criteria Mapped to Engineering Evidence

Criterion 1: Original Contributions of Major Significance

This is the primary criterion for most engineering O-1A cases and the one where the most powerful engineering-specific evidence lives.

The criterion requires that the contributions be original and of major significance to the field. For engineers, major significance is established by how others engaged with the contribution: whether they built upon it, adopted it, referenced it in their own technical decisions, or otherwise demonstrated that the contribution moved the field or a significant portion of it.

Open source projects with documented adoption are the strongest form of this evidence for engineers because the adoption is publicly verifiable. A project with 10,000 or more GitHub stars and documented production use by named organizations demonstrates both originality and significance in terms USCIS can verify independently. Letters from engineers at other companies who specifically describe using and building upon the project strengthen the case by adding qualitative context to the quantitative adoption data.

Contributing to highly selective projects with rigorous review processes proves extraordinary ability through the selection process itself. Projects like the Linux kernel, Chromium, or TensorFlow accept only a small percentage of contributions due to high quality standards. If patches were accepted to these projects, the acceptance rate and review process should be documented, along with code review discussions showing expert engineers evaluating and approving the work.

For proprietary systems, the evidence takes different forms: patents filed on novel technical approaches developed in the role, architecture decision records bearing the engineer's name, technical case studies showing the system's scale and impact with the engineer identified as the architect, and letters from senior technical colleagues describing why specific design choices were significant and attributing them to the engineer.

Patents strengthen the original contributions argument when they have been commercially applied, licensed, or cited in subsequent patents. A granted patent on a technology that the engineer's employer has deployed at scale, or that other companies have licensed, is stronger than a pending patent on an approach that has not yet been adopted. The petition should document the patent's current status and any evidence of adoption or licensing.

Criterion 2: Critical or Leading Role at a Distinguished Organization

This criterion requires establishing two things independently: 

• The organization is distinguished

• The engineer's role within it was critical or leading

For software engineers, distinguished organizations include technology companies with documented market standing, significant funding or revenue, recognized industry reputation, and notable product deployments. 

Large established technology companies are distinguished by their market position. Well-funded startups may be distinguished by their recognized investors, their technical reputation in the field, or their documented market traction. Open source foundations and projects are distinguished by their community scale and industry adoption.

The critical role argument for individual contributors requires more work than for engineering managers because the structural centrality of a staff or principal engineer is less obvious than that of a team lead or director. 

The petition must establish that the specific engineer's technical decisions were essential to the organization's technical outcomes, not that they were a skilled member of a team that produced good outcomes.

Staff engineer, principal engineer, distinguished engineer, and fellow titles at major technology companies carry meaningful weight for this criterion because these roles are specifically defined as involving field-level technical leadership rather than management or ordinary engineering execution. The petition should document what these titles mean at the specific organization: the selection criteria, the percentage of engineers who reach these levels, and the specific technical authority that comes with them.

For engineering managers, directors, and VPs, this criterion is more naturally available because the organizational authority of these roles is clearer and more documentable. The evidence standard is the same as for the CXO guide: document what decisions were specifically yours, what authority you had, and what measurably changed because of your leadership.

Criterion 3: High Salary or Remuneration

Technology compensation at senior and staff levels frequently places engineers well above the national median for their occupation, making this criterion one of the most readily available for engineers at the L5 equivalent and above at major technology companies.

The salary should be within the top 5% of reported salaries for the role and city. Comparison tools such as Levels.fyi, the FLC Data Center, LinkedIn Salary, and Glassdoor provide role-specific and location-specific benchmark data. The petition must make the comparison explicit and document it: the engineer's total compensation (cash, bonus, and equity valued at current or most recent grant price) compared to the published survey data for the specific role level and geographic market.

Equity compensation is includable when it can be valued objectively. Vested RSUs at a public company have a clear market value based on the share price at vesting. Options at private companies require a 409A valuation or the implied valuation from a recent funding round to establish fair market value. The calculation and its basis must be documented, not asserted.

Total compensation at staff and principal engineer levels at major technology companies, including equity, routinely reaches $400,000 to $800,000 or more in major markets. When compared to BLS data showing that the 90th percentile for software developers nationally is $211,450 (May 2024), the case that compensation is significantly above peers is often straightforward if the documentation is properly assembled.

Criterion 4: Judging the Work of Others

This criterion is satisfied by formal evaluation roles where the engineer is selected based on expertise to assess others' technical work. Not all code reviews qualify. The question is whether the engineer is selected as a recognized expert to evaluate work by others in the field, not whether they are performing normal employment duties.

Strong evidence for engineers includes: 

• Serving as a program committee member or reviewer at recognized technical conferences (NeurIPS, ICML, CVPR, ICLR, OSDI, SOSP, NSDI, and comparable peer-reviewed venues)

• Serving as a technical reviewer for IEEE or ACM publications, judging at recognized hackathons or engineering competitions at the invitation of the organizing institution based on the engineer's recognized expertise

• Serving on advisory boards where the engineer formally evaluates technical proposals

Judging criterion clarifications address modern peer review. Serving on technical conference program committees, reviewing GitHub pull requests for major open source projects, evaluating grant applications, or assessing startup applications for established accelerators all potentially satisfy judging requirements when done at high levels.

Maintainer status on major open source projects satisfies this criterion as well as the original contributions criterion because maintainers formally evaluate and accept or reject contributions from others. Being a maintainer proves sustained recognition by the project community and other core contributors. Maintainer status is not given lightly: it requires demonstrating technical excellence, good judgment, and community trust over time.

What does not qualify for this criterion:

• Routine code review within a team as part of normal employment,

• Hiring interviews (which evaluate candidates for a specific role rather than the quality of their work in the field)

• Mentorship of junior engineers. 

These are standard employment duties, not selection as an independent expert evaluator.

Criterion 5: Published Material About the Engineer

Coverage in professional or major trade publications, or other major media, that focuses on the engineer and their specific technical work. The coverage must be about the individual, not merely mention them as part of a team or a company story.

The January 2025 USCIS policy update explicitly recognized digital publications, podcasts, and major online outlets as qualifying alongside traditional print. For engineers, strong evidence includes: feature articles in recognized technology publications (Wired, IEEE Spectrum, Communications of the ACM, The Register, InfoQ) focusing on the engineer’s specific technical approach, podcast appearances where the engineer is specifically sought as a named expert on a technical topic, coverage in recognized developer media discussing the engineer’s open source projects or technical contributions, and profiles that attribute specific technical innovations to the engineer by name.

One of the most frequent weaknesses in O-1A petitions is reliance on self-promotional content. Personal blogs, company websites, and self-published articles carry little weight since they lack independent editorial control. 

Articles that appear advertorial, media placements obtained through sponsorships or paid PR services, and content published on platforms controlled by the beneficiary or their employer are common red flags that can trigger an RFE.

Technical blog posts published on personal sites or company engineering blogs do not typically satisfy this criterion even when widely read. 

The distinction is editorial independence: Coverage a journalist or editor chose to pursue because the engineer's work has field-level significance is fundamentally different from content the engineer or their employer published and promoted.

Criterion 6: Awards and Prizes for Excellence

Competitive recognition from bodies that evaluate engineering excellence through peer-reviewed or expert-evaluated processes. For engineers, relevant evidence includes: best paper awards at recognized technical conferences with peer-reviewed submission processes, competitive hackathon wins at established events with documented selectivity, recognition from respected professional organizations (ACM, IEEE) through competitive programs, and grants or fellowships from recognized sources in the engineer's technical domain.

The January 2025 update confirmed that awards need not be received at advanced career stages. Competitive wins from internship-era hackathons at major technology companies, early-career fellowship awards from recognized foundations, or competition wins from graduate research can support this criterion when the award was genuinely selective and peer-evaluated.

Employer-nominated awards and internal recognition do not satisfy this criterion. An award that originates with the engineer's own organization, rather than from an independent evaluating body, does not establish the external recognition the criterion requires.

Criterion 7: Scholarly Articles or Comparable Technical Publications

Authorship of scholarly articles in professional journals or recognized publications in the field. For engineers, this includes peer-reviewed conference papers at top venues (NeurIPS, ICML, CVPR, ICLR for machine learning; OSDI, SOSP, NSDI for systems; CCS, USENIX Security for security), journal publications in IEEE or ACM publications, and technical reports from recognized research institutions.

Technical writing that influences thousands of other engineers proves extraordinary ability through knowledge dissemination. If other engineers reference your articles, cite your techniques, or build upon your ideas, this proves you are advancing the field through knowledge sharing. However, the publication venue matters for this criterion: content published in genuinely recognized technical outlets with editorial standards is treated differently from personal blog posts regardless of readership numbers.

The comparable evidence provision in the O-1A regulations allows petitioners to submit evidence of comparable achievement when a specific criterion does not readily apply to the field. 

For engineers working in applied industry contexts where peer-reviewed publication is not standard practice, technical standards contributions (IETF RFCs, W3C specifications, IEEE working group documents), widely adopted technical specifications or API designs, and highly cited engineering design documents may qualify as comparable evidence. The comparable evidence argument requires explaining to USCIS why the criterion does not readily apply to the specific engineering sub-field and why the alternative evidence is comparably significant.

Engineering Leaders: Additional Considerations

Engineering leaders, meaning staff and principal engineers, engineering managers, directors, and VPs, can draw on the full criteria set above and additionally on the structural elements of their leadership roles.

Staff and principal engineers at major technology companies occupy roles that are specifically defined as field-level technical leadership rather than team management. The selection criteria for these roles, the percentage of engineers who reach them, and the technical authority they carry are relevant contexts for the critical role argument. Documenting what these levels mean at the specific company, how many engineers hold them as a percentage of the engineering organization, and what technical decisions the engineer has authority over strengthens the petition significantly.

Engineering managers and directors satisfy the critical role criterion most naturally when they can document business outcomes tied to their specific leadership: systems delivered under their direction, engineering team growth, key technical decisions made under their authority, and organizational outcomes attributable to their leadership. The distinction between managing a team that produced good outcomes and specifically driving those outcomes through identifiable decisions is the same challenge as for CXOs, just at the engineering management level.

Engineering leaders at distinguished organizations also have stronger access to the judging criterion through their involvement in hiring, promotion, and technical review processes within the field. Participation as a technical interviewer or hiring manager is not judging for immigration purposes because it is standard employment. Participation as a technical advisor to recruiting firms, as a speaker and evaluator at technical fellowship programs, or as a judge in external engineering competitions is judging in the immigration sense.

Open Source Evidence: A Dedicated Section

Open source contributions deserve specific treatment because they are uniquely powerful evidence for engineering O-1A cases. Unlike proprietary work, open source contributions are publicly verifiable without requiring USCIS to take the petitioner's characterization on trust.

The metrics USCIS evaluates for open source projects include: GitHub star count as a signal of peer recognition within the developer community, fork count as an indicator that others built upon the project, download or installation counts from package managers (npm, PyPI, Maven, crates.io) as a measure of active use, and adoption by named organizations as evidence that the work has been put into production use rather than merely explored.

GitHub stars O-1A visa thresholds vary by project type, but generally 5,000 or more stars for individual projects, or 10,000 or more combined across multiple projects, indicate significant achievement. These thresholds are not hard cutoffs but practical benchmarks. A project with 5,000 stars and documented production adoption by three Fortune 500 companies is a stronger case than one with 15,000 stars but no evidence of actual use in production systems.

The most powerful open source evidence is adoption testimony: letters from engineers at other organizations who specifically describe using the project in their production systems, what problem it solved for them, why they chose it over alternatives, and what it would take to replace it. Letters from engineering leads at recognized companies explaining their technical dependency on the project create the kind of independent external validation that USCIS weighs most heavily.

Maintainer status on a major existing project is evidence for both the original contributions and judging criteria simultaneously. Being accepted as a maintainer of a project like React, Kubernetes, TensorFlow, or Linux requires demonstrating to existing maintainers that the engineer has the technical judgment and community standing to evaluate and accept contributions. The acceptance process itself is documented and defensible as evidence of peer recognition.

For engineers whose open source work is primarily in lower-profile repositories, the focus should shift to contribution quality over project scale. A core contributor to a niche but technically significant project that is widely depended upon in a specific domain (database drivers, networking libraries, security tools) can build a strong original contributions argument around the depth and criticality of the contribution even without mass-market star counts.

Profile-Building: A 12-Month Roadmap for Engineers

Months 1 to 3: Audit What You Have and Identify Attribution Gaps

Begin with a systematic audit of your technical work over the past three to five years. For each significant project, system, or contribution, ask: what specifically did I design or build that others could not have? What measurably changed because of my specific decisions? What evidence exists that isolates my contribution from my team's contribution?

1. Collect all existing documentation: GitHub contribution history, design documents, patent filings, and any technical writing you have done that reached external audiences. Identify your highest-impact open source projects by star count, download metrics, and any documented external adoption you are aware of.

2. Then identify what is missing: where does your work lack independent external validation? Which of your most significant technical contributions exist only in internal systems with no publicly accessible documentation? Which peer or expert relationships could produce independent letters about specific work?
   
   
   

3. Engage immigration counsel at this stage to map your existing record against the eight criteria and identify which three or four to build toward based on your current profile.

Months 3 to 6: Build Open Source Presence and Conference Engagement

If you do not already have a meaningful open source presence, this is the period to establish one. The most effective approach is to build something that solves a specific documented problem in your domain and publish it with high-quality documentation, an active maintenance commitment, and deliberate community building through technical writing that explains the project.

Apply for speaking slots at recognized technical conferences. Conference CFPs (calls for proposals) are typically open six to nine months before the event. Major venues in your domain, whether that is machine learning, systems, security, distributed computing, or frontend engineering, have well-established proposal submission processes. A technical talk accepted to a recognized conference generates both published material evidence and judging activity when the engineer is later invited back as a reviewer.

Apply to serve on technical program committees. Once you have presented at a conference, reach out to the program chairs and express interest in reviewing submissions for future years. Program committee service is documented, generates formal invitation letters, and establishes a pattern of trusted expert evaluation across multiple years.

Months 6 to 9: Generate Independent Validation and Pursue Patents

This is the period to focus on converting existing work into documented external recognition. Identify engineers at other organizations who have used your open source projects or been influenced by your technical approaches, and reach out about their willingness to provide letters. These conversations are more productive when there is already a genuine professional relationship, which is why starting early matters.

For any novel technical approach you have developed in your current role that has not yet been patented, discuss patent filing with your employer's legal team. Patent applications can take months to prepare and file. An issued or pending patent filed during this period becomes available evidence for the final petition.

Write technical content for recognized external outlets. Contact editors at IEEE Spectrum, ACM Queue, InfoQ, or domain-specific recognized publications with a pitch for a specific technical topic you have deep expertise in. The pitch should be grounded in a specific technical insight from your work, not a general overview. Editors respond to specific expertise that their readers cannot get elsewhere.

Months 9 to 12: Document Compensation and Critical Role

Assemble complete compensation documentation: the most recent offer letter or compensation statement, vesting schedules for equity, RSU grant agreements, and any bonus documentation. Pull comparable data from Levels.fyi, the FLC Data Center, and a second source for the specific role level and metropolitan area. The comparison should be on total compensation, not base salary alone.

For engineering leaders: pull the organizational documentation that establishes the critical role argument. This includes the organizational chart showing your position and span of control, the charter or role definition for your specific title level, any board or executive communications referencing your specific technical decisions, and the metrics for systems under your technical ownership.

For individual contributors: work with management to obtain a letter specifically describing your individual technical contributions, the decisions that were specifically yours, and what the outcomes of those decisions were for the organization. This letter is more useful when it describes specific technical decisions rather than general performance excellence.

The Kazarian Two-Step for Engineering Cases

At Step 1, USCIS evaluates whether evidence exists that at least three of the eight criteria are satisfied. For a well-prepared engineering case built around original contributions, high salary, and critical role, Step 1 is typically cleared without difficulty.

At Step 2, USCIS evaluates the totality of evidence to determine whether it establishes that the engineer has sustained national or international acclaim and stands among the small percentage at the very top of their field. This is where engineering cases most commonly encounter difficulty.

Some petitions present normal senior-level responsibilities as if they were extraordinary achievements. USCIS is looking for distinction, not just competence or strong performance in a demanding role. Compensation evidence is also less persuasive without proper benchmarks, and open-source work is weaker when the petition cannot show meaningful adoption, influence, or industry reliance.

The Step 2 failure mode in engineering cases is almost always the same: the evidence shows a highly competent, well-compensated senior engineer at a good company rather than a field-level recognized practitioner. Addressing this at Step 2 requires evidence that is independent of the employer, specific about individual contribution, and comparative against what peers in the field typically achieve.

The expert letters are the most important Step 2 evidence. Letters from recognized independent figures in the field who can specifically describe how the engineer's work influenced their own technical thinking, what they built because of the engineer's contributions, or why they consider the engineer's technical approach to be field-level significant carry substantially more weight than letters from the engineer's own colleagues, managers, or direct collaborators.

Frequently Asked Questions

I work at a top tech company but most of my work is proprietary. Can I still qualify?

Yes. Developers who work primarily on closed-source proprietary systems face the challenge of demonstrating impact without publicly accessible code. Solutions include executive and peer letters describing system scale and the applicant's specific technical decisions, sanitized performance benchmarks, architecture diagrams illustrating the applicant's individual design contributions, and patents filed for novel technical approaches developed in the role. The challenge is real but not insurmountable. The petition must work harder to establish individual attribution through internal documents and external expert testimony.

Do GitHub stars alone satisfy a criterion?

No. GitHub stars alone do not satisfy an O-1A criterion, but they serve as supporting evidence of recognition when combined with documented production adoption by named organizations, download metrics, and letters from engineers at companies using the project. Stars indicate peer awareness; production adoption with named users establishes significance.

I have a high salary but my other evidence is thin. Can I build a case on compensation alone?

No. You need at least three criteria, and a single strong criterion with weak evidence elsewhere will likely fail at Step 2 even if it technically clears Step 1. Compensation is an important criterion but functions best as part of a case that also demonstrates individual technical distinction through original contributions, critical role, or judging activity.

Can I use technical blog posts for the published material criterion?

Generally not for the published material criterion as a standalone. Blog posts on personal sites, company engineering blogs, or platforms like Medium or Substack lack the independent editorial control that makes published material evidence credible to USCIS. 

However, technical posts with very high engagement that have been covered or cited by recognized external publications can contribute to the original contributions argument as evidence of field-level influence. The January 2025 update explicitly recognizes digital coverage in major online publications, so a third-party profile of the engineer in a recognized tech publication that cites their blog work is stronger than the blog work alone.

At what career stage should I consider the O-1A?

Most successful engineering O-1A petitions involve engineers with five or more years of progressively responsible experience who have reached staff, principal, or senior staff levels. 

Early-career engineers who have made specific high-impact contributions (highly starred open source projects, best paper awards at major conferences, patents with commercial adoption) can qualify earlier, but the sustained acclaim standard requires more than a single exceptional achievement. An honest assessment with immigration counsel is the most useful diagnostic.

This article is intended for general informational purposes only and does not constitute legal advice. O-1A requirements, USCIS policies, and processing times change frequently. For an assessment of your specific engineering profile and the evidence needed to build your case, consult a licensed immigration attorney (Talvisa can help) experienced in extraordinary ability petitions for technology professionals.