vExpert: Two Years In, and It Is Not a Certification
What the vExpert programme actually recognises, how the application works, and the contributions behind mine. Plus why Sydney VMUG is open, and what we will do to make your first session easy.
I've been a VMware vExpert for two years running. People ask what it is fairly often, and the honest answer takes longer than the question expects, because the name is misleading. It sounds like a certification. It isn't one.
There's no exam. Nobody tests whether I can build a workload domain or troubleshoot a failed upgrade. The programme recognises what you give back to the community around the technology, which is a different thing entirely, and the distinction matters enough that Broadcom says it in plain words on the application portal: "It's not a technical certification but a recognition for your community efforts."
So this page does two jobs. It explains how the programme actually works, for anyone weighing up whether to apply. And it sets out what I've contributed, because a public award with nothing behind it is just a logo.
What the vExpert programme is
vExpert is Broadcom's recognition programme for people who share VMware knowledge publicly and sustain it. Bloggers, authors, speakers, podcasters, VMUG leaders, forum moderators, script writers, video makers, people who run user groups in their own time. The award runs on an annual cycle, February to January, and you have to reapply each year. Nobody carries it forward on reputation.
It's open to customers and partner employees alike, and to independents. As of early 2026 there were somewhere between 1,025 and 1,091 active vExperts depending on which Broadcom page you read, spread across 64 to 76 countries. The numbers disagree with each other, which I find quietly reassuring about how the programme is run: it's a community thing, not a marketing machine.
How you get in
You apply. There's no nomination, no sponsor requirement, and no quota that I'm aware of. The form asks you to evidence your contributions across four areas, and the reviewers score what you submit against four criteria that Broadcom publishes openly: content quality, originality, consistency and impact on the VMware community.
That word consistency does a lot of work. Three brilliant posts in one week and nothing for ten months reads worse on an application than something modest every fortnight for a year. The programme is trying to find people who keep showing up.
The four paths, and picking the wrong one is a real risk
The form asks you to choose a qualification path up front, and the reviewers read your evidence against that path. The common mistake is choosing the one that describes your job rather than the one that describes your contribution.
Evangelist covers people whose contribution is published work. Blogs, books, videos, podcasts, conference talks, tools. If the bulk of your evidence is things you made and put online, this is yours.
Customer is for people advocating from inside a customer organisation, typically through user groups, reference programmes and internal advocacy that spills outward.
Partner is the equivalent from inside a partner or reseller, where the contribution is enablement and ecosystem work.
There's also a VMware Business Unit lead sub-path for people inside Broadcom. Choose by where your evidence is strongest, not by your business card. Mine is Evangelist, because the writing is the bulk of it.
What it actually gets you
More than I expected, and the valuable parts aren't the ones that look valuable from outside.
My own record
Two years, both under the Evangelist path. I'm setting the whole thing out below rather than just naming the award, partly because a badge with nothing behind it is worth nothing, and partly because people ask me what a successful application looks like and a real one is more useful than advice.
Year one and year two were not the same application
The first year I got in mostly on user group work. I was running chapter operations, coordinating speakers, and the writing was sporadic. It was enough, and I suspect it was closer to the line than I realised at the time.
The second year is almost the inverse. The user group work carried on, but the publication became the bulk of it, and the application got much easier to write because the evidence was simply sitting there with dates on it. That is the actual lesson, if there is one: the application is not the work. Do the work in public all year and the form fills itself in.
The writing
This publication. It started on Substack in May 2026, moved to its own self-hosted Ghost site in August, and was renamed in September when the scope outgrew VCF alone. Between late May and early October I published more than a hundred long-form technical articles. All sole-authored. All sourced from public Broadcom and VMware documentation, with the references listed, because an architect reading a claim should be able to go and check it.
It is organised as series rather than scattered posts, which matters more than it sounds. A single post about tenancy is a post. Three posts that take someone from day one to a working multi-tenant design is something they can actually use.
VCF 9.1 architecture and design
The design changes that actually alter how you draw the thing, a multi-part topology field guide, and a checklist of the decisions you need to have made before you start building. The checklist came out of watching the same five questions get asked at the same late point in every project.
Getting from vSphere 8 to VCF 9.1
Originally a five-part upgrade series, later rewritten as a pair: a staged path for the people deciding, and an engineer's companion covering topology, network, storage and integrations at every stage for the people doing it. Two audiences, two documents. Trying to serve both in one article was the mistake in the first version.
Security and lifecycle
VMSA severity analysis with a remediation map for every supported stream, post-quantum readiness and what harvest-now-decrypt-later means for an estate you are designing today, file integrity monitoring, STIG compliance, certificate renewal, and the shift from baseline-based to image-based host patching.
VMSA-2026-0006, full severity picture · Harvest now, decrypt later
A seven-part AI infrastructure series
The one I am most pleased with, because it refuses to stay at the marketing layer. GPU utilisation and why two thirds of yours are idle. Why decode is bound by memory bandwidth rather than compute. Why a quarter of a card is not a quarter of the capacity, and what MIG does that time-slicing does not. What quantisation actually costs you. Honest cost-per-token modelling. Which inference engine, and whether it matters. And RAG treated as the distributed systems problem it is rather than a feature.
Two thirds idle · Waiting for memory · A quarter of the card · Smaller numbers, faster tokens · Cost per token · Which engine · RAG
Adoption, which is mostly about what people already own
Three parts on getting value out of licences customers are already paying for: the first ninety days on 9.1, the entitlements sitting switched off, and tenancy design. This came from a pattern I kept seeing, which is organisations buying a platform and then running about forty per cent of it.
The first ninety days · What you already paid for · Tenancy design
Hyperscalers and licence portability
Amazon EVS explained for people who design VCF rather than people who sell AWS, and what bring-your-own-licence now means in practice across AVS, GCVE, OCVS and EVS.
Explore 2026, covered from twelve thousand kilometres away
I was in Sydney, not Las Vegas. I covered the event anyway, publishing eleven technical articles across the four days as announcements landed, then went back afterwards and catalogued every single breakout session. That coverage reached more people than anything else I did this year, which was not the plan and is worth remembering: you do not have to be in the room.
Three tools, given away
These took the longest and I would point a reviewer at them first. All free. No sign-up wall, no email capture, nothing phoning home. I feel reasonably strongly about that: a community resource that harvests your address in exchange for access is a lead magnet wearing a community resource as a costume.
User group work
Sydney VMUG, where I work alongside the Chapter Leader on governance, the speaker programme and continuity. Until October 2026 I was also ANZ lead for APJ vCommunity, aligning what the Australian chapters needed with what the regional programme was trying to do. That role sat with my employer and ended when I left Broadcom. The chapter work did not.
What I do with the benefits
Worth being specific, because the benefits list reads like marketing until you see it used. The home lab licences are the reason the writing can be concrete: when an article describes a fleet upgrade or an identity broker migration, it is usually because I ran it. The pre-Explore briefings under embargo are why the day-one coverage could go out on day one instead of a week later. And the private vExpert channel is where I check whether something I think I have understood is actually right before I publish it to a few thousand people.
I hold VCP-VCF Architect and VCF Administrator, which is what makes the three-year lab licences available. I am working toward VCAP and then VCDX, which is a longer road and a different kind of thing entirely. vExpert does not help you pass those. It does mean you have a lab and people to ask.
What did not go well
We moved the chapter to an independent registration platform after the previous portal failed. That failure cost us attendance at the June session, and I had not treated registration as something that could break until it broke. You find out your sign-up flow is fragile at the exact moment people cannot sign up.
Come and help run this
Here is the part I actually care about, and the reason this page exists at all.
VMUG chapters run on a handful of volunteers. That is true in Sydney and it is true almost everywhere. It works right up until someone changes jobs or has a kid or burns out, and then a chapter that looked healthy goes quiet for six months. The fix is not finding one more heroic organiser. It is having more people involved, each doing less.
So: Sydney VMUG is open. Not open in the sense that you may attend, which was always true. Open in the sense that if you want to help shape it, speak at it, or run part of it, there is room and we would like you there. You do not need an invitation and you do not need to know anyone.
Community sessions are the thing I most want to see more of
A community session is a practitioner standing up and saying what they actually did. Not a product pitch, not a roadmap slide, not someone from a vendor explaining why their thing is good. Just a person describing a real piece of work: the design they chose, the migration they ran, the thing that broke at two in the morning and what it taught them.
These are consistently the best sessions we run and consistently the hardest to find. Vendor content is easy to source because vendors want the slot. Practitioner content depends on practitioners volunteering, and almost everyone talks themselves out of it. The usual reasoning goes: it is not impressive enough, someone more senior should do it, it did not go perfectly so there is nothing to show.
That reasoning is backwards. The sessions people remember are the ones where someone was honest about what went wrong. A polished success story teaches an audience very little. "We got this badly wrong for four months and here is what we would do differently" fills a room and stays with people. If you have a scar, you have a session.
Things that make a perfectly good first session
None of these need to be groundbreaking. They need to be true.
- A migration or upgrade you ran, including the bits that went sideways
- A design decision and the reasoning behind it, especially one you would now make differently
- A tool, script or dashboard you built because the existing one annoyed you
- Your home lab, how you built it and what it cost
- A certification path you went through and what the study actually involved
- A product feature you evaluated and chose not to use, and why
- Something adjacent: Kubernetes, storage, networking, automation, AI infrastructure, security. It does not have to be VMware to be useful to a VMware audience
- A ten minute lightning talk on one specific thing you figured out
What we will do to make a first session easy
If speaking is not your thing
Plenty of the work has nothing to do with standing at the front. Finding speakers and chasing them politely. Venues and logistics. Sponsor conversations. Running the Discord and keeping the comms going. Welcoming people who turn up alone and do not know anybody, which is genuinely one of the most valuable jobs at any meetup. Helping newer members find their footing. Committee roles when they come up.
Any of these is a real contribution, and all of them count toward a vExpert application later if that is something you want. But do them because the chapter needs them, not for the badge. The badge is a side effect.
How to actually start
Turn up to a meeting and say hello. Join the chapter Discord and post in the channel. Or go to vmug.com/sydney, find the next event, and tell whoever is running it that you would like to help. That is the whole process. There is no application and no vetting.
If you are outside Sydney, the same is true of Melbourne and Brisbane, and of the other 230 or so chapters worldwide. Find yours and do the same thing.
If you're thinking about applying
Do. The bar is lower than people assume and the application itself is useful even if you don't get in, because it forces you to write down a year of work you'd otherwise have forgotten.
Five things I'd tell anyone filling in the form
Answer the question the box is asking. The sections look similar enough that content drifts between them, and leadership work in particular has a habit of landing in the events box. If a reviewer reads your events section and finds no events, that section scores nothing. Read each prompt, then check that what you pasted actually answers it.
No placeholders. Obvious, and easy to miss in a draft you have been editing for weeks. Square brackets in a submitted application say you ran out of time.
Give the numbers you can stand behind, and only those. Subscriber counts, article counts, chapter sizes. Where you don't have a number, describe the thing instead. Inflated figures are worse than absent ones.
Lead with what you built, not what you attended. Originality is one of the four criteria. A tool, a script, a checklist, a catalogue, anything that exists because you made it, beats a list of events you went to.
Ask a vExpert PRO. They're regional, they're listed in the directory, and reviewing applications is literally what the sub-programme is for. I didn't do this the first time and should have.
Sources
Programme description, qualification detail, benefits, review windows and the "not a technical certification" wording: vExpert Application Portal, Broadcom.
Review criteria (content quality, originality, consistency, impact), the February announcement and the June second cycle, sub-programme eligibility: Announcing the 2026 vExpert Program, VMware vExpert Blog, 12 March 2026.
Member and chapter figures, and how vExpert sits alongside VMUG, VMware {code} and the Broadcom Community: Broadcom Community Programs for 2026, VMTN Blog, 11 March 2026.
Member counts vary between the two Broadcom pages cited (1,025+ and 1,091) and country counts vary within a single page (64 and 76). Both ranges are given above rather than picking one. Programme details change between cycles; check the portal before applying.
This page is personal writing. Views are my own, and nothing here is an official statement of the vExpert programme or of Broadcom.