I Am a Forward-Deployed CEO

I am the CEO of a rapidly growing, Index-backed startup of about 50 people. Last month, I shipped more than 50 features and bug fixes to our core product, which benefits every customer. About 35 of them originated from working closely with a single firm. This was a slow month by this year’s standards, and over the past year, I’ve spent quite a bit of time at customers' offices, including Gunderson Dettmer and Ropes & Gray.

In the law firm world, there are rainmaker partners who don’t open Microsoft Word. Then there are partners who scrutinize redlines sent out at 11 pm. Both can be excellent and celebrated by their firm.

In contrast, the tech startup world is not comfortable with in-the-weeds leadership. The expected path for a technical founder is to build the first product, hire a team, and delegate product building to others while executives focus on fundraising and hiring. Doing otherwise is seen by top investors to be a failure to scale. 

Yet at some recent point, this expectation has changed. Maybe it’s Sam Altman’s talk of the first single-person unicorn or Paul Graham’s essay on Founder Mode, maybe it’s the fact that the leverage of AI agents is disproportionately empowering to those with high agency, but the tides have shifted. And I’m all for it. I never found the transition a happy one, and how I feel hasn’t changed. 

Forward Deployment

Palantir coined the term "forward-deployed engineer" (FDE), and I (along with much of Draftwise’s leadership and engineering teams) worked as forward-deployed engineers at Palantir.

In simple terms, forward deployment means sending someone who can actually change the software to sit with the people whose problem it is. Despite what many vendors will tell you, FDE is not solutions engineering, implementation, or “legal engineering” that configures a product on your behalf (note: legal engineering is analogous to solutions engineering and is itself a valuable role). By definition, someone forward deployed must have the aptitude and agency to change the product itself.

FDE is more of a mindset and a skillset than a job description. While at Palantir and now at Draftwise, many of my teammates don’t have the words “forward deployed” in their titles (although some do), yet these “software engineers” and “product managers” act in the spirit of FDE. 

FDE doesn’t work without culture

Customers of Draftwise often tell us that one of the best things about working with us is that when we make promises, we deliver. Sometimes, I make those commitments. Just as often, someone else does. 

At most software companies, “it’s on the roadmap” or “we’ll look into it” is a guess. The person making the promise often doesn’t have the authority to make it happen, and everyone in the room knows it. That’s why buyers have learned to discount it.

The real question is what must be true about the company to keep all its promises. I can think of 3 things:

• A culture that keeps its commitments. Vendors often placate customers with “we’ll look into it,” even when the person saying it has no ability to bring resources to bear on the problem. One of our written cultural values is different: we take our commitments seriously, not just to the letter, but to the spirit of the promise.
• People need agency to develop the product. At most vendors, solving a customer problem means convincing a technical resource that it matters enough to prioritize, with seniority and political capital often determining what gets done. In a forward-deployed organization, the person closest to the problem has the agency to solve it directly.
• The truth is on the front line. In a typical software organization, customer understanding degrades as it moves from the account manager to the product manager to the engineer to the executive. It’s a game of professional telephone, and one reason completed roadmaps still lead to poor adoption. The alternative is radical.

At Draftwise, I’m grateful to work alongside talented engineers, PMs, and FDEs who embody what makes forward deployment valuable to customers. Yet, as I mentioned earlier, I still write code. And when I do, the changes can be substantive. I built the first version of Playbook Studio over a quiet weekend for internal use. Soon after, we deployed it to Gunderson Dettmer, achieving human-level accuracy on commercial redlines.

Being CEO doesn’t mean I make all the product decisions. It gives me proximity to customer problems that others may not see, and my responsibility is to take accountability for those problems. When that gives me proprietary understanding, I will forward deploy and change the product directly.

But proximity cuts both ways. What reaches me is a skewed sample precisely because I am CEO. That’s why we operate on a radical cultural tenet: the best idea, supported by the most compelling data, wins. Engineers and product managers routinely overrule my product ideas, and the company is designed so they can. From CEO to engineer, everyone’s responsibility is to do what is right, not what the most senior or loudest voice says.

You have to cultivate culture

None of Draftwise’s culture is accidental. We knew what great teams could look like, and we were deliberate about building on the best of what we’d experienced.

• Low ego, so the best idea wins, regardless of title. Everyone is focused on doing what’s right for the customer, not playing politics.
• High trust means that when we make commitments to the customer or the market, we deliver on them in both substance and spirit. 
• Our single driving KPI isn’t valuation or market share. It’s the impact we have on our customers’ businesses and our accountability for solving their problems. When our customers win, we win alongside them.

It’s an unorthodox and delicate balance. My hypothesis is that without a culture like this, the FDE model simply doesn’t work.

Why I still code as CEO

For the first time, what I have always believed a chief executive should be able to do aligns exactly with how software is now built. Here’s what my average workday looks like:

• 6 am - review the output of my overnight agents, then dispatch more coding agents.
• 7 am - client meeting
• 7:30 am - review output of earlier agents, then dispatch more agents
• 8-10 am - meetings
• 10 am - review output of earlier agents, then dispatch more agents
• 10:30 am - meetings
• 11 am - review output of earlier agents, then dispatch more agents
• The cycle of agent delegation & meetings continues throughout the day.

The shape of the day is perfectly aligned with how agents work. Software used to demand continuous attention, which is why running a company and building one were incompatible, at least for high-growth companies trying to scale. However, in the past 2 years, the rules have changed. Software requires judgment in short bursts. And as an executive who spends a lot of time in customer meetings, my calendar is full of little pockets where I can slot in short bursts of judgment. 

AI is not a team member. It has no judgment of its own, no accountability, and no stake in the outcome. It is an instrument, like a spreadsheet or whiteboard, only better.

And it is not mine. Everyone here uses it. Our engineers and product managers get more out of it than I do because they were already closer to the work.

The same instrument serves very different purposes, and choosing between them is the discipline. Sometimes I build a canvas for a conversation, something to think against or show someone what I mean. Sometimes it becomes a real feature, shipped to every customer. Increasingly, the most valuable use is changing how a team operates. Not a product change, but a change to how the company runs.

This isn’t an excuse to build whatever I feel like. I am not vibe coding my business. Ownership and maintenance are real constraints, and my bandwidth isn’t that of a developer.

At Draftwise, we’ve learned empirically where the new boundaries of effective team operations are. Our culture allows us to keep iterating on how we work to get there.

Do what is right for your customers

The advice that founders should stop building and move to managing and recruiting mostly comes from investors, and it is good advice. It is right more often than it is wrong, and for sound reasons. Somewhere along the way, though, it hardened into a rule. It was never a rule.

Not every CEO can or should be forward deployed. Writing code is a skill you should use only if you have it. I spent years building distributed systems, holding patents in big data and machine learning, and trained as an FDE at the company that created the role.

You also have to want to build. Plenty of excellent founders don’t, and that’s a difference in skill set and approach, not a shortcoming.

It also requires a specific company culture. Without it, a chief executive in the codebase is a liability rather than an instrument.

So when the next investor asks when I’m going to leave the coding to the engineers, here’s my answer: engineers have these tools. So do product managers. So does everyone on the team. I will use every tool available to do right by our customers and take responsibility for their problems. Right now, one of those tools is writing code.

______________________________

‍See forward deployment in action

We’re bringing this same approach to Legal Ontology by Draftwise, working closely with firms to structure their proprietary knowledge around the way their lawyers actually work and make decisions.

Learn more here.‍