The engineeringification of everything
Why every role seems like an engineering role now (and what it means for you)
Engineering has escaped the codebase. The tools, mindset, and identity increasingly shape every function.
Spend enough time in startup circles and you’ll hear this engineeringification of everything:
“Oh, I’m a design engineer”
“We’re following best practice of GTM engineering”
“I need to talk to their sales engineer about implementation”
This raises two questions:
Why is every role becoming an engineering one?
Should I be worried?
This post answers both of these.
The engineeringification loop
The spread of engineering tools, skills, and identity into non-engineering roles, AKA “engineeringification,” is driven by a feedback loop that looks like this:
Take the role of design engineer as a specific example:
Design tools get more powerful. They’re not just for wireframing. Tools like Figma, Tailwind, and design systems baked into frameworks mean decisions shape production code. A button goes from being “just a rectangle” to a set of responsive, accessible variants that fit with your existing system.
Using them is complicated. Fully leveraging a design tool like Figma or a framework like Tailwind requires understanding product features, configurations, syntax, hotkeys, best practices, limitations, and constraints. At some point, you might even need to read the code.
Non-technical people learn anyway. Because engineering time is scarce and iteration speed matters, designers learn enough to ship. LLMs make this easier: they can generate Tailwind components, UIs, or even prototypes rather than hand-coding them.
Skills accumulate and identity shifts. At some point, the designers stop handing off work and do it themselves. They ship product code, debug layouts, and make tradeoffs between design and performance. Calling this just “design” makes less sense.
A new identity emerges and startups latch onto it. The label appears: design engineer. Power users adopt it, companies like Vercel start hiring for it, and tools begin marketing to it. The loop restarts, now with a clearer identity to build around.
Tools change skills, skills reshape identity, and identity demands new tools.
Why is engineeringification happening now?
People have been building powerful tools for many roles for a long time now. What makes this time different?
1. LLMs make it possible
LLMs make complex, domain-specific tools more accessible. Seemingly every tool has an AI assistant, an MCP server, or an AI-powered alternative.
Non-technical people can learn how to use the powerful tools once exclusive to engineers faster and easier. With them, they can:
Generate apps and prototypes with tools like Lovable, v0, and Claude Code.
Automate and optimize go-to-market with tools like Clay, Pocus, Vitally, and Lemlist.
2. Capital makes it inevitable
Engineeringification is a good business (we know because we’re in it). It’s where B2B SaaS is heading as companies are willing to pay for it, VCs are willing to invest in it, and playbooks for success exist.
You can see this reflected in the growth and valuation of AI-powered B2B SaaS startups serving non-engineers like Sierra, Lovable, Fin.ai, Bolt.new, Decagon, Clay, and Replit.
The capital flooding into the space improves the tools, provides users more capabilities, encourages new startups entrants, and increases marketing toward the engineeringification of identities.
3. Identity makes it permanent
The final driver of engineeringification is identity. Once people start seeing themselves as engineers, the loop becomes self-sustaining.
You don’t have to look far to see this shift in action. YC job posts show how non-technical roles are increasingly engineering focused:
Engineeringification gives individuals new autonomy while saving engineers time. Success encourages non-technical people to expand their skills and use the tools more. As they spend more time on engineering-like work, they begin to identify less with their old role as it undersells the value of their work and how technical they are.
Instead, people identify more with what they’re building and the people who build (AKA engineers). This new identity eventually crystallizes often via blog post, conference talk, meetup or even tweet. Think Andrej Karpathy on vibe coding, Anthropic hiring a prompt engineer, and Vercel promoting design engineering.
New identities compound the loop: people adopt it, tools are built for them, and marketing reinforces it. This feeds the cycle all over again.
The meaning of engineer is changing
What it means to call yourself an “engineer” is a sensitive topic. It’s literally illegal to call yourself one without accreditation where I’m from.
Engineering once meant a specific set of skills in a bounded domain reinforced with formal training and gatekeeping. This remains true in physical domains as failure has physical consequences, but software’s low cost of failure makes gatekeeping harder to sustain. Boundaries are eroding.
The defining line of engineering is moving away from “who is allowed to build” toward “who has the ideas and dedication to actually build it.” It’s less about knowing all the theory and more putting it into practice.
To some, this looks like a loss. Engineering feels deprofessionalized: more self-taught practitioners, less depth, titles lose meaning.
For many more, it’s a gain: more autonomy, faster iteration, increased leverage and a better ability to ship solutions to real, valuable problems.
Should you be worried?
The line between technical and non-technical work isn’t disappearing, it’s being redrawn. Whether you’re an engineer or not, the winners will be those who think like builders:
For non-technical people, don’t be afraid to take on more “engineering” tasks. Tools have become more powerful and specialized and people like you are succeeding in using them. The combination of LLMs and MCP have made it easier to both learn and interact with more tools.
For engineers, congrats! The world is investing a ton in making YOU more powerful. Use these same tools to turn yourself into a full stack shipping machine AKA a product engineer. For example, you can use Exa for competitive research, BuildBetter for user interviews, Figma Make to design a UI, and PostHog AI to analyze your product usage.
For startups, build for these new types of engineers. At a minimum, let people do engineering: have an API, make your docs machine readable (I love a “Copy as Markdown” button), publish an MCP server, and connect with other tools.
Those who embrace the engineeringification of everything will find themselves riding the wave it is creating. The billions trillions invested here has to benefit someone. Why not you?
Words by Ian Vanagas who, after all this, is still a bit skeptical of the “content engineer” role.
🦔 Jobs at PostHog
We’re hiring for many kinds of engineers (and almost engineers) like:
📚 More good reads
WTF is a forward deployed engineer? (and why everyone is hiring them) – Jina Yoon
Spinning the Wheel – Dylan Martin
How I do user interviews – Paul D’Ambra
The startup interview questions that actually matter – James Hawkins
The Rise of the GTM engineer – Matteo Tittarelli and Maxence Vanderswalmen
📺 PostHog on YouTube
Are you asking the right questions in interviews? James Hawkins argues not.
I'm seeing that the faster engineers ship, the more of a product manager they have to be. Seeing that happen in real life it's quite exhilarating. I feel more like the hog on the right, I'm seeing the landscape and sensing good times ahead for motivated engineers.
As a physicist and long-time aerospace engineer, I find your thesis on 'engineeringification' fascinating. While the boundary of 'who is an engineer' is shifting, the core remains the same: the rigorous application of logic to solve real-world problems. Whether it's a design engineer in Figma or a systems engineer at a launchpad, the 'builder mindset' is the common thread that drives progress.