Interview with Barbie Brewer
Auto DevOps is a fully featured CI/CD pipeline that automates the delivery process. Simply commit your code and Auto DevOps does the rest. GitLab
the open source project, is used by more than 100,000 organizations and has a large community of more than 2000 people who contributed code. The company is remote only with 300+ people working from their own location in more than 39 countries.
What are developers looking for in a DevOps application? Is there anything they should be looking for that they tend not to consider?
So true to our value of transparency here GitLab, I might be a little biased in answering this, as I will be answering in the context of GitLab. Much of what DevOps tools need to do right now for developers has matured, so the time is right for consolidation to a single application. So the first thing I think you should be looking for DevOps tools is a single application. This gives you the advantage of dealing with a single vendor rather than an ecosystem of partners. It also gives you one database and one API so that you can develop your own integrations if you'd like to, we have more information about that in our handbook. I also think that you should be looking for innovation. GitLab as a project and a product that is consistently improving. Many other platforms have slowed down or stalled their rate of innovation. At GitLab we add significant new value to our users and our customers every 30 days in a new release and we're pretty religious about making sure that goes out every 30 days and I really think it's safe to say we never missed that. I also think you should look for open source. It's really shocking to me that in 2018 most developer platforms are closed source, developers can improve GitLab themselves and for others, which makes the entire product and the entire ecosystem stronger because we're all contributing to it and the ability for everyone to contribute is a really strong advantage.
How should companies go about defining the culture they wish to cultivate?
This is an excellent question and one that is very hard to answer in just two minutes. But I would start with ensuring that your culture matches your product and your product matches your culture. Don't do things within your culture and your values that contradict what you're trying to achieve as a company and the reason that your product exists. An example of this at GitLab would be transparency. We're an open source company and so we've decided to run ourselves as an open source company not just our product but our people operations and much of what we do is very public facing and more so than I've seen it pretty much any company I've come across or worked at are. All of our OKRs are out there for the world to see. Our handbook is out there for the world to see and there's much more in it than a typical handbook. It's not only there for the world to see, but it's there for the world to contribute to, even if you don't actually work at GitLab you can make changes to our handbook and someone GitLab can merge that change for you. So the transparency is an example of our product and our culture coming together. And that's something that you really should strive for when developing your culture and your values. Another thing that I think you need to be very careful about in building your culture and your values at your company is inclusiveness. So often we look at values and culture we can use values as a culture as an excuse to discriminate and they never should be. Even if you have very strong values that you need everyone to be aligned to and have that really strong DNA and backbone. You also need diversity of ideas, perspectives, backgrounds and that drives innovation and that drives success. So taking inclusive and diversity for granted will be a detriment to your company and a detriment to your culture. So you should focus on that and how you're going to embed that, what you're doing it takes away from it and what you can do that will add to it. You'll be amazed at how much more innovation and productivity you get when you actually believe and act like everyone can contribute and enable everyone to do so. You also should know yourself.
Has your experience with GitLab taught you anything interesting about productivity?
I have been delightfully surprised by the productivity that exists that GitLab who is an all remote company. I would have thought we'd have some loss of productivity in an all remote company. But we don't. In fact, i would say we're more productive. We enable people to contribute regardless of where they live. We've got over 300 employees but they're in over 40 countries and probably over 275 cities. So we've had to learn how to be productive when we're not all in the same room and in doing so I think we've actually improved productivity. Not only do I not waste three hours in the car driving to work every day but I also have access to everyone at the company not just those that sit near me because we've used technology and we've used processes and procedures to make sure that we are including everybody. And when you include everybody you get everyone's ideas you get more innovation you get more diversity in perspectives because of is coming from a different place in the world. They have different ideas. Rather than decreasing productivity, it drives more productivity, drives more innovation and it is an amazing thing to experience. I also think that the way that GitLab does iteration makes us much more productive. I will tell you it's been one of the harder values for me to learn and get comfortable with but as I do I find myself getting much more productive and that's wonderful to see. A key is also learning how to work asynchronously at GitLab and that's been new to me. I've been at companies who have global offices but haven't really put the effort forward to make sure that they can work asynchronously in all office locations feel included in the discussion. At GitLab we're all in the same boat. We're all working remotely so we make sure that we're including everybody and it's a wonderful feeling to have that you didn't miss out because you happened to be sleeping during the time of that meeting. People take the time to record their meetings or document their decisions in the context around it. So regardless of what time zone you're in you can still contribute and still be part of the solution. And that really helps drive productivity as well. It's a wonderful thing to experience.
How does the HR challenge at GitLab compare to that at your previous companies?
So there were definitely some unique challenges in HR working at GitLab. But it makes it fun. So one is compensation. We have over 300 employees in 40 countries and lots of different cities, different marketplaces not all that have market data on compensation for these roles. It's wonderful that we're able to employ people in roles that their town doesn't have and they don't have to leave town to do that role but it does make things like compensation and diversity more challenging. Diversity more challenging because everyone is coming from a different perspective in a different norm. But we have to come together and make sure we're treating everybody with respect and inclusively and we're coming from different definitions of what that means. So I am definitely trying to teach the company to speak up say something if they see or hear something. Don't let people keep fumbling over their mistakes but be willing to accept mistakes and then teach people how to stop making them and be very diverse and inclusive. The remote work is unique. We're scaling and growing very fast, that's unique. Remote management is a different management styles says we get leaders and who are working remote for the first time. They need some coaching and guidance and training on what that means and how to manage their teams. So those are things we have to work on as well. But in general these challenges I think are wonderful because I think if we can get more companies operating this way we will have more people and more areas of the world having wonderful careers and positions that can really support their communities and their families, their lifestyles and we will get it right. We'll make mistakes, it won't always be easy. We're constantly iterating on a compensation but I trust that in our culture where everyone can contribute we're getting to a better place and we'll continue to do so. But the challenges are there. And we're having fun working through them.
HR requires an understanding of people on a personal level, and also across the breadth of a company. Do you have any tips for keeping both perspectives (and everything in-between) in equilibrium?
At GitLab working at all remote company we do have to make sure that we do things thoughtfully to make sure that we're building a strong relationship and knowing each other and building trust with each other. So there's a number of things that we do around this. One is the company calls, which are every morning Monday through Friday and then one evening for some of our team members that live in Asia and we talk about our lives. There are about five minutes a company meeting information but then it's really social. We talk about our kids, our pets, our cooking, our games, our travels, our movies, our books. And it really is a social time for us just to get to know each other. And you get to know more people than you would if you were in an office space where you really just talk to the people who sit around you. I get to learn about people in Nigeria, Zimbabwe, the Netherlands, China. It's really an amazing opportunity to get to know people from all areas of the world. We also do functional group updates on a regular cadence of each group talks about what they're doing, in their accomplishments, their plans, their challenges. This is a time for us to talk about that in about 10 minutes and then give the rest of our team members opportunity to ask us questions for 20 minutes. So we do those, and all these calls are calls that we record. So if you were missing that meeting because it wasn't a right time zone for you, you can still go in and hear what was said and get to know people that way as well. And then you can reach out individually to whomever you want. And we have technology that it facilitates those one-on-one discussions as well. I do open office hours every week where I just open a video window and anyone who wants to can come in and ask me questions can talk to me. And that's also a great way to make myself open for people to talk to from the company. Anyone who wants to. We also introduced eight of our business partners who should be working with our managers to make sure that they understand that they're people managers not just project managers. And that means knowing your team knowing their motivations and being there for them and being able to coach them and myself and our business partners should be able to assist managers in doing that. But yeah it's a fun challenge here at GitLab.
Hi Barbie! DevOps is in itself a culture of sorts. Are there any cultural differences between GitLab the organisation and GitLab the system?
A big part of our culture here at GitLab is to use our product, drinking our own champagne is extremely important to us. We run the whole company on an instance of GitLab and that's not just for developers. That's for sales, for marketing, people ops, finance you name it. If you join GitLab you learn Git and you learn to use GitLab. You start contributing to our handbook, uploading your picture and information about you onto the team page. For example, something that we all do ourselves, we create branches, merger quests, read diffs. And it's really a great way to understand the product really well but really we use the product to run the company. We're also believers in clear and consistent terminology. So you see quite a few similarities between our product and our organization for instance terms we called dev op stages 'monitor, plan and verify' and those are present within our product management pages, within our team names, within our titles for developers and our designers. Now one difference between what we do at GitLab and how we advise our customers to steer their dev ops culture is that we're an open source Saas. Most companies have only one context for their code their SaaS. In our case, we have ourselves managed version, we have our GitLab.com version. Makin sure that the context remains equal in the minds of our developers is a unique challenge. In the case of open source, we also have open source contributors outside of the actual GitLab company who nevertheless need to write features that will work at a GitLab.com scale. So that's a unique challenge that we face at GitLab.