Baruch Sadogursky

Introducing Baruch Sadogursky

Baruch Sadogursky is a developer advocate and the head of developer relations at JFrog. His passion is speaking about tech and he is a regular speaker at the industry’s most prestigious events including DockerCon, GopherCon, Devoxx, DevOps Days, OSCON, Qcon, and JavaOne. A JavaOne Rockstar, the co-author of Liquid Software, and a Cloud Native Computing Foundation (CNCF) Ambassador, Baruch is a vocal champion for the interests of the developer community. Find Baruch on Twitter: @jbaruch.

Geertjan Wielenga: You're very knowledgeable about what's been going on in the developer relations world over the past few years in terms of conferences and podcasts. Could you just sketch out the landscape as you see it?

Baruch Sadogursky: Developer relations is on fire. Every day, there are new books, podcasts, and conferences. People are doing more and more in this area. In terms of the landscape, there are a couple of very good conferences. There is the whole franchise of DevRelCon, which runs in three different locations: London, San Francisco, and Tokyo. It was in China for a couple of years too, but I'm not sure whether that's continuing.

Those are, for me, extremely important conferences if you're in this space because all the practitioners get together and talk about the stuff that matters. There are so many topics covered if you count all of the three different conferences. The good news is that all of the talks are online, so you can go and watch all this content for free.

Geertjan Wielenga: What kind of topics are addressed at these conferences?

Developer relations conferences

Baruch Sadogursky: You'll find ge-neral topics like empathy and ethical questions, then you'll also find very practical topics, such as how to create a successful presentation or what the best style for technical writing is. There are talks about the stuff that we all care about, which includes key performance indicators (KPIs), measurements, justification, budgeting, and so on.

Geertjan Wielenga: Are you saying that there is this whole community supporting people who are doing developer relations?

Baruch Sadogursky: Yes. There is another conference, run by Evans Data, called Developer Relations Conference. I've never been, so I can't really testify, but from the content and the organization, it looks like more of an old-school evangelism thing. Also, it costs $1,000, which makes it not really accessible for most of the community.

Geertjan Wielenga: How did these developer relations con-ferences come about in the first place? They seem to have boomed in the last five years.

Baruch Sadogursky: Developer relations, as a discipline, has become more established. In the past, there was some planning and theory behind it, but it was more niche.

The Evans Data conference has been running for 15 years, so it's not new. However, in the last five years or so developer relations has become more mainstream for our industry. All kinds of companies are looking for approval from developers or looking to hire a group of developers. Realizing that developer relations is important, companies have started to invest in it and plan for it. An entire industry has subsequently been built up around developer relations. All these podcasts and books have been created due to the realization that almost every software company now needs developer relations.

On my way to the office today, I was listening to a webinar from a bunch of developer relations specialists at companies that do developer relations purely for HR. There was a company that sells home improvement equipment and it has a developer relations department that actually helps it to build a better brand and to recruit better developers. Everybody now wants to do developer relations.

Geertjan Wielenga: How did you end up in this domain yourself?

Baruch Sadogursky: I've worked with the two cofounders of JFrog, Yoav Landman and Fred Simon, since 2004. Before JFrog, we worked together doing Java consultancy at a company named AlphaCSP. We did a lot of Java 2 Platform, Enterprise Edition (J2EE) back then and also Spring. We drifted toward the automation of continuous integration and started to use Maven and stuff around it. At some point, we realized that Maven had great potential, but it was missing this key element of having an in-house repository.

Yoav and Fred wrote an open-source tool named Artifactory for our customers at AlphaCSP. They realized very early on that there was huge potential. Very large and important companies had started to use the tool from day one. Yoav and Fred eventually left AlphaCSP to start JFrog.

I stayed with AlphaCSP and also worked at a couple of other places. Eventually, Yoav and Fred called me and said, "Okay, it's time to come home. And by the way, we've invented a new job for you that we're going to call 'The Secretary of State' or 'The Minister of External Affairs.' You need to represent JFrog to the community and help us to spread the word. You need to get feedback from those people." That's how I got into this line of work.

