Open Source over Secret Sauce
Unveiling the Core Values of Relationships with Developers: Building Trust and Authenticity in the DevRel World.
It’s been a year now since I stepped into the DevRel world, and there’s one question I’ve heard over and over this year:
What is DevRel?
While there are many answers to this (and I even wrote about it here), something happened to me last week that gave me a new, inspirational perspective on it. Listen to a story.
A couple of weeks ago, I asked a developer-marketer friend to help me find someone for a very specific professional service I needed. She looked around, asked for some recommendations, and found an agency offering that service.
When she requested a quote, this individual sent her an extensive deck (20 slides) of their various services, including a price tag ranging from $1k-$20k for a monthly retainer. Upon reviewing their deck, I noticed many standard marketing/PR activities and numerous mentions of their “secret sauce,” which were supposed to intuitively assure me of their expertise.
“Can we just pay them for the specific service we need?” I asked my friend.
“I asked him, and no. He only works on a retainer,” she replied.
“What are his objective commitments for the retainer?” I inquired further.
“Nothing, but I received many recommendations about them,” she responded.
“Sorry, it’s difficult for me to work with ‘Secret Sauce’ people,” I replied and found someone on Upwork for $1k, including objective commitment.
When I pondered why it was so challenging for me to work with such businesses, only one thing came to mind — my background as a developer.
At this point, I understood what DevRel is!
So, What is DevRel?
DevRel is an abstract field that encompasses many functions — User (and Developer) Experience, Technical Writing, Product Management, Marketing, Growth, Sales — BUT, it all must come with one twist: a fundamental respect for developers’ values.
Isn’t it just the same way we do relationships? In order to build a stable relationships, we first must know and respect the other side values. The only way to build a stable relationship with developers is know and respect those values.
“What are these values?” I’m glad you asked.
The following is a skeleton of a list I made with some values.
The Developer Relationships Values
As every relationship novice knows, the most crucial part of any relationship is listening to others. I would be delighted to receive your comments on other values that I could elaborate on in future posts.
Open Source over Secret Sauce
A couple of years ago, I worked on a product that was 20 years old. Our team’s work was 80% on bug fixes and 20% on new releases. I remember asking one of my managers for an example of a product that is reliable and stable after 20 years of coding. The one common value of all the software he mentioned was: Open Source.
The main value of open source is the community. When needs are driven by the users and not by the sales teams’ need to acquire more customers, it promises many years of stability. There’s no secret sauce that should be mixed in your open and authentic values.
In DevRel, it should be the same. Always look at the developers and be open with them. This doesn’t mean you shouldn’t have business goals. You should, and no one will pay your check if there aren’t any. How do you know what is your business goal? Be open! If you keep your strategy and work open and authentic, the users will tell you what your strategy should be, and the business goals will naturally grow from it.
Horizontal Scaling
If I were asked what the primary engineering value contributed to the rise of Cloud Computing and SaaS, I would no doubt say it’s Horizontal Scaling.
If you’re not familiar with the differences, the main abstract difference between horizontal and vertical scaling is your focus. In vertical scaling, you look at the computer resources; if you need to scale them, you add more resources no matter what the product needs to work better. Horizontal scaling looks at the product itself and scales the computing resources by the need of the product domains you need to focus on.
Let’s take the traditional Growth Marketing role as an example.
In the vertical scaling culture, you’ll hire one person who will be responsible for the following goals: data analysis, user retention, user acquisition, etc. This individual will apply the growth marketing playbook they know and search for the activities they should undertake, such as SEO, attribution, etc.
While this position description sounds simple and promising, if you’ve ever tried to hire someone for growth marketing for developers, you probably know it’s likely to fail. The main reason for this experiment’s failure is the domain expertise needed for each of the activities undertaken by the single Growth Marketing person.
Just as you wouldn’t vertically scale an entire application only because the database needs more hard disk space, overlooking the expense you pay for the rest of the application, this single entity will never scale efficiently.
What if we horizontally scale the growth marketing needs instead of hiring a vertically scaled entity for it? This is exactly what DevRel is.
By examining the growth needs of the product and seeking professional advice from a growth individual (similar to the cloud computing provider), you can concentrate on the domain needs and expand it across numerous DevRel (and even product developer) functions. The horizontal scaling of needs and functions is the key to successful DevRel work.
Know your Strengths
The best advice I ever received for advancing my career as a senior developer and technical leader was to identify my personal strengths and focus on developing them in line with product engineering needs. When I understood and accepted that I couldn’t do everything, my career took off.
In DevRel, it’s precisely the same. If you open the DevRel playbook, you’ll find a multitude of activities. The most important thing to remember? You can’t do them all.
When considering your business goals, the team members, the positions you might hire, you can compile a list that will help you focus on the strengths that will enhance your DevRel activities. Making smart choices here is the most critical skill for achieving success.
Crystal-clear Definition of Done
One of the greatest frictions between engineering and non-engineering teams, is the definition of done of a task.
Let’s consider UX/UI as an example. One of the most common jokes among UX and engineering teams working together is the pixel/experience perfect result of a UX requirement. The main reason for this friction is the nature of accuracy in both teams’ way of work.
In UX/UI teams, many assumptions are made intuitively or by external factors unknown to the development teams. In engineering teams, there are no intuitive assumptions or external influences; there are formal factors that get things done. To break this friction and keep work agile, it is super critical to focus on task definition and the definition of done.
In DevRel, the approach to definition and the definition of done is no less important than in purely engineering teams. To make DevRel work and measure the results, the key to success is a crystal-clear definition of done.
Healthy and Stable Relationships
Looking at this list, I can apply these values and habits to any kind of relationship. Building a healthy relationship requires keeping things open, ensuring commitments are scaled horizontally, investing in understanding strengths, and exercising definitions. But is that all that’s required? Of course not, relationships and (DevRel) require continuous investments in learning the principles that make them valuable, creating a frictionless life that builds a secure and stable environment for all stakeholders.
So, you are asking, “What is DevRel?” DevRel is any non-developer function that strictly follows developers’ values. You can’t sell anything to someone if you don’t recognize their values.
Let’s Connect!
As part of my plans for 2024, I aim to share often some insights here on DevRel. Following my profile will provide you with notifications and help me stay committed to my audience 😉
If you enjoyed this post, I would be happy to hear about it. You can show your support by 👏🏻 this post, leave a comment, or telling me directly on my LinkedIn at https://www.linkedin.com/in/gmanor/
