Nima leads the Alliance team at Gitlab responsible for partnerships with Hyper-scalers, Cloud Operators, Platform Providers and ISV Partners. His role encompasses strategy, recruitment and go to market success with a growing team of partners. He is a 20+ year veteran of the computer industry with various leadership roles at Google, Pivotal, VMware, Joyent, SixApart, Flickr, Deloitte, Sun Microsystems and Boeing. Nima is a graduate of Stanford, UC Berkeley and UCLA with degrees in Engineering and Business. In this episode Nima Badiey shares his journey, career tips and tricks, and ultimately technical alliances leadership at its finest
Nima leads the Alliance team at Gitlab responsible for partnerships with Hyper-scalers, Cloud Operators, Platform Providers and ISV Partners. His role encompasses strategy, recruitment and go to market success with a growing team of partners. He is a 20+ year veteran of the computer industry with various leadership roles at Google, Pivotal, VMware, Joyent, SixApart, Flickr, Deloitte, Sun Microsystems and Boeing. Nima is a graduate of Stanford, UC Berkeley and UCLA with degrees in Engineering and Business.
In this episode Nima Badiey shares his journey, career tips and tricks, and ultimately technical alliances leadership at its finest
Timeline/Topic
00:00 - Opener
00:14 - Intro to Nima Baidey
00:31 - Nima's Journey
03:20 - How networking is a huge part of career success
12:11 - What are good partnerships, or ones that don't work as well
15:22 - What is Nima's definition of Empathy?
17:35 - The democratization of open source
24:41 - The Culture at gitlab
30:04 - The Nuances of Alliances... What are the different alliances out there?
40:05 - AWS re:invent and building alliances at large events
44:47 - What work in Nima's career is he most proud of?
46:16 - Interlude - Gitlab's IPO Congrats!
Episode Links
https://about.gitlab.com/partners/
https://boleary.dev/thoughts/supplychain/
https://www.linkedin.com/in/jamesjwatters/
Support the show by checking out our sponsors below!
***SUSE Rancher Government Services***
SUSE Rancher Government Solutions (RGS) is a leader in Linux and Kubernetes management for federal and U.S. government entities. RGS leverages SUSE’s Linux expertise and Rancher’s Kubernetes excellence to provide secure open source solutions that adhere to federal compliance regulations supporting SAP HANA, HPC, cloud, edge computing and container management
***Styra***
Learn how to operationalize Open Policy Agent at scale with Styra: https://hubs.ly/H0Pnkm20
***Shipa***
Do you want to give developers an internal platform to enable self-service and application observability, freeing you to focus on implementing application policies and scaling infrastructure?. That’s exactly what Shipa delivers. All you need to get started, land a win with your developers, and save you time is a namespace! Take an online tour here: https://onboarding.navattic.com/
***Teleport***
Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications, and databases across all environments. You can download Teleport at https://goteleport.com/popcast
***COCKROACH LABS***
What if you could build like Big Tech? Use the same powerful infrastructure that they spent engineering centuries building...It’s actually possible now with CockroachDB.
The founders have spent the last eight years creating a cloud-native, distributed SQL database that provides the consistency, ultra-resilience, data locality, and massive scale for modern cloud applications - tech that was once only available to the likes of Google, Facebook and Netflix.
Check them out and get started for free at https://cockroachlabs.com/popcast
***GITLAB***
GitLab is The DevOps Platform. Deliver software faster with better security and collaboration in a single platform. Try GitLab today. https://about.gitlab.com/free-trial/
***Cisco***
Check out Cisco's super informative blog https://ciscotechblog.com/
***CIVO***
Civo is an alternative to the big hyperscale cloud providers.
They've launched world's first managed Kubernetes service powered by K3s. With sub 90 second cluster launch times, a simplified Kubernetes experience,and predictable billing, Civo is on a mission to create a better developer experience.
Get $250 free credit to get started. Sign up today at https://civo.com/popcast
POPCAST SHOW DETAILS (SUBSCRIBE!)
YouTube: https://bit.ly/3xgmmCj
Audio Podcast (Apple, Spotify, and others): http://bit.ly/35MXfte
Follow us on (Twitter): https://twitter.com/PopcastPop
Follow us on (Linkedin): https://www.linkedin.com/company/the-popcast-with-danpop
- [Narrator] This episode of the Popcast is brought to you by these sponsors.
- Hello everyone, welcome to the Popcast. I have a special treat for you today, alliances. Like a lot of people are like, "Oh, what are they?" Like, whatever. I have one of the best, one of the best in the world. This is a Nima Badiey. He's the global VP of alliances at GitLab. Welcome to the Popcast.
- And great to be here, thanks for having me.
- So the Popcast is, you know, if you've watched it, the idea of this is like, I want to hear about your journey, like all the way to getting to GitLab, first time on a computer, like, "Hey, I like this. I want to do alliances," or whatever, where you got to. Let's talk about that.
- Yeah, no, this is really funny, 'cause we just had an offsite with my team, and we talked a little bit about career building, and what your career is gonna look like. It's never a straight line up and to the right. It's gonna be this weird squiggly line. You're gonna go backwards. You're gonna go sideways. So I always start off telling people, I started my career working at the age of 13 digging ditches for my father's construction firm, because I was hands-on, you're low skilled labor, but it's a great way to earn money. First you earn money for, you know, gas money, or whatever you want to do in terms of your summer off, back when those days when we had precious summers off.
- Where'd you grow up? If you don't mind me asking.
- So I grew up in Southern California, in Los Angeles, and it was kind of a great time to be there. But again, I was an engineer or tradesman, a craftsman at heart, and I love to build things and take things apart with my hands. Really curious nature, but you know, you don't go to college thinking, "I want to major in alliances." Like, there's no such thing as alliances. There's not even a book on how to do alliances properly, and I think it's kind of a part of a dark art that most people don't study by virtue of getting a proper book education, but one that's more experiential. So when I talk to people about what, you know, what was your journey? My journey was, you know, construction to pay for college, and then after college, grad school. Grad school I spent a summer building airplanes at Boeing, and then I went and built computers at Microsystems, and I went back to school to get an MBA, and for a brief time, I built PowerPoint decks with Deloitte. And then I re-followed my heart back into technology, and kind of started at the bottom rung, where in my mid thirties, it's, I'm competing with 20 year olds, but I wanted a career in tech, and I really loved that. And I went back to being a product manager, first at a couple of different social media companies, but then by virtue of just building out a network, and getting to know people, you know, stopped getting into that sort of cycle of applying for jobs, and then we're just kind of introduced to people who are looking for a particular skill set, or a particular person to take on a job, and nearly every job I have had, I hadn't done it before. And two people were willing to take a risk on you and say, "You know, you seem pretty smart. I think you can get it. I'm gonna hire you for the company, not the role, because I think you'll grow into it." And I keep seeing a lot of people posting about that, saying to hire for the company, hire for cultural, hire for empathy. The ability, the skillset required to do this job will actually come very quickly and very naturally. So about 10, 10, 12 years ago-
- Can we talk about that real quick? I'm gonna interrupt you for a second.
- Actually, I'll talk about it as in the context of Pivotal where, you know, what I had learned on my own kind of became codified into a way that one company does business, so-
- But I want to talk about the networking aspect. I'm gonna double click on that one, because the networking aspect is, like, if somebody's listening to this right now, you're a pro at this, this is what you need to do to do technical alliances as well. You need to be able to network. If like, the listeners and the watchers here, like, what Nima is like, Here's the things, the recipe for this.
- So I will borrow a page out of someone who has been a huge mentor to me, a gentleman named James Waters, who's now the CTO at VMware for the Tanzu cloud application platform. And so he was my boss when I was at VMware, and he literally, he took a risk on me, because I came in with a reference from a gentleman named Jason Hoffman, who's the CTO and founder of Joint, and at the time Jason had taken a risk on me and said, "You know, I you're a product manager. Have you ever done marketing before?" I said, "Not really, but I can figure it out." And he gave me a job doing product and partner marketing, and that kind of blossomed into other things. But to get back to kind of what James taught me, he said, "In your career, there is an inflection point. For the majority of your career, your network is all about who you know, and then there's a tipping point, and then it becomes about who knows you, and everything before and after that zenith will change." So before that, it's really about, you have a brand. You have a personal skillset. You have a perishable knowledge. You continue to invest in that knowledge. You have an internal network that's built inside of your company of other people who help you do your job better, but then you start growing your network outside of the company, other people who look like you, other people in sister industries, or partners, or customers. You grow that, you grow that, you grow that, and at some point when you tip over, your engagement with individuals becomes different. Like, you're no longer the one who hunts, but the one who people come to, and then you become more of a brand ambassador, right? It's more about your thought leadership. It's more about you investing in your growth network, and this is where you actually start elevating your network. No longer are you meeting with other people who are at the same level as you, but now you're connecting with VPs, with CEOs, with CTOs, with founders, and also in tangential areas. Like if you're in technology, you'll actually connect with VCs or connect with bankers. You'll connect with entrepreneurs and organizations that support those types of people, partly because these are supportive of your network. Like for example, after I had joined VMware, and we got carved out to be at Pivotal, I would routinely, you know, go up and down Sandhill Road, and meet with venture capitalists. It's not because I was pitching a product, because I was really interested in the portfolio of companies that they had invested in. And I was looking for partners who are at the right stage, and provided the right level of services, and technology, and capabilities that could append and add value to what we were doing at Pivotal. At the time Pivotal was a small, fledgling, thousand, 8, 1200 person company. We had just been started. We certainly didn't have enough resources, enough money, or enough engineers to build all the things we wanted to. Well, we could find partners that had products that were mature enough, and new enough, and comported to the whole idea of cloud native architectures that we could sister with, and we could do a great co-sell, or a meet in the market motion together, even do something a little bit more sophisticated than that, and that's really where it started. Then you start gonna conferences, and you get to start meeting people within conferences, and you start collecting conference badges, and at one point I used to have all my conference badges hanging on a hook and it, the coat hanger literally fell over, 'cause it was so heavy, and I still have it somewhere. If we put them all on, you look like Mr. T from the A Team, right?
- Right here we'll have a graphic of Mr. T here.
- Exactly, and it's great, 'cause that's the investment you have to make. And we talk about, this is a job that you can't, there's no acceleration curve for it, right? There's no equivalent to time in seat. You have to invest the time and effort required to build your network, to build your competency, to build that, that capability, that skill set, that awareness, right? It takes time, and it's just, there's no way to accelerate. And so someone doing alliances at the age of 20, it's a great time to start, but think about how much more mature you'll be in your 30s, or in your 40s, or even in your 50s. And the world of experience that you have seen is so much more valuable from someone who's a little bit more senior, a little bit more experienced. So like, for a lot of people who are getting into this job, my recommendation is just kind of build your brand, build your skillset and your knowledge, be curious about everything, but also appreciate that it just takes time. There's only so many hours in the day. There's only so many people you can meet in a given day, and there's only so many experiences that you can possibly fit into a year. You can't inorganically force it. That's been helpful. It's a test of patience, and not a lot of people have the patience to do it. Good partnerships don't happen overnight. It's just kind of continued investment in growth, and personal growth, and personal development that helps you build proper, stable relationships, and those are the ones that you keep with you, because that person that sits across from you, for example, from SIS-TECH that that we're speaking with. They may go on to a different job later on. They're gonna have a positive experience with what they did with GitLab, and maybe potentially me, or somebody else, and remember that experience, and then take it to the next job, and I'll take it to my next job. And that, quickly, you bring all of these great relationships with you, and grow these very important connective tissue in all of your relationships, and I think that again, takes time for you to build the competence for you to build even a reliable brand around yourself, around like, who is this guy, Nima? What does he do? Do I know him? Does he know me? And what can he do for me? To something that is akin to more of a conversation with the person across the table from you, or sitting next to you, as opposed to being an adversarial relationship, which is really not what you want. Partnerships are additive. One plus one is more than two, but it takes a while for two people to, two parties to figure out that narrative, and you've gotta be open to just exploring to get to that point so you can have that better together story. So sorry, it was kind of a run-on answer to your question, but mostly.-
- Yeah, again, these are the things, if somebody is listening to this right now, they know like, these are the things that they're gonna have to like, you know, put together from their career perspective to go to the next level, and by the way, shout out to James Waters. Good, really great guy. I'm actually obligated to say Tanzu, 'cause that's what I need to do. James is a great guy.
- James Waters is fantastic.
- Yeah.
- And part of the part of, I think, what makes James really special is that he surrounds himself by incredibly smart and capable people, and so that rising tide lifts all boats, and allows you to not only learn more, I mean, I've learned a ton, just sitting in the room, listening to the way that the James would pitch, that James would talk to people. He was very inclusive. When he spoke, people would listen, and that kind of gravitas takes a while to cultivate, but he did it like it was drinking water. It was just native capability for him.
- Wonderful, wonderful guy. Like I said, I've had some great interactions with him in the exact, like you said, he draws people to them, you know, the way he speaks, and also it makes people feel part of the solution in the room. It's a very, it's a rare art, and he's one of the best in the world at it.
- [Announcer] Do you want to give developers an internal platform to enable self service and application observability, freeing you to focus on implementing application policies and scaling infrastructure? That's exactly what Shipa delivers. All you need to get started, land a win with your developers, and save your time is a namespace. Take an online tour at onboarding.navattic.com. That's O N B O A R D I N G dot N A V A double T I C dot com.
- [Announcer] GitLab is lead dev ops platform. Deliver software faster with better security and collaboration in a single platform. Try GitLab today. Go to https, colon, forward slash, forward slash, about, dot gitlab dot com, slash free trial. That's https, colon, forward slash, forward slash. A B O U T dot G I T L A B dot com, slash F R E E, dash T R I A L. Check them out.
- Let me ask you this.
- Ask me that.
- I'm gonna ask you this question. So again, you talk about partnerships, and talk about these things. What are good partnerships and alliances, and then conversely, what are bad? Or ones that don't work as well?
- So I'll start off with kind of this answer. Assume all partnerships in the beginning of that, right? It's kind of ideation. Ideation takes on the philosophy that you don't have the right answer, that over time with small, incremental changes, you will be less and less and less wrong, and really good partnerships kind of start off with that premise. You're not going to be able to eat the whole whale on your first deal. You're gonna have to find an in with a partner where you provide a value that is greater to them than the value that they perceive they provide to you. So for them, they believe that it's net positive in their direction, and so you're gonna have to spend some time to figure out well, what's important to them? Is it time to market? Is it a capability? Is it reach? Is it network? Is it a price competitiveness? Feature parody? Is it competitive intelligence? A lot of different variables that start off a good relationship, and then what you need to do over the time is, is once you've inked that relationship, that's not the finish line, right? That's the start line. Then you need to work together to figure out at what point in what motion does it make sense for us always to participate? And that's really tricky to figure out. It's not obvious, because a lot of companies and technology, especially in our sector, we tend to have sometimes, you know, similar feature sets. Sometimes we're slightly competitive with each other, and there's a bit of a Venn diagram overlap. You have to get over that, right? Just accept that there's some things you do really well, some things I do really well. Maybe together, what we can do is solve a customer problem, because more likely than not, we have mutual customers, and they're likely gonna take a look at both of us, and say, "Well, I need both of these two things. I need SIS-TECH and GitLab." But now they're stuck. How do I make the two work together? Oh boy, that's a tax I don't, that's a burden I don't want to have as a customer. What if we get together, and we figure that out for them, and we present an intact idea that out of the box, this is how SIS-TECH works really well with GitLab. This is the service that adds value on top of GitLab. These are the capabilities that now a SIS-TECH user can expand with GitLab in terms of a dev ops portfolio. And you start to really think through from a customer's perspective, how do I solve customer problems that I may not necessarily understand, but have empathy for? How do I exhibit this ability to showcase that I understand my customer's needs, and my customer's needs do not have a direct correlation with my product, or your product? It's really somewhere in between, or a combination thereof. So when we all got to Pivotal, we were introduced to this idea of scoring for empathy as part of the recruitment process. So whenever we would actually interview candidates, one of the rubrics that we used was empathy, and I, you know, delightfully, when I left Pivotal, and joined Google, this was a big part of Google's recruitment tactic and interview process. They were really looking for people who had empathy, and they couched it under this term of Googliness.
- Can we talk about this, just empathy in general, like, what is your, what is this definition? Everybody has their definition of what empathy is, like, you know what I mean? But we're like, what would you say? What is your definition of what empathy is?
- You know, it means different things to other people, but I think at its base, it just, can I see it from your perspective? That's it. Even if I don't agree with you, can I just see it from your perspective? If I can see it from your perspective, I can then understand how to, like, for example, if you're in a negotiation, empathy is really important to you, because you can understand the opposing party's, you know, defensive points, their defensive arguments, their particular position. And as, if you're in the legal profession, it's incredibly helpful for you, why they tell you in a court of law you need to have an adversarial position. Empathy actually is a really, really important skillset for you in any job market, in any role that you have. But in particular, with alliances, half of our job is just understanding the other party, understanding how our customers would use A and B together, understanding how my partner views me, how I should view my partner, how we can, you know, figure out if there's actual middle ground, where we can work together. And a lot of these partnerships here, they really do take time to matriculate. We have partnerships that might take three years to matriculate. I think of, you know, large technology companies that they're just kind of set in their ways. They have a particular way of working, and they may not adopt new technology as quickly as you would like them to, but over time, they will definitely grok the value of something new, and something innovative, a different approach. Same thing with customers, right? Most of the, you know, dot com startups tend to adopt cool new technologies very quickly. They grok it, but larger companies, especially in financial services, or banking, or insurance, medical, manufacturing, energy, these sectors, they look on these, you know, smaller, nimbler startups, and say, "I would like to achieve that. I'd like to be able to do that, but I have an organization that has a lot of momentum that's difficult to change overnight. Now how can I-"
- It's like moving a battleship. You've heard that analogy a thousand times, right? You, you know, like moving a battleship is much more difficult than taking like, a speed boat, and making that change. It's-
- Exactly.
- It's, I gotta be honest with you. It's why I don't go to larger companies. I've gotten these offers all the time, and it's like, so smaller companies to me are much more nimble, right? That's number one, and number two, like, you can react with the times much more quickly. It's just like open source, right? Open source can, is amazing, because you can change courses so quickly, you know what I mean? So, yeah.
- And that's what I, that's one of the things that kind of is the great democracy kind of a democratization of software is open source is a chance for pretty much everybody to have equal voice, and it's a true meritocracy. So in the case of, let's say, let's say Falco, for example, from SIS-TECH, right? I think SIS-TECH saw a very relevant need within the Cloud Foundry, sorry, not the Cloud Foundry, with the CNES, the Cloud Native Eco System, and identified, yes, we'd like to build a product, but the first step to building a product is to, in a community like CNCF is to get consensus. So if we could get consensus on a design pattern on a framework that could solve this problem, then we can actually build products, and services, and monetize on top of that. I think the Falco approach was really great. And one of the rubrics that tells you this is working is when other people started adopting Falco as the underlying technology for solving a specific problem.
- I'm super proud of that. It's, GitLab is again, one of our huge adopters of Falcon. Again, I'm very proud of the community manager for Falco, everyone. I'm sorry, I took my podcast hat off, and put that on. But you know, the way that I look at it is we are community-based, but exactly like you said, it's been adopted. We can offer things like, you know, threat hunter, for instance, for GitLab, you know, it's because it's an underlying basis, and it is a de facto runtime, you know, tool for, you know, runtime detection on Kubernetes. The way my analogy has always been, what Kubernetes is the distributed computing, I feel that Falco is for runtime security. If something's happening in your buy-in, where you're able to see it very, very quickly. And again, like you said, the telltale sign is other companies adopting it. When we did the CNE-BPF day Cooper, at CubeCon, seeing Apple using Falco, and speaking so highly of it, literally I was so touched, but also all I saw all these community members, like folks from GitLab, like folks from, you know, AWS, like IBM, Cisco, all these people that are contributing, they're doing these things. It's exactly like you said, it's a true meritocracy. When people come in and they feel part of this. They feel part of the growth of Falco.
- That's really important too, is in the open source, you want to be able to collaborate, share ideas, and let the best ideas matriculate into whatever becomes the, what's post incubation in CNCF? I don't know what they call it, core?
- It's graduation.
- So it's been great to see that, but at the same time, like from our perspective at GitLab, the problem that we're trying to solve is we consider ourselves a platform, so a platform should technically come with all the batteries included. We want that first getting started experience to be profound for the customer, to delight customer, so that they say, "This is exactly what I needed to solve all my problems." Now, will it have all the features, and all the capabilities that every single customer in the world wants? Probably not. They're going to customize it for their unique environments, but you want to give them exactly everything they need just to get started, and a lot of platform players and customers, and it just actually happened with Cloud Foundry back when I was at Pivotal was we had the added responsibility of considering the customer's needs, and then choosing certain technologies, and embedding that, or including that in their overall getting started experience. So, for example, with, and I'll go back to Cloud Foundry, just to use that as an analogy. Like, we were initially very enamored with, I think it was Andy Wiggins' 12 factor app model, right? And so that's brilliant. That model actually explains and architects, or even roadmaps a much cleaner way of building applications, and there are some simple rule sets. We looked at Heroku, and we said, the bill pack model is fantastic, because now all the environment variables, and everything I need to compile an application into a specific runtime is available for me as a service, and all I need to do is just upload my app, and it can auto detect, and build all the libraries and dependencies I need. Shannon Condos, a product manager at Pivotal was kind of on the forefront of creating the service brokers, said, "Hey, what if applications can actually have one-to-one, one to many relationships with add-on services that are provided outside of the platform layer, outside of the past? How do we describe that?" Well, that's for how service brokers were born. So all these great ideas were kind of born in, and there were included as part of the overall Cloud Foundry package. So when you bought Cloud Foundry from Pivotal, it all just worked. You didn't really need anything additional, and then you could customize it for your own environment, own needs, with just the way you worked. And I think the platform provided have this unique responsibility of helping customers curate what they think they will at least need. Now, most platforms are interchangeable, meaning modules can be replaced with something that's much more sophisticated. Technology does move. Like for example, when I was at Google on Anthos, the SCN started out being, I think it was Calico by Tigera, but eventually moved to EVPF. That was kind of a normal graduation. As better technology emerges, the platform provider's responsibility is to replace the technologies, but make it seamless to the end customer. End customer doesn't have to do anything differently now. So in that guise, it's refreshing to see companies that are developing and promoting these kind of early technologies, really promote and participate with platform providers to help them better understand, well, this is how Falco should be included in these five or six different platforms-
- It's something GitLab does so well. It rolls with it. I mean, again, I think there's things you all do with like, you know, policies, but option of like, normally, Falco there's adoption of all these underlying things that make it better to use, you know, your commercial aspects there. I mean, you all do that extremely well, and extremely quickly. And it almost, it's almost like, like you said, like you see things like at those where initially it was Tigera, and they moved over to Psyllium, for instance, from the EDBF perspective. But it was also, like with you all, I love the fact that you all very much drink your own, you know, apple juice, or whatever it might be, right? You all like, "Look, this is fantastic. We're gonna try to adopt this, and then we're gonna put it in there," and it makes everything even better. But your ears are always out there, and also like, you adopt this very, you know, Git-centric way. Like, you have your principles, like, everybody can see GitLab's you know, principals out there, 'cause I, you know, I had Brendan O'Leary on last night, a couple of weeks ago during Cube Con there, a week before Cube Con, and he talked about those principles. Let me, I'm gonna ask you this one, to go off the reservation and go back here. Let me ask you this, like, the culture at GitLab. I want you to, you know, you've been in companies, a bunch of companies, and you're good. I want you to talk to me about how it seems like everybody who works at GitLab just loves being there. Talk to me about that culture of GitLab culture.
- I will. I mean, I've only been here less than a year. I will parrot that sentiment very strongly. I think every company I have gone to has exhibited an even stronger set of cultural values that benefit the mass, like the, all the employees, all the investors as a whole, and let me back up, and explain what I mean by that. I think what's unique about GitLab is to the public, we took this remote first attitude, and they see it as, "Oh, well, they're a hundred percent remote company, so that must be something that's akin to the way that they work." But if you peel just a layer of the onion back, what we're really saying is we want you to be productive in the environment that you feel the most comfortable. And so you're gonna have people who are, they work asynchronously. They like to work on their own time. They like to work in their own environment where they're comfortable, and they can really be producers. And these are the makers of the world who may not necessarily feel comfortable being in a hyper-socially interactive environment. And I say this, because when we were at Pivotal, you know, the engineering teams had to pair, and when we came over from VMware, there were definitely some engineers who expressed a tremendous amount of anxiety having to physically pair with another individual. What, two keyboards, two laptops, one, one machine? I don't feel comfortable sitting that closely to another person. I don't feel comfortable sharing my ideas on my code. I feel exposed, but the benefit of that was before anybody wrote anything down, or typed anything up, or actually hands on keyboards, we would talk about it. "Hey, is this the right approach? How should we fix this problem? How do we solve this kind of difficult challenge that's in front of us?" And that made the quality of the code so much better. So overall, it was the right thing to do. Within GitLab, it's really about working the way or giving the employees a way, and the opportunity to work how they are the most comfortable. So if you're at home, and you're asynchronous, and you just want to be on Slack, and just do your work, you can do that. If you're like me, and you're, you love being on Zoom, and synchronous, and dealing with people, you can do that too. And so it pull, it gives you the environment that allows you to be the most productive. And, you know, the guides that I say that I now save, you know, two hours of my life, not having to commute, and clog up the freeways, and basically being in an environment where I'm just, in a car you're not productive, right? I don't feel comfortable doing calls, 'cause I can't pay attention. I can't write. So that was kind of dead space from, but now I get that all back, and I'm a lot more productive, which means that I can spend more time with my family. I can stop working at six o'clock and go work out, or go make dinner, or, you know, help my kid with his homework. That all really helps out. And once they're able to curate that environment, then the collaboration comes on naturally. The tool itself GitLab is really designed for collaboration. We kind of talk about our mission statement is really everyone can contribute, and we really do mean that. And I think part of the, the scary part I should say is most people think of Git as like some sort of black art science that only developers know, and oh, you you'll have to do everything in the, in a terminal show, you have to have these Git commands. Well, the reality is no, you can work that way, or you can work in the browser. And this idea of anybody can suggest a change, and a set of editors are permitted to review the change, and approve or deny the change has been around for 20 years. We used to call it Wikipedia, right? So people would write content. Someone would edit it, and it would get approved, and then updated, and improved over time, but that's how code works. Now, if you operate that way, all of your documentation can be created, and developed, and improved that way. Now we get into more sophisticated tranches with things like Kubernetes and network configuration, and infrastructure. Well, I can, for example, put all my Git Ops configuration within code, and curate an update exactly the same way as I do with code, or with documentation. Also we have a shared philosophy of working together. Everything is transparent, it's auditable, it's reviewed. We have an audit trail of who made the change, why the change was made. We have a lot more transparency in the code, and better yet, everything that's configurable can be stored in a single location. So my firewall rule sets aren't in a flat text file on the firewall. My security settings aren't in some configurable proprietary system over there in the corner that only one person has access to.
- My policies, my rules, everything. It's standardization. Everything is here in one place, and again, the enabler, GitLab, and also, here's the reality, financials, right? I mean, this has been, you know, financials, federal agencies, all those. It's super, super hard to do that on some type of public git. And you hear the software supply chain issues, and I'm not gonna, we're not gonna go into that. There's been enough of that. You know, if you want it, you know, honestly, if you want to see a great thing, I'll put a link in the thing. Brendan O'Leary did a great blog about software supply chain. Again, plug, plug. It was just an awesome thing. But I want to ask you this, look, there's, I'm gonna go back to the alliances question in general. It's like, look, there's people like listening to this are like, "You know, oh, it's just, you know, I go talk to the software company, whatever." There's so many nuances to alliances. There's, you know, there's software alliances, ISV partners. There's, you know, like, hyper-scale cloud providers. There's the channel. Can you kind of give like, that elevator of the different types of like, just overall alliances that you can have in a company?
- Yeah, I mean, the principal role of anybody within alliances is to build a bridge, right? That's really what we do. We build bridges between islands that did not previously have connectivity, and I'll kind of walk into kind of how you get into this. So what is alliances? Alliances is basically a relationship between two entities. You're a company and another company, and you'll hear it couched in channels versus alliances. Now, channels historically has been very much a sales motion. It's really the extraordinary arm of a sales organization, where sales has direct sellers. You know, these are briefcase-caring individuals who sell directly to end customers. Channels tended to be more like an agent broker model. There are other entities out there who are selling agencies that we can engage, and we can get a one to N relationship through them, as opposed to one-to-one relationship with direct selling. Channels has an extraordinary ability for a company, especially a growing company, to have a 10 X return on their sales investments. It's a great way to scale up without having to scale every infrastructure resource you have within the sales organization. Alliances typically falls sometimes within the sales organization, sometimes within products, sometimes it's strategy or CTO, really depends on the company you talk to, but these are relationships where basically, three different things happen. One is solution completeness. We partner with company that adds something that our product is missing, that we think customers are going to want, right? Maybe we don't do monitoring. We can work with a Datadog to provide that monitoring layer. Maybe we don't provide a specific area of security. Maybe we can work with SIS-TECH to provide that as an add-on. And that way the customers have that option of like, if I need this extra security, I can buy it from SIS-TECH. The second is to partner with what we call traditional platform providers. A platform provider, is like a Red Hat with OpenShift, or VM-ware with ESX and Tanza, where this is where companies run their applications, run their application estates, run their entire application portfolio on top of, and the reason these types of partnerships are important is because for one thing, as an alliance manager, that's a captive audience. They have a whole bunch of customers all in one platform. So if my stuff works with their platform, technically I have access to all those customers who also run on top of that platform. And then the third type of alliance partnerships are the hyper-scalers, and these are basically platforms to the nth degree with, you know, with exponential growth capacity. The hyper-scale is like Amazon, Microsoft, Google, Ali Cloud, as well as the two true clouds behind them. They're on the vanguard of this kind of next generation motion that's happening, where we've gone from in a, like, you know, 1800s of let me produce my own electricity, to a utility model. I've gone through, let me buy my own expensive sun servers, and have my own data center to I'll let that be managed by a managed service provider to actually, know what? The rate of innovation from these hyper-scalers is so much faster than I could have ever hoped for that I don't even have to pay for software anymore. Everything is a consumable service. I just pay for what I need, and I don't pay for any of this extra stuff. I don't have to worry about installing software anymore. I don't have to worry about uptime of services. This is fantastic. It's a true utilitarian model. I think a lot of big businesses are slowly getting g to the point where they're comfortable with that idea, right? The SLO SLA guarantees are superior coming from the hyper-scalers. The uptime is better. The quality of the services, the rate of innovation, and the lowering cost of the services is at the point where it's just a lot better, more attractive if I actually go that route. Now, a lot of companies will stay on prem, or they will at least leave a part of their, of their estate on prem, because it's very expensive to move, or the underlying technology isn't really cloud native, or they just don't have the resources to move it over. But at some point that inflection curve will happen, and it'll just be much more organic and natural for us to actually start in the cloud, so this born in the cloud mentality will happen. All Fortune 10,000 companies probably have designs and aspirations to be all cloud native, but they're faced with the reality of they have a lot of inventory, of catalog, of stuff that they currently run in different areas that couldn't possibly migrate over. So it might just make more sense to leave them where they are, but then adopt these new cloud native methodologies for the next generation of applications. And they're probably growing their application footprint at a rate of doubling it every five years. So within a couple of years, even a decade, the proportion that's on prem, still on mainframes, still on legacy systems will just be diminishing over time, and the bulk will actually be running on the cloud. So these are the three types of relationships we look for, where GitLab can materially facilitate the adoption and migration of customers to these platforms, as well as their productivity on those platforms themselves. So if I'm a, let's say Ford Motor Company, right? Most of us think of Ford as an automobile manufacturer. I think of them as a software company that just tends to bend sheet metal, and slap four tires on it. The Ford F-150 of a couple of years ago has 150 million lines of code. So at some point, we're gonna realize that Marc Andreessen's vision of software's eating the world has been realized, because every company in order to survive the next 15 years is fundamentally gonna have to resolve that they are in fact, a software company, and software is a core competence. So whether you're providing insurance, or banking services, or medical services, or, you know, energy, everything is now built in software. If you're a manufacturer of oil and gas, you're using software. You're building software. You're creating value and customers through software, and we see this everywhere. Like, nothing has been untouched by it, and so the ability to have a software competence, to have the tool sets that allow you to be much more productive with the limited resources that you have, to get ideas through the ideation funnel, you know, through development, through testing pipeline, validation certification, then out to, you know, your cloud of choice, your deployment target of choice is gonna be super critical, and so we used to talk about the day in the life of a developer as being basically an eight hour day, where you start your day having an inception with your team, a standup, where you share a couple of ideas, you capture those ideas as user stories, or feature sets in your planning tool, then you pull from the planning tool, your backlog, you develop it, you store it in your source code repository, you work with it through ID, and then sometime around 4:00, 5:00, just before you're about to leave, you do your merge request, your pull requests, and your job is done, but then all the automated system, their intake over, and then they build, and compile, and test, validate, and deploy your software image. And so you have in an eight hour period, a tremendous amount of productivity, because you just did something new that didn't exist that morning. And you can see as you're walking out the door, the fruits of your labor, 'cause hopefully on the radiators, you know, your, all your compilation tests are all green, and your pipeline tests were all green, and it means that it's already deployed into production. That that would be the ideal scenario for any developer. I think every developer in the world would love to live in that utopia. We're not all there yet, but slowly and surely, we will get there.
- With tools like GitLab again, GitLab, see here? GitLab.
- [Announcer] What if you could build like big tech? Use the same powerful infrastructure that they spent engineering centuries building? It's actually possible now with Cockroach DB. The founders have spent the last eight years creating a cloud native distributed sequel database that provides the consistency, ultra resilience, data locality, at a massive scale for modern cloud applications, tech that was once only available to the likes of Google, Facebook, and Netflix. Check them out, and get started for free at cockroachlabs.com, slashpopcast. That's C O C K R O A C H L A B S dot C O M, slash P O P C A S T. Check them out. Civo is an alternative to the big hyperscale cloud providers. They've launched the world's first Kubernetes service, powered exclusively by K3S. With sub-90 second cluster launch times, a simplified Kubernetes experience, and predictable billing, Civo is on a mission to create a better developer experience. Get $250 free credit to get started. Sign up today at civocloud.com/podcast. That's C I V O dot C O M slash P O P C A S T. Go check them out.
- You know, it helps you get there, but let's I'm gonna ask you this question. This is airing during a Reinvent week, right? This is, you know, let's talk about Reinvent as a place, you know, and large events in general, like for building alliances, you know, like I think again, it's like, the pandemic was really difficult for you to have these face to face kind of conversations about, wow, it's cool what you're doing. I'm doing something cool. Let's, maybe we can do something cool together, right? So talk to me about like, these events as a place to garner new alliance partners.
- So one of the things I loved about Reinvent was actually the expo. So I almost, in the last eight years I've gone, I hardly get to make it to any of the sessions, because most of my time is spent on the floor, or in one of the little niche coffee shops that are around there, just connecting with people. I think what Amazon has done exceptionally well as a hyper-scale, as a cloud provider, as a cloud partner is they have become the center of gravity for all things cloud-related, almost like the CES of cloud. And so by virtue of pulling all these people in, you really only have to go to two or three or four events per year to hit the majority of the companies you want to work with. So if you're a independent ISP shop, you're building something, you can, you know, quickly pair with other similar companies in your space, build a relationship, build an alliance by just going to Reinvent. You can also build the relationships with your Amazon partners there, and build your capabilities on the, kind of the growing subset of all the services that Amazon provides. And I think at the last count, Amazon had over 160 plus services. That's phenomenal. So if I'm a, if I'm an ISV, not only can I build something that is a value that can run on top of Amazon, that is now consumable Amazon customers, I'm adding something that Amazon doesn't have, but I can actually run my entire business on top of Amazon itself. I can just be born in the cloud. They have a great, fantastic, you know, really fantastic set of services through SAS Factory, and all their application migration services, and all the consultants, partners that they have. And they make it really easy for you to just build on them, and not have to really concern yourself with some of the lower level infrastructure management and orchestration issues. I can build applications that basically interact with Amazon completely through an API, and so all of my guarantees, all of my contracts with Amazon are gonna be software contracts through an API. And I know that they're not gonna change that much, because in most cases, if you publish an API, your intent is not to deprecate that API. It's to append on top of it, and keep improving it, because you want stability. That's the one interface you're exposing to the world. You can rebuild and refactor your entire product behind the scenes, but your APIs, will always remain stable. And when Jeff Basos, you know, enforced that idea within Amazon about, was that 11, 12 years ago? I think he unwittingly set the stage for all things to be API driven, and all connectivity to be API driven, which is fantastic, because it really makes programming a lot easier. I'll just pass you something, some data, some , some payloads. I get something back, and I don't have to worry about that part of my code working or not working any more. You know, it's based on a guarantee. It's based on a spec that's been published, and that's even a little bit cleaner than it's got a standard SDK, because those APIs are always live. I can always test against it.
- And again, that's, I think why, you know, it's what 67% of the market, right? In terms of like, or higher in terms of like, are you using Amazon of exactly for that. You can scale these things using the APIs. You can build more services. You can grow your services as a company, I mean, as developer. You know, we didn't have these things like, you know, like starting out. It was like, you know, PCF helped get, you know, get us to the mid-ground, and then having these APIs, and these other services, like Kubernetes, and all these, you know, helped to do this.
- [Announcer] Learn how to operationalize open policy agent at scale with Styra. To get started, go to the link at H double T, P S, colon, slash, slash, H U B S dot L Y, slash H zero P, N K M two zero.
- [Announcer] Teleport allows engineers and security professionals to unify access for SSH servers, Kubernetes clusters, web applications, and databases across all environments. You can download Teleport right now at goteleport.com. That's G O T E L E P O R T dot com.
- So let me, I'm gonna ask you the last question. And the question is, is what work in your career are you most proud of?
- That's a tough one. I think every subsequent job I've had has had more responsibility with a more visible product, and a more visible company. So I would say every job I've had, I'm more proud than the previous one. And part of that has to be attributed to the people who've helped me get here, so I think a lot of thanks to those who, you know, will probably remain unnamed on this podcast, who've mentored me, who've given me the opportunity, who've been, who've leaned in, provided feedback, good and bad. That's really important for personal growth, and personal development, but it's also the opportunities to actually step into the role. I remember Paul Wright said something when we first started Pivotal. He said, "Look around. For every person who's here, there's probably a thousand people in the world who would love to have your job, but you're the person in this role right now, so make the most of it, right? Do the work, do the hard work, challenge yourself, because you don't get this opportunity frequently." And it's true. He was absolutely right. You don't get to, you know, very few of us ever get to actually be in a company that IPOs let alone do that twice in one career. That's kind of crazy. So knock on wood, be grateful and thankful. I think the other question-
- I'm doing labs IPO. That's on that again.
- It's a great journey.
- It's a great journey, but also I got a lot of friends over there, like Mel Smolensky and Brad, and now you, right? It's just like, there's, it's such a, such a wonderful, you want the good people to win, and when I saw that, I'm like, "The good people won." I was so proud of you all for that.
- It's nice to be rewarded for your hard work, and certainly it's a nice, you know, bobble to put on your shelf, but I think you only celebrate for those five minutes, and you pat yourself on the back. You've earned it, but again, recognize that the work isn't done, right? An IPO is really, you're the third mile of a marathon. We've got a lot more work to do. We don't rest on our laurels. We actually double down, and work even harder. The one question I think you asked in the beginning is kind of, how do you become, how do you get into alliances is the one I'm really curious, and I want to end with that one. There's no right answer, to be honest with you. Like, you can kind of hear, just speaking with me, I've got a little bit of technical savvy. I've got a little bit of product savvy. I've got a little bit of like, like legal savvy, or sales savvy. I have seen people within alliances come from all over, all walks of life. Even on our team, we have folks who have a sales background, people who have an engineering background, those who've come from a pure marketing background, and then others who've just actually never had, weren't born in technology, didn't start in technology or cloud. They had a completely different career path, and somehow had ended up here, and they've taken on that mantle of responsibility, and said, "I'm gonna lean in. I'm gonna learn, and I'll do the things that need to be done for me to be able to build this capability within myself." And they may short time it within alliance, or this may become, you know, ultimately a career path for people. I work with colleagues that have been in their specific area of expertise for 26 years and more, and I also work with colleagues for whom this might be their fourth career, right? All of these people bring something very important to the table, and what makes a great alliance person is the person that really wants to be there, right? Don't inherit the job, take the job, you know? Lean in hard. Don't, there's no gospel that we can follow. There is no, you know, there's no stone tablets. There's no rule sets that you can follow. It's completely unwritten, and I think if you want to be successful, the trick is to lean in. The trick is to listen. Like, be open to learning. Find people who are smarter than you, who've got more experience than you, and see if they're willing to mentor you. An hour, a year is enough, having someone who's super experienced, just tell you what you can do. It's the meta knowledge. You don't know what you don't know. You really don't know your own potential until someone pushes you in that direction, and then you challenge yourself to meet those milestones, and then exceed them. All these are great. I have never met anyone in alliance who has been unable to build on their past to become better at the job that they have, right? So if you're good at sales, use that as your strong muscle, and then work on where you're weak. If you're great as a technical person, start there, and then build out your sales muscle, but do the things that are very uncomfortable to you, but definitely try your hand at it. You know, we have, we live in a culture of we have heroes, right? We want people to win. We don't appreciate the level of investment it takes to get to that point, and when my son was, you know, playing Little League in baseball, it took a while for him to understand baseball is a failure sport. You know, every-
- You're considered a success out of three, you know, 300, you know, right?
- Exactly. Right? It's you're gonna, you're gonna be disappointed. You're gonna drop the ball. You're gonna miss the base. Something's gonna happen. More often than not you're gonna make mistakes, and then, you know, you're gonna have more losses than wins. That's just the nature of the game. But I think every one of those is a learning experience. Winning is a learning experience. Failure is a learning experience, and it, you have to treat it that way. If you make the same mistake twice, shame on you. But if you've made a mistake and learned from it, and can share that learning, that is huge. And we really talked about just you grow that, build that. The last piece I'll leave you with is, you know, when you watch sports, and they do that kind of interview with the coaches, I love watching the coaches that don't necessarily debug themselves. Like, what went wrong with your team today? Who didn't play well? But elevate what the other team did well. Like, I recognize that coach so-and-so did this play, or the linebacker ran this particular app, or, you know, the quarterback was really able to be situationally aware, and step out of the pocket, right? That is really important to be able to recognize excellence in others, and understand what you can learn from it, because your own experiences are gonna be super limited, and you're only gonna be able to see a couple of colors within the rainbow, but to see all the colors, all the potential, it's really important to pay attention to what other people are doing. This is where your network is really important, because we have to invest the time to reach out to people, have phone calls, Zoom with them, go grab a drink, dinner, socialize with them, right? Part of our role is being hyper-social. It's super uncomfortable for those of us who are introverted extroverts. We get to come back home, recharge, go back out again. But I think it's super important, because that network gives you information that you don't normally have. You can't research on Google. It's not available in your email. It's nobody on Slack you can ask, and you didn't have the experience, but to build out your network is super critical within an alliance organization, because they will help you think through your problems in a way that you haven't thought before, and I do this all the time. If I'm trying to do something new, that's untested, different, or I haven't done it before, there's a huge network of people I can reach out to, and ask them, "Have you ever done this before? How did it work out for you? What should I watch out for? What are the mistakes I'm gonna make that I should just at least be self-aware?" And overall that will, that I think that will serve you well in how well you can do within an alliances organization. And then the end of the day, yeah, sometimes you've got bad days, but you also have good days, so celebrate those as well.
- So you all, again, you got an education, an education from one of the best in the biz in terms of technical alliances. He's seen it all. He's done it all. This has been one of my favorite episodes this season, Nima. Thank you so much for what, you know, again, just providing this. Let me speak a little Farsi to my friend here, mercy for everything. I appreciate it, and hopefully at some point we'll get out to Los Angeles again ,and we'll maybe have some koobideh, or maybe some tahdig, or something like this.
- I like that, any chance to go out and eat, and celebrate is fine by me.
- Thank you so much for being on the Popcast, Nima.
- And it's been my pleasure. Thanks for having me.