Wesley Faulkner is a native developer advocate... and other things I learned recording his DevJourney (#131)

This week, I published Wesley Faulkner's #DevJourney story on my eponym Podcast: Software developer's Journey. Among many other things, here are my main personal takeaways:

Wesley was introduced to BASIC and PASCAL in grade and middle school. Soon after, he discovered he could tweak existing games like this and became obsessed with finishing his exercises early during those classes to tinker further. Wesley didn't have a computer at home, so the next time he really tinkered with computers was in college, 10 years later.
He studied Electrical Engineering in college when Windows95 came out. It was so new that it leveled the playing field. Experienced computer users had to discover this paradigm, which allowed him to catch up quickly.
His first computer was a "piece of junk", and broke down merely one month after he bought it. But he brought it to a computer store and asked the owner if he could observe how the repair went. When it was fixed, he asked the owner if he could come back. This led him to work there for a few months and pay for his studies. He troubleshot many computers over those months, and tinkered a lot with hardware, growing invaluable skills in the process.
This bold asking for what he wants is a recurrent theme and is even the advice he gave us at the end of the interview. He got his second job like this as well, asking the speaker after a presentation if he could work for him. This led him to work for a startup and basically creating the whole testing pipeline for a new line of computer chips. Unfortunately, this company got acquired and Wesley lost his job and his mean of financing his studies. He had to drop college.
Wesley got a job at Dell, on the "MI40 Team" ("Millenium Impossible", the team responsible for helping customers solve the Y2K bug). Wesley had little to do during this job, so he focused on learning, teaching, and sharpening his "soft skills". That led him to be offered a job at Dell after this contract and got promoted every year. When he left 6 years later, he was the go-to technical person for big customers and was flying all over the Midwest at a moment's notice. This phase of his career helped him develop empathy, learn how to communicate with people, relate to them, and explain the technology.
Almost burnout, he transitioned to AMD, working on a home entertainment PC. Since some software was produced in house, Wesley learned what it takes to create a software product there as well. Working with marketing on this product line, was his introduction to communities. When he left AMD, his next jobs revolved around technical communities, for instance at Atlassian and Namecheap. In 2017, he discovered the world of developer relations at IBM.
When he decided to move away from IBM, Wesley announced his intentions on Twitter, and realized how much of a "silent-following" he had built. His work in the open was observed to a degree he had never imagined and received fantastic endorsements. At DevRelCon, he finally realized that "this was where he belonged".
There are still various definitions for Developer Advocacy. Wesley's definition is representing the company for the communities, and to the company, representing the community. There are also many ways to embody that idea. Wesley focuses on finding the people who need the solution the company provides, instead of trying to create new needs.
Truthfulness and honesty is key to a good developer-relations department. If the company pushes for glorified salespersons, you will end up being disingenuous to the company. Only with truthfulness will you be able to represent both sides.
"Ultimately, sales are where everything reports to, but it doesn't have to be a straight line." When DevRel is hooked to sales, the metric will be money and sales. If it is hooked to marketing, you will be measured by the leads and engagement you create. If you report to engineering, you will measure progress on technical terms, signups, or use of an API, etc. The fewer points between sales and advocacy, the hardest for the advocates.
Wesley defines success for himself as minimizing the space between "expectation and reality". If people get what they expect from interactions with him, that's a win. So he measures his success by happiness.
Wesley describes Developer Advocates being at the (right) places, where the discussion around your products is not yet happening, i.e. where marketing doesn't have a reach yet.

Advice:

"Ask the question, put yourself out there, there is value in the trying"

Quotes:

"Pushing things (CPU Chips) until they broke is one of the things that I loved"
"My first question is always 'why' and if it does not make sense, I try to get rid of it"
"Being embedded in a community, is not something you do once, it has to be a way of living"

Thanks, Wesley for sharing your story with us!

You can find the full episode and the show notes on devjourney.info.

Did you listen to his story?

What did you learn?
What are your personal takeaways?
What did you find particularly interesting?