Principal Engineer, Developer Experience & Platform Systems

The opportunity

Our product teams are talented, but the systems around their work have not kept pace with the organization. Developers lose time waiting for environments, navigating inconsistent standards, rebuilding common capabilities, negotiating unclear ownership, and compensating for dependencies they cannot control. Important architectural decisions are sometimes made too late, repeated across teams, or separated from the people who must implement them.

We are hiring a Principal Engineer to help these teams build on one another’s strengths and change those conditions.

You will study how software actually moves from an idea to dependable production use, identify the constraints creating the most friction, and build the platforms, tools, technical foundations, and working relationships that help teams make progress together. You will also look for opportunities to connect expertise and invite people into work that expands what they can contribute.

You will remain personally involved in architecture, prototyping, implementation, testing, documentation, and delivery, working alongside the people who will use and help shape these shared capabilities.

Your job is to make good engineering easier to do.

What you will own

You will own the technical direction for developer experience and shared software-delivery foundations across the organization.

• Discovering where developers wait, repeat work, lose context, compensate for unstable dependencies, or make decisions the surrounding system should handle more effectively.
• Designing and building shared platforms, developer tools, libraries, automation, reference implementations, and paved paths that improve autonomy without hiding important constraints.
• Creating reliable local-development and testing capabilities so teams can make progress without depending on fragile shared environments, production access, or perfectly synchronized backend delivery.
• Establishing clear architectural boundaries and reusable patterns across APIs, front-end systems, component platforms, testing, continuous delivery, and developer workflows.
• Turning ambiguous organizational problems into working technical prototypes, then evolving successful prototypes into trusted organizational capabilities.
• Improving feedback systems through static analysis, automated tests, contract validation, continuous integration, documentation, observability, and thoughtful human review.
• Helping teams use coding agents and other AI-assisted tools responsibly, with explicit context, deterministic evaluation, bounded tasks, acceptance criteria, and engineering controls appropriate to probabilistic output.
• Making complex technical problems understandable, bringing relevant expertise into the conversation, and helping people turn that understanding into shared decisions and action. Make the problem, constraints, trade-offs, and signs of success clear.
• Building trust across Engineering, Product, Design, Security, Legal, Procurement, Finance, Infrastructure, and executive leadership by listening to what each partner is responsible for protecting, making room for different perspectives, and following through on shared work.
• Creating communities and opportunities for people across teams and disciplines to bring their expertise into real work, learn from one another, and contribute beyond the boundaries of their current roles. Connect that participation to the shared practices and platforms they help shape.

How you will work

You will begin with curiosity rather than a predetermined platform strategy.

You will spend time with engineers in their actual workflows. You will examine code, delivery pipelines, architecture, dependencies, team boundaries, policies, and recurring points of confusion. You will distinguish essential constraints from inherited assumptions and avoid automating a process before understanding why it exists.

Some problems will require code. Others will require architecture, a clearer boundary, a better interface, a changed responsibility, or a trusted conversation between disciplines. You will be expected to recognize the difference.

You will operate as a technically authoritative individual contributor. You may lead initiatives and temporary teams, mentor engineers, facilitate architectural decisions, and help leaders set direction, but you will not need a large reporting organization to have influence.

Most of your work will involve direct technical contribution: design, implementation, prototyping, testing, investigation, and review. Collaboration, explanation, mentoring, documentation, and shared learning will be part of how you do that work. You will invite others into design and delivery so that knowledge and capability grow through participation.

The balance will shift with the problem and the people involved. We value useful outcomes, sustainable working practices, and shared ownership of what you build together.

What success looks like

During your first three months, you will:

• Build trust with engineers and the disciplines that shape their delivery environment.
• Develop an evidence-based view of the most consequential friction in our software-development system.
• Identify which constraints require a shared technical solution and which require clearer ownership, policy, or communication.
• Deliver at least one useful improvement with the engineers who will use it, and learn from their experience.
• Propose a small, prioritized platform roadmap grounded in observed developer needs.

During your first year, you will:

• Ship and sustain shared capabilities that product teams voluntarily adopt because those capabilities make their work materially easier.
• Reduce one or more significant forms of waiting, repeated implementation, dependency instability, delivery risk, or slow feedback.
• Improve teams’ ability to develop and test independently of shared environments and unavailable services.
• Establish understandable technical patterns that increase consistency without turning architecture into a permission system.
• Help teams adopt agent-assisted development where it creates real leverage while preserving accountability, review, and reliability.
• Create a durable feedback loop between platform builders and the developers using what they build.
• Make technical and organizational trade-offs more visible to engineering and business leadership.
• Help people find relevant expertise, contribute across team boundaries, and carry shared work forward with growing capability and autonomy.

What you bring

We are looking for someone with substantial experience designing and building software systems, combined with the judgment to understand how technology, organizational boundaries, and human behavior interact.

You likely have:

