The Most Undiscovered Job in Tech Isn't a Tech Job

Somewhere in your industry there's a person who's been doing the work for twenty years. They know exactly where it breaks. They've watched the same fixable problem come back every quarter for a decade. They've tried bringing it up to IT and been told it's not on the roadmap. They've built workarounds in spreadsheets, in email folders, in the heads of whoever they trained. If you asked them what software their job actually needs, they could tell you in five minutes.

That person has never been hired to build software. Until now, nobody like them was. The job didn't exist.

I think it's about to be the most valuable hire a certain kind of company can make, and almost nobody is looking for it. I'm writing this for the person I just described. It might be you.

I'm building a company called Basa. We make infrastructure for how deals get done in the creator and entertainment world. Before this I managed a band for ten years and ran a podcast network for five. Thousands of deals from both sides of the table. I'd never written a line of code.

I started Basa in the middle of a period when I thought the professional world was about to become unrecognizable. Still do. The riskier choice for me wasn't building a company. It was getting another job at something that might not exist in five years. I built Basa because I'd lived the problem, and because the only thing that felt like it made sense was to be early and be curious about what was coming rather than waiting to find out.

For most of the last three decades, building software required three people. A product manager figures out what to build. An engineer writes the code. A designer makes it usable. Tech calls this "the triad." It existed because no single person could do all three jobs. If you wanted to build something real, you needed all three.

That system held for thirty years. Then Claude Code came out in December, and a lot of us who run early-stage companies quietly realized that our operating models — how we decide what to build, how we build it, how fast we move from idea to working software — were about to be rewritten. Not in a year. Not incrementally. Immediately. Every early-stage startup right now is a testing ground for a new kind of operations. We're all running different versions of the same experiment, and the companies that figure out the right model fastest are going to have an advantage the old way couldn't produce.

I'm writing this from inside that experiment, a year and a half in, with a specific bet on who you hire when the old roles aren't the right starting point anymore.

Silicon Valley's conversation about AI and hiring right now is almost entirely about how to evolve the three existing roles. Engineers become more product-minded. PMs learn to code. Designers ship end-to-end. The builders who dominate the next era will come from inside the triad, just reshaped. That's the consensus.

What's strange about this is that the valley prides itself on thinking from first principles, and on this particular question it's doing the opposite. It's retrofitting three existing roles instead of asking what roles would exist if you started today. The bias makes sense — the conversation is being shaped by people who built their careers inside the triad, and when you ask someone to predict the future of a system, they tend to describe the system they know, reshaped. But that's not first-principles thinking. The other thing that's true is that the technology is available to everyone. Not just the valley. The same tools that are reshaping how engineers work are reshaping how a twenty-year veteran in another industry can work. The democratization happened already. Most of the conversation hasn't caught up.

From first principles, the question is different. If you were hiring to reach an outcome, with the tools that exist right now, who actually gets you there fastest? I don't think it's any of the existing roles. I think it's the person who's lived the problem for twenty years and can now build the solution themselves.

When I started Basa, I hired engineers and designers and figured I'd be the one in the middle, translating what I knew into what they should build. Then I spent eighteen months translating.

I'd try to explain to an engineer why a certain kind of creator deal stalls. Not just that it stalls. Why. The way an agent reads a clause. The way a brand's legal team flags risk. The way a particular phrase in an offer lands differently at 9 a.m. than at 5 p.m. the day before a holiday. I'd explain what I meant by "fair." I'd explain what I meant by "clean."

The engineer would build something. What came back was always a little off. Not because the engineer was bad. What I was trying to describe wasn't describable in a spec. It was an instinct I'd developed over ten years of sitting across the table from managers and agents and lawyers.

Imagine trying to teach a stranger to cook your grandmother's recipe over the phone. You can tell them the ingredients and the temperatures. But the part where you know the onions are ready by the smell, the part where you adjust the salt because the tomatoes taste different this week — that part doesn't transmit. You have to stand at the stove.

So I was standing at the stove and calling instructions across the house to someone holding a hammer. It wasn't sustainable. A year ago, roughly half of our budget went to technical talent. By the end of this year it'll be closer to 10-20%. Not because engineering doesn't matter — our CTO owns the backbone and we've invested accordingly. Because most of the work we need to do isn't engineering work. It's translating twenty years of judgment into software, and I was in the way of my own company.

