Before Adi David joined Fern, he was a forward deployed engineer (FDE) at a software analytics company that used Fern for their documentation and SDKs. There, he relied on role-based access control (RBAC) to document the customer-specific features he built. One of the first features he shipped at Fern made RBAC easier to use.
My previous company embedded FDEs alongside customers to build custom solutions for their specific data needs. That was my role. I worked directly with customers, built off the product roadmap to cover whatever they needed, then documented what I built and shared it with them using RBAC on our docs. We used Fern for both the docs and our SDKs.
I never spent much time learning how to use Fern. I'd make real contributions to our documentation without really thinking about the mechanics of it, which is about the best thing I can say about a piece of developer tooling.
Why I joined Fern
I was initially drawn to Fern because I liked using the product as a customer and interacting with the Fern team in our shared Slack channel. What really sold me on working at Fern, though, was my in-office interview. People kept walking up to each other's desks to ask questions, and everyone was quick to help. It was a very collaborative environment.
The other draw was the shape of the role. I'd loved building things for real people, but I didn't want to stop being an engineer. Fern's sales engineering role is unusual in that you build demos for a customer, but then keep supporting them for as long as they're a customer. In practice that means I'm building features, fixing bugs, and staying in the relationship, rather than handing things off after a sale. Since the whole platform is built for engineers, the SE role gets to be an engineering-heavy role too.
And I also love Fern's continued startup energy. When I hit a customer pain point or something that would make my own work better, I can take ownership of it, build it, and ship it.
Building from the other side
Back in that job, when I built documentation scoped to a specific role, I wanted to see what that role would actually experience before shipping it. I didn't have a clean way to do that. I'd set up RBAC for something like a security persona, merge the PR, and hope it looked right, or reconstruct the view some other way. It was a small thing, but I hit it constantly.
Once I was at Fern, I ran into the same problem from the other side. Plenty of prospective customers need RBAC to gate their docs. One enterprise cybersecurity deal we were working on needed the docs to show each of their own prospective customers a different set of pages based on their use case. When I build a demo I set it up to match, with each role seeing only what applies to it. To make sure the demo is as polished as it can be, I wanted to see exactly what each role experienced before merging. But preview links rendered all content on the site, with no roles applied, so there was no way to check a role-specific view short of merging the PR and looking at the live site.
So I proposed the feature to the Fern team and then built it myself. Now all customers can preview what their docs site looks like under a specific role or configuration without merging the PR first. I wanted it as a user, and I wanted it even more as a sales engineer.
That's one of the things I love about working at Fern: If you want something to exist, you can build it. You're expected to know your priorities, but within that you have a lot of room to improve the product in the direction you think it should go.
I recently made a fix specifically for my old team. They run an authenticated docs site behind JSON Web Token (JWT) and their customers complained because Claude assumed it can ingest the docs site. This is because Fern offers an MCP server by default for all of our customers. So I added a config option to turn the MCP server off for authenticated sites, reducing support tickets.
What my work looks like day-to-day
A few things have surprised me most after joining Fern:
- Sweating the details. On demos, that means matching a prospect's fonts and colors, scraping their site cleanly, pulling elements from their Figma, even improving their agent readiness score before we show them anything.
- Autonomy. I build whatever a customer needs. The default answer to a request is "yes": either I get it done with existing Fern config plus CSS, or it's a good enough idea that I build it for everyone.
If turning the docs problems you've lived with into shipped features sounds like your kind of work, we're hiring.