That was seven years ago and, back then, we didn't really know how to do developer relations. We made many mistakes. We did evangelism instead of doing developer advocacy, for example, which meant one-sided communication and just trying to increase our audience size, instead of creating a dialogue and ongoing engagement. There wasn't much information out there about developer advocacy at the time or, at least, I wasn't good enough to find it.

Geertjan Wielenga: What do you like most about this role that you're in at JFrog?

Baruch Sadogursky: For me, it's the perfect job because it allows me to both be technical and network with other developers. I get to help and see the impact of that. When I was a developer, it was satisfying when I was able to create new things, but the feedback loop was very long, if it existed at all.

As a developer, you write something and maybe you see your code running in production, but that's it.

"In developer relations, you actually have a full feedback cycle."

—Baruch Sadogursky

The question is, how does your work improve the lives of other people? In developer relations, you actually have a full feedback cycle, which is extremely important for me. If JFrog manages to help developers, we hear it from them. If we don't do something right, we get feedback on what we can do better. We can take that feedback, implement changes, and have another try at helping the developers. Developer relations is the pipeline through which feedback travels. That's very satisfying because we can see how our organization is making an impact and how developer relations is making an impact.

In this role, we represent something that other people create. If we do developer relations to increase the adoption of a product by developers, to be able to hire better developers or to get better feedback, those outcomes allow us to support other functions in our organization.

Geertjan Wielenga: What kind of personality fits this role best?

Personal qualities needed

Baruch Sadogursky: I'm constantly recruiting because the right kind of people for these roles are hard to find. Most of the functions in developer relations are technical.

There are obviously some roles that are not technical, such as a community engagement manager or a community builder, but developer advocates, engineers, and technical writers all have to be technical.

The other side of this role is that you need to be an outspoken and community-loving person. I used to say that people in developer relations need to be extroverts until I was corrected; I was told that many people who do these roles are not actually 100% extroverted. They don't necessarily get energy from other people, but they still know how to engage. I'm more cautious now when I talk about requirements in developer relations, although I think that it is easier for extroverts, who naturally get their energy from engaging with other people.

Geertjan Wielenga: Why is the combination of technical knowledge and people skills so difficult to find?

Baruch Sadogursky: The majority of technical people are not necessarily very engaged with their tech community, either because they don't like doing that or because they're not very good at it. I don't want to get into generalizations and make statements about mutual exclusivity, but that's been my experience when trying to recruit.

Both when hiring internally and externally, I've found that whenever we have good technical people, they are either not interested in or not capable of being community beasts at the same time. I don't know why; I'm definitely not a psychologist. My observation is simply that it's very rare to find people who are both very technical and outspoken in their community.

Geertjan Wielenga: Do you have a typical day in your role?

Baruch Sadogursky: Developer relations is very diverse. We try to do tons of stuff around community engagement, including staying in touch with different communities and finding out what those communities are, where they are, and what is of interest to them. That's one end of the spectrum: pure social engagement. The other end of the spectrum is writing code, contributing to projects, doing code samples, and so on.

Other tasks include writing presentations, giving those presentations, taking part in webinars and conferences, and writing blog posts. On top of that, you have to make sure that all of this work is trackable and measured. That involves writing event reports and managing the influencer or networking database.

