Sam Ramji is a 25-year veteran of the Silicon Valley and Seattle technology scenes. He led Kubernetes and DevOps product management for Google Cloud, founded the Cloud Foundry foundation, and has helped build two multi-billion dollar markets.
We chat to him about how you drive business growth with community.
Patrick Woods (00:00): So for everyone out there listening, Sam is being very generous with his time today. He's in the middle of an executive offsite and offered to come have this conversation with us. So you're been generous, Sam, so thank you for being here.
Sam Ramji (00:10): Thank you. It's a privilege. I love what the Orbit team is building. I love what the Orbit community is doing to come together. I think the innovative use of everything from how you've figured out how to use an open-source model to explain what is actually happening under the hood. As we think about communities with the same level of precision that maybe we used to think about buyers and customers with all the way to what you're doing on Discord. And now I get to grow and learn a little bit about Twitter spaces. So super cool.
Patrick Woods (00:39): All right. So thank you for the kind words, Sam, as always. So for folks who just joined, feel free to head over to discord.orbit.love, where we're having a chat in real time in conjunction with this live conversation. If you have questions for Sam, as we go through, feel free to drop them there in the Discord, and then I'll pull them up and ask them along the way as well. So today we're talking to Sam Ramji. Sam is the chief strategy officer at DataStax and previously held VP roles at places like Autodesk and Google. He was the CEO of Cloud Foundry, as well as chief strategy officer at Apogee. He's been thinking about leading teams and organizations and communities for a really long time. And he's also an advisor to me. And for transparency he is also an angel investor in Orbit. And we're very proud to have him on the team. So Sam, did I miss anything there in the intro?
Sam Ramji (01:25): I think you might've forgotten that I'm a super nerd and I love developers and development because it's the best job ever. And so anybody taking care of developer communities as it has a fast path to my heart.
Patrick Woods (01:36): Amazing. So Sam, this chat is called driving growth with community, and I've got some specific questions around that as we go through this thing. But before we dive in, would you mind sharing some context about you, beyond the fact that you're a super nerd and maybe touching on some of the stuff that you're working on at DataStax and maybe more broadly, how community has been a part of your career?
Sam Ramji (01:57): Yeah, I guess the reverse chronology is popular, so I'll start with DataStax. So I had been working to bring Apache Cassandra to the forefront of the industries thinking about databases. And so that is entirely powered by community in community, around community. The power of open source as this awesome positive sum game. Some people compare open source to Stone Soup. That's not the worst idea ever, but the idea that you could keep building and nobody loses knowledge in the process, everybody gains from it. Before that I worked at Autodesk, which is where I started to see how powerful Cassandra really is. We had a five petabyte system that we built out of Apache Cassandra that's powered pretty much all of the digital experiences for Autodesk's desktop software, which was connected by data that all needed to have a safe place to store it and in a fast place to achieve it.
Sam Ramji (02:52): At Google, and that was about 1,100 person engineer organization. So that's also a community of practice within a giant company. So you'll see that the consistent piece here is community. At Google I had the privilege of leading, not just product management for Kubernetes, for compute engine, for app engine, for all of the developer and DevOps products that we built, but also about 500 DevRel folks across the organization. So apart from DevRole for Google Ads, I led DevRole all for all of Google.
Sam Ramji (03:23): And that was a pretty extraordinary experience going way, way back into the 2000s. I led open source for Microsoft and was basically on point to change the company's strategy from crush and destroy and to embrace support, and stop seeing this community as other. And start seeing open source people as self. And I think that was a very formative opportunity for me. And it's certainly defined the rest of my career. So that was 2004 to 2009. So here I am, I'll be 50 in October. So hopefully to many more years of community head, but many years behind me.
Patrick Woods (04:01): Wow. Thanks for the incredible overview there. Yeah. Lots of impact, lots of context and history. You just mentioned this idea just to dive in to your experience at Microsoft, to [dev 00:04:12] you mentioned the shift from seeing open-source community as other to self. Can you talk a little bit more about what you mean by that?
Sam Ramji (04:18): Yeah. So Bill Gates was quite famous for having said open sources of cancer. Steve Balmer said open source is communism. Those are clearly very divisive statements within the culture they occupied because they were in a U.S. business culture and they are invoking images from the Cold War. So when our language we can start to create and generate hostility and lack of safety. Part of what happened there is that people at Microsoft who joined, it felt like if they were into open source, they needed to drop that part of themselves in order to fit into this big company. And as the most powerful software company in the world at the time, that really had a chilling effect, both on employees, but more broadly non-employees and non-employees who were fans, "Can I be a Microsoft most valuable professional if I'm also into open source?"
Sam Ramji (05:03): So there's the Cold War methods symbolism or mythology that it was a book by that speaking the creation of self versus other. I had a chilling effect on the whole industry. So reinspecting that and saying, you know what? People who are working on open source are engineers, they're developers. They love operating systems, love compilers. They love great, great IDEs. They're curious, we're all developers. That started to be the bridge that led us explain to Steve and to Bill and to the rest of the company. No, there's no problem here. The only problem is that you're not letting them play in your playgrounds. Linux is great. Linux is extending all these things and not today. The Linux represents over a quarter of all workloads on Azure. So this bridging and finding the ability to say, "Oh, this is a developer, I'm a developer."
Sam Ramji (05:53): We can call this person itself. Now it can have a little more trust. Now we start to play some positive, some games was at the core of the reinvention that was happening in the late 2000s. And that I think that such an Adela is Ascension has really put a finer point on it to say, we are connected with everyone when I was at Google just before I left. And the reason I left was that we lost the GitHub acquisition. So we were in a very deep process to acquire GitHub into Google, to power up our cloud and developer strategy, our platform, our capabilities, and bring them to more people. Microsoft as you know won the deal. And as they stepped into that, that was the apotheosis of Microsoft saying, "We are developers. Every developer in the world is someone that we care about and we want to be connected with."
Sam Ramji (06:40): And now they're the first $2 trillion companies in history, I think. So there's a real connection between what we used to think of as markets and war and hostility. And now we're starting to see, oh, there's community and there's people and there's growth. So there's no accidents that expanding this circle of what we call self has led to Microsoft's shift to be not only extremely valuable, but much better left.
Patrick Woods (07:12): Yeah. I'm curious about some of those topics or conversations that you were having internally to introduce this language of self versus other, how did that come to life? Thinking about like stakeholder management, internal politics, whatever label you want to put on that process, how do you do this jujitsu move, where you completely shift the framing from other to self? What does that look right?
Sam Ramji (07:37): Well, you have to hack the culture. And so this is where you and I've had some great conversations recently about what is go-to-community look like? Everybody knows what go-to-market is. What's go-to-community. So if you have a company that's got a really powerful go-to-market mechanism as Microsoft did. And still does. You have to really understand that and explain in those same mathematical, accounting, financial marketing terms, why this thing is going to change your business for the better. You can't hope that people will understand the new thing on its own merits. That's way too much to hope. Everybody's really busy. They've got their own things to do, but if you can surrender yourself and really understand what the company structure is, what people value, how they measure, what they value, and then explain your new idea in their language, then you have a hope.
Sam Ramji (08:24): So at Microsoft, we had this extremely structured, balanced scorecard, about 33 elements on the scorecard. Every executive got paid more or less based on the company's achievement against a scorecard and something that happened before I was there. And that I was able to hack was the company already said they cared about developers. They just wanted them to be Microsoft developers. We started running surveys and doing work research against developer satisfaction. There's a score that everybody got called DevTracker. So how are we doing with developers? As we started to tie that need for growth and improvement on that metric to these new ideas backed by research that said, "Hey, if you could go run PHP on Windows, people would be happy."
Sam Ramji (09:09): Oh, okay, let me tie that into the company strategy. We want more web workloads is actually a large scale company initiative to win the web, so Bill Staples, who's now the CEO of New Relic, and I, pulled together the research and created a plan to say, "PHP on Windows." He was the IIS workload, which is the web server on Windows. PHP on Windows is a great idea. Let's go do all the technical things that we need to, turned out PHP hadn't been rebuilt in 64 bits. And actually the Windows libraries hadn't been recompiled since 1999.
Sam Ramji (09:42): So there's some low hanging fruit. But we were able to create something new. We spoke Microsoft language, "Win the web workload, DevTracker, you can improve your DevTracker score by five points this year, just go run this PHP on Windows campaign. It's going to be awesome." And that was how that was the mechanism that we used. And it required a lot of humility and surrender to understanding how other people thought and then getting inside their frame to explain our idea. And that's how we did it.
Patrick Woods (10:14): Yeah, I think that's such a crucial perspective. I think about this a lot. And I think about more broadly community today as a concept is it's, getting a popularity of community builders are getting a seat at the table inside of larger and larger organizations. And this is a question that comes up a lot when I'm talking to builders at all stages. It's like, how did we get that seat at the table? "How do we get what we deserve?" As builders as I think your perspective here of approaching it with a degree of humbleness, surrendering yourself to the context of the organization, really speaking the language in terms of the company's strategy. I think there's a lot of lessons learned for all of us here about how to do that appropriately and frame the ideas and the packaging that will be acceptable to the organization. So that's really great.
Sam Ramji (11:00): Yeah. I would like to offer you something that Alison Randall taught me. She was one of the people who was extraordinarily kind with her time and her reputation because she's well-known in the open source community. And if you're on the outside of Microsoft and you were an open source community person, you really could only lose reputation by interacting with Microsoft. You wanted to stay away. But so Alison was very kind, she's an incredibly thoughtful person and she was raised by anthropologists. So despite being a deep technologist and we're all working on tough technology problems, she brought some skills from anthropology to us and sat down and had an offsite with my team. She said, "Look, there may be a useful idea here for you, which is that you are culture brokers." And we all sat up and we were like, "Wow, culture brokers, what a neat thing."
Sam Ramji (11:48): And then we're like, "Well, what do you mean, Alison?" And she said, "Well, a culture broker is someone who can be in culture A, and really get them and show up as a native there. And can then also go to culture B and really get them show up as a native there. But you are really your own culture C, which can be completely authentic in both. But you could explain them to each other. So you have to create this third culture." And I think that's really what community building with developer relations is going through right now. We've had sort of, culture A, has been the market side of the business, go-to-market sales, do all the things and B, has been the community side of the business. Here's how we talk to developers. It's real qualitative. You have to get it.
Sam Ramji (12:34): But the maturation of DevRole has got to be that we create culture C, where we can say, we can explain both sides to each other. We can use some tools from each side so we can challenge our leadership. We can talk to our CEOs and say, "How many people do you have on go-to-market? Okay, you got 150? Great. How precisely do you measure their outcomes? Okay, great. How important do you think those are? Okay, great. How important do you think community is? Oh, it's super important. Okay. How many people do you have in your go to community? Oh my gosh. Like three. How precisely do you measure those? Three, odd I really don't know."
Sam Ramji (13:15): Creating some shift there where we can create this new culture C, where you don't have to be one of us in the DevRole world to understand and value what we do. That's the maturity cycle I think that we're going through. And frankly, that's something that I think that the orbit model is a huge innovation, powering us to have a more clear, mechanical mathematical way to explain why we believe what we believe from what we're doing.
Patrick Woods (13:41): So you've touched on this idea of go-to-community. And in this chat today, you don't have talked a lot about it. And you're the person who introduced that idea to me. I don't know, a couple of months ago. So could you spend some time talking about this concept of go-to-community and I'd love to hear what are some ways that's coming to life tactically and inside of DataStax.
Sam Ramji (14:02): Sure. We began using the GTC terminology as an effective provocation to start changing how we invest. Adding more people to the team. If you want to have a great outcome with a cloud service, it turns out people want to use it and then they'll pay for you if it's valuable. So it's a lot like open source. It's very hard to get people to pay you to try something. So we know that adoption is the path for all of the future success for the company. And we know that adoption at scale. If you need to get 10,000 people using a databases as a service, for starters, you can't have your sales team go out and talk to 10,000 people. This is probably all really obvious to everybody on the call, but it's not always obvious when you're a ten-year-old company that knows how to do a certain method of selling.
Sam Ramji (14:49): And there's a lot of companies that are going through this transition from strictly, "I'm going to call you, you're going to listen. You're going to think that this thing is amazing. And then you're going to try that." It just doesn't work for cloud technologies. Now we have go-to-community engine. You can find it at Kat Sandra, katsandra.io. That's built by a team. That's got telemetry inside it. And the team themselves are DevRel community leads. They understand what people want and need to figure out how to build a community engine. Or we use Orbit to measure that, of course. And it's changed the narrative in the leadership team, in this offsite I'm in right now. The conversation is not just how many more sales people do we need to hire and what regions? But how much adoption do we need and how are we going to have our go-to-community efforts, scaled, measured and powering adoption?
Sam Ramji (15:41): So we use Discord, for example, for workshops for being able to do education at scale in the COVID era. And that's been extraordinary. The tools and techniques we've learned as we've found measuring people's success and happiness matters. And then making sure that if we want more of those results, as we understand how those turn into business results into our revenue, how do we scale that up proportionally? I think that's the big challenge and the big opportunities. How do we think about go-to-market and go-to-community proportionally with each other and proportional to their impact on our revenue and our adoption?
Patrick Woods (16:21): Yeah, that's fantastic. I'm curious about the [villian 00:16:26]. This is going back to the, it's similar to the conversation that we were having about Microsoft and change management there. When you think about the GTC as a concept, and it's maybe set up principles, how has that worked for you? Rolling that out entirely, with the other execs, with the board, I have some suspicions that you tie it back to company strategy and some metrics around adoption, but are there any other specific things that you found useful in terms of communicating that idea internally?
Sam Ramji (16:52): In terms of communicating it internally, I think being able to tell stories about other obvious wins. It's very hard to make sense of yourself to yourself all the time. People are stuck in their own stories or they're immersed maybe cognitively blind to their own behavior. So being able to tell a really good story about somebody else that is really powerful. So I had a unfair advantage of telling the story about Kelsey Hightower, because he worked for me at Google. And I'm one of many managers who came through and had the privilege of hanging out with him. And you can draw a connection between that person who's vibrant, charismatic, easy to understand Kubernetes, which clearly ate the world. And the growth nurturing and leadership and investments in that community. And then people go, "Oh, shoot, okay." If we want more of a Kubernetes like outcome, then we need to have some of those same behaviors.
Sam Ramji (17:45): So that was effective storytelling for the leadership team and for the board to be able to connect these things and make it look like part of a pattern rather than trying to be the smartest person in the room and show how we can uniquely figure this thing out. So the nice thing is we don't need to configure this thing out. We're a community of community builders here on this call. And so we can all share and learn from each other. So someone in this session has an amazing story. That's going to help somebody else bring their company on board with this whole set of behaviors and thoughts and practices. So I think that's an opportunity for all of us. What are the great stories that we can use to educate people in the go-to-market culture and bring them into the go-to-community culture?
Patrick Woods (18:35): This is great. I think that sharing stories is maybe one of the most important things we can do as community members and builders. One of the things we try to facilitate in our own Discord, because to your point, it's the stories we share tools for driving change, and these are the ways that we actually change the context and change people's expectations. And so I think the power of story is enormous. And by the way, if you're just listening in and we are having a side conversation in the chat at discord.orbit.love, where you can follow along with some of the folks having a chat and taking notes, and then ask any questions of Sam, there in the chat.
Patrick Woods (19:13): I've got a tactical question that comes up a lot. I would say in my conversations with everyone, from community managers, to CEOs and founders, which is one about organizational design or org structure and the relationship between community teams or GTC folks more broadly, and you'd like to put it practically like community and marketing, how are those related, are they separate teams? What have you seen work well, how should people think about the relationship between teams that are potentially related, but maybe distinct as well?
Sam Ramji (19:48): Yeah, it is a very vivid topic. It's an outstanding question. I guess I'll start with about two months ago when I interviewed our new chief marketing officer and I was like, "Ah, I'm going to make this a really hard conversation. I want to make sure that we pick the right person, can they meet the bar?" And I asked exactly what you just asked, maybe not precisely in those words, but I said, "As you look at taking on marketing for DataStax and taking over the whole organization, all the promises, all the outcomes, all the commitments, where do you see developer marketing?" And some of us said, "Ah, well, I'm not sure it's really marketing because developers hate marketing." You said, "I think there's a community team." And I think we, as marketing need to learn from the community team about what people like, and then we need to rebroadcast that.
Sam Ramji (20:41): But I see the community team as being really the R&D for understanding what users want and how they talk about what they like that we're doing. And then we can find ways to retarget that content, but I don't confuse myself that developers want marketing or that there should be a developer marketing org under the CMO. And I got to tell you, I was absolutely thrilled with that answer. I thought it showed so much depth and also humility. Because there's a new incoming executive. You could certainly want to get your arms around everything and build the biggest possible territory. But he really showed his mission orientation by focusing on the details that mattered. The corollary to that is that the challenge that I offered our CEO and maybe it was February, I think, Patrick, that you and I talked about. So go-to-community.
Sam Ramji (21:30): I was having that conversation internally in January, trying to find a way to stimulate rebalancing, that has ended up moving a lot of pieces inside the company. And now DevRel is part of product management, where we were focused on the developer experience, the developer product and the developer tooling. So that is now one team. And I think that the next piece for us will be to more tightly integrate DevRel with engineering so that the action and the experience is much more DevRel is community product managers in a way. Taking the user feedback and bringing together ideas that actually go immediately into the priority queue rather than being thrown out of backlog, which is something I've seen in some organizations, but really bringing the liveliness of small tweaks, 1,000 small tweaks are more powerful than one feature often for developer adoption and stickiness people will stay with you when you've polished all of the rough edges off. And it's a tool that feels smooth and it fits your hand. That's the experience that you'll almost never get from a product manager, but you will get from a DevRel person.
Sam Ramji (22:42): So while long story short. There's a lot of organizational design in there. DevRole is not marketing, it's a lot closer to product. And when you think about go-to-market, people are talking about flywheels often. So we do have that, but we've also created what we call the developer flywheel. And we're now making a very strong claim internally, which is why do we organize this way? Why we merged these groups? And the claim is very simple. The flywheel is the product. It's not something you bolt on. It's not a bunch of other activities, the flywheel is the product. Again, this might be super obvious to many of the folks who are listening in, but I hope maybe that pithy expression can help you communicate with your leaders.
Patrick Woods (23:27): I think it's great. I think let's spend some time on that idea that the flywheel is the product, what do you mean when you say that? Because I think I know what you mean by like specifically, can you unpack a little bit more nuanced to the parts of the flywheel and the significance of that statement?
Sam Ramji (23:44): Sure. So you'll think a classical flywheel says, "We have this particular set of content. This content is going out on the web. We're seeing what works, we're adding some SEO to it. Now we're starting to do some targeted ads." And how can we create that as an engine that keeps tracking more and more people and as more and more content goes out there maybe it's our YouTube channel or any particular vehicle. It should spin faster. All of the little pushes that we've made over years, the engineering concept of a flywheel, something that retains momentum and the whole system keeps getting bigger and you push it. But this is typically content about the product rather than the content. That is the product. So you end up unfortunately often hiring people who aren't using the product that often they're doing user studies, they're trying to understand using language, what experiences they're trying to package that into new language.
Sam Ramji (24:38): So there's this separation that makes a lot of things that are obvious to a user disappear. The language gets a little bit janky, and then you just try to bring people to the product. Now you've got people at the product and they're like, "Oh, the edges, a little rough." So you spent all this work getting someone there, but you can't keep them stuck there. So if we flip it around and say, the most important thing is that the experience has it's own flywheel. The experience keeps getting better, that we're sampling our users. We're using telemetry to see where they're getting stuck. We have something as simple as Google has a unified user feedback system to make sure that people can report on their experiences if they want to, or that we can bug them gently, not too frequently to say, "What do you think we should be doing better?"
Sam Ramji (25:23): And to be able to pull that stuff back and say, that is at the front of the sprint, not the back of the sprint, like just in case we get all of the other things that we were going to get done. We're going to put in some of these user affordances, but they actually go into the front. The product flywheel ends up being something that turns faster and faster as more people use it because you've built a system where experts who use the tool are listening to novices who used the tool and helping engineering build the tool better. And so that as a capability for a corporation, an ongoing flywheel where the practice speeds up faster and faster, you will flip the whole marketing problem on its head because the community will talk about what you're doing. The community will actually do the marketing for you.
Sam Ramji (26:09): And then, like Thomas said, if you find something amazing that the community is saying, then you can go and do your SEO. Then you can go and spend your advertising money effectively, reducing marketing to science because you already know this contents good. Now your job is just to share it out. But if you put the dollars and the people and your focus, your capital allocation goes into having a very fast iteration cycle for the product that keeps driving user feedback in, at the front of the priority queue. That behavior will blow away the competition. I think MongoDB is a wonderful example of a company that focused on this very early on. And people said, "My gosh, this is not really a great company. Their balance sheet doesn't look good. I don't like their margins. What's their repeatability?"
Sam Ramji (26:56): But now look where they've gone. They're focused on community. And their developer flywheel has future-proofed their business and enabled them to get into cloud where they now have a $20 billion valuation. It's awesome. So again, finding exemplars that we can tell stories about to showcase this, I think is a way that we all move ourselves and our industry forward.
Patrick Woods (27:20): One of the things you said a moment ago before we do delved into the flywheel is that the community team is essentially R&D that I'm not sure if you're watching the Discord channel, but that blew up, a lot of love for that idea. So I think that-
Sam Ramji (27:36): Oh, cool. Yeah, no, I'm single tasking on you. I'm sorry. I'm not on the Discord, but I'll check it later. Put all my attention on our conversation.
Patrick Woods (27:43): Yeah, I appreciate that. That just stands out as a really specific and pithy thing that really resonated with me.
Sam Ramji (27:50): That's awesome. Thank you very much.
Patrick Woods (27:54): Can you talk a little bit about measuring the stuff, how granular should companies be when they're thinking about whether it's the flywheels or they're go-to-community strategy. Maybe to ask it one way, do you have a balance scorecard or DataStax, and is this stuff audit or what are the top level measures that you are looking at?
Sam Ramji (28:17): Yeah, so we do have a balanced scorecard, at DataStax. When we look at the measures every Monday as leadership team, and I'm sure that the more granular measures in each subgroup are at the source of a lot of their focus on Monday morning as well. At the top level of the company, we look at adoption and retention of developers as users. We look at velocity of the product feature set itself. We have a DataOps team, that pulls in the telemetry from product usage. And then we look at that and correlate it to activity in different parts of the world and use it to assess whether our forecast for our sales outcomes is roughly on target, but also helps us find places that were under invested in.
Sam Ramji (29:11): So we're expanding in India faster than we had planned to because the numbers tell us that's the place that we're starting to see a lot of utilization. So I think granularity is really important. You want to have super fine grained telemetry, and then you want to be able to find the patterns, and turn those into metrics. You can't announce everything as a company metric, but if you can find the thing that is maybe not causal causality is hard to prove, but the best correlations and elevate those to metrics and say, we're going to watch that because mostly what you're trying to do with these metrics is creating a system of leading indicators that tells you if you're going up or going down and what corrective action you want to take.
Patrick Woods (29:53): Amazing.
Sam Ramji (29:54): Yeah, so I can publish our scorecard at some point that's useful. It probably easier to see than to fully articulate, but hopefully that's helpful.
Patrick Woods (30:03): Yeah. We, they take you up on that at some point, because I feel like the tension that I sense when talking to whether it's a founder or a CSP person or a community builder manager for that magic matter, it's like the translation from what's going on with the community, is it working is it not? And then you're figuring out the connective tissue between, I guess, community inputs and business out outcomes, because we'd like to describe communities as complex systems and the space and the time between the input and the output can be a long time. And so yeah, this area is, I think, top of mind for everyone in terms of developing those leading indicators for understanding the relationship between activity and investment in the community, and then the second order effects on the business side of things.
Sam Ramji (30:52): Yeah. Absolutely right. I think we draw some of the data from our model directly in our dashboard. And we had an amazing experience with someone, many folks on the call may know Jono Bacon, Jono led the Ubuntu community back in the 2000s. He's also a big fan of thrash metal. So if you see Jono ask him how his Pant Terra skills are coming, he's actually an amazing musician. He's a great guitarist is a good singer too. But he spent several months with us as a consultant, building our community strategy. I'll tell you what I think we did really well. We didn't try to get Jono to build a sidecar where he'd go off and build a strategy for community for the whole company. We brought him in and built our team around him. And then we focused it on an absolute must win company priority.
Sam Ramji (31:42): So I think this is the key. You don't want to play around where it doesn't matter because it's hard for people to focus on your prototype or your project is likely to fail. But we knew we were betting the company on bringing Cassandra and Kubernetes together. So of the whatever eight different projects that were suggested that we could work with Jono and one to learn how to do a better job of community as a company, how to organize, how to measure. We said, we're just going to do the most important thing, which is obviously Cassandra, Cassandra and Kubernetes, that'll add a lot of people to focus because they felt like their day jobs were totally connected to this thing. So that was very helpful. So I think you could say, "Well, Sam, don't you know this stuff, why did you have to hire Jono?"
Sam Ramji (32:26): I think for a couple of reasons, first he's amazingly good. And he puts his entire focus on this. And I think you may find other folks like that, but most importantly, no, person's a profit in their own country. And this is where humility comes in as well. Just because you know the thing, it's still hard to get listened to because you've been around and people have a certain picture of you in their mind. And then your identity limits how they can listen to you. But if you can bring in somebody else, who's super confidence and explain that they're super competent, then they get listened to with fresh ears in a way. So I think Jono had a multilevel impact for us and directly contributed to how we measure the community at the company.
Patrick Woods (33:03): Yeah, Jono is fantastic, lot of big fans. We need to get a jam session together. I'll be on the drums and you and Jono can be on, you play guitar, right?
Sam Ramji (33:14): Yes. I do. That'd be awesome. It would be awesome because without a drummer, always guitar, it's just go nuts and we screw up the time signatures and we take infinite solos. So you need [crosstalk 00:33:25].
Patrick Woods (33:25): Yeah, totally, totally. I'm happy to bring in the structure. That's often my role in the work and then music.
Sam Ramji (33:34): It's awesome.
Patrick Woods (33:36): For everyone listening. If you have a question for Sam, feel free to drop it into the Discord it at discord.orbit.love. You'll see the conversation going there and I may make it to some live questions too. So if you want to raise your hand, we may try to get to them. Before we jump into any questions. Sam, I'm curious, you shared a lot of, I would say very positive and creative things. You know what to do, how to be effective. Are there any lessons learned or got yous you've seen or experience when it comes to thinking about the role of community and driving growth?
Sam Ramji (34:09): Oh yeah. So many they all cluster around the same one concept, which is trying to get people to come and understand you on your own merits, whatever those are. So you'll see this when communities get very egocentric, which is not uncommon, it's unnatural. We're defining who we are. You would take 15 years ago, we would talk to people in the open source community and be like, "Oh, open source is so great." "Why?" "Well, it's open and it's really good. And we have a lot of smart people working together," and you can see people's eyes glaze over because all of this qualitative narrative that only makes sense to somebody who already gets it. That's a mess. And when we carry that on, we can create our own dispossessed silo.
Sam Ramji (35:02): Where we're the only people who understand this thing. We have to hire those folks. And we start creating an island of misfit toys. And I've heard this use this expression raised from a Santa Claus movie from American culture, Rudolph the Red-Nosed Reindeer. So it was an imaginary place, but it's often used as a way to describe the folks who fit into DevRole, is like the Island of Misfit Toys. But if we don't try to get off the island and we lick our wounds and just say like, well, we're doing amazing things over here. And if people just understood us better, everything would be great. Now let's go back to our work. We can't leave it there. We have to actually build the bridge. We have to figure that stuff out. So most of the anti-patterns fit in there and they lead to a lot of waste. A lot of just waste of time and effort. And also a lot of emotional hurt where people feel like they are working 80 hours a week and they're delivering the future for the company, but they are not appreciated, not understood.
Sam Ramji (35:58): And those are tragedies. Those make me feel really bad. So I would say pay really close attention to mood. And if you are seeing that somewhere in the team, the mood is not good. You can probably chase that negative mood into some version of this anti-pattern, where there's an island of misfit toys being created. And then as soon as you know what that problem is, you know the answer. You have to figure out how to build a bridge what's on the other side so that their value can get unlocked and expressed.
Patrick Woods (36:31): It seems like so much of this stuff comes back to this idea of seeing oneself as a cultural broker to have the conversations.
Sam Ramji (36:42): Yeah. And it's difficult. Because it's like how do you know who are the doctors at a party? They're the ones who are all clustered in a tight circle by themselves using jargon to speak with each other. It's satisfying for them because they love their work. And using the jargon is really satisfying because they can discuss really complicated ideas really quickly, but it's impenetrable. So we tend to jargonize the work that we do because developer communities are actually really complicated. And if somebody says, "Hey, I've got 20 years in developer communities." That's not one year 20 times. That's actually 20 years of novel experience. And to talk to somebody else, you're going to use a bunch of jargon. It's much easier to talk to people who already get it. So it's a very natural, emergent human behavior.
Sam Ramji (37:27): And so the cultural brokering piece and why I want to emphasize that. And even the term go-to community is an act of culture brokering because you know, you're speaking to somebody who doesn't understand what you do, but who does understand go-to-market. And she was trying to lessen the cognitive gap for them to come over to this new understanding of how to build the company.
Patrick Woods (37:52): Well, if you hear me typing, it's because I'm taking lots of notes.
Sam Ramji (37:57): I appreciate it. But I appreciate the fact that you're watching the Discord and that I can just put my attention on you because that's a gift for me.
Patrick Woods (38:06): Yeah, I appreciate that. I mean, basically the Discord is just a bunch of people saying, "Wow," and a big integrated site, so.
Sam Ramji (38:13): Awesome.
Patrick Woods (38:14): Or maybe Rosie's making fun of me for saying, wow, I've sat in a lot of these call.
Sam Ramji (38:20): That's really nice to hear. It's super nice to hear because I think I have a lot of social anxiety and introverted. So it's hard enough to speak in public, but when you actually can't see anybody, then really don't know if you're making a good use of people's heartbeats or if you're just wasting everybody's time. So I appreciate that feedback.
Patrick Woods (38:40): So zooming out a bit, you've been thinking about communities and their role inside of very large organizations for a long time. And I feel like fast forward to today, especially the past 12 to 18 months community as a concept and a discipline, it seems to be coming to the forefront for a lot of people and companies, have you observed that too? What's that feel like as someone who's been a deliberate thinker about these things for so long to see community emerge as something that's very top of mind for a lot of people?
Sam Ramji (39:15): It is incredibly satisfying. It's incredibly satisfying for a couple of reasons. One, there's a whole cohort of folks that I grew up with. If you look at like RedMonk, well, you look at James Governor and Stephen O'Grady. I think the conversation I had with them was probably in 2006, when I made Microsoft a client, which made them pretty excited because it was helping them deliver on RedMonk. It's a contraction of Redmond and Armonk because they were going to look at Microsoft and IBM. Stephen wrote this great book called The New Kingmakers, which was based on his essay, the new kingmakers where all of this stuff about things I believe, which was developers as technical users have a creative profession. It's their creativity that defines the boundaries of what your business can achieve and their selection of your tool is going to be what makes or breaks your company.
Sam Ramji (40:07): They're going to make you the king or they're going to make you the joker. So now look at where that concept is like, it's now obvious. And so I get to see folks that I've worked with for decade and a half, two decades, and it's company. It's like your old school team or whatever. You can celebrate those changes. I think the other thing that's really exciting as I've been in Silicon valley for 25 years and the nature and speed of company formation has really picked up. So we're seeing a lot more focus on building components. I got to invest in a small machine learning startup recently that their whole point of view is like, "Hey, what if we make an AI API for this particular subset of the machine learning space, how could we make that really valuable to developers?"
Sam Ramji (40:55): The fact that that's like a constant conversation. This developer centricity, and how do we create communities around it? I don't know. I feel like all of the times I've come and the privilege of being able to be in a conversation like this in public with you, it just tells me that I haven't wasted all this time in my life doing stuff that people didn't understand, just a whole bunch of us were doing our own R&D. And now that it's becoming mainstream, it's important and useful. And so we have an opportunity to share.
Patrick Woods (41:29): Very powerful word, Sam, I appreciate you again, taking the time out of your busy schedule from your offsite-
Sam Ramji (41:35): No problem.
Patrick Woods (41:35): ... some conversations happening. Yeah. The Discord that people are loving the staff. I mean, I always love these conversations. Again, thanks again for coming on the chat. In terms of final parting words here, we've got a bunch of people listening in that. I'm just looking at the list. We know a lot of people here, there's some founders here. There's some people that are community builders and endeavor folks inside of. It's a pretty cool companies. Would you leave any parting advice for the folks that are on the cutting edge out there trying to bring this idea of go-to-community to life, any expectation or pat on the back, you could give them before we wind down today?
Sam Ramji (42:11): Yeah. I guess I would say two things. One let's make this real together. The ability like Thomas Jefferson said, "To share knowledge is like lighting a candle. And if I light someone else's candle, they now have lights and my candle is not diminished." So if we want to make this really break out into the mainstream, let's all start using this term, go-to-community. Let's co-invent it. Let's write about it and explore the boundaries of what it could mean because it could create a space for all of us to share our practical lessons. And who knows. I know Patrick, you've been invited by the Stanford Graduate School of Business to chat and help people in the business school, normalize this and understand how to come at it. So if we multiply that times, everybody on this call and we all get a chance to participate, either in creation and knowledge by writing or presenting or talking about it, I think that would be super powerful.
Sam Ramji (43:10): The big expectation that I guess I have for everyone on the call is like, oh my God, it's finally here. Right? Our time has come. Developer communities are shaping the economy. I've just spent the last couple of months doing a deeper research into the state of the machine learning, market bots data from PitchBook. 35,000 companies in the world say that they are doing AI machine learning or Big Data. Cutting that into just infrastructure startups. There's 800 really credible startups anywhere from pre-revenue to 100 million dollars. And they are all focusing on ways to connect data to developers, whether it's a data engineer or somebody doing data science or whether it's an application engineer and that's scale.
Sam Ramji (43:58): The reason I mentioned that 35,000 is that's the shape of the future. You just look to 2025 and you go, that's the whole economy. So the pressure, the draw or the demand from all of that on all of the other infrastructure that we build as software is enormous. So it's all developed and mediated. The scale is spectacular. And with every abundance comes in new scarcity. Sure you've got a tool, but who uses it? Who cares? That's literally our business and developer community. We help make people care about what we're doing and we help the people building our product, care about the people who are using it. So this is our time.
Patrick Woods (44:42): This is our time. That's such powerful words for someone who's been living this out for quite a while. So Sam, thank you again so much for coming on today. I know everyone appreciate it so that I certainly do. Good luck with your offsite.
Sam Ramji (44:59): Email me at email@example.com. So it's a privilege to talk with you all today. Thank you so much.
Patrick Woods (45:03): Thank again, Sam. For everyone else, follow along at communitycamp.com for the agenda for the rest of the week, which is today and tomorrow. And otherwise we will see you in Discord at discord.orbit.love. Thanks so much everyone. And see you online.