🤖AI Transparency Statement: This will be flagged as partially or mostly AI written. The role profile section was initially drafted by me, went through editing loops with Claude Opus where I ended up replacing a good bit of its generated text. I used Claude Opus to create the initial sample job description section using my inputs, notes and about 20 industry job descriptions I pulled. I edited the descriptions lightly then expanded with my own success section - I feel like this is a good use of AI writing since job descriptions are usually very mechanical. Job description analysis was completely authored by me. Once I had the complete paper, I did a couple rounds of adversarial reviews and grammatical polish with Claude.
This experienced builder role profile expands on the mid-career and generalist operator profiles already shared in 2026. It describes a family of senior roles spanning product, program, engineering, data and operations leadership that owns what gets built, for whom, in what order, and they are accountable to outcomes. They have 10+ years of experience in industry where they have built functions, products or organizations from zero, and carry the tacit knowledge that only comes from navigating difficult paths to success and experiencing setbacks along the way.
While these role profiles are standardized in industry and at the frontier AI labs, independent AI safety orgs have yet to adopt them.
Inferred from their job postings, Anthropic and OpenAI‘s operating models reflect the rest of tech where they staff matrixed positions that serve as the connective tissue to the research teams to promote working on the highest impact items, while also performing the strategy and planning work of how to integrate the research into their infrastructure, products and outputs like model cards.
The gap is a mapping problem: AI safety organizations are aware of the symptoms they’re facing, but aren’t creating org structures, roles and job descriptions to address them that would be familiar to someone entering from outside of AI safety. The job never gets posted, candidates don’t see the opportunity, and both sides walk away concluding the other one was not there.
For orgs to scale their impact, they not only need more headcount, including operators, but experienced builders that can help build matrixed orgs, prioritization and accountability frameworks, and infrastructure and tooling to allow them to work efficiently, diffuse that work, and have it adopted across AI safety.
Given a vague problem, no process and no precedent, an experienced builder runs discovery, generates a plan, aligns it, sees it through to implementation and adoption, and measures if it worked. Ownership covers what gets built, for whom, in what order, and then are accountable to outcomes (not just the outputs), which separates them from someone executing fixed requirements. They support building the machine that produces the output, but don’t write the code or perform the research themselves. With enough technical fluency to earn credibility with researchers, they hold their own on strategy, and coordinate across multiple disciplines and functions to create an aligned plan. Ruthless prioritization is the norm, where they use standard prioritization and organizational frameworks to direct efforts including stopping work already underway, which is rarer and harder than knowing what to start.
An experienced builder’s background shows a track record demonstrating building from zero, designing processes, creating tooling and measurements, and managing teams. On their resume you’ll find them driving high-stakes initiatives in large complex organizations, making tough decisions, and defending them. When you talk to them you’ll learn how they navigated fragmented tooling, lack of shared standards, work repeated across silos, and no meta-analysis being performed. This allows them to pattern match on those past experiences to deftly navigate challenging scenarios and avoid common pitfalls.
The profile spans responsibility levels without changing shape, from owning one core function, to several, to overseeing the people who own multiple functions.
The generalist operations roles that AI safety has already started building out are very valuable, but they are a different job. An operator works inside a system that already exists, driving goals someone else has set and producing previously agreed upon outputs. They are the oil that keeps the organizational machine running smoothly, and support executing how the machine is built.
In contrast, the experienced builder defines what machine needs to be built, and why. They define the strategy, and oversee tough prioritization decisions, and are ultimately held accountable to the outcomes, not just that the output was created. The work starts a step earlier than a generalist operational brief usually does, at the point where the requirements do not exist yet, and the scoping is the work.
An organization that hires this experienced builder role profile shifts tooling design, procedural loads and adoption efforts to those with background and expertise in driving them, leaving researchers to spend more of their week performing research. Output rises in volume and in consistency because the standards live in tooling that’s been democratized and adopted, resulting in faster and more defensible decisions and research. With each person working within their core competencies, burnout is reduced. The organization then gains the ability to absorb additional money and headcount without breaking, which matters in a field where capital is arriving faster than the capacity to coordinate it.
Background on this section: I thought it would be helpful to write a sample job description containing the keywords that would be familiar to me. I’ve chosen an evals ‘product’ that represents something I’ve thought about, but a builder could post under many other role titles with differing responsibilities, and different applications.
What’s different about this role: Today, AI safety orgs thinking about this type of work may see it purely as tech-led infrastructure or tooling engineering and administration, missing the tight loops of gathering user requirements and validating against them, or driving adoption of tooling and process.
Several of our teams run evaluations of frontier models, with others researching advanced evaluation methods. Most of them start from the same open-source tools, and over time each team has adapted those tools in its own way.
That works for any single project. Across the organization it creates friction. Results from two teams are hard to compare, and past work is hard to find or query, so meta-analysis across evaluations rarely happens. When one team develops a promising technique, or a new method shows up in the field, getting a second team or organizational adoption is high effort.
This role owns that problem. You’ll work with the researchers who design evaluations, the engineers who build and run them, and the downstream users that consume the results to figure out what would help most. The answer might be shared infrastructure, common standards, or better use of the tools teams already have, and it will likely change as the field does. Researchers set the research direction. You own making the work around it faster, more consistent and easier to build on, and making sure what gets built is actually used.
Disclaimers: This is a very small sample from the 80,000 Hours job board. You can find deeper analysis on postings in posts like this. The purpose of this section is not to diminish the importance of these roles, or to imply that hiring orgs have done anything incorrectly. I’d also acknowledge that in small orgs roles tend to be very fluid, so it’s very reasonable that a builder may still support covering off some of these tasks.
TL;DR – This sample included operationalists that keep orgs running smoothly, and technical counterparts that implement the systems, but lack the builder to coordinate and prioritize the most impactful work.
I analyzed 4 recent job descriptions: 2x operations, 1x chief of staff and 1x tech lead which I found to be representative of the public postings I frequently review.
I observed that the operational roles don’t directly own what gets built to solve the broader organizational goals, prioritization of those efforts and defining the measures of success. They focus on supporting the organization to be its best, and take administrative tasks off leaders and other team members. They include tasks like creating new employee onboarding, defining policies, ensuring adoption of tools or processes and applying a project management style of planning and reporting. A builder works alongside this role to understand where the existing infrastructure and tooling wasn’t meeting the organization’s needs, continuously backlogging and re-prioritizing a product feature list.
The tech lead manager owns implementation details, organizing their team, and ensuring the health of their infrastructure and tooling. While unreliable tech would be a drag on the organization, it doesn’t define what to build next to meet the org’s next biggest needs. To build a unified roadmap, the builder brings user and org needs, the tech lead owns the technical side, and they work together to resolve tradeoffs.
While working with both of these roles, the builder is also constantly talking to users, other stakeholders, leaders and analyzing trends in industry to build a complete view of all the challenges, trends and potential solution options.
In this matrixed approach, each role gets to leverage their strengths, rather than being asked to cover a broader scope. They work together very closely with the builder as the connective tissue. The outcome is arriving at the right solutions, faster, with more incremental progress along the way by taking time to more deeply understand the full picture before creating the next thing.
If you want to see the more detailed analysis I did on this section, you can view it on the linkpost. I couldn't get EA Forums editor to collapse this section and wanted to limit the default length.
As Sam Smith put it in an earlier post, “scrappiness is a means, not an end”. AI safety has done well to scale to this point, but also is now cognizant of the growing pains of scaling.
I think:
I believe that maturing role types and org structures is a critical component to scaling the impact of AI safety’s work. I hope this can become a starting point for discussion with fieldbuilding and AI safety organizations. The goal is that this role becomes recognized, shows up in job descriptions, and hired for allowing experienced builders to fully leverage their abilities and for AI safety organizations to scale their headcounts and impact.
Asks: Tell me whether you recognize the need inside your own program or organization, what makes you hesitant or what you see as incorrect in this assessment. Even better, let’s schedule time to discuss the opportunity, needs and how this could be built out.
I’d like to thank Sam Smith for reviewing this work with me, and supporting fieldbuilding for mid-senior folks like myself, including through other posts like Good Senior People Exist and We’re Wasting Them.
Thanks for putting this out Paul, excited for hiring managers to think more about folks with product management backgrounds and how they can have the most impact!