• Principal-, Staff-, or architect-level experience building shared software platforms, developer tools, API-driven systems, front-end foundations, or internal engineering capabilities.
• Current hands-on software-development experience. You can move from an architectural conversation into a codebase and contribute directly.
• Strong system-design instincts and the ability to simplify ambiguous problems without pretending their constraints are simple.
• Experience building reusable technical foundations that serve multiple teams or products.
• Experience with modern JavaScript or TypeScript systems, Node.js, web platforms, APIs, automated testing, continuous integration, and continuous delivery—or comparable depth in another modern software ecosystem.
• A history of improving reliability and delivery through test-driven development, static analysis, automated quality gates, contract testing, or deterministic simulation.
• The ability to investigate a developer workflow, identify its actual bottleneck, and design an intervention appropriate to the problem.
• Experience influencing across teams and disciplines without relying on reporting authority.
• The judgment to balance consistency with team autonomy and to distinguish a useful paved path from an inflexible mandate.
• A habit of making complex technical problems understandable to engineers, product leaders, executives, and risk-owning partners, and helping them move from discussion to shared action.
• A leadership style that creates agency: inviting people into meaningful work, supporting their growth, and helping them succeed independently.

Particularly relevant experience

You may be especially effective in this role if you have built or led work involving:

• Developer-experience platforms or internal developer tools.
• Local-first development and test environments.
• Stateful API simulation, service virtualization, contract-first development, or dependency isolation.
• Shared UI platforms, component libraries, design systems, or front-end architecture.
• Monorepos, build systems, code-quality automation, or CI/CD foundations.
• Legacy modernization and incremental architectural migration.
• Architecture decision records and collaborative decision-making.
• Developer documentation treated as part of the product.
• Engineering communities, technical education, mob programming, or other ways of distributing knowledge.
• Responsible use of coding agents or AI-assisted development within explicit engineering controls.
• High-stakes cross-functional work involving Security, Legal, Procurement, Finance, Infrastructure, regulated environments, or executive leadership.

We do not expect one candidate to have done all of these things.

What this role is not

• A people-management position with engineering work confined to occasional code reviews.
• A project-management or agile-coaching role.
• A platform-operations position dominated by cloud administration, infrastructure support, or an on-call queue.
• An architecture-review-board role that primarily approves or rejects other teams’ decisions.
• A mandate to introduce a large platform before understanding our developers’ needs.
• An internal consulting position that ends with recommendations someone else must implement.
• A productivity-enforcement role focused on extracting more output from individual engineers.
• An AI-platform role requiring model training, MLOps ownership, or speculative replacement of engineers.
• A narrowly front-end role, although deep experience with browser platforms and shared UI architecture is valuable.

The environment you will join

You will have:

• Direct access to senior engineering and product leadership.
• Senior engineering sponsorship and a clear organizational mandate to improve the systems around software delivery.
• The authority to work across team and departmental boundaries.
• Time to investigate root causes instead of being measured only by short-term ticket throughput.
• A meaningful implementation budget and access to engineers who can contribute to larger initiatives.
• The ability to prototype before committing the organization to a major platform investment.
• Executive support for challenging inherited assumptions when evidence suggests a simpler or more effective approach.
• Freedom to remain an individual contributor while exercising organization-wide technical leadership.

You will have access to the code, developers, decision-makers, and systems needed to contribute directly and bring others into the work.

Work model

This is a remote-first role within the United States. Your effectiveness will be judged by your contribution and the outcomes you help teams achieve.

Travel will be occasional and tied to a clear purpose, such as collaborative discovery, architecture workshops, team formation, or customer learning.

We support focused work, flexible scheduling, thoughtful written communication, and collaboration across time zones. Meeting expectations will leave room for focused engineering work and a sustainable schedule.

Compensation

We publish the complete compensation range before the first interview. The package will reflect the organization-wide technical scope of a Principal Engineer and will include competitive base compensation, meaningful incentives or equity, comprehensive health coverage, retirement benefits, and generous paid time off.

Compensation will recognize the scope and responsibility of senior technical leadership in an individual-contributor role.

Our interview process

Our interview process is designed to understand how you investigate, build, reason, and collaborate through real work and thoughtful technical discussion.

1. A conversation about what you want to build and the conditions in which you do your best work.
2. A discussion with engineers about a real developer-workflow problem in our organization.
3. A technical conversation using a system you have actually designed, implemented, repaired, or evolved.
4. A collaborative architecture exercise centered on discovery, constraints, trade-offs, and incremental delivery.
5. Conversations with the engineering leader for this role and at least one cross-functional partner.
6. A final discussion covering the mandate, organizational support, compensation, and any concerns you want resolved before making a decision.

The process will respect your time. Any substantial preparation, original work, or take-home project resembling production work will be compensated.

Why this role matters

Capable engineering teams do better work together when they have clear boundaries, dependable foundations, useful automation, fast feedback, and the autonomy to make good decisions. Relationships and opportunities to participate help people draw on one another’s expertise and expand what they can accomplish.

We are looking for a Principal Engineer who brings curiosity, technical judgment, and care for people to that work—and who wants to build alongside them.