Head of DevRel
Roku
DevRelCon New York 2024
Gene Chorba explores the nuances of managing partner-focused DevRel, emphasizing the strategic value of building deep, high-tier developer relationships. He discusses the importance of exclusive collaborations with top partners, which help drive innovation and ROI while benefiting the wider developer community.
Gene also shares insights on balancing these high-touch partnerships with the need to keep broader ecosystems healthy and engaged. This approach, he argues, is essential for long-term ecosystem sustainability and impactful DevRel programs.
Gene: Hi everybody. Thank you for joining us for a talk about partners, and this is about navigating some DevRel work that we do, which involves partners or deals with private ecosystems, partner ecosystems, more limited ecosystems that are out there in the world. But before I get started, I’ll kind of want to talk a little bit about my bonafides. Hi, I’m Gene Chorba. I’m the head of developer relations at Roku. I started my career as a software engineer, but then about 12 years ago I moved into developer relations in developer relations. I’ve done a different few different jobs. My main career has been at Ionic. I was a DevEx manager. Then at Riot Games I led our developer relations all work there for five years, and then for the last three years I’ve been at the head of developer relations at Roku. Through all this, I’ve also done a lot of developer relations consulting with enterprise companies and people who are doing big infrastructure work.
So we’ve got stuff like Delta, Home Depot, Goldman Sachs, the defence industry using DARPA, secretary of Defence. I’ve worked with them, Warner Brothers and et cetera throughout my career. But this talk is really going to focus on kind of where you can do more in smaller places where it’s like, how do I do more with these high tier partners and high tier developers and how the work you do there will then trickle down and help a broader ecosystem of people you’re working with. But before we get into that specifically, I want to talk about what I feel like as the eras of DevRel and how we’ve kind of expanded and different things that have changed for DevRel as it’s grown. Those really are like the early two thousands, late two thousands to early 2010s, mid 2010s late 2010s and now the early 2020s, and I’m very excited to see what happens after that.
In the early two thousands, we saw the open source era. This was a big shift from the closed proprietary tech that had existed in the 1990s and even sometimes into the early two thousands where we had these big infrastructure or monolithic systems that didn’t want to share, didn’t want to integrate, didn’t want to do whatever. You hired IBM because you didn’t want to screw up, you didn’t want to get fired. There was a whole tagline, you don’t get fired if you hire IBM. But we moved into these more open community driven innovation systems where Source four launched as the really the first web-based repository for sharing code. You had the Apache Software Foundation, which has pioneered the concept of open source software development. You have the Linux Foundation, obviously just like everywhere.
Mozilla did a lot of their early work in that time, and this really was a time of like, oh wait, openness is available for all of us.
Then late two thousands to early 2010s, we moved into the API revolution. This was from a move from general community where it was like, Hey, everybody, join, join, join. Let’s build to moving towards API centric developer engagement. People were building companies just off of APIs. This was the launch of the Twitter API that happened as the first major social API that was launched. Then a year later, they had the Facebook platform social graph, API, which led to a boom in social gaming apps led to games, apps, all sorts of stuff happening over the platform led to some later down the road political destabilisation. We don’t talk about that. Twilio comes out during this period of time, Stripe revolutionises payments, and of course we got AWS. So we moved from having to have all these tech, you had to have all the hardware and build your stuff from scratch and have a rack mount and all that stuff to be able to do anything to these worlds where it’s like I could spin up a project, I can spin up something at any point in time and really be open.
Then we got the mid 2010s, and I call this the developer experience era. This is where we really started to focus on developer journeys, user experience, how you’re going to really make it the most effective way to use your product and for people to learn and be able to do things. So we went from quantity of developers to the quality of the developer experience and things like the Slack API has set new standards around developer friendly documentation and how to integrate it with different things. You have Stripe really taking a lead here for raising the bar in the gold standard even today sometimes for clear, concise, interactive API documentation, you have TwilioQuest, which started to launch during this time, and that’s a really great way. And the first time we saw gamification of documentation Docker with their containerization meant that everybody could start off at the same place and you didn’t have to do these big complex setup process.
We could always just, we’re all in, we’re going to start working. We have the same systems for everybody. And obviously GitHub was this great learning and education place where there was, they had learning labs, they had systems in place for you to start learning. Then in the late 2010s, we went into data-driven DevRel, and this was all about the move from intuition. We think that’s working to really data-driven DevRel strategies. We really needed to be able to understand exactly the tactical reasons. We were doing certain things and we saw certain things go away and certain things grew in the industry as part of that. But it became part of when DevRel became a strategic business function at companies. As we continue to grow, as we continue to mature as an industry and we became a core delineation or vertical in many companies, it’s like, okay, what’s your DevRel strategy?
What is that line up to with your profit loss smart systems? How are you going to talk about this in your investor letters and stuff like that? So it was a very big important step for us to take, and I’m really glad we got there now, at least for a lot of companies, we’re seeing this partner focused era. In my mind, it is a shift towards there’s still these open ecosystems, but they’re and broad ecosystems to support. But there’s also this very important and even more focused strategic, high value developer and partner work that’s being done because that is really what’s paying the bills for everything else, and these co-creation, innovation and different systems allow dev teams to continue to expand and continue to be very important for the growth of a business. But with everything, there are challenges as we’ve moved into what I call this partner focused era, we’re dealing with the balance of exclusive partnerships or exclusive access or tier to access versus the broader ecosystem health. In the past, everybody kind of got to see everything you all were sharing. It was all part of the same community. But now we’re seeing where it’s like, okay, are you part of that tier or are you part of that tier? Are you part of that tier? And you have to manage how you’re going to deal with partners and developers of all tiers and keep everybody happy because if you let one stagnate, they’ll all die.
Let’s talk a little bit about traditional devel versus more partner and tier, tiered focused DevRel when it comes to your primary audiences for DevRel with traditionally how this has worked, it’s like broad developer community, broad communication to everybody. We’re all talking, everybody gets information, but when it comes to more of these partner focuses, you really are focusing at these high tier developers and you’re trying to figure out what’s making things move for them and what their problems are. And so all of these different categories right here, the audience, the access, the content, the metrics, the depth resource allocation, they all really fit into this space where when you’re doing content, normally you’re doing these generalised, Hey, what’s the thing we should write about that’s going to help the most developers? Impossible. That’s not the focus here. The focus is here, how do I solve a problem for a specific set of partners and then that can ladder down to everybody else and we can fix that as well.
So for example, Roku, we have maybe a Disney or an NBA or somebody comes to us and it’s like, Hey, we really don’t understand how this payment system system works. Okay, well, we should probably put content around the payment system refresh. We maybe do a webinar, we can do some content, we do whatever, and we’ll invite everybody else to include in those. But those are being built specifically because that high tier partner needs it and that high tier developer, because they’re driving more revenue, they’re trying to more business focus for us, which allows us to then fund our team, do more stuff for all other types of developers. And all of this is similar when it comes to relationship depth. When you’re doing more traditional, you have this broad, almost like a line where it’s like you’re meeting as many people as possible. You’re trying to build these relationships with everybody, but they’re not that deep.
It’s like, oh, I know your name, I know where you work. I know little bits about you. Maybe there’s a few that are, I know more and stuff like that. But when it comes to more partner and high tier, you need this, I’ll steal from engineering T-shaped relationships where it’s like you have these broad relationships with everybody still, but those top level people who matter, the people who are doing the open source projects, the people who are really moving the needle for your company, you have to have deep relationships with what’s going on there. You need to know what they’re feeling, how they’re feeling, how you can have a relationship together, how you can really be mutually beneficial as much as possible. And so the resource allocation follows that as well, where when you’re dealing with everybody, you can’t give the special attention to someone. So it’s about giving special attention to one group that is potentially providing more value, but still not ignoring the rest of the community to be able to do more.
So why partner focused DevRel? Why deal with these high tier devs and these partners and everything we do? Well, it’s increased ROI. If we’re able to turn someone who’s already big on our platform or big users or are building awesome stuff into even bigger, it’s probably just an effect of, Hey, this growth is even more. It’s going to be a lot harder in a lot of ways for us to go from zero to 20 with a bunch of different people than to get someone from 50 to a hundred if we’re focusing on them completely. So we might get them to adopt new tech integrations. We might need to be able to get them to adopt new payment systems. We may be able to co-development. We may have new open source projects, we may have all of these things, and because of this, we’re able to also do deeper integrations and early access and very things like that with strategic partners.
So this means that when we’re launching a new feature, we can do an alpha and we can be like, okay, well who are we going to choose to test with this alpha? Well, because of privacy, security release issues, we can’t give it to everybody. We can’t just be like, Hey, give us our feedback so we can pick one of these bigger high tier developers and be like, Hey, give us all your feedback. And as we’re working with them and they’re getting that feedback, we’re in this co-develop mode mode of like, they’re like, oh, well we want to use it this way. It’s like, oh, we didn’t think about it that way, but we can do that. And so the tools that come out don’t have this huge cacophony of people just like, I want to go this way. I want to go this way. It’s the people who are already building the most successful things on your platform, giving you the advice of like, Hey, this is actually how we need it.
And things are more tailored and targeted for you. And so you get these deeper integrations as well as the control and security because sometimes you can’t give certain people things. We’ve released products over the years and all of the companies I’ve worked with where I didn’t realise I just unlocked fraud or I just unlocked various things that people are going to do that were going to be malicious. Not to call out any specific company, but I got a letter, a cease and desist an hour after I won a hackathon for a payment system and then their legal system team sent it cease and desist. I built a money laundering app. I didn’t realise I did that, but I did. But in a tiered access programme, you probably don’t give access to that type of technology to a random dev off the street. So it’s really important to do these things, especially when you move into IP control where I’ve worked in a lot of entertainment startups, a lot of places like banks, a lot of places where they’re really, really care a lot about not having their competitor have their information.
So talk about some of the advantages of this type of thing and where it sits for everybody. So for your company and where you work and where you’re doing DevRel, it’s really about accelerated innovation through these strategic collaborations and being able to work with them as much as possible as they grow and you grow together because a mutually beneficial thing we’re doing, it’s not just about you as a company doing, you have to be giving back at the same time. So it’s like you get that increased market penetration, you get the increased development, everybody doing things and it’s increased product offerings and stuff on the other side for the partners, they get these great co-marketing opportunities to be able to grow and do things and it’s like, oh, I get opportunities to try things nobody else does. So when this goes to market, oh my god, there’s only going to be three devs on the planet that have access to it, so I’m going to get the users and I’m going to be able to keep doing stuff.
And it drives that interest to continue developing, to continue being involved with everybody and deeper integration. I talked a little bit a while ago about how we can do these early access programmes, how we can do do more about what’s going to help other devs as much as possible. And for the ecosystem, there’s these clear pathways of like, Hey, here’s how you go from your generic general dev working on our platforms working out there. And then there’s tiers of here’s how you grow and are you do things like are you a paid customer? How much revenue are you generating for the platform? Are you bringing this many customers on the platform? Things like that, which will continue to increase your value to us or are you, on the other hand, there are people who bring absolutely no revenue to the platform at all. Are you an open source dev that is doing really cool things that are really pushing our platform to the next level? Well, how do we get you in the room and talk to you and get access to you more as well? And this makes a more sustainable developer ecosystem because the money that is being generated and being attributed to DevRel by doing these high tier engineering work, product work and really onboarding business to the company means that that money is like, okay, we’re going to be going. We will go to you and be able to do more there.
So how do you identify and select your tier one devs and partners that you’re going to be working with? Well, these are kind of some of my criteria that I use when I am trying to figure it out. And I’ll say of all of these, the most important is cultural fit and shared vision. If they’re not culturally going to align with you and you’re not going to agree with them, you’re going to have conflict, you’re going to not agree or they’re going to be mad at you because you go with a different partner for a certain early access thing or they’re going to be very mad that like, oh wait, why is that person team A get that? And I don’t get that, but I get this. But they don’t get that. And it creates these animosities. You really need to be complimentary on what services are being offered and what tech things for different tools and stuff like that.
But market influence is huge. If you’re building a new tool, building a new OS open source project, you really want that people who are going to have the most reach and get the most adoption through it because it’s so valuable. But the potential for mutual growth, like, hey, if we work with this open source team and give them access to this API that nobody has, is this API tool going to blow up and then help so many more devs and that means they’re going to get more funding and we’re going to get this beneficial knockback effect. On the other hand, it’s like, oh, that’s a no brainer. Let’s go do that type of stuff. And really just being more strategically aligned with our goals is really important at the same time.
But to do all this, you have to have the programmes in place to limit and do tiered access. And most developer programmes don’t have these right now we’re seeing more and more of them. There’s the very basic ones are paid versus non-paid, but or maybe it’s like you’re in this sign up for specific software system versus another software system, but we need to expand these more into different tiers of what’s going to happen for different people. And so you’ve got your public API or public SDK with documentation that’s happening there. Then you got your registered or verified developer, which is going to have a little bit of enhanced support, enhanced endpoint maybe where it’s like you get access to something that the general public can’t get access to. And then the premium, the partner, the high tier people who are like, you’re getting exclusive APIs, exclusive SDKs, dedicated support, co development, innovation, early access, all those types of opportunities, which will allow someone to really do a lot more.
And then when it comes to implementing these, it’s really important to define the clear criteria and benefits of each tier for a developer to be able to really be part of these, how do I go from, I’m this guy that I want to be over here, but I’m here, how do I do that? And you want to be very clear. It’s like, okay, well let’s talk about it. It’s like, well, you have the path of being able to go down the path of being an open source developer or go work at this big company, or you start your own company or what are you doing? And we can work together to make sure that you get as much as you possibly can, but you need to have the technical infrastructure as well to be able to do some of this automated for automation and tracking and metrics, so who’s actually being valuable and providing value.
And then you have budget to be able to do things because of that. And then lastly, you’ve got to balance the exclusivity and the ecosystem health. You have to main some level of public access to foster community, to developers around the world who are doing things. And you have to be there. And occasionally you ask a question, you answer questions. Occasionally you’re in there, but it is definitely more valuable for you to spend more of your time with the high tier of valuable people, but you have to do more and you’ve really got to regularly review and adjust your structure based on feedback from the ecosystem. Our people who are just getting started feel like there’s so left behind or so many resources aren’t there. And you’ve got to really work and understand where you are and be flexible about it because it’s really important.
If you do not balance exclusivity and ecosystem health, you’re going to kill your programme and then you’ll have to restart. You’ll hopefully have time, hopefully aren’t fired, but you’re going to be able to do it. And you have to maintain this level at all times because we are not in the business of just completely locking everything down at all times. There may be specific features that you can lock down and make completely private, but at some point you’re going to have to open things up so people can play in that sandbox. So let’s talk a little bit about high value partnerships with developers and companies that you’re going to do through DevRel. So there’s a bunch of different types of partnerships and you can pick them based on like, oh, I want to do it for this period of time, or I do it with this type of industry and various things like that.
So you’ve got your platform specific, so it’s like, oh, am I trying to be on a tv? Roku would be example of a platform specific type thing, or am I trying to do something that’s more industry specific, I want to work in medical or I’m working in finance or I’m doing these types of things where I’m finding developers who are building things for those specific things or innovation partners. We’re seeing this a lot with AI where it’s like, how do we partner with someone who’s of awesome AI dev to give them early access to the tools so they can try it out and we can learn everything we need to know about those types of things and go to market partners on like, okay, we’re spreading into different regions and different products and how do we get those people to be able to adopt our new stuff? And these all have to be done with the strategy of you need to really be collaborative at all times. And I’ve listed a few ways to be collaborative and to work together, and it’s meetings, it’s partners like account managers, it’s all sorts of people helping out for you to build, able to do a lot of stuff. And it’s incredibly valuable and it can really push your company to the next level.
But all of this requires measurement. It requires you to know what you’re doing and needs to know the performance of what’s happening because it’s so important. So when it comes to partner satisfaction, I’m a big fan of a net promoter score to understand how those high tier partners are really valuing what you’re doing and everything like that, and your retention rates, how many people are churning out of your ecosystem on a developer perspective, on a high level and at the highest tier, how many people are staying, how many are growing, what is going on that and what is their engagement with some of the exclusive resources or support they’re getting? Is it being valuable to be part of those things? Business impact, I’m sorry, technical integration. That’s another one that’s really important where it’s like what’s the API call volume? What’s the SDK usage? Are we seeing adoption rate of new features we release for people to be able to use?
Is there a number of integrated special solutions that you’ve worked on that have been successful business impact? What is the revenue generated through these different partner and high tier developers that have come through? Are there market share growth because we’ve decided to do these things and then how many joint customers have been acquired? And this is more specific for platforms, but if say Roku, we partner with someone on a new feature and they launch it and because of that feature they add 50,000 new subscribers and they’re using our products, it’s like, well, we jointly now have added 50,000 products to the platform and that’s a mutually beneficial thing we’ve now done and it’s a valuable thing there. Then innovation metrics. So this is a big one about how quickly are we going to market, how quickly are we doing contributions, how much are you helping us improve our product so that we can help you do more and the general developer ecosystem can do more.
Lemme go into two case studies real quick. So one here is Roku. If you don’t know us, we’re basically the dominant TV brand, NOS here in the United States. And we are basically a large amount of the TVs you use, but we do TVs, we do iot, we’re big ad systems and we do a lot of hardware, but we’re a developer-centric ecosystem. But because for us for people to develop for Roku, they don’t necessarily just have to build an app, they also have to have content into that app. So while we can acquire as many devs as we want, teach them all how to build Roku apps, if they don’t have a content or something to put onto that app and put it on the platform, it’s kind of not useful for them. So this is where a lot of the strategy of like, okay, we’ll focus on the people who have content and find them engineers to work with and do various things around.
That has been very helpful because we have our Roku developer programme, we have our advertising framework, we have our Roku pay, our open source programme, and very much other things to be able to do a lot for these developers, but we do have this tiered engagement system where there’s this public SDK public documentation and open access to anybody could join and they can go learn these programmes. But then there’s these premium, larger and larger programmes where it’s like, okay, well you’re this, we need to give you that much access or you get access to this because you’re in this region or things like that where we need to continue to work with them and continue to grow it as much as possible. But it’s really all about, hey, taking what is working with these high tier partners, high tier developers, and trying to make it as available to everybody else as well, whatever learnings we get out of it, whatever we find from it because it’s super valuable.
Next, I’ll talk about Riot games a little bit. Riot games, if you don’t know, they’re one of the largest video game companies in the world. They’re funny enough based in Santa Monica, but most of their players are outside of the United States. They’re one of the rare where it happens where an American game company is more popular abroad than it is in the United States, but they look at developer relations and their developer ecosystem, not like most for them. Developer relations and developer system is not for them to really make more money at all. It is purely to benefit players and to create ecosystem enhancement. So they have these games, they have sharp corners, they’re hard to play, they’re very difficult, but riots like strategy actively encourages third party tools and applications to enhance the overall player experience. And as they do this, they find the good experiences that teach people how to play better.
They coach them their apps, their tools to bet on performance or improve what you’re doing. And as those things develop, they recognise them, they co-brand them, they give them resources to be able to do more, and so they’re elevating them to more players are able to use them, but they give them increased access because they’re like, okay, you’re not cheating, you’re not abusing this system. And it’s still fair for everybody in the EEC system to use it. Okay, well let’s give you more access that would otherwise might be used maliciously to do other things. And they’re able to do these strategical, be very strategically aligned with people who are like, I want to make better player experiences. And they’re like, I want to make the best player game. And so together they’re be able to build this really interesting developer ecosystem of companies that are making money and developers who are making money building interesting gaming tools, but the company doesn’t want any money from it.
So as we start to wrap up here, I want to talk a little bit about some of the common challenges with this type of strategy. So number one, top of mind is resource allocation. Balancing the support between tiers of users and tiers of developers as you’re building your developer programme around this is really, really tough. And it continues to be something that you’ll have to monitor constantly because it’s so easy to fall into the, Hey, I’m only going to talk to these devs because they’re bringing in a hundred million dollars or whatever, and I need to balance that approach constantly. So scalable support, clear resource allocation guides and where is it going to go is super, super key. Conflicts between partners will happen, but it’s really about partnership agreements, complimentary ways of working with each other. Hey, maybe choose one for this one. I got you next one, figuring out how it’s going for these various people.
And then ecosystem health, you’ve got to avoid that over reliance on a few partners. You’ve really got to spread out the wealth to as many people as possible and maybe this early access programme you’re doing for this product, cool, you’ve got those. Maybe it’s so easy to be like, okay, well they already have experience, let’s do it again. It’s like, well, maybe we can bring someone else in new and make a valuable contribution to this and swap through as we can. Internal alignment, because you are doing so much more co-develop things or getting feedback a lot more at a higher level, and you really want to implement that and develop the tools these people want, you’re going to have to have a lot stronger relationships with your engineering teams, your product teams, people who are making strategic business decisions, operations and everything, et cetera on both sides to make sure that these things continue to operate and are doing well.
And lastly, scalability. These can take off, they can really do well, but you’re going to run out of resources real quick. It’s one of the things we struggle with where it’s like, how do we do more but maintain what we currently have? Because you need automation, you need self-service tools and gradually expand as you can and argue for additional resources. So quick key takeaways, partner focused and high tier developer relations. Focus drives revenue, it drives business value. It really pushes more and more money towards developed relations. And you get attribution for it, but it doesn’t work for everybody. So don’t just, Hey, go do this. We don’t know.
It’ll work for your programme, but tiered access does. So I would go look at it, go see if it makes sense for you and work with that as much as possible and measure and really communicate the impact of what you’re doing internally, externally, to partners, to engineers, everybody so that they understand the value that’s being done where you’re going to get your basically resourcing to help as many developers as possible.
And then lastly, next steps. If you want to do this one, feel free to reach out, happy to chat about this anytime. Added my Twitter at the bottom, but I’m also just gba at any Roku, gmail, whatever it is. I’m happy to talk to you and then figure out if you’re want to develop a third party model for you to be able to do this and assess your Dev Rel strategy if you’re doing it. Because a roadmap of cultivating and growing strategic high tier developer work could really benefit any company, but you don’t always have to do it fully structured. So thank you so much for listening. And I think I have a little bit of q and a, but yeah,
MC: You sure do have a little q and a. Does anyone have a little Q? Any little Qs? Big Qs? Yeah. All right. Wait, is it a little Q or a big Q?
Audience member 1: Just a little Q. Little Q. Like little awesome presentation. The history walkthrough is just spot on. Curious within the context of Roku, this feels like this was an evolution, so I’m curious what was happening before and what was the catalyst for Roku building this out?
Gene: Yeah, honestly, a lot of it was there. When I joined Roku, it was a partner focused org because entertainment, but I brought a lot of, we did similar things at Riot when I was running that programme where it was like, cool, we have these people we trust more. How do we do that? And so I think every dev programme has a few devs in your community where it’s like, I trust those people more than other devs. And so it was a big thing for us of like, oh, how do we do this? The left, there was a lot of lessons from DevRel that I brought more into the entertainment space of like, Hey, I know you have all these contracts and you do it more partner business wise, we need to think about this as a developer business as well, where it’s like, okay, you may go try and sign this contract, but we have to say that that’s physically even possible or build a lot of work around, Hey, how does someone innovate or bring in, they didn’t really have, how do we do early access development or how do we do providing people limited access to certain things?
And about three years ago we started doing that. Yeah.
Audience member 2: Hey Gene, good presentation. Lots of good detail there. In some of the experience that I’ve seen now, it’s a bit different where some of the larger companies have had these partner programmes for a long time, the dev plus companies, and now they’re trying to figure out how to be dev first companies and branch out to larger companies, and there’s a real cultural shift that needs to take place. That’s hard. Any thoughts there?
Gene: Yeah, no, I’ve seen this. I gave a talk at, I was at AppNexus I think, or something like that because they lost a plot where I was kind of saying where it was very focused on these high tier developer accounts and they forgot about the devs. And so the balance, that’s why we’ll Hammer constantly is like, you’re doing this so you can pay for the other things. But they brought in a lot of people who are very much strategic account managers or here’s how you do business growth. And it’s building just those people ignoring the tier twos, the tier threes, the long tail developers out there that will provide value eventually. And so you can’t ignore them. So I will literally quit a job if they tell me, Hey, you can’t support general developers because you’re cutting off that ecosystem.
Audience member 3: Hi, what is the biggest risk and the biggest opportunity when implementing this kind of approach?
Gene: Biggest opportunity from my view is that you get actual, you get more targeted feedback from your highest level users, what matters the most to them. These are the people who are using it every single day. And they’ll tell you something like, Hey, this takes 20 seconds every day of my life. Can we remove that? And it’s like, well, that is a huge quality of life happiness thing for any level of developer, but for them it’s so much more impactful. And then it bleeds down to a lot of different people. We have a bug right now that is affecting our entire developer ecosystem that is basically like it’s signs you out of the developer portal randomly. We’ve been trying to fix it forever, CSS or something broke. But because of that, it’s this real big struggle around, okay, well do we prioritise the work to fix that because is this delay in time or do we go do these other bigger engineering projects we need to do and get stuff done?
And it’s tough to balance those and it’s going to be a gut check each time. The biggest risks I think she mentioned was really it is like if you lose the focus and you lose the plot and start not thinking about developers and you start thinking of ’em as just money and you just think, okay, well just put the money where the most value is only there and that stuff doesn’t percolate elsewhere, then that’s not going to work. If you’re going to build a tool, why not give it to everybody else? But some companies don’t want to do that.
MC: Any other bigger little Qs, arrays. Alright, Gene, thank you so much. Thanks so much. A big round of applause.