MENU

Everything

is Engineering

What if your job isn't “doing the work”, but building the system that does?

Every function and role in a startup is becoming engineering

Since the days of Fairchild Semiconductor¹, the role of engineering has been to design and build systems where computers reliably do the work for you. 

That’s been a software engineer’s quiet advantage and the driver behind why software companies scale the way they do. 

If you wanted to tap into this advantage, you typically needed a CS degree (or a similar path to getting in your “10,000 hours” of practice). 

AI coding agents have collapsed that requirement. The engineer's advantage is now in anyone’s hands – and when that happens, the nature of what you spend your time on changes. It looks a lot more like system design than it used to.

1

Fairchild Semiconductor (1957) — founded by the "traitorous eight" who left Shockley. The company that effectively seeded Silicon Valley.

Since the days of Fairchild Semiconductor¹, the role of engineering has been to design and build systems where computers reliably do the work for you. 

That’s been a software engineer’s quiet advantage and the driver behind why software companies scale the way they do. 

If you wanted to tap into this advantage, you typically needed a CS degree (or a similar path to getting in your “10,000 hours” of practice). 

AI coding agents have collapsed that requirement. The engineer's advantage is now in anyone’s hands – and when that happens, the nature of what you spend your time on changes. It looks a lot more like system design than it used to.

1

Fairchild Semiconductor (1957) — founded by the "traitorous eight" who left Shockley. The company that effectively seeded Silicon Valley.

Permissionless leverage is the future

If you've ever managed a team, you were already building systems. Hiring, incentives, goals, accountability – that's a human operating system designed to produce output. Leaders have always been systems builders in that sense.

The difference is what the system is made of now and what kind of leverage you get.

If you've ever managed a team, you were already building systems. Hiring, incentives, goals, accountability – that's a human operating system designed to produce output. Leaders have always been systems builders in that sense.

The difference is what the system is made of now and what kind of leverage you get.

Naval Ravikant² drew the line between permissioned and permissionless leverage. Managing people is permissioned – every unit of output requires coordinating another human with their own incentives, energy levels, and career ambitions.

2

Naval on the four forms of leverage: capital, labor, code, and media.

Naval Ravikant² drew the line between permissioned and permissionless leverage. Managing people is permissioned – every unit of output requires coordinating another human with their own incentives, energy levels, and career ambitions.

2

Naval on the four forms of leverage: capital, labor, code, and media.

“Probably the most interesting thing to keep in mind about the new forms of leverage is they are permissionless. They don’t require somebody else’s permission for you to use them or succeed.”

— Naval Ravikant, 2026

Leverage from software is permissionless. Once you can architect the system, you scale it without asking anyone. How you structure your data, chain tools together, handle edge cases – those are architectural decisions, not people management ones. The leverage is uncapped and the constraints are completely different.

Until recently, you needed to be an engineer to access software leverage. LLMs and AI coding agents closed that gap. You don’t need to be an engineer to do engineering work now.

Leverage from software is permissionless. Once you can architect the system, you scale it without asking anyone. How you structure your data, chain tools together, handle edge cases – those are architectural decisions, not people management ones. The leverage is uncapped and the constraints are completely different.

Until recently, you needed to be an engineer to access software leverage. LLMs and AI coding agents closed that gap. You don’t need to be an engineer to do engineering work now.

PERMISSIONED

Managing people. Every Unit of output requires coordinating another human with their own incentives, energy, and ambitions.

PERMISSIONLESS

Leverage from software. Once you can architect the system, you scale it without asking anyone. Uncapped.

None of this makes people skills irrelevant. It changes what sits alongside them. The systems you're building now are made of code, data, and models – not just org charts and processes. That requires a different kind of fluency.

None of this makes people skills irrelevant. It changes what sits alongside them. The systems you're building now are made of code, data, and models – not just org charts and processes. That requires a different kind of fluency.

GTM Engineers are on the rise

You might think of Forward Deployed Engineers as the earliest example of this trend, but that was really ‘implementation’ rebranded. What's different now is that the core functions themselves are changing into engineering.

You might think of Forward Deployed Engineers as the earliest example of this trend, but that was really ‘implementation’ rebranded. What's different now is that the core functions themselves are changing into engineering.

The GTM Engineer³ is the real canary in the coal mine. Go-to-market has always been a strong software first mover (e.g. Salesforce as the first major SaaS) and had people stitching systems together using pre-built integrations and/or developers. What’s changed is that GTM is adopting engineering directly and able to architect pipelines dramatically better and quicker than they could have before. You can see this in the jobs posting:

3

GTM Engineer — a role emerging at the intersection of growth, RevOps, and software engineering.

