Note: Logging my copy here, with a couple of small tweaks from the version posted on EA Forums.

🤖AI Transparency Statement: This article was fully written by me, then went through basic grammar and voice checks Claude Opus 5.5. Initially I had a second human author that also contributed and provided feedback, but they requested to drop off the project.

Epistemic Status: I’m confident in my ability to join and quickly ramp up in new domains based on my long work history demonstrating this. I have not yet started a full-time AI safety role to assess if it may be uniquely different.

Intro

I’m a mid-career generalist looking for a role where I can quickly make a large impact on AI safety. In this article, I’d like to share my experiences as a generalist that has spent years in industry moving through different roles, functions and products as a way to assuage at least one of the fears that appears to be common amongst hiring organizations.

Although I’m focusing on AI safety, I imagine this may be felt in other cause areas

The Problem

What I and other generalists trying to join AI safety have observed is a fair amount of gatekeeping. Some of this may be with good intentions, like making sure people are committed to AI safety and will remain invested when times are challenging. However, I think this is at odds with the calls for more generalists and mid-career professionals, challenges scaling organizations and the overall impact of AI safety. Specifically, I’ve observed firsthand and see evidence of signal mismatch being an artificial barrier to entry that can cause both sides to assume the other isn’t interested, and walk away.

Definition: Generalists in Industry

The generalist term has been borrowed by AI safety to roughly mean people that aren’t researchers and engineers, but will support their work and organizations.

In industry, it has a slightly different meaning, which may have one or more of these defining qualities from their career:

• Worked across multiple industries or sectors
• Worked across multiple functions or products
• Worked across multiple role types or role titles

We’re the jack-of-all-trades that don’t worry too much about role and function titles, and are more interested in finding tough problems to solve. We’re sometimes also called multi-passionates or multi-potentialites.

By contrast, a specialist in industry is someone that has typically stayed in a single lane of function or product for the majority of their career. For example, they might be a software engineer focused on secure payment solutions. Their leveling will grow, and responsibilities will shift over time towards management and operating more strategically. But fundamentally they’ve stayed in the same area such that each change is a familiar step from the last.

There’s arguments and use cases for each role type. Hiring a specialist generally means they can start adding value sooner with less context gathering than a generalist. But, specialists with an exact fit aren’t always easy to find. And more importantly, some hiring managers instead seek fresh perspectives, and this is where generalists shine. 

Generalists have loads of tacit knowledge, and quickly pattern match a new situation to one they’ve already encountered. They’ve seen this movie before, and learned both from their success and failures. They’re expert navigators, and although they might not ramp up quite as quickly as the specialist they have unique value and impact to offer immediately.

Perhaps more importantly, when a generalist dives into something new, we go all in. We thrive in learning and building out the latest context map. We internalize the challenges, feel the pains, genuinely want to solve it, and then celebrate the wins just as hard.

My Story as a Generalist

I wrote the below narrative not as a long-form resume, but to demonstrate how I’ve successfully moved through very different domains in my life.

I didn’t set out to be a generalist, but maybe I was always bound to be one.

When I was a kid I didn’t have a clear answer to what I wanted to be when I grew up besides being really into computers and tech. This became more of an issue as I graduated high school, got accepted into college, then had to declare a major. I chose Electrical Engineering, which left me with a lot of options, but then as I wrapped up 4 years later, I still didn’t know exactly what I wanted to be when I grew up. After graduating, I took my first full-time job with a power company designing substation protective systems. This used maybe 2% of my degree, but I was happy to jump into this new domain and learn about power transformers, relays, circuit breakers and SCADA. I also used my prior experience with layout and design tools like PageMaker and Photoshop to ramp up quickly on working with our drafting tools. Ultimately though, the power industry wasn’t for me. I wanted more freedom to flex my creative problem solving, not replicate designs that hadn’t fundamentally changed in decades.

I joined National Instruments (NI)’s Engineering Leadership Program as an Applications Engineer, a generalist’s dream to support any of 6 core product areas and a requirement to exit the program to work on them in one of 3 functional areas (product, engineering or sales). Here, it again became a problem that I couldn’t define what I wanted to do for the rest of my career a couple of months in (besides sales, which I knew wasn’t for me). Most of my peers were confidently all-in on their chosen areas. They got the attention and projects, and I got skepticism. As for me? Well, I could do this. Or that. It didn’t particularly matter because I knew I’d go jump in with enthusiasm. But, it was really hard to prove that.

I was finally given a shot on a neglected team working on audio/video test hardware and software R&D. I’m a bit of an audiophile, but otherwise had no background in the domain. What happened? I entered into the chaos of a high-touch support team with very little documentation. We spent 10 days overseas with the rest of the team gathering product support info and learning how to decode things like an NTSC composite video signal. I quickly ramped up my proficiency across the products, needed to escalate less often, and then started documenting everything for users to self-serve on. I even authored a published 10-page user guide technical document. Over 2 years I transformed the role that had become unsustainable for my predecessor to being able to add on other unrelated products to my remit.

That success was noticed by the web support team supporting customer self-serve of 100s of products across 1000s of webpages. I was given the opportunity, piloted and then pioneered a brand new role that had never existed which we dubbed Content Curator. Effectively a business analyst now, I not only owned and analyzed 1000s of webpages, but I was able to update many of the pages myself based on my past knowledge. I built out and documented processes for the role and then coded out an extensive toolchain to inventory, track and score all of our content. I also became certified in an industry methodology called Knowledge Centered Support that I leveraged when I worked with my old Applications Engineering peers.

