There is no denying that the demand for developer advocacy is peaking. Everywhere I go, I can see a huge demand for developer advocates, and this is awesome because this is the career that I chose for myself. But other than this, it is also proof that companies finally realize the value of improving developer experience in the products they offer. As such, this current spike for developer advocates is also a problem. This is not a simple career path to get started with.
In this blog post, I will try to provide the best advice that I wish to have received when I started this developer advocacy journey. I have been doing this for a while now — both as a practice and a full-time job. The best thing one could do when they learn (you can read this as fail enough) is to share with people getting on board. Without further ado, the best advice is this:
Create the habit of transforming complicated things into simple things
I know that this advice may sound like one of those fortune cookies advice, where you feel that there is some wisdom behind it, but you have no freaking idea what it means in pragmatic terms. Don’t worry. I will explain what this advice means, but for you to properly understand, I need to explain how I came up with this advice in the first place and how this advice applies to different aspects of the developer advocacy career.
Forget the spotlight 📸
Let’s face it: being famous makes you feel awesome. I don’t know a single person working as a developer advocate that doesn’t like to get the spotlight. And you shouldn’t be ashamed of it. It is part of our nature. We all crave attention. Having spent a significant time working as a software engineer might not have granted you enough popularity since you are behind a monitor writing code most of the time. It is cool but not fancy. For this reason, I think most developer advocates start their career craving for this. The problem is when you only care about this.
The year is 2009, and up to this point of my career, I had spent a significant amount of my time getting really good at some technologies from the middleware space, such as Messaging, Integration, and SOA. Dang… I was really good at this. I was solving hard problems, I was writing blog posts about it, and I was being sought as a leader in this space in the company that I was working for. The only thing I didn’t have was people knowing who I was. This is pretty much how I started my journey into developer advocacy — trying to get known in the community.
So I started to apply for conferences to have talks accepted. It wasn’t easy at first because all I wanted to do was to show off my knowledge. So my abstracts were always full of jargon, acronyms, and sentences showing how amazing I was. For this reason, I spent a significant amount of time being rejected by conferences. That hurt me well. I couldn’t understand how I could be rejected since I was an expert in the space I was involved, and all the conferences I was applying for were about that same space. When I realized that while writing an abstract, it should not be about me but the audience.
It was magical. I started to write better abstracts focusing my energy in writing not what I would like for people to think about me but what they could learn from the talk itself that could be interesting. When I got my first talk accepted, I remember that I celebrated so hard with my wife at the point. Then it happened something that people starting with developer advocacy are often never prepared to: deliver the talk. At this point, I wasn’t so concerned with this because I had the talk approved already, so nothing was being at check anymore. Wrongly presumed, of course.
My first talk at a conference was horrible. I spent most of the time trying to sell myself and how amazing I was. By the time I actually started to talk about the subject that the talk was about, I made it so terribly confusing for people to understand that everybody started to show the question mark faces. In that situation, I was trying to impress people with my knowledge. I was trying to show them how smart I was and, though not intentionally, how dumb they were. Unsurprisingly, my talk was one of the worst evaluated talks from the conference. Once again, I was repeating the mistake made while writing the abstracts. Trying to make everything about me and not about the audience.
The year now is 2012. At this point, I had spoken in several different conferences, some of them really known in the technology space, but I was far from being sought as a good speaker. I am a slow learner, so I had to waste almost 3 years making the same mistake to recognize that I had to change something. Well, I started my journey in checking where I was failing by talking with some friends. What would be of us without them, right?
Pretty much the advice I got was: “Ricardo, you are a monster in the field you are in — but you don’t know how to express yourself.”. I must share that at this point, I was devastated. Mainly because years before throwing myself in the talk’s circuit, I had been a Sun Microsystems instructor, and I was used to teaching Java to developers. And I was good at this. I couldn’t possibly understand why I would be sucking so hard as a speaker. It turns out that delivering a class training is not the same as speaking at a conference.
I observed other experienced speakers and how they deliver their talks to fix this problem. Whether watching them live or via YouTube, I spent a significant amount of time trying to capture the essence of their talks. Do you know what I had found? All great speakers make sure to deliver one simple thing very well understood, and they literally don’t care about being complete. I had watched speakers taking whole 45 minutes to deliver very well one simple concept.
I reflected on this and realized that the time I spent trying to impress or sound smart was obfuscating my real job as a speaker, delivering one thing very well. When I say “one thing,” I am not saying this literally. It can be two or more. But as long you deliver them clearly, well-articulated, and in a way that people leave the room with that concept stitched into their brains. What does this tell you? That once again, it should not be about you but the audience. Forget the spotlights. Focus on the people that came to learn with you.
Learning this helped me to improve other aspects of my speaking as well. It helped me emphasize key concepts and revisit them after explaining instead of rushing to the next one. I learned that it is more important to concretely finish one concept that delivers the whole talk without people actually understanding what you explained. I learned that for people to understand what I was saying, it should be not up to them to be smart but up to me to make sure that this happens. This also taught me that it is important to think through how much content you should deliver for every single talk. It is all about the audience. After doing this a few times, I realized that the key was to — making sure that things would sound simple rather than complicated.
By the time I started to apply this advice to my public speaking engagements, I had started to sound less smart, but people started to learn more, and I started to get more people to know me and enjoy my work.
There is always a thing 🤫
No matter which technology you are working with, there is always something complicated to use. When I worked at Red Hat, I was responsible for the middleware business, all about the JBoss application server. Back then, developers would effortlessly use it to deploy their Java EE applications. Still, it was always a mess while handling multiple classloaders regardless of how experienced the developer was. At Oracle, I was deeply involved with SOA and Big Data technologies, and there was not a single project where I would not see developers struggling with how to ensure the correct size of their services. When I worked at Confluent, I repeatedly saw how hard people struggle with Kafka’s partitions concept. There is always a thing.
A common mistake new developer advocates commit is ignoring where they should focus on. Instead, they tend to focus on what is cool, what grants them more popularity, what will make them shine with their bosses, or maybe what they know very well, which means that there is also a problem of not willing to leave the comfort zone. Regardless, this is a huge mistake. Developer advocacy is often about making developers’ lives easier, and you should start with the thing that hurts them the most. It shouldn’t be hard to spot those. It will be what developers often complain about on social networks; it will be the product or feature with most ticket escalations on support, or perhaps whatever feature people try for the first time and fail nonetheless, and have to undergo many iterations until making it work.
The industry has a concept called “quick win.” Quick wins are the efforts you or your team executes successfully that don’t represent the completeness of a project or goal but grant them a small objective victory. When you start your job as a developer advocate, you should focus on building a quick win. Pick the most complicated, horrible, criticized, or unwanted feature of your product and turn it into something straightforward. By doing so, you will see that your work will shine in a short period, and you will have a bit of credibility for doing more of it. I have a quick story to share about this.
When I first joined Confluent in 2018, I tried to apply this concept by spending a significant amount of time listening to people inside and outside Confluent. My question was always the same: “what part of the product you hate the most and why. A good example that I heard was deploying the Confluent Platform manually into cloud providers.
Then I decided to do something about this. I had experience with infrastructure-as-code with Terraform, so I decided to write a Terraform module that would deploy Confluent Platform in different cloud providers (I had to write modules for AWS, Azure, and Google Cloud) so developers could spend more time using the product than with plumbing. Aspects like VPC’s, subnets, security groups, volumes, images, disk sizes would be completely handled by Terraform. The user would be given an SSH endpoint to connect with the public key if they wanted to configure anything further.
When I showed this for the first time in a meetup, people were amazed how I could, in less than 10 minutes, ramp up a complete stack from scratch in a given cloud provider, present what I was trying to present, and after all, destroy everything programmatically.
When you focus your energy on making a developer’s life easier, it pays it off. Sometimes you can be mad at your engineering team because you have filed JIRA tickets to improve something, but you are also part of the problem when you don’t do anything about to change. As a developer advocate, it is your job to improve how developers consume certain products. Whenever possible, try to pick something terribly broken with your product and work to make it simpler. Create the habit of transforming complicated things into simple things.
This is going to help you not only to become a better developer advocate but also to show concrete and tangible results from your work to the company you are working for.
Influence as much as you can 🎙️
Like many things in life, being successful sometimes doesn’t depend only on you. The role of the developer advocate is certainly not an exception. Even if you undergo the journey of transforming complicated things into simple things yourself — you have to make sure that other people are also doing the same. This is important because your job may entangle with others’ jobs, and when this happens, you need to make sure that your approach is followed. Like I did with the other examples, let me share a personal story.
During my tenure with a previous company, I would often partner up with people from marketing to deliver tailored content to specific audiences, mainly when the idea was to execute a given campaign. I won’t bore you with the details of what this means because this is purely a marketing thing, but what matters is that these campaigns would usually come down to me just to be delivered without any say-so from me. Up to that point, I would already have the concept of transforming complicated things into simple things very clearly in my head, so I couldn’t avoid but wonder that sometimes, the campaign that I was assigned to execute wasn’t necessarily following that practice.
My first attempt in simply delivering what was being asked failed terribly. The key points to be delivered were not tailored for the developer audience but instead for a business audience, and as such — developers hate it. Funny enough, this was not a mistake from the marketing team because they indeed created the campaign to focus on developers. But since they don’t know how developers think, they were not even aware that such concern must exist. FWIW, this is not necessarily a mistake on their part, as people from marketing have different inputs, audiences, and outputs than developer advocates.
Then I sat with them and explained how we should have created the content and why. Lucky for me, they were very receptive to this, and we agreed very quickly. Then for the other campaigns, I started to get involved in the loop in the early phases of the campaign to help with content tailoring. Of course, it wasn’t all flowers, and there was a considerable amount of struggle, back-and-forth until we ended up with a campaign strategy that would follow the simplicity principle. If you ever had to work like this, you know that there is a bit of traction in every step of the process, but the final result pays itself off.
The same process also had to occur in another instance with the engineering team, to which I had decided to contribute more in providing the proper feedback on how the CLI tools from the product should be designed. While they had decided to follow industry patterns, the reality is that the actual community using the product would have all sorts of problems while using the CLI. Therefore, it had to be thought with a different mindset, one not so complicated as it was being.
Bringing simplicity for developers is oftentimes a job that you must execute beyond the scope of your individual tasks. Sometimes it requires you to partner up with other departments. It requires you to provide the proper feedback to the right people and fight that the feedback is heard, acknowledged, and triggers changes based on them.
Summary
Transforming complicated things into simple things should be the modus operandi in how developer advocates do their job. Whether you are starting or doing this for many years, this is the secret of separating good developer advocates from the average ones. But if you are starting your career as a developer advocate and want to know how to make sure your job will be impactful, this advice is probably the best thing you should follow.
I don’t know how other developer advocates see themselves after doing this job for a while. Still, I can share that, at least for me — keep transforming complicated things into simple things is pretty much everything I do in my job. It morphed from being something I started to do to something I essentially do and thus can’t be done differently.