The GTM Engineer³ is the real canary in the coal mine. Go-to-market has always been a strong software first mover (e.g. Salesforce as the first major SaaS) and had people stitching systems together using pre-built integrations and/or developers. What’s changed is that GTM is adopting engineering directly and able to architect pipelines dramatically better and quicker than they could have before. You can see this in the jobs posting:

3

GTM Engineer — a role emerging at the intersection of growth, RevOps, and software engineering.

Yes, some of this is title inflation. But titles can signify genuine new capabilities emerging.

And when you pair this with how the actual work feels day-to-day, I’ve found it harder to dismiss. From my own experience:

Yes, some of this is title inflation. But titles can signify genuine new capabilities emerging.

And when you pair this with how the actual work feels day-to-day, I’ve found it harder to dismiss. From my own experience:

None of these stop requiring domain expertise, but the value is increasingly combining it with engineering. If everything is engineering, then there are implications on both how you build the team and individual skills that you should learn.

None of these stop requiring domain expertise, but the value is increasingly combining it with engineering. If everything is engineering, then there are implications on both how you build the team and individual skills that you should learn.

The "fork-shaped" generalist

If one person with the right technical fluency can build what used to take a team of five, the maths on hiring changes. Teams get smaller, but more importantly they change shape - more “player-coach” style Managers who also do the work, more ICs that are “agent orchestrators”. I (with some bias I admit) have found generalists who can own building an entire system end-to-end are doing pretty well with this new structure.

The type of generalist talent I keep coming back to is what Brie Wolfson calls "fork-shaped" – not T-shaped (broad with one spike), but deep in multiple areas. Nothing gets past them.

If one person with the right technical fluency can build what used to take a team of five, the maths on hiring changes. Teams get smaller, but more importantly they change shape - more “player-coach” style Managers who also do the work, more ICs that are “agent orchestrators”. I (with some bias I admit) have found generalists who can own building an entire system end-to-end are doing pretty well with this new structure.

The type of generalist talent I keep coming back to is what Brie Wolfson calls "fork-shaped" – not T-shaped (broad with one spike), but deep in multiple areas. Nothing gets past them.

Domain

From

To

GTM

Generic outbound, blast campaigns, simple routing

Inbound scoring and routing, transcript-powered data entry, dynamic campaigns, churn predictors

Finance

Excel models & slides (FP&A)

Wired data layer (Xero, Stripe) → live dashboards + AI agents

Talent

Shared spreadsheets & slightly overcomplicated CRMs

Custom lightweight CRMs, auto-ingested comms, AI scoring

Operations

Recruiters scrolling LinkedIn, network & pattern-matching

Bulk data ingestion, custom taxonomies, AI-surfaced matches

Function transformation under technical multiplier. Pattern observed across four functions; structural rather than coincidental. Source: author's field observations, Q1 2026.

Nothing gets past them (1984)

Hiring for this is going to look different too. I look for evidence of tinkering (what’s their favorite tool? What have they built? Where did they get stuck and what did they learn?) and how they make decisions around the systems they’ve built (which model would you apply and why?). I don’t know if the playbook for this exists yet, but it’s worth solving.

Hiring for this is going to look different too. I look for evidence of tinkering (what’s their favorite tool? What have they built? Where did they get stuck and what did they learn?) and how they make decisions around the systems they’ve built (which model would you apply and why?). I don’t know if the playbook for this exists yet, but it’s worth solving.

In this resonates, what do you actually do?

You don't need to apply all of this at once. Pick the domain closest to your current work and choose one workflow to rebuild. The path below is sequenced — peel it back one layer at a time.

01 - Pick up the same tools engineers use

Cursor, Claude Code, Codex for building. Supabase for data. GitHub for version control. Railway for hosting. You don't need to master them — you do need to be in them and have a preferred stack to spin software up quickly.

02 - Tinker constantly — and use it for real work

When something new drops, spin it up. The next time you have actual work, try to build a system that can do it for you. It's slower at first — that's the J-curve — but it's worth it for what you learn. Every time you open these tools you're paired with an engineer.

03 - Learn the systems design concepts

Even if you're the pirate, you should understand architecture. Data engineering is the biggest bottleneck — how to structure, store, and move data so your agents can use it. Some UX literacy helps too (AI polishes a UI, but can't design a novel flow).

04 - Keep yourself plugged in

Find your crew — the edge moves too quickly for curriculums, so favor groups who swap notes and riff. Then nail the information feed. X/Twitter is where the frontier shares first; podcasts and Substacks show you the longer arc.

Long Lines is a publication by Carrara © 2026

Long Lines is a publication by Carrara © 2026