A framework for where GTM roles are headed. Position accordingly.

A friend texted me this recently:
"The funny thing about AI is it doesn't really make anyone good. It actually widens the gap between people who were already good and everyone else."
He meant technical employees specifically (we worked for a long time in B2B enterprise tech together). I haven't stopped thinking about it.
It explains everything happening in enterprise GTM right now. The roles are shifting and the ratios inverting. The people pulling ahead and the ones wondering why.
I've spent the last decade building global pre and post-sale teams. Over a hundred interviews across Addepar and Kizen. When I evaluate GTM talent, I use a simple two-axis framework.
Technical skills: Can you open a laptop and make something work? Can you read an API doc, understand a data model, prototype an integration? You don't need to be an engineer. You need to be dangerous enough with technology that clients trust you to solve problems, not just describe them.
Commercial skills: Can you run discovery that uncovers the real problem? Can you effectively communicate technical concepts to various audiences? Can you navigate a room with competing agendas, connect what you're building to business outcomes, and move a decision forward? Not about being a closer. About being fluent enough in the language of business that clients trust you to guide them.
Plot those two axes and you get a clear map of where roles sit today. For a seasoned operator, the top-right is where you want to be. High technical fluency, high commercial acumen. I call it the unicorn zone because these people are tough to find.
One thing to be clear about: this is a relative comparison, not an absolute ranking. The chart isn't measuring who is the most technical or the most commercial. It's measuring which combination of both creates the most leverage in this new AI era.
The best candidates I've interviewed don't just land in the top-right. They move there over time. Given the right environment, the right challenge, the right leadership, they can track linearly up and to the right over time. That's what I'm actually hiring for. Not where someone sits today, but rather, their potential to continually increase their skillset in both vectors.
AI just made that movement more important than ever.
Before we talk about where roles are going, it helps to know what they're converging toward and how.
The Forward Deployed Engineer. High technical depth, enough commercial instinct to work directly with clients, and the ability to own the full cycle end-to-end. A title that is hot in the market and a profile that already exists and already works. Recent example: OpenAI just announced their launch of their own deployment company, which will harness an FDE approach to deploy their agents across the enterprise. This is great strategy from a team that has arguably been losing the enterprise business to Anthropic. If you want to drive meaningful adoption of AI in enterprise workflows (outside of chat) you need a robust interpretation layer. Enter the FDE motion.
https://x.com/OpenAI/status/2053824997777457651
Given the nature of new AI products, especially ones deployed to the enterprise, every client-facing technical role in enterprise GTM is becoming an FDE. Not eventually... now. The question is which roles get there fastest and which ones get left behind.
There are two categories of AI tools driving the shift described in this article. The first is reasoning and building tools like Claude, Cursor, Copilot and others like them. These move you up the technical curve faster than any career path used to allow. Helps with: Architecture decisions, integration logic, code steps, prompt engineering, building, etc. You don't need to know everything, but just need to know enough to direct the tools and interpret the output.
The second is orchestration platforms: tools that let you design, chain, and deploy LLMs across real business workflows, and build entire products without a dedicated engineering team behind you. This is where the leverage really compounds. The ability to take an LLM beyond a single prompt and wire it into a multi-step, production-ready workflow for a client is extremely powerful and critical for actual ROI in the enterprise.
In practice these two categories work together. I'll use my own work as an example. Using Kizen I built our Encompass Underwriting Agent from scratch. Kizen handled the orchestration, the LLM deployment (Gemini or OpenAI) depending on the action), observability, and the workflow logic + business context. Claude helped with architecture and coding. Without these tools, I couldn't have shipped it. This is a real production-ready solution with significant ROI (reduces manual document workflows in underwriting by 90%).

