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 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 remove it.

This is not a governance position disguised as engineering. It is not a transformation-program role centered on status reporting, process compliance, or telling teams how to work. You will remain personally involved in architecture, prototyping, implementation, testing, documentation, and delivery.

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 significant architectural decisions legible: what problem we are solving, which constraints are real, what trade-offs we are accepting, and how we will know whether the decision worked.
• Building relationships across Engineering, Product, Design, Security, Legal, Procurement, Finance, Infrastructure, and executive leadership before an urgent delivery problem requires those relationships.
• Creating communities in which engineers can learn from one another, develop shared practices, and influence the platforms built for them.

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.

A healthy working pattern for this role will usually be:

• Approximately 60–70% hands-on technical work, including design, implementation, prototyping, testing, technical investigation, and review.
• Approximately 20–25% architecture and cross-functional problem-solving.
• Approximately 10–15% mentoring, documentation, community building, and organizational learning.

Those percentages are guidelines, not utilization targets. We care about outcomes and sustainable leverage, not performative activity.

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 rather than spending the entire period producing a strategy deck.
• 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.
• Leave teams more capable and autonomous—not more dependent on the Principal Engineer.

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 explaining technical decisions in language that engineers, product leaders, executives, and risk-owning partners can understand.
• A leadership style centered on enabling capable people rather than controlling them.

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.
• 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.

We will not hire a Principal Engineer and then deny them access to code, developers, decision-makers, or the systems they are expected to improve.

Work model

This is a remote-first role within the United States. Your effectiveness will be judged by your contribution, not by your proximity to an office.

Travel will be occasional and purposeful—for activities such as collaborative discovery, architecture workshops, team formation, or customer learning—not routine commute theater.

We support focused work, flexible scheduling, thoughtful written communication, and collaboration across time zones. We do not expect constant meeting availability or treat visible online activity as evidence of impact.

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.

We do not use an individual-contributor title to discount work that would otherwise be compensated as senior technical leadership.

Our interview process

Our interview process is designed to understand how you investigate, build, reason, and collaborate—not how quickly you can perform unfamiliar puzzles while being watched.

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.

There will be no unpaid take-home project that resembles production work. If we request substantial preparation or original work, we will compensate you for it.

Why this role matters

Software delivery does not improve simply because talented people are told to move faster. It improves when those people have clear boundaries, dependable foundations, useful automation, fast feedback, stable relationships, and the autonomy to make good decisions.

We are looking for a Principal Engineer who can see that whole system—and who still wants to build.