In an ideal world, all these tasks would be done by a team of diverse people, but in the real world (this ties back to our struggle with recruitment and also the fact that we're a pure cost center for the organization), we don't always have the luxury of five people at our disposal who each have a narrow domain to focus on. Everybody does everything, so a typical day is quite chaotic.

Geertjan Wielenga: Is developer relations really a cost center, then?

Baruch Sadogursky: Oh, absolutely. We cost JFrog money and we need to justify this money in terms of providing a ROI. This ROI is not 100% clear or trackable, of course.

Imagine that you're speaking at a conference and people hear about your project. Some of them will like it and try it. Although it's clear that you're making an impact, how much impact?

Was it worth sending you to this conference? Does it even work having you on the payroll? It's not clear. In developer relations, we fight to prove the ROI every day, so, yes, we are a cost center for the organization. We hope that we're a justified cost center, but we do cost money.

Geertjan Wielenga: As a consequence of all these diverse activities, I can imagine that each person must take on a lot of work. Can the result be that you work far harder than you really should?

Baruch Sadogursky: I think that's true for most of us in developer relations. The people I know in these roles are some of the most hardworking people in their organizations. We care about so many things from so many different domains that it naturally creates work. If you spend an entire day writing a marvelous piece of code because it's important and you enjoy it, that then leaves you working into the evening to get everything else done.

Geertjan Wielenga: I recently heard an interesting idea: "If you're a very hardworking person and you work 30% less, nobody will notice the difference, and you will still be productive." What do you think about that?

Baruch Sadogursky: Yes and no. I understand where that's coming from, but if you just start doing 30% less, I bet people will notice. Things that have to be done won't be done. It's better to ask, "Can I optimize and be 30% more efficient?"

It isn't effective for developers to work very long hours. If you do one thing all day, you're in this zone for X number of hours.

Piling on more hours will actually diminish productivity to zero very quickly. However, in developer relations, we don't have the same excuse because we do so many different things.

If you've been writing code for five hours and you feel that your code is only getting worse, do something else; get in touch with the organizers of your next meetup. It requires almost zero mental effort on your part to do that, but it's still something that needs to be done. When you're done with that, write a blog post or an event trip report for your last trip. Choose a completely different activity that you definitely can do effectively even when you're tired from writing code. When everything else fails, fill out that expense report you've been postponing for weeks.

It's very important to work efficiently, but I don't think we can cut our work down and expect that no one will notice. Maybe I'm just lying to myself about how important I am, but I would like to believe that the stuff that I do is important enough that I can't just throw it into the garbage.

Caring too much

Geertjan Wielenga: Sometimes people care too much about the tech that they represent, which means that they work too hard. Do you not agree that, in some cases, we should take a step back?

Baruch Sadogursky: I completely agree that we carry too much on our shoulders, but I think that's part of the job. We're in developer relations because we care too much. I don't see how that's a bad thing. I don't want to lose my investment in this work because I need that passion to do my job.

Geertjan Wielenga: If the company that you represent starts going in a different direction, how should you respond to that?

Baruch Sadogursky: You need to be invested in the vision of your organization. If you're aligned with this vision and if you understand why the pivot was made, then that pivot is natural for you as well.

We had this come up at JFrog when we started being a tool for Java developers. We then became a tool for .NET developers and JavaScript developers. There came a point when we realized that the people who really care about our tools, and the people who we should care about, are actually the tools teams or the DevOps enablers in organizations and not necessarily the research and development teams themselves.

That was a huge pivot for JFrog. We started speaking about data centers, tooling, and DevOps for entire organizations. We basically switched our entire community in terms of our targeting. You now see us less at developer conferences, especially Java conferences. The people who we care about are now different and that wasn't an easy change to make. I felt perfectly comfortable with the change because I understood that it was the right thing to do. Our tool is much more helpful to some people today than it was 10 years ago. We need to talk to those people and help them instead.

"We need to understand what our organization's needs are and put them above our personal relationships and tech communities."

—Baruch Sadogursky

I often see developer relations people who care about their tech communities too much. They stick to those communities, even if they move to companies that should target different communities. I'll give you a hypothetical example: say some-one was working for a company that does tools for Java development and now they're working for a new company that does tools for JavaScript development. At the next Java conference, you see that they're there with their booth again. It's not because this is what their organization wants: they just feel comfortable in their old community and building relationships in a new community is hard. That's a mistake. We need to understand what our organization's needs are and put them above our personal relationships and tech communities.

Geertjan Wielenga: Another difficult situation is when the company that you represent makes a decision that the community doesn't agree with and you're on stage on a Monday morning receiving questions about this decision. How do you handle that?

Baruch Sadogursky: That's a very tough spot to be in. That goes back to the question of how much we care about what we do. There may come a point where you have to say, "I can't defend or justify this decision." That's when you should leave the company.

However, there have been times when although I didn't 100% agree with a decision, I still rallied behind it because I understood why it was made. I can live with that. It's like every other leadership situation: you might disagree during the process of making a decision, but once that decision is made, you're either behind it or you watch that the door doesn't hit you on your way out.

This is our world in developer relations. If you're a developer and you disagree with your boss' decision, you will be grumpy for the rest of the day and that's pretty much it. If you're in developer relations and you represent the company, you might find yourself in the position where you need to advocate for and defend a decision that you don't 100% agree with. Your integrity should step in and you should decide where to draw the line.

Geertjan Wielenga: Do you need to know everything about a subject to get up and talk about it on stage?

Baruch Sadogursky: As I mentioned, a developer relations person can be non-technical, but for developer advocates, the more technical they are the better. How technical you need to be depends on the nature of your product and your company.

You need to be extremely technical if you're advocating one product and you need to dive deep into how this tool works and what the use cases are. On the other hand, JFrog's tools integrate with over 25 different tools and programming languages. There is no way that I can be proficient in all of them. I do my best to keep track of the principles of how they work, but that's all I can do. We have communities that we see as being more valuable or worth the investment of our time, and they are where I dive much deeper, but still, it's impossible to know everything about everything. T-shape is the best I can hope for—broad knowledge with deep specialization.

Geertjan Wielenga: What happens if you're giving a talk on the stage and you get a question at the end that you don't know the answer to?

Baruch Sadogursky: The right approach is to be very honest about it and just say, "I'll have to come back to you on that because I'm not sure." Alternatively, you could pretend that you know more than you do. Sometimes that works, but I'd say that it's not worth the risk of being caught.

Geertjan Wielenga: Might another option be to open up the question to the audience?

Baruch Sadogursky: That's a little bit dangerous because you don't really know how to validate the answer. Someone might say something that sounds like the right answer but is wrong. You would have to endorse it or not endorse it, without knowing the answer yourself.

Geertjan Wielenga: What are some current developments that you find very interesting in developer relations and also in tech?

Baruch's hot topics in tech

Baruch Sadogursky: As we discussed, more people are starting to understand what developer relations is and how to do it right. I track those developments as part of my professional growth as a developer relations specialist. I try to go to all the DevRelCons, read the books that are available, and participate in podcasts and conversations.

"We have the ability to evolve software all across the board at a velocity that we've never seen before."

—Baruch Sadogursky

One of the most exciting areas in tech is accelerating the continuous delivery of software and migrating from continuous delivery to continuous updates. We have the ability to evolve software all across the board at a velocity that we've never seen before. That's exciting because this proliferation of software at a previously unseen speed is something that is extremely important for the world today. When you try to think for a second of something that exists in the modern world that isn't powered by software, you can't. Our ability to ship software has become critical.

Geertjan Wielenga: Do you see software writing itself, delivering itself, and updating itself in the future?

Baruch Sadogursky: The writing itself element is the most problematic of them all because the domain is not easily automatable. Business problems are, at least at the moment, too complex for algorithms to solve by themselves.

Building and delivering are easily automatable, but they will be even more automatable in the future. I don't think that needing to write software is going to go away. I definitely think that the other aspects can be minimized to a level that we see in elite teams, where a team of five people can take care of building and delivering software for a huge development organization.

Geertjan Wielenga: What advice would you give to anyone interested in entering this field?

Baruch Sadogursky: There is a lot of knowledge out there today. Blogs and newsletters are great places to start. There are podcasts like DevRel Radio too. The first step is to decide what your function in developer relations could be. This doesn't mean that you will end up doing only that, but it will give you a clear starting point.

Geertjan Wielenga: Thank you, Baruch Sadogursky.