I started hiring SMEs who could build. SME stands for subject matter expert — the person who knows how the work actually gets done. In my world that's someone who's been an agent for fifteen years, or ran a management company, or spent a career in-house at a brand approving thousands of campaigns.

Here's what "who can build" actually means, because this is the part the phrase undersells.

A marketing SME on our team found V0 before the rest of us knew what to do with it. V0 lets you describe an interface in plain English and get back a working, clickable prototype in minutes. She started using it to build future-state versions of features we were planning months out. Not a sketch. A real thing you could click through. What used to take us three weeks — brief, design cycles, revisions, waiting for engineering capacity just to produce the first prototype — now takes overnight. The first time she showed me one, I realized we'd been paying a tax we didn't have to pay. V0 is now our primary prototyping tool. Figma is no longer the starting point. So far we haven't found a downside.

The more interesting shift is what's happening on the backend. SMEs on the team are now writing backend code in Claude Code, with engineering providing guardrails on anything that touches the core system, security, or integrations. I built a workflow myself in about three minutes — gave Claude a set of transcripts and asked it to produce a specific kind of analysis I needed. The thing it produced was 60-70% of the way there on the first pass. The old version of this would have meant a spec, a PM conversation, an engineering sprint, and revisions. Weeks. Instead I started on third base, cleaned it up, and shipped it (or asked my Cofounder/CTO if I could ship or risk deleting the codebase…still learning) .

If someone with zero software background can do that, the question isn't whether this generalizes to the rest of the team. The question is what stops it from generalizing. Engineering is moving toward building through natural language. The skill that matters most is being a good enough storyteller to describe what needs to exist. Domain experts have been doing that their whole careers. The tool is new. The skill is old.

Which brings me to the part of this that's harder to hire for than the skill.

The SMEs who can build don't act like employees. They act like solo entrepreneurs operating within a collective framework. They have insatiable curiosity. They're willing to reimagine systems rather than retrofit them. They run hypothesis-test-validate loops on their own work. They're comfortable with the kind of chaos that comes from building something new, and they have the systems-thinking instinct to turn that chaos into process rather than letting it collapse into noise.

Most SMEs I meet are brilliant at their domain and completely uninterested in rethinking how they work. That's a respectable choice. It's just not the hire. The slice I can hire is the small percentage of twenty-year operators who look at AI tools and think finally, I can build what I've been wanting for ten years. Those people are rare. Much rarer than I expected when I started looking. When I find one, they don't look like an engineer, a designer, or a PM. Their resume says manager or agent or producer or coordinator. Which is exactly why they're not showing up in anyone's hiring funnel. Every tech recruiter is fishing in a pond labeled engineer-designer-PM. The people I'm hiring are in a different pond entirely.

Nobody has figured this out. We haven't. The operating model is a work in progress. The jagged frontier of AI — accelerating different parts of the work at wildly different speeds — breaks the old sprint cadence and forces you to rebuild how a team coordinates. We're testing things, failing some, keeping what works. We're nimble enough to fail fast and change. That's the point.

The deep knowledge of the industries AI is about to reshape is sitting in people who are already in them. A benefits administrator who's spent twenty years wrestling with a broken system knows what that industry needs. A casting director who's coordinated thousands of deals knows what's wrong with the current way it's done. An operations manager in a mid-size manufacturing company knows what the software they're stuck with fails at. Those people don't need to move to San Francisco. They don't need to learn what a PM does. They can build what should have existed all along, from where they already are.

If you're a twenty-year veteran in an industry that isn't tech, and you've spent the last year or two playing with AI tools and realized you could finally build what you've wanted forever, I want to hear from you. That's the hire I'm trying to make.

And if you're a founder hiring engineers and designers for a problem that's really about domain expertise, try it the other way. Hire one SME from your industry who can build. See what happens when the translation layer isn't there anymore.

Mine collapsed. I don't miss it.

Nobody has figured this out. Which is exactly where we want to be. The opportunity is there for anyone early and curious enough to go take it.