I am in conversation with two AI (agentic stuff) startups, both small, one very early stage. They are each independently sensing they need a specific type of role, sorta engineer, sorta not, and I’ve been cracking my head open trying to find the words and ideas to convey what I think that role should be and do for them, more precisely than what they have already figured.
Then the linkedIn post below (and by extension the referrenced freshly minted article by The Pragmatic Engineer) pops up for me this morning, and came in handy, timely, and with pure gold! The article opens with:
One interesting trend in the AI startup segment this year is the rise to prominence of a specialized software engineering role called “Forward Deployed Engineer” (FDE.)
This FDE role is very close to what I have in mind, only with the exceptions that it’s a position in companies with a great need for supporting existing customers with their established AI solutions/products, and also most of them work with 1 customer at a time. On the other hand, the startups I’m talking to, with products at different stages, are needing novel ways to reach potential customers across various industries, in addition to needing a sharper vision for where to take their roadmaps, as it’s to be expected.
Post:
Below I’ll mention the tremendous opportunity in front of these startups, and after that I will use parts of that article to reinforce why I think the role that will help them to capitalize on this opportunity needs to be in the Engineering org, and what flavor of engineer would have an org-wide impact, which I believe is the greatest value of this role, given the times.
This might be interesting to consider whether you are an AI company or an individual looking to break into an AI company.
The opportunity
Enterprises that have been working with machine learning (ML) for years know what they need but, more importantly, have expertise to evaluate what products will continue serving them. It is mostly business as usual at this layer.
Everyone else… seems everyone else is pretty much yolo’ing their way thru, at best (or worse? I can’t decide), and at worst they are on the sidelines, waiting. The understanding to support their decision-making isn’t there, and the education needed is lagging. The little education that there is might be delivered by experts in ways that are incomprehensible to newcomers.
Unfortunately, with things moving so fast, actions (and inactions) have the potential of being very costly.
Obviously the opportunity here is to serve this market really well. But the tremendous opportunity is to dare to reimagine the ways how we can do that.
New rules, new roles
So, with the intention of being imaginative, I believe the spirit of this role should be this: Chief (ai) Decision Officer (hereinafter reffered to as: CDO).
But this should be a hands-on role, NOT a “C” level position. Although (extracting from the article):
FDEs responsibilities look similar to those of a startup CTO: you’ll work in small teams and own end-to-end execution of high-stakes projects.
—Palantir
This is not a (pre/post/normal) sales position either. But in a way it is, because it is selling the most under-rated item in the AI market today: Decisions! Good, solid, comfortable, delicious decisions that keep driving things forward with confidence. The agentic systems/MCP expertise gap is real, and is a critical blocker when it comes to decision-making.
Nor should it be Dev Advocate. Why? Advocates are and will continue to be great partners to engineering, but:
(FDEs) Drive their core product engineering roadmap and make important prioritization and scoping decisions that determine when we build custom solutions vs. accelerate larger existing projects.
… FDEs embed within core product engineering teams to develop expertise in the most relevant technical areas.
—Ramp
And:
Drive tangible outcomes through hands-on implementation
Proactively remove technical blockers
Lead rapid prototyping and iteration
Drive Agentforce innovation
Become a trusted strategic partner
Implement and enforce best practices
—Salesforce
Same with Product Managers, same with Solution Architects. A seasoned software engineer is, imo, the most well-equipped to smoothly navigate this side of the business and tackle demands like these ones.
There are a ton more gems behind the paywall, including reports from different FDEs about how they split their time, none of which I’ll quote here due to IP. But I think I can mention a couple general ideas that came to mind for me from reading rest of that article and that I believe are critically important to pay attention to:
- Clarity and precision are the new competitive advantages
- Bet on people and ideas that have the potential to turn The Flywheel of greatness, because with things moving this fast, the alternative for companies is not being late to the party, it is getting deeper into the doom loop
I’m sure you are at the edge of your seat wanting to know what else the CDO should be and do, and why!
NOTE
I will refrain from suggesting a title for this role. I personally think something that conveys traditional engineering leadership works, but maybe you come up with something unique. Maybe you use FDE. I will use CDO going forward for that reason. And also because I invented it (maybe) and think it’s cute.
The engineer
The flavor of engineers who will majorly deliver as a CDO brings something distinct: they’re seasoned enough to drive technical discussions, yet grounded enough to remember what it feels like to not understand something. They must, in some significant way, have the stamina to stay consistently ahead of the developers they’re helping make decisions about AI adoption. And they are not ever so far that they’ve forgotten the journey, but far enough to illuminate the path forward with hard-won clarity.
This role must be under Engineering because of the depth of continuous technical understanding it demands. Critically, it must be trusted, both internally and externally, to discover and drive organization-wide engineering outcomes that most directly influence adoption among the underserved developers they aim to empower. Skin in the game.
This role needs to inspire max confidence and trust that it will be "selling" only the most appropriate engineering DECISIONS.
The strategic imperative
The CDO operates at the intersection of what’s technically possible, what’s strategically valuable, and what developers actually need, especially when they don’t yet know what that is. The CDO is, simultaneously:
- Internally focused: Trusted to drive alignment between engineering capacity and priorities, and business ambition, ensuring the roadmap reflects both what can be built and what should be built to ensure adoption is perceived as an obvious and seamless choice
- Externally credible: Serving as a technical voice developers trust as a tech leader, and someone who learns their challenges deeply enough to co-imagine and co-create solutions that serve them
- Organizationally backed: Having the mandate to coordinate across teams, influence strategic decisions and outcomes that span beyond any single engineering team
This last point is crucial. The CDO needs to be explicitly chartered and supported to work across boundaries, to pull together teams for things like rapid prototyping, and to have a direct line to leadership when critical decisions need to be made.
It’s important that this role has the imagination to invent what’s possible, the necessary access and resources to validate ideas, and the engineering credibility to make it real. Keep that flywheel of greatness flying!
Boundaries and balance
The risk, of course, is that without clear boundaries, this becomes the “everything AI adoption” role, a one-person chaos management system. That’s not sustainable, and more importantly, it’s not strategic. The CDO’s charter needs to have some heuristics to decide where to draw boundaries, however this needs to look for a given company/team. Some ideas:
- Yes to defining the technical vision that makes AI adoption obvious for developers across industries
- Yes to leading cross-functional engineering initiatives that accelerate product-market fit
- Yes to establishing architectural patterns and technical standards that internal teams follow
- No to being the sole technical decision-maker for every adoption-related feature
- No to gatekeeping innovation or becoming the approval bottleneck for any team initiatives
- No to becoming the single point of failure for strategic technical decisions
An organization might need to incrementally build capability around this role.
Looking forward
I am inviting all of us to consider thinking outside of old boxes: there has been a fundamental shift in how software is built. We are needing new solutions, new ways of thinking, and maybe even new ways of working.
The FDE role is such a great idea, and I hope it is here to stay. To contrast, this CDO role might not be needed once we all sync up around the meaning of this whole new AI thing and what it can do.
To be clear, the ideas here cover the “what” and the “why” of this role. The “how” is what would go in a job description and will depend on how many of these ideas you choose to adopt.
Good work doesn’t have to be hard work. But it does have to be thoughtful work, and have the right level of support. I hope this article inspired you a bit. Maybe you can incorporate one or two ideas into new roles. Maybe this can be a North Star a current role can evolve into. Maybe we can learn from you about a role you created with the same purpose but works entirely different?