May 1, 2014
Runscope Raises $6M Series A
Just one year after launch, Heavybit member company Runscope has raised a $6 million Series A round led by General Catalyst.
Few growth-stage companies succeed on a sole product offering. This panel of successful Co-Founders explores how successful B2B companies go from delivering a single developer tool, to building massive ecosystems. The session explores real examples in how repackaging, new market expansion, and competitive analysis have made them category leaders.
Delyn Simons: First, I wanted to introduce Erica Brescia. She is the COO and Co-Founder of Bitnami, and the leading provider of packaged applications for any platform. This is very impressive, she heads the company’s sales, business development and marketing operations efforts. In December 2018 Erica was recognized at the Women in Technology Awards as COO of the year.
We next have Sid Sijbrandij who is the Co-Founder and CEO of GitLab, which has established itself as the single application for the entire DevOps cycle. As CEO he has steered the company from Show Hacker News to $110 million dollar Series D in six years.
Then lastly, we have Mike Knoop, Co-Founder and Chief Product Officer at Zapier– Not “Zay-pier,” it rhymes with “Happier.” He leads the company’s product management, UX and design teams and under his leadership the company scaled to $50 million dollars an ARR with 200 remote employees in more than 19 countries. They support 1,500 app integrations, a lot of the “Zaps,” and empowers millions of customers including Adobe, Envision and Spotify.
I’ll be your moderator for today, my name is Delyn Simons. I recognized a few friendly faces out there in the audience. I am the Director of Product Marketing for the Platform team at Shopify. So, let’s get right into it. I’d really like to know what size company that you have scaled to. If you don’t mind just calling out the name of your company one more time, and then how many employees you’ve grown to. Erica, we will start with you.
Erica Brescia: At Bitnami we have 75 employees and we’re a bootstrap.
Sid Sijbrandij: At GitLab we have 575 team members.
Mike Knoop: All remote?
Sid: Yeah, they’re all remote. So in more than 50 countries. No offices.
Mike: That makes us look small.
Delyn: 50, wow.
Mike: At Zapier we’re about 200-220. Also fully remote across 25 states and 14 countries, or so.
Sid: And profitable.
Mike: Profitable, yes.
Erica: We’re actually distributed, too. We’re in 10 countries and 30% of our team is remote.
Delyn: So, to start out, dev tools to dev ecosystem. How do you make that transfer? I want to better understand how each of your companies has evolved from a single product offering towards an ecosystem, and as part of that, I wanted to hopefully establish for the audience some context about what you consider the minimum requirements to be able to define yourself as an ecosystem?
Mike: I can take it first. Zapier, when we got started we were just Brian, Wade and I. My two co-founders. Back in 2012, we were not an ecosystem. Zapier, we built the first 50 or 60 integrations ourselves.
We just listened to what our customers were asking us to build and we decided to build those.
When we launched in summer 2012, we had live chat on the website, like Olark, at the time–
Erica: I remember we did too.
Mike: I remember being up for 24 hours straight just being overwhelmed by live chat after we’d done our Tech Crunch launch. Users were asking “When are you going to support app X, Y, Z?” These were companies and products I’d never even heard of before. It was really clear at that point that if we were going to scale the company and scale the business and the product, we were going to have to turn into more of an ecosystem, where we build a platform and build a partnership model where folks could build on top of Zapier instead of us having to go build all those integrations ourselves in order to scale.
When I think of the word “Ecosystem,” that’s what comes to mind for me, is the word “Open.” If you have a standard model in which folks can work with you, I think that’s the minimum bar you have to meet to be considered an ecosystem. To paint our story with Zapier, we were not an ecosystem when we were doing all the integrations ourselves. When we were deciding who we partner with and what APIs we worked with or whoever or whatever stores we try to get listed on ourselves, that’s not an ecosystem.
Delyn: How many Zaps did you build before you opened it up to the ecosystem?
Mike: Like 50 or 60, the first 50 or 60 over the course of about four months. Some late nights there. Then after we launched we opened it up and scaled from that point to 2019 today, where we have over 1,500 that are all built and maintained by our partners.
Delyn: That’s amazing. How about GitLab?
Sid: GitLab got started at GitLab version control and GitLab CI to run your tests, and then a person from Poland, Camille made GitLab CI much better. We said, “That’s amazing. We’ll make that official. You want to join us?” He came and he said, “We should combine the two applications.” And me and my co-founder were like “No, obviously not. Those are separate things everywhere.” He said, “Maybe you don’t believe it will be a better experience, but at least believe it’s more efficient because we prevent some duplicate work.”
That’s one of our values, so we did it and it turned out it was a much better experience for our users. Something we totally didn’t anticipate because we had joined the two applications at the hip, like the integration was as good as you can make it. We made custom APIs, but still having it in a single interface and a single data store was way better. We doubled down on that as a company, and today it’s everything from planning what you’re going to do to monitoring, securing, and defending and everything in between. Packaging, release management, which we still call it our secret, not that we don’t tell anybody, but that people only believe it after they’ve used GitLab.
Delyn: What do you consider the minimum definition to be able to qualify to call yourself an ecosystem?
Sid: Our ecosystem is the contributors to GitLab. Because we have so much scope we cannot do it all ourselves, and we have over 2,000 people who contributed back functionality to GitLab. Every month there’s more than 100 improvements in the product that come from the wider community. That’s the bar for us, to be way above those hundred.
Delyn: The minimum is to have people contributing back?
Delyn: Very nice. Erica, I loved our conversation about platform earlier, and how you define platforms. Can you tell the audience a little bit about Bitnami?
Erica: Sure. From a platform perspective I really like this concept of the Bill Gates line, which we were talking about on the call. Which is “To call yourself a platform, there have to be companies building on top of your platform that are creating more value than you’re getting out of it yourself,” and I think that’s a great definition. It’s important to draw the distinction between a platform and an ecosystem, because you can have a great ecosystem without being a platform.
When it comes to Bitnami, I think we’re a little different than the other companies represented on stage, because Bitnami is known for this catalog of open source applications that we package and deliver on all of the major Cloud platforms. It’s almost like a three-sided market. We have users, over a million people a month come to Bitnami and acquire applications that they can deploy locally or in the Cloud, and then we have these Cloud provider platforms that we have to work with to ensure that we deliver a great out of the box experience for running the applications that we package on the platform.
Then we have all of the ISVs (Independent Software Vendors) or open source projects whose projects that we are packaging. So, when I think about the Bitnami ecosystem I think about all of these different open source projects with which we engage, and I’d love to see us doing more of that, as well as our user ecosystem who are pretty involved in what gets packaged next and giving us feedback. It’s not open source in the sense that we don’t get contributions, but we still have a lot of active companies and system integrators and users who are contributing to the direction of Bitnami in the application library.
Delyn: Your statement that you can be an ecosystem without being a platform, can you double click on that a little bit?
Erica: I think it’s important in an ecosystem that both parties are getting something out of it. It might be developers who are contributing and they get something out of it in the sense that they either improve their resumes or they get a feature implemented, or they might be systems integrators doing the work and then contributing it back to companies. There’s a lot of ways that they benefit, and I think that’s an important aspect of an ecosystem. But I think when you look at a platform it really is about revenue.
Is there more monetization happening by all of these other companies that have developed and built on top of you than you are generating yourself?
I think again, Bill Gates’ line not mine, but I think it’s a good way to think about it.
Delyn: How did you know that you wanted to not only offer your products as a platform, but grow into an ecosystem? Did you know that from the very beginning, or did you stumble in like “That would be a good idea to open this up.” At what stage of the company? I’d like to hear from each of you.
Mike: I don’t think we did set out to build an ecosystem.
Delyn: You just needed to hire more people so you could multiply that 60, right?
Mike: I think it was something we learned along the way that we needed, in terms of figuring out when and how. It was often just due to user demand. I think when you’re building any ecosystem you have to have a really good product at the core of it. For us, we were always just really responsive to listen to what our users wanted and were asking us for. That’s how we got those initial insights, in terms of who to go partner with and how to think about building that ecosystem out and building a platform out. Basically, inbound demand.
Sid: We realized later on we wanted to be a company.
Delyn: Good one.
Sid: So Dimitri, my co-founder, lived in the Ukraine. He had two things that bothered him in his life. First of all, that he didn’t have running water. Second, that he didn’t have great collaboration tools at work.
Sid: The priority is obvious, he solved the second thing first. He built GitLab. I saw it a year later on Hacker News, and I’m like “This makes so much sense.” I sent him an email, “I’m going to run GitLab.com without you. I hope you don’t mind.” He’s like, “No. Totally cool, it’s open source. Thanks for making it more popular.”
A year later I realized that most people were running GitLab themselves and that’s where the market was, and Dimitri tweeted “I want to work on GitLab full time,” out to the entire world. So, I sent him an email and we agreed on compensation. I went to the local Western Union money office. He said, “You want to wire money to the Ukraine from the Netherlands? Do you know this person or is this someone you met over the internet?” That’s how we got in business.
Delyn: A beautiful co-founder story.
Sid: Yeah, thank you.
Delyn: That’s amazing. What do you think went well and what was painful about discovering that process, would you say? Were there any bumps along the road that you’re like, “Maybe we shouldn’t be an ecosystem?”
Erica: We started out as an ecosystem– Our version of an ecosystem from the very beginning, because there was no way with building this application catalog that we could do it and drive adoption and make it successful without engaging with other people. It’s painful in the sense that you have a lot of different constituents that you have to think about as you’re building out your strategy.
You can’t always make everybody happy, but you at least have to make people feel like they’re treated fairly and build trust with them.
I think it’s really easy when you’re building out an ecosystem of any kind, or even just a partnership program before that, it takes a lot of time and investment and care and feeding. I think people consistently seem to underestimate the amount that you have to invest in making those relationships successful. Not sure if you would agree with that.
Sid: For us, the big risk is if you start a company based on an open source project, that the two diverge. One thing we did early on is set out to be very transparent about what we do. You can still find our OKRs online, our marketing metric meeting is livestreamed to YouTube, our handbook of over 2,000 pages is online. It started because we wanted to make sure that we didn’t alienate the community. If you can look into a company you have more understanding and you can more quickly say when something goes off the rails.
Delyn: Speaking of pain, did you ever have a pain point when the transparency was too much? Over-transparent? Has anything come back to bite you?
Sid: We had small things, but it’s been remarkable how little it hurt. The upside in the ability to hire people that are aligned with your values has been enormous. We got like 13,000 applications a quarter, people just see our stuff and they’re like “Yeah. I was already referencing all your stuff, and then at a certain point I was thinking ‘Why don’t I just join the company?'”
Delyn: When you’re at the beginning of your ecosystem journey and you’re in the process of choosing your platform partners, we know that platforms and partners are only as valuable as the partners and the enthusiasm of the broader community. Your choice of your first partners is super important, so can you talk a little bit about who you chose to focus on and build for first? What was behind that decision making, and then maybe in retrospect, was that the right choice?
Mike: In the early days of Zapier, before we even had a product and before there was actually software you could use, we had landing pages on our site with the classic “Fill out the form if you want this integration to exist,” and for the first four or five months of the company, that’s all Zapier was. If you went onto Google or you came across the partnership page and somehow stumbled across Zapier, you filled out the form and really the fulfillment process was Brian, Wade and I spending all night building that integration and then delivering it to you the next day. Like, “Just-in-time” building the partnerships out.
I think that worked really well for us because, like I was saying before, it helped us be really aligned with what our customers wanted. It made sure that we actually were building things that users wanted. I think one of the dangers we get into when you start thinking about building partnerships that early in your company is that partnerships–
They can blind you to how good the product is, because you invest all your effort and time thinking “If I can just get that partnership, things are going to go awesome,” and you focus all your effort on that.
Whereas the product stagnates and you pay less attention to the bad parts of the product and pay more attention to the exciting thing on the partnership side, but I think the way we went about it was still a good hybrid approach where we try to align the partnerships that we’re building out, with what users were telling us. It’s due to the product we were building as well.
Delyn: In retrospect, was that the right approach? Do you think?
Mike: Yeah, if I could go back and do it again we would do it that way. Definitely.
Delyn: Yeah, first partners. How about your first partners, Sid? At GitLab?
Sid: I think if you’re small, partnerships don’t make a lot of sense unless you have a very differentiated product. But most of the time, it’s a waste of time because no one wants to partner with you because you’re nothing. So, you spend a lot of time on nothing. Our first great partner was one of our customers. It was like a fortune one company, and I’m a genius at pricing, so I gave them an enterprise license for $1,400 dollars.
Delyn: Great pricing strategy.
Sid: One of those people now work at GitLab. She was like, “Come on. We had so much money, and you only asked for this much.”
Erica: I think we’ve all made that mistake, though.
Sid: We spent two engineering years building the features they wanted, but luckily the features they wanted were good proxy for features other people wanted. So, we lucked out there. One of the things we do now is that we have an open feature request tracker, or we have an open issue board basically, and people just chime in on the features they want. They can upvote and our salespeople drop Salesforce links in there, and our support people drop Zendesk links in there if there is a support request for that, or if there’s a customer who is interested.
Then the product managers have all the information, and even the engineers sometimes say they onboarded at the company, like “I’m getting all this feedback from this person I can find on the team page,” and we were like “That person might not work here, that might just be a user who really cares about the feature and they tell you what to do.”
Delyn: You’re inviting your partners and customers into your roadmap almost, it sounds like.
Sid: Exactly. Our real issue tracker where we really work is just open to the world, and it’s been amazing. I don’t understand why more companies don’t do it.
Sid: It keeps us honest, too. If one salesperson said to a customer, “We worked on it this week,” and he’s like “No you didn’t.”
Delyn: I can tell. Erica, how do you prioritize? I saw some nodding heads in terms of what stage of partnerships is the right one. How do you prioritize your partnerships to make sure that it’s the right partnership for you at the right stage?
Erica: It’s pretty clear for us, and I would say I agree with Sid, most of the time when I’m working with earlier stage startups I tell them to steer away from partnerships because they can be such a huge sink of time. People get all excited because some big part company wants to partner with them, and then they spend a bunch of time and sometimes money, and it goes nowhere.
Mike: They really want to acquire them, is what they want.
Erica: Yeah, exactly. Sometimes. Or suck knowledge out of them, depending on who the company is. It was pretty obvious for us. Our first really big and important partner was Amazon, and that was just the nature of where the Cloud was at the time. We started building images for Amazon before they launched a marketplace. We were publishing tens of thousands of images before they launched, so they came to us when they were building out a marketplace and said “We need your help. We need content. We can’t go to market with an empty marketplace, we need Bitnami to partner with us.”
That worked out fantastically well for us, because as soon as we were on Amazon every single other Cloud vendor was like “Bitnami, we need you in our marketplace too, because we want to do what Amazon’s doing.” That gave us a tremendous amount of momentum and is really what allowed us to bootstrap the company.
They’re partners, but they’re customers as well.
Our approach to partnership from the Cloud platform partner perspective is really pretty easy and clear to understand. We work with the major Hyperscale Cloud vendors across the world, and so prioritizing isn’t that hard. They also have to pay us, so whether or not they’re willing to actually fork up the money is a pretty powerful prioritization mechanism.
Delyn: That’s a great way to prioritize. “Are you going to help me pay my bills?”
Mike: Can I ask something? That’s interesting. So, it was a shortcut to trust, if I heard right. Did you feel like you’d earned that level of trust yet in the market, or was this a shortcut to getting it?
Erica: At that point in time I would say probably not. We had trust from ISVs — the Bitnami story is a long one and I won’t bore you with the details now, — but we started out packaging ISV software before we launched the marketplace. So a lot of the ISVs trusted us because they had been paying us to do all their packaging before we started doing this.
But definitely from a user trust perspective it made a huge difference, and in the early days we used to work with a broad range of Cloud vendors instead of focusing on the largest ones, and I remember having a conversation with one where we said “If you want to white label it, we can talk about that,” and they were like “No. We want the Bitnami brand because that means that we’re a real cloud.” We were like, “Holy cow, that’s cool.” Thanks to Amazon we got a lot of extra juice.
Delyn: Nice. You know you’ve arrived when they want your logo on their site.
Erica: I know, that was a really proud and very cool moment for me, I’ll admit.
Delyn: Very cool. User acquisition strategies, how do you decide when it’s the right time to partner with other companies? What model do you use to decide who to partner with?
Sid: I think we have a lot of users. There’s about 5 million people already using GitLab, so when we do acquisitions it’s aimed at acquiring part of our roadmap, things we want to build. There we have a problem because we’re a single application, so we cannot acquire some technology integrated with GitLab, it has to be made inside GitLab. We have a public acquisition offer page that won’t surprise you, but we list out how much we pay per founder and where we’re interested, and it has a Google form to apply.
Then we get a team that made something before that’s really good, but they didn’t get enough distribution to succeed, and then they join us and then in half a year they rebuild it within GitLab. We’ve only done a few so far, but it’s been a big success. One company, Gemnasium, built all our security offerings within that half year. They had only dependency scanning when they came in, and a half year later they also had container scanning and static and dynamic code analysis.
Delyn: How about user acquisition strategies for Bitnami?
Erica: We’re moving more into the enterprise, and so a lot of our direction there is from what users are asking for. We just did a user survey and we had over 19,000 responses, and obviously one of the questions we ask is “What do you want to see next on Bitnami?” Rather unsurprisingly we’re getting asked to package a lot of AI and ML applications. So we take that user feedback, package those apps, do a lot of partnering with the Cloud vendors around their own services as well for those types of things, and then that creates this virtuous cycle of driving more user adoption in areas we’re interested in expanding.
Delyn: I wanted to change gears a little bit and talk about designing for a great developer and partner experience for your tool, which is important not only for the dev tool, but the dev ecosystem part. So, developer advocacy. How essential is having a developer advocate team, a community team, in order to be a healthy ecosystem? Then if you could talk about who you think out in the market is doing this well, and then lastly, I’d really like to find out from each one of you, as your company is organized, what are your opinions about where developer advocacy is best reporting into you? Within your organization?
Mike: I feel like this is a question for you, Sid. You’ve got the biggest developer ecosystem out of all of us.
Sid: Marketing has cheap constituents, so there’s buyer marketing. Marketing to the people that will buy the product. There’s user marketing, and there’s community marketing, and community marketing for us is the people that contribute to the product. Here we’re talking about user marketing and the developers and operators are users, and we’ve set it up very much as a giant support desk where people respond to what’s being said on the internet. So basically, if you mention GitLab on Hacker News or on Reddit or on our Twitter feed or someplace, it gets fed into Zendesk and then we have a team of three people that respond to that.
Many times they answer themselves, but also they connect with people inside the company. The relevant person inside the company gets a Slack message, “You’ve got to respond here. Someone has a question I can answer.” That allows us to be much more responsive, and over time we added multiple channels, and one of the things we look at is “How fast are we responding, how many different channels can we respond? How many responses did we get and do people like the responses? Do they like it, did they respond to that?” Of course it’s also like when someone writes something great, send them some swag. Make sure you cross post their blog post, etc.
Delyn: So the developer advocacy within your company is community marketing, because everyone who’s having questions is technical in nature and usually a developer?
Sid: Yes. This is developer advocacy or user marketing, community marketing is having people contribute to the product. Ray is doing that, and he’s so successful that right now we were backlogged in responding to all the stuff that’s coming in. But he’s organizing hackathons and we have people who– We call them merch request coaches, so if you want to contribute to the product we have people dedicated to getting your contribution over the finish line, because there’s a huge amount of things you have to comply with before we can accept it.
Delyn: Nice. Are any of the hackathons in person or is all of this done virtually, online?
Sid: The hackathons are with people that don’t work at the company, so by nature they’re online, it’s over a weekend and there’s swag we send out and live meetings we do online.
Erica: Can I make a comment on that? I think Sid has done remarkable things with GitLab. Check out their handbook if you haven’t. I’ve probably sent a hundred people to look at it, because I think it’s really cool how you explain everything you do. I don’t know that developer advocacy should always roll up to marketing, I think GitLab is unique in how they’re organized and also the people that they’ve hired. I am usually pretty firmly in the camp of developer advocates should report into engineering and not marketing, just because of the way a lot of traditional marketing departments work.
I don’t think that the developer advocates end up well positioned to focus on the stuff that developers really care about, and I think it’s really important that there is a super tight feedback loop between developer advocates and the people actually building the product.
To me that means in most companies and especially in very large ones, you’re much better served and you’ll be able to attract much better talents, quite frankly, if you have people working in engineering. Because most developer advocates are folks who have been engineers before, and then move into this role. They tend to just fit much better in engineering org. I think what Sid does works really well for them, but I don’t know that’s the case everywhere.
Delyn: The exception that proves the rule.
Sid: I think that makes a lot of sense.
Delyn: You can’t talk about ecosystem without talking about app marketplaces. Atlassian, Shopify, GitHub, Heroku all have some type of app marketplace. How important do you think it is for users to be able to monetize and get new users via your platform ecosystem?
Mike: Shopify also has it’s own app marketplace.
Mike: In my experience, it seems like there’s a pretty natural life cycle for most SaaS companies where after you get initial product market fit, you grow to be a large enough size where you have enough influence, enough customers, and you’ve created enough value where you get big enough– To reference back to Erica, that Bill Gates line, if you have enough revenue where you can give a small percentage of that revenue out to an ecosystem and they can build and run their own businesses that are meaningful.
I think there’s a crossover threshold, and I think Shopify is an example of one where when we first got started it was probably not quite there, and now it’s well beyond this point where there’s a huge app ecosystem where they’re able to get partners to create and build integrations. Build and attach add-on products and probably create entire companies, like self-sustaining one, two, three person shop companies. That’s a pretty exciting trend, I think we’re still pretty early in the SaaS ecosystem days just in general, like in the history of the internet.
I think we’re starting to see the first wave of really big companies starting to build giant ecosystems, and I think we’re going to see a lot more over the next decade or so.
I think every app ecosystem that I’ve seen, they always have different values that they bring. If you think about the apps– Apple App Store, Google App Store, Zapier, Shopify, GitLab, Bitnami. I think each provide a slightly different value, but I see in common, when you get to that certain size, they’re all providing distribution in some way. That’s the common thread.
Delyn: To add on with Shopify, we have 2,500 apps in our app store, but when they realized that it was actually part of the growth and distribution model, when we had VCs coming and knocking on our door and asking us about the growth strategy, because a lot of people were quoting Shopify the app marketplace as part of their growth strategy. Which I thought was really interesting. How about app marketplaces for Bitnami?
Erica: We don’t have an add-on marketplace like Zapier does, right now we are the content and the value that we deliver is really this consistency that you get. So, if you get two different apps from us, they’re going to be packaged and deployed in a consistent way across all the different platforms you want to support. But I agree with Mike, it’s really about distribution and now we have enough traffic coming through our website that we have people lobbying to get onto Bitnami. Because it not only helps them support all these different platforms, but they know they can get in front of a lot more users. But until we got to that point it was hard to engage because we weren’t worth the effort to engage.
Delyn: What does the governance look like for that? For a 75 person company, that can be a heavy lift to make sure that they’re all the right quality.
Erica: We’ve built a lot of tooling to automate all of this, like a tremendous amount of tooling that we’ve now productized and taken into the market as its own product. That’s our enterprise product.
Delyn: So, here we’re going to get to the remote. This resonates so much with me because hiring in the Bay Area is nuts. I think we can all relate to that. It’s very competitive and you guys each have a really unique angle on remote work, like the number of countries. What would you say is the top 1 or 2 tips to making sure your distributed teams and your remote work culture, especially in an age like today, where trying to fit everyone into one office just doesn’t scale. Both from paycheck-wise as well as real estate-wise. I’d love to hear from you about how you make remote teams work, and especially across countries and time zones.
Mike: I can take it first. Remote companies are interesting. At Zapier, it’s fully distributed, 100% distributed so we don’t have a central office. Everyone works from home offices. One of the things I’ve learned is that running a remote company forces– Things you need to do to get good at running your fully distributed company are not things that are unique to running a distributed company. Getting good at communication, having OKRs, having an alignment tool, having ways to clearly define scope and responsibilities, having clear title and leveling. All these things are things that every company eventually has to get as they scale in order to continue growing.
I think remote companies and distributed companies can force you to think about and pay attention to those things earlier in the lifecycle of the company. So when we were only 20 people, we were having to think about “How do we communicate? Now that we have a management layer in the organization, how are decisions made?” We had to write all those things down instead of being able to rely on very implicit processes of hearing people talk to each other in the office and assimilate, and absorbing information that way.
I think that actually sets us up, sets any remote company up for a lot of long term scaling success too, because you’ve institutionalized really good scaling practices much earlier in your company. I think that’s probably one of the biggest learnings I’ve had running Zapier fully distributed, is how much it’s helped us scale later on by building those good processes in early.
Sid: Fully agree with that. I think too of our values, which really help. We have transparency and iteration as values, and that transparency makes things better for the sender and the receiver of messages in the company. For the sender, you can send it once and then multiple people can get it because you’ve written it down or you’ve recorded it on video, so you don’t get interrupted. People can consume it asynchronously.
For the receiver, you don’t have to interrupt someone else. You don’t have to wait to get something. It’s out there already, it’s the best version that we currently have. It’s not some telephone game where you hear it third-hand. Then the iteration, if you bite off smaller things and do them quicker, you need less coordination because you’re taking a smaller step.
It’s not so important that it’s exactly in the right direction, and because you have less coordination you have fewer like synchronous meetings that are needed. You’re able to have less overhead and get more velocity out of the same amount of work.
Delyn: Any tips for remote work at Bitnami?
Erica: First I want to address something Mike said, which I think is absolutely true. Which is it forces you to document everything and put a lot of structure in place much earlier than you might otherwise do. What’s interesting to me is I’ve been at a few unconferences where there have been conversations with venture capitalists and also major acquirers, and one of the things that you hear people say is they don’t want to hire remote companies, it’s too complicated. They don’t really know how to deal with remote work.
I’ve seen that changing a lot in the market recently, but what’s funny about it is it’s like, they should be thinking about all the advantages of hiring a company like that, because we’re forced to operate a different way, and, in what I would say, a more sophisticated way in many cases. Because of the fact that people are remote and you need to write things down, and I also agree with Sid’s comment about values. I’ve given several talks about how we manage this at Bitnami because we’re not entirely distributed, which has its own set of problems.
We have two offices, one in San Francisco and one in Spain, and then we have a bunch of people working all over the world from like Taiwan to Argentina, to Europe, to everywhere. It’s interesting because I have to explain when we hire people, we start from before we even hire people at making sure that they have this common set of values that allows people to work together very well. We look for people who are great communicators, who team up well, who live all these other Bitnami values. So even when you’re pulling people together from different cultures and all over the world, they have this shared set of values that makes it easier for them to operate as a team from the get go. That’s one of the great unifiers that we use at Bitnami.
Delyn: Do you have any time zone? Do you talk about making sure that you at least have four hours a day together, or do you talk about that at all? Or is it fully, you work your own work hours?
Mike: I don’t know about you two, but we don’t have a core set of standard hours at Zapier. Funnily enough, that exact line you used is something that I tell every single candidate doing offer calls. “We don’t have a core set of hours, but the way that this works is if you can find two to three hours of overlap with the immediate teammates that you’re working with, you’ll be fine and you’ll be successful.”
The company is set up where everyone has an equal footing, so everyone’s willing to be a little flexible. If I need to wake up early one morning or stay a little later one night, I can time flex that, and everyone’s in the same boat so they understand and can empathize with each other on that front. One of the interesting things is as we’ve gotten bigger, we’re getting to the point where we have enough time zone coverage where we can start to be intentional about grouping teams together based on time zone. Through the trough of the middle scaling phase of the company, the beginning of the company we primarily hired over networks in North American and South American time zones.
It was easier to communicate, and then we went through a scaling phase where we got a lot more international and it’s a little tougher, and we’re coming out of that other end where we’re starting to have enough critical mass around the entire world. I like to say, “The sun never sets on Zapier,” where we can actually group together folks in a smart and intelligent way, and that’s also helping alleviate some of the pain we have.
Delyn: How do you do that with 50 employees in 50 countries?
Sid: Time zones are the bane of our existence. We have a golden hour where we have some overlap between the West Coast and Europe, and we have our company meeting then, our group conversation.
Mike: What hour is it, out of curiosity?
Sid: It’s 8:00 a.m. Pacific.
Mike: 8:00 a.m. Pacific? That doesn’t surprise me.
Sid: The hard thing is we have people in the Asia-Pacific, and they cannot join. So I’m working on transitioning it to completely asynchronous, but that has been very hard. We have started to have more teams that are grouped in similar time zones, so we work a lot with stable counterparts and we make sure that everyone is in Europe or everyone is in the US. So, that’s been working well. I think still remarkable how much we’ve been able to do where the group– The company call, its five minutes of announcements and then 20 minutes of breakout calls.
We just hang out together with some people, and the group conversation is a department. They have an entire slide deck, but the contents of the call is just asking questions to them based on that slide deck, and those have been working really well. But I need to find a way where we can rotate a bit more, so that the people in Asia-Pacific also have a chance to participate instead of just asking questions up front and then watching the recording.
Delyn: Right, time zones. OK, we are at our last question before happy hour. We’re going to get our crystal balls out and gaze into the future a little bit. How are you trying to evolve your ecosystem over the next few years? What problems do you think absolutely cannot be solved with a healthy ecosystem?
Mike: We have 1,500 integrations/apps on Zapier today. I’d guess that’s probably 5-10% of all the apps that could ever be on Zapier, given the state of the market right now. So I think the future for us is to just continue to grow and make and grow that percentage to a higher number, so we can serve more customers who use those tools. I think that growth and angle makes me think of what I think ecosystems and partnerships are always going to struggle with.
Coming back to something we talked about earlier, it’s hard to take shortcuts to building an ecosystem. You have to have a really good product, you have to figure out ways to scale that, and get big enough. At that point then you can start to really open it up and build a standardized partnership model for folks to capture some of the value that you’ve created as a company. But there’s no fast shortcut to that by magically partnering with Google when you’re a 10 person company. It’s very rare for anything like that to ever work out, and I think it can mask more problems than it actually benefits.
I think that the real answer there is you just have to stay really focused on building a product that users love, and keep growing it that way, and eventually then you can layer in partnerships and eventually grow into an ecosystem.
Sid: For us, we’ve continually expanded the scope of the product and do more of the DevOps lifecycle. So I’m really glad we didn’t have any very strong partnerships with things that later on we ended up integrating into the product. An ability to partner has been to go deeper, so the foundation on which we’re built. Kubernetes, Hypercloud providers, those are things and those are organizations we can partner with. Kubernetes and Cloud are now our most successful go-to-market partnerships. Just think of VMware and Cisco, and Red Hat as well.
Delyn: What would you say is a problem that you definitely cannot solve with a healthy ecosystem?
Sid: I think you’re seeing a lot of tools right now that have old plugins, and they’re starting to break. So if you depend on plugins to add functionality that should really be in your core offering, what you’ll find is that over time your product becomes stale because as you evolve and as plugins evolve, they break other plugins. So that’s a disadvantage. You cannot test the ecosystem, and people become reluctant to upgrade.
Your upgrade cycles slow down and then you’re in a whole world of hurt, so never use the ecosystem for something that should be core to the product. If your product should function well with X, Y, Z you should make sure it’s a core part of the product so you can test it. Then people can feel safe to upgrade instead of depending on plugins and then trying to have plugins that everyone should have, and things like that.
Delyn: How do you make that call? How do you say, “This is something that obviously needs to be part of our core offering?”
Sid: We went pretty much to the extreme, where we say “Look. It’s open source. If you want to make something on GitLab, just contribute it back to the product so that we have the test there.” We have more than 100,000 tests now in the product. So we make sure that it doesn’t break as you upgrade, and that’s a better experience for our customers but also for the people who wanted that functionality in the first place.
Delyn: How is your ecosystem going to evolve, do you think, in the next few years? What do you think ecosystem is not a good Band-Aid for?
Erica: In terms of how we’re going to evolve, we actually have a major focus of starting to onboard commercial applications into Bitnami. So that’s a pretty significant change for us, we have been focused up until now on open source and some commercial variants of open source. But now that we’ve more productized this tooling we’re going to be expanding by bringing on a lot more enterprise commercial applications. In terms of what an ecosystem is not a Band-Aid for, I’d say a great product. But you can’t build an ecosystem if you don’t have a great product, so I think those two go hand-in-hand.
But one of the most important things for sustaining a great ecosystem is trust. Sid’s response to how they handle this and the integrations is a great example of that, as being transparent and open about potential challenges and why you’re doing the things that you do, and making sure that you stay true to the promises that you’ve made to your ecosystem when building out the company.
If you look at some of the things going on in open source with different projects like changing their licenses and things like that, there’s a lot of great conversations happening about how trust is built and maintained and what implicit commitment you might be making around your product. Staying true to that is really important to maintaining a healthy ecosystem.
Delyn: Being transparent and making sure you are earning the trust of your ecosystem. Thank you very much, everyone. I wanted to thank our entire panel, Bitnami, GitLab and Zapier for joining us today.