That morphed into owning the manuals and specs documentation experience on the web where I continued to leverage everything learned so far to take on another new role that hadn’t existed before, trending for the first time towards a role title of Product Management.

A couple of years later, NI’s leadership was itching to put chat on the website. The problem? None of the roughly 7,000 other employees had any experience in this. No problem. I sold my plan, learned the tech, became a conversational designer, generated training for live agents, and was put in charge of an engineering team. We achieved a lot of success quickly, and did it with a skeleton crew.

Now 12 years into my career, I finally found at least one thing I wanted to commit to: Product Management. I had inadvertently already been recreating the framework of the role. But, I did have one problem when I went to interview outside of NI: I wasn’t speaking the same language as industry. I took a course to learn the standard industry terminologies, and more importantly their standard methodologies and frameworks.

I joined Expedia Group as their Senior Product Manager for their internal online A/B experimentation platform, having run 1 online A/B experiment prior. Part of the reason I was externally hired was for my generalist background and to bring a fresh perspective to a team of specialists that had largely remained unchanged for a decade. I had to learn data engineering concepts and a complex pipeline that worked on the scale of petabytes, how to run scientifically valid A/B experiments, and why our users struggled to use our product to do that. I drafted our new strategy from scratch in 2 months, at 6 months felt comfortable on many tasks solo, and at 12 months was fully up to speed to operate autonomously. I also drew on my old roles to help our team do things like build a better knowledgebase and documentation set. Over 3 years later, I left an A/B experimentation domain expert, having driven major successes like doubling test volume year-over-year twice.

The funny thing about product management is that I don’t consider it a career, or even a role. It’s a title that describes a core set of skills and abilities. A product doesn’t have to be hardware or software, it can be research, or it can be an organization. What matters is that I’m good at opening up ambiguous problems, and driving them towards solutions that we can measure the outcome of.

My 18-year career is broken up into 2-4 year chunks, each with a different domain, “product” and role function. Each one I was able to ramp up quickly in, begin contributing and driving outcomes within the first couple of months. There’s no reason for me to think that won’t translate to AI safety where I’ll join with curiosity and enthusiasm to learn another new domain. I want to know what your challenges are, and who else to talk to to learn more. I’ll convert that into a plan that we’ll align on, set measures to, then start executing again.

Counter-Questions

If industry generalists have a track record of changing roles every 2-4 years, what’s to say they won’t rotate out of AI safety in that timeframe?

• Most generalists still stay within a theme for longer stretches of time. Plus where in industry they might have been driven by chasing profits and status, they’re often arriving at AI safety because they’re bought into the larger cause and their desire to drive high-impact outcomes and because at least some of them are ready to operate in a system where making more money isn’t the sole objective.
• There’s lots of unique work and problems to solve in AI safety. There’s years of buildout ahead, and it’s going to constantly evolve. Generalists love new problems to work on. They will likely move around within the ecosystem.

If a generalist is a jack-of-all-trades, doesn’t that also make them a master of none? AI safety requires deep domain knowledge of the area being worked on to be successful in the role.

Yes, and no. I enthusiastically jump in feet first, vacuum up all the information and context I can get my hands on. But I’m also cognizant that I will never be and shouldn’t become an expert. I cover a broad set of knowledge, but only at the depth I need to drive successful outcomes. I’m comfortable with my limits and know when to hand off to experts with deep knowledge. If you zoom out of AI safety a bit, the size and shape of its problems look a lot like other things I’ve already encountered, and I thrive in that pattern matching to speed up time to solution.

Further, if we only think within the confines of AI safety, we might be missing out on a lot of important external ideas, arguments and methodologies. I’m always interested in reading outside of the stated curriculum to understand both sides to put together the full picture. I’ve also observed existing teams and orgs that are so close to the problems that they’re trying to solve that they miss a solution sitting right in front of them.

Won’t adding a generalist that’s not already all-in dilute or deviate our goals? Will they become revenue/growth focused? How can we know that a generalist is fully bought in?

My goal isn’t to remake your vision, it’s to help you solve what you’ve identified as your biggest problems. I will push on measuring success based on outcomes, rather than just outputs which can be uncomfortable at first. I may suggest new measures, or new ways of doing things. Most importantly though is that this process comprises negotiation and discussion. I expect a strong counterpart with deep domain knowledge that can challenge me, and ultimately work together to find the strongest solutions.

Conclusion

In AI safety and beyond to other high-impact organizations, I hope this helps lower the bar slightly for considering hiring experienced generalists like myself by assuaging fears that they won’t be able to ramp up and impact your organization quickly. While your challenge is unique, I’ve spent my career breaking down new problems, and am confident I can repeat the pattern again.

Ways to lower the bar and adjust expectations:

• Hiring orgs: Become more comfortable with new hires ramping up and gaining full context once joining an org. Applicants should be able to describe the high-level landscape, but may not have every detail yet.
• Fieldbuilders: Offer courses targeted towards generalists, rather than just researchers and engineers. For example, in university it’s common to offer a Physics 101 course for non-STEM majors, and another for STEM because the non-STEM group doesn’t need the full rigor to apply the learnings to their future work.