How is technical content used in enterprise sales (w/ Buu Lam of F5)
Learn how F5 uses technical content to support enterprise sales, from deployment guides to Sales Engineer enablement and customer education.
Technical content used in a PLG motion is quite different from how it gets used in an enterprise motion. There are plenty of frameworks that explain this, but I wanted a practical view of what it actually looks like inside an enterprise sale.
What content gets used, who uses it, and where does it actually help move a deal forward?
To answer that, I spoke with Buu Lam, who spent more than a decade in Solutions Engineering at F5 before moving into DevCentral and community leadership.
In this article, we discuss:
- How a 100+ page deployment guide helped F5 close deals around Microsoft Exchange
- What Sales Engineers need from content when every customer environment is different
- How one research report can work for both engineers and budget-holders
- How F5 used technical education to help its audience adopt DevOps
- What changes when you start looking at technical content from the CEO’s perspective
- What to build first if you’re starting a technical content and community engine from zero**
If you’re a content marketing manager at a devtool company starting to sell into enterprise, there are some very practical lessons here.
Let’s get started.
A quick note on F5
F5 provides application delivery and security infrastructure for large enterprises. Its technology helps organizations deploy, operate, secure, optimize, and govern applications and APIs across on-premises, cloud, and edge environments.
Its customer base is concentrated in Fortune 1000 and Global 1000 companies, particularly across financial services, technology, healthcare, manufacturing, transportation, education, government, and service providers. More than 80% of the Fortune Global 500 rely on F5, including the 15 largest global banks, 10 largest global insurers, and 10 largest global telecom companies.
In financial services, for example, F5 works across environments where uptime, security, data sovereignty, and regulatory requirements are part of the infrastructure decision. Its solutions address requirements around DORA, NYDFS 500, APRA CPS 230, audit trails, incident reporting, and continuous resilience testing.
So you can imagine the complexity Buu was dealing with when he was selling F5.
Now, let’s look at where content actually fits into that process.
1. The sales asset was a 100+ page deployment guide
The first example Buu gave me was Microsoft Exchange.
At the time, companies were running Exchange in their own environments, and F5 was being used in front of Exchange Client Access Servers to handle things like load balancing, SSL, remote access, and application security. F5 worked closely with Microsoft and built an iApp template and deployment guide specifically for these Exchange deployments. The guide went through extensive engineering and testing and was intended to give customers a supported path to configuring F5 correctly, with less work.
The guide walked an administrator through the actual deployment: prerequisites, supported Exchange and BIG-IP versions, different deployment scenarios, certificates, configuration steps, SSL offloading, security settings, troubleshooting, and manual configuration options. It even documented specific failure cases, such as certificate errors and authentication issues, and was updated as new Exchange and BIG-IP versions introduced changes.
That tells you what F5 was trying to solve with the content. A customer could already decide that F5 was the right technology. The harder question was: how do we actually put this into our Exchange environment without our engineers having to figure out every configuration detail themselves?
Buu told me this kind of content helped F5 close countless sales with customers using Exchange.
There was no marketing fluff. It was accurate and explained Exchange in a way that non-Exchange admins could understand. It got you up and running very quickly.
That last part is important. The guide was doing a job inside the sale: reducing the amount of technical work and uncertainty between buying the product and getting it into production.
When I asked him about the commercial impact, he said :
it’s amazing how easy a sale can be if the product works quickly and flawlessly in a complex situation.
For a content team, this changes the brief. You are not just producing content about what the product does. You are documenting the specific environments, integrations, configurations, and problems that can make a customer hesitate to deploy it.
2. The sales engineer becomes the customization layer
The deployment guide handled a repeatable problem. But once an enterprise customer has a different architecture, requirements, or constraints, someone still has to connect the dots. That was Buu’s job as a Sales Engineer.
I asked him what piece of content he wished existed during a deal but had to build himself. His answer was about getting as close to the customer’s specific situation as possible.
I always wanted to get as customized as possible for my customers.
For Buu, the more precisely he could solve the customer’s problem, the stronger the sales story became.
The more precise I could solve something for a customer, the more compelling the story.
That level of customization could mean adapting written material or building a demo around the customer’s environment. And it could take a lot of time because the SE had to retain the full context of the customer and connect it back to what F5 could offer.
This could take a lot of time to assemble and really relied on my memory to know the entire context of the customer and match it with what we could offer.
This is where I think technical content can do more for Sales Engineers than simply give them something to send to a customer. It can turn repeated technical work into reusable building blocks.
F5’s iApps are a good example of this idea in practice. F5 created application templates that abstracted much of the configuration work from its deployment guides, while still allowing customers to customize the configuration for their environment. For complex applications such as Microsoft Exchange, F5 says the difference could be significant: up to 1,200 manual clicks versus around 50 with the iApp.
F5 also documented how customers could customize iApps themselves, including changing the questions presented during deployment and changing how those answers were implemented.
That is the kind of content system I’d want a content team to build around its Sales Engineers. Not one asset for every possible customer. A set of reusable technical building blocks that an SE can pull from and adapt: reference architectures, integration guides, configuration examples, deployment templates, troubleshooting guides, and demos.
The question I’d leave the content team with is: "What are our Sales Engineers repeatedly building for customers that we could turn into a reusable technical asset?"
3. One report, two very different conversations
Buu’s next example was F5’s State of Application Strategy report.
F5 has been running the research for 12 years, surveying IT decision-makers about how organizations are building, securing, and operating applications. The 2025 edition had around 650 respondents, with 65% holding executive or senior leadership roles. Technology, cloud, and financial services were particularly well represented.
The report is also designed to be used beyond simply reporting industry trends. F5 positions it as a resource for IT leaders to evaluate strategies, support IT priorities and budgets with data, and prioritize the challenges they need to address.
That context made Buu’s answer interesting to me. The same research can enter conversations with people who have completely different responsibilities.
This report is written in a way that allows us to flex to either audience.
For a budget-holder, Buu uses the research to talk about the broader themes F5 is seeing and where the organization fits into those trends.
For budget-holders, we can share what themes we’re seeing often, it matches with the audience.
For an engineer, he uses the same report differently.
For an engineer, this is particularly interesting because it can really guide where they want to invest their time learning.
That is a useful way to think about research content in an enterprise sales motion. The asset does not have to change for every stakeholder. The conversation around the asset can change.
An engineering leader might use the findings to decide where the team needs to build expertise. A technology executive might use the same findings to discuss priorities, budgets, or where the organization is falling behind the market.
Buu also made a point that I think matters for developer companies selling into fast-moving categories:
With how quickly the market has moved in recent years, I know from personal experience, it’s important to get ahead of learning.
That gives research a second job beyond generating leads. It can give your audience a reason to understand a changing market, while giving Sales a credible piece of evidence to bring into an enterprise conversation.
For a devtool company moving upmarket, I’d think about research content this way: give the engineer something worth learning, give the decision-maker something worth discussing, and give Sales something credible to bring into the conversation.
4. When content becomes part of the customer’s learning curve
The State of Application Strategy report showed one way content can support an enterprise conversation: the same research can be useful to different people for different reasons.
Buu gave me another example where F5’s content was solving a different problem.
F5 was seeing a growing gap between NetOps and DevOps teams. Developers were pushing for faster application delivery, while network teams were still dealing with many of the same manual, task-based processes they had used for years. F5 had seen this with its customers and built Super-NetOps around that skills and collaboration gap.
The program was a structured learning program with video instruction, hands-on labs, and guides covering DevOps methodologies, automation, orchestration, and infrastructure-as-code. Participants were taught how to take network services and put them into automated toolchains.
F5 even had a specific outcome in mind: move teams away from manual, task-based work and reduce time-to-service from days to minutes while maintaining compliance, policy, and performance requirements.
Buu remembers what was happening with the audience at the time:
We were going through a time where our traditional F5 audience was faced with the rise of DevOps practices in their environment.
A few people inside F5 started building education around that shift.
A few folks internally had started a real movement of education by creating learning content that helped our audience learn about DevOps and start to employ the practices.
What stayed with Buu was what happened to the people going through it.
I saw careers take a new direction as a result and that really stuck out to me.
That changed how I think about education content in an enterprise motion. Sometimes the customer needs to learn a new skill, adopt a new workflow, or change how their team operates before they can get the value they bought the product for. In that situation, a blog post is not enough. You need content that actually teaches the work: labs, examples, workflows, code, and enough structure for someone to go from understanding the concept to doing it.
F5’s Super-NetOps program is a good example of that. The content was helping the customer build the capability required to operate in a DevOps environment.
For a content team, the focus should be on what customers need to learn before they can get the full value from the product.
5. Then Buu saw content from the executive seat
By this point in our conversation, we had talked about content helping customers deploy F5, helping Sales Engineers customize a solution, giving different stakeholders something useful from the same research, and teaching customers new technical skills.
Then I asked Buu what changed when he moved into his role as Technical Advisor to the CEO.
That role gave him a different view of the same work. He could see how technical decisions were being discussed at the executive level and how they connected to the company's direction.
That connection is also visible in how F5 defines the Sales Engineer role today. Its SEs are expected to design solutions around customer business objectives, articulate technical and business value, and support the sales process with solution designs, demonstrations, proof-of-concepts, and customer-facing content.
I wanted to know whether seeing that from the executive side changed how Buu thought about technical work and content.
His answer was straightforward:
Ultimately, engineering work has to roll up to a business objective and business value.
He had already learned to think about the customer's business through Sales Engineering. From the executive seat, he was now seeing the other side: how F5 itself thought about its priorities, how executives understood the company, and how they wanted to explain that story to the market.
I learned this from my work in Sales but learning about this from within our own company was really interesting to see how our executives view our own company and how they tell the story to the market.
That matters for content because a technically excellent piece can still be disconnected from what the company is trying to achieve.
If the business is entering a new market, pushing a new product category, or trying to change how customers think about a problem, the content needs to contribute to that objective.
6. Start with what your customers are already trying to do
After talking through deployment content, Sales Engineer enablement, research, education, and the business side of technical content, I asked Buu a more practical question: “If you had to build this content and community engine from zero today, where would you start?”
His answer was much simpler than I expected.
The first thing I would do is speak to our customers and understand what they’re doing with our products and what they want to do next.
That means starting with customer conversations before building the editorial calendar.
What are customers actually implementing? Where are they getting stuck? What are they trying to do next? Which questions keep coming up in Sales, Support, and customer conversations?
Buu believes there is usually enough material there to get started.
There’s always low hanging fruit out there and racking up some initial wins is so important for: earning trust, building confidence, showing value - and so much more.
F5’s DevCentral is a good example of what this looks like when it compounds. Today, it has more than 300,000 technical peers, with forums, technical articles, videos, code samples, training, and other resources.
But the interesting part is how F5 describes the community itself. Its technical forums are built around people asking questions, having conversations, and finding solutions. Its technical articles focus on helping someone accomplish a specific goal with F5 technology.
That is basically Buu’s advice in practice: start with what customers are already trying to do, solve those problems, and let the next set of problems tell you what to build next. Then keep publishing.
It’s great to dream big but establishing a cadence of consistent output helps prime the pump for future success.
For a content marketing manager trying to figure out enterprise content strategy, I’d take that literally. Talk to Sales Engineers, Support, and customers. Find the technical questions that keep coming up. Turn the repeatable ones into useful content. Then keep going.
Closing thoughts
There is a lot to learn from what F5 has built around its customers. DevCentral has been around since 2003, and today it brings together technical forums, articles, videos, code samples, training, certifications, and more than 300,000 technical peers. The depth and consistency of that ecosystem is impressive.
What I found most useful from my conversation with Buu was seeing how many different jobs technical content can do inside an enterprise motion. It can help someone deploy the product, give a Sales Engineer material to work from, help different stakeholders understand the market, teach customers new skills, and support a broader business objective.
Thank you, Buu, for taking the time to walk me through these examples and for sharing what you’ve learned from working across Sales Engineering, technical leadership, and F5’s community.
And credit to the F5 team for continuing to invest in the technical ecosystem around its customers. There is a lot here for devtool companies making the move into enterprise to learn from.
If you’re a content marketing manager at a devtool company thinking about selling to enterprise, start with the questions your Sales Engineers are answering every week. Those questions will tell you a lot about what your enterprise content strategy needs to become.
