Made by
Made by
Director of Product Management
Sisense
DevRelCon London 2023
In this talk from DevRelCon London 2023, Moti Granovsky addresses the complexities and lessons learned from steering a company towards a developer-centric approach. He recounts the process of reorienting the company’s priorities to place developers at the forefront and provide tactics to overcome hurdles like accumulated technical debt, conflicting priorities, internal uncertainty, resistance to change, and gaps in technical knowledge. Moti underscores the value of drawing on the insights of in-house developers, soliciting feedback from outside the company, pacing the transition carefully, and dedicating resources to empower and enable staff.
Matthew Revell:
For our next speaker. He was the first DevRel person at Sisense. He’s now director of product management. We have Moti. Grohovsky. Let’s give him a DevRelCon welcome.
Moti Goranovsky:
Hi everyone. I’m fairly excited to be here. Finally, in person, I did DevRelCon 2020, but as you all know, it was not done in person due to a certain pandemic. So I want to tell you a very short story of something that’s happening in our company that I think might be of interest to a lot of you. Imagine that you find yourself in a position, you’re a DevRel in your company. Maybe you’re the only DevRel like I was. And you all know the struggle, the burnout, everything. You’re trying to push for recognition, for leadership support, for budgets, and you kind of do that day to day. As you can see, I’ve been in the company for 10 years. I started being the first DevRel about six years ago, and one day you wake up and you find yourself in a new reality where you’re no longer a sideshow in the company. Suddenly the entire company is shifting to become developer first and developer experience developer relations, developer advocacy become the company’s maybe not primary focus, but one of its key goals. That sounds really great, it’s really exciting, but I can tell you from experience, it’s also scary and it’s very challenging. And this is a process that we’re going through right now, and I want to share with you some of the insights that we’ve gained and some of the things we’ve done in the past few months as we’re kind of moving through that transition.
So first, a bit of background. My career at Sisense has been pretty long, and it’s been pretty much on the same trajectory as the company itself. We started out as a self-service BI platform, and over time kind of organically we grew into the embedded analytics market. Now, when you talk about embedded analytics, there’s obviously developers involved because you need to white label, you need to customize, you need to extend, you need to embed. There’s got to be a developer there, but the developers weren’t the kind of primary audience that’s still the analyst, the BI users and the developers are there to make things happen. So as a company that started with self-service for business users, obviously we had to make some product changes. We needed to build some APIs, we needed to create some sd, and we’ve done that. But because developers weren’t our primary audience and we weren’t really focused on this audience, and we didn’t really know what we were doing because we’re a small startup back then, we kind of hacked it together.
We released a few public rest APIs. We built a nice JavaScript library for embedding and kind of trudged along. But then essentially what started happening is that developers became more and more and more involved in the sales process. They became decision makers, stakeholders, they could veto the decision to purchase our product. So obviously we started focusing on a bit more, giving them more attention. Let’s build a developer portal with better developer documentation. Let’s upgrade our APIs, make more APIs, public, things like that, and still developers aren’t the primary audience. And then as that grows and the use cases where developers want to do things with our platform increase not just in volume but also in complexity and creativity, we find ourselves kind of always trying to catch up, right? Developers come in and they say, we want to do this thing, we want to do that thing.
Is it possible? We say no, but we’ll give it a try. We accumulate a huge backlog and we keep on trying to catch up to this. And then again, one day we’re starting to talk about developer first, and it took me a little bit of time to actually kind of get to grips with that. I’ve been in the grind for so long that I didn’t actually think this could happen. I didn’t think that it was possible that a company that was not developer first originally would become one. But what happened is, at least one of the kind of drivers for it was that we got a new CEO and the new CEO comes from a tech background and heard kind of what we’re doing with developers, and he said, this is the future of the company. This is what we should be doing. And all of a sudden if you’re in that position, you find yourself kind of in a spotlight that you’re not used to.
So let’s talk a little bit about some of the challenges that can bring. So I’m going to focus on five specific challenges, and I’ll run through them fairly quickly, pretty obvious. I think the first one is technical depth. It’s kind of a big umbrella term, but essentially, if the product was not built with developers in mind, and now you want developers to use that product as a primary audience, as your primary persona, the product’s probably not going to fit that, right? So you’re going to need to make a lot of changes to the product to make developers happy when they use it because it wasn’t originally built for them. The second one is competing priorities. We are a large company. We have a lot of customers and a lot of revenue from those customers, and obviously we’re not going to shift away from that. We want to add developer first to our product strategy.
But now certain people, including myself as now a product director, are kind of feeling torn apart. How much time do I spend here? How much time do I spend there? What happens if there’s a conflict of interest between these two needs that don’t always converge? The third one is the kind of confusion that this creates within your organization. You are not alone within your company. You have marketing and sales and support and finances and a lot of other functions within the company that have been working on non-developer audiences within their respective roles for years. And all of a sudden you’re telling them, Hey, there’s this new audience and they’re completely different. You all know that developers are a fairly unique audience and people are confused by this change, confused by those conflicting priorities. And also often they have misconceptions about what does it mean to be developer first. They’ve never heard that term before.
The fourth one, which is very related to this one, is fear of change. Generally, people aren’t always as receptive to changes. We’d like. People are afraid that maybe their jobs will become irrelevant. People are afraid that it’s going to become harder. They start asking themselves, well, I’m not a developer. How am I supposed to sell to developers, support developers, and so on. So there’s obviously fear of change. And lastly, domain experience and expertise. Now, all of you are the main experts in working with developers, but like I said in our company, we had excellent people who really knew bi, really knew the analytics market, but didn’t necessarily know how to work with developers. And you want to make this strategic shift in your company, but you need some skills for that. So let’s talk a little bit about some of the things that we’re doing right now to try and mitigate these challenges.
So number one, obviously we had technical debt. We need to solve it, so we need to work on our product. As an example, on August 1st, we’ve released our first significant SDK that we’ve built. It’s still in beta. I’m very proud of it. You can go on Sisense dev and check it out, but it’s a huge ganan effort. It took us about a year to build it, and it’s a huge investment in this direction where we are actually trying to prove to developers that we have them in mind and we’re building things for them. The approach we took there is very different from what anything we’ve done before. We put developer experience at the top of the priorities. Anything else, including functionality, takes a second place. Another thing, since we lack some of the domain expertise is let’s find external consultants. We’ve engaged with the few people, including from this community, who are really experienced in building developer products and API first product and ask them for input and feedback.
I’ve got to say, I’m really happy about this. We got really positive feedback and really encouraging feedback on product direction that we’re taking and some of the decisions that we’ve made. Training and enablement is a really, really important thing to mitigate both the fear of change, and again, that lack of expertise. You can’t always remain with external consultants perpetually. You’re going to need to upscale your entire organization in order for them to be able to succeed. So you really need to focus on enablement. Ownership and structure is important to treat those conflicting priorities where you need people to know what their main focus is, what their KPIs are, so they don’t get that feeling of being torn in half. Leadership backing is super important. We got really lucky because our CEO is the one who pushed us in this direction. He’s been incredibly supportive of that.
He’s been sending weekly newsletters, writing blog posts internally, really kind of sending a clear message to the entire organization that this is what we’re doing, this is why. These are the challenges we’re going to face. It’s really, really important that you have the backing of your leadership and of course, balance and assurance. We’re talking about adding this new audience to an existing audience we have. We need to make sure we don’t hyperfocus on this new thing and drop the ball on what we’ve been doing so far. It’s really important to show that balance. Now. Lastly, I want to leave you with four takeaways that I think are the most important. There’s obviously a lot of caveats and stuff like that, but basically if you find yourself in this position, these are what I believe are the four most important things that you need to keep in mind.
Number one is use your own devs. One of the big benefits of being a software company that is developer first is that your audience sits within your walls. You have developers, they have the same preferences, the same behavioral patterns, everything like your target audience. So start by talking to your own developers. Ask them what they want, what they like, and use that as your initial kind of seed input. Second, beware of biases. It’s great to have that internal input, but everyone working for the company has biases. So make sure that you take that into account. Get people from the outside, customers, prospects, consultants, whatever that may be, community to give you input and validate what you’re trying to do. Take it slow, don’t rush it. It’s not going to happen overnight. You need to give people time to adjust to this change and invest in enablement.
I’ll repeat that over and over again. Invest in enablement, help your people ramp up into this new reality. Now, before I finish, because I’m out of time, just keep in mind we are obviously still in this process. We’re not done, and I cannot pretend to be an expert on how to do this, but if you find yourself in this position, or for example, as a DevRel looking for a job, you’re considering accepting a job in a company that isn’t developer first. My kind of goal here is to tell you one, it is possible that this will happen to you as well, and that’s great. It’s exciting. Two, you should think about that and be ready for it because I wasn’t. And yeah, that’s pretty much it. Thanks everyone.