This is where my friend's observation bites. The roles that benefit most aren't necessarily the most technical or the most commercial, but the ones where the combination of both gives AI something meaningful to multiply:
Skill estimates are generalizations based on typical role profiles. Individual variation is significant. This is a framework for thinking, not a performance review.
Solutions Engineering has the most to gain (I am biased). I want to be specific here because this role gets conflated with Sales Engineering constantly.
Solutions Engineers are typically found at platform companies where the product is flexible by design. The client comes with a problem and the SE's job is to build or meaningfully configure a solution and commercialize it. The work is open-ended, often custom, and spans pre and post-sale. The technical variance is high because no two engagements look the same.
A solutions engineer gaining leverage with AI can now punch well above their weight class. They can sell and deploy more technical products than their headcount should allow. Compress a four-person engagement into one. Own conversations end-to-end that used to require an entire team. The bottleneck was always the build time and AI tooling helps accelerate it.
Sales Engineering is different and the distinction matters. Sales Engineers sell a defined set of products. Their job is to demonstrate fit, handle technical requirements, and configure within a known scope. I've done both and the depth of problem solving required is fundamentally different.
AI still helps meaningfully here with faster demos, sharper RFP responses, better technical prep. However, the ceiling is lower because the work is more repeatable. AI compresses what they already do well rather than unlocking entirely new capability. Perhaps AI tools help Sales Eng move up that technical curve. However, those who are already prototyping and building are probably ready for a solutions gig anyway.
Implementation gets a massive technical lift. AI accelerates what they can build, configure, and automate. The commercial gain is smaller, but technically the ceiling rises fast for anyone willing to embrace it.
Client Engagement and Success Managers (CESM) gets a modest boost. Relationship-focused by design and that doesn't change. AI helps with account intelligence, prep, and surface-level technical fluency. Enough to be more useful. Not enough to close the gap with the roles above.
Sales (AE) is more nuanced than it might appear:
The traditional AE motion (relationships, deal navigation, ROI/Biz case, closing, etc.) isn't going away. In complex enterprise cycles, that commercial orchestration is still the engine.
AI makes AEs sharper on research, personalization, and prep. The baseline work gets faster. That's real but it's table stakes.
The more important shift: the products AEs are being asked to sell are getting more technical. AI-native platforms, agentic workflows, API-first tools. Buyers are sometimes more technical and these evaluations are more sophisticated. An AE who can't credibly speak to how something works (just enough to hold their own at least) will start losing deals to AEs who can.
The AEs who thrive in the next cycle will close the technical gap enough to maintain credibility in technical conversations, even if they're never the ones driving them.
This isn't about AEs becoming engineers. It's about the minimum viable technical bar rising. The products are changing and the pitch has to change with them.
R&D (not shown): I'll stay in my lane on the engineering and product side. But the same convergence is happening there. Marc Andreessen calls the destination "builder". One person who can write code, design, and ship product. The standoff between programmers, PMs, and designers is collapsing the same way GTM roles are.
Here's the hard truth. You are more likely to be displaced by someone who figured out how to use new tools than by an agent or automation directly.
AI gives more leverage to people who were already good, making them harder to catch. It found the solutions engineer who was already technically curious and gave them leverage across what used to require four specialists. It found the implementation lead who was already a fast learner and compressed their delivery cycles in half.
The gap between those people and everyone else is widening.
The variable AI amplifies is technical curiosity. The willingness to tinker, build things, and direct tools with actual client context behind the prompts. That context and their ability to orchestrate it are the moat. Anyone can generate an architecture diagram. Only someone who sat through six discovery calls knows which architecture actually solves the problem.
Technical curiosity is also a choice. That's the part nobody wants to say but it's true. You don't have to be an engineer. You have to be willing to close the gap.
Plot yourself on the quadrant honestly. If you're technically strong but commercially thin, use AI to simulate discovery conversations and practice value articulation. If you're commercially strong but technically thin, pick one AI tool and go deep on it this quarter.
The roles that win the next cycle aren't the deepest specialists or the smoothest talkers. They're the ones who can move fluidly between both and who started moving before the dust settled.
The gap is widening. The question is which side of it you're on.
Where do you sit on the quadrant? What's one thing you're doing to move? Let's discuss.
0
1
1