 Hi, my name is William Chia. I'm a product marketer at GitLab, and this is a customer persona video a Customer persona is a generalized way of understanding a person within an organization That fills a particular role now Everybody is different and everybody has specific needs that depend on the situation But a persona is a is a type of general profile that looks at a type of role and asks What are common to most people that fill this role within most organizations? What do they care about? What are their wants and needs? What are the things they struggle with so that when you talk to somebody in this role you can tailor your language To that to that specific person's needs. So this video is for a DevOps director So first let's take a look at their their kind of role and in within the organization What's their mindset? What are the attributes of a DevOps director director of DevOps? So this is a role that is hands-on. They're they're an owner and operator They're a person who defines architects builds integrates and they care about tools and processes and They're leading the team that actually uses the tools So this is a very hands-on role. They they're builders. They're doers And they lead groups of people that are actually using the tools as opposed to a more strategic role That may be more distance from using something like it lab So this person in particular owns and improves the delivery pipeline So very specifically the the director of DevOps is going to care about their source code repository They're build solutions continues integration continues delivery. They're going to care about infrastructure testing packaging and container and their deployment tools So that delivery that software delivery pipeline is what the DevOps director cares about and manages They they care about maintaining code base integrity So they're going to care about things like code quality and adhering to security and compliance standards So they want to make sure that the code that they're shipping into production is is of high quality It's going to be running without bugs and doesn't fail and it's going to run in production at a high quality This is somebody who understands Automation and is generally seeking to drive more automation and how to integrate multiple tools together This is something they normally do This is the DevOps director tends to research evaluate and recommend tools But may not necessarily own the budget especially in larger enterprises They're the ones who will do the evaluation for their team But then we'll often do a recommendation up to to somebody else they'll tend to report either into the engineering org or Sometimes into a specific operations group depending on the company to make a purchasing decision So what is a what is a DevOps director care about? So they want to implement better people processes and technology So they're continually seeking to optimize and speed up the software development delivery process They want to improve the quality of production releases So they they want to not only move faster, but they want to do so with greater stability And so the DevOps director is tasked with both of those things which can be at odds with each other They are tasked with helping the enterprise move towards more automation So DevOps in particular is about automating Processes and this is a a main part of the director of DevOps role They as a result in order to automate things in order to make things more stable And in order to make things move faster They are going to want to formalize and standardize processes So there might be smaller development teams within the organization that start a new process or start a new tool That are a testing bed to show that there can be some success somewhere and a DevOps director It can also be on the lookout for One team doing something well that then they want to they want to standardize out across the organization They generally want to simplify things so they don't like having Multiple tools. They don't like having a lot of complexity because that slows things down. That's very hard to manage so Simplicity and standardization go together The director of DevOps is usually not responsible for defining security standards But they are responsible for implementing those security standards So they do care a great deal about security gaps and they're tasked with with implementing security standards Another point and in the same way that they're tasked with speeding things up while also maintaining great stability That can be at odds with each other another challenge for the director of DevOps is they're often tasked with innovation So in order to move things faster In order to do better you have to change and you have to innovate but at the same time You know, there's a lot of risk involved when you're doing new things So the DevOps director is going to tend to want to use proven technologies So yes, they want to innovate. Yes, they want to move forward But they tend to want to know that other organizations that have done this as well Other organizations have seen success with this as well and the one is proven technologies And for the most part the director of DevOps is not defining strategic initiatives But they're the ones that are tasked with implementing those strategic initiatives. So Certainly if you can find out with an organization, are they You know, depending on their level of maturity, are they part, you know doing digital transformation or digital maturity? Are they just trying to adopt DevOps or are they trying to go cloud native? Those kind of larger broader strategic initiatives or even, you know, supporting new technologies The DevOps director is not necessarily defining those But they are tasked with implementing and supporting those and so they do care about where the org is moving strategically Some of the challenges and the pain points Multiple teams using multiple different tools So a DevOps director has to be familiar with all of the tools and this can create amazing time sink for them Just trying to get familiar with all of the different tools that different teams are using or that teams could be using That can be a time sink and a frustrating process just keeping up with it all in addition multiple tools can mean multiple licensing costs and multiple vendors and they can be very costly and Trying to train their staff and try to train themselves on using all of these different tools can also be a high cost the director of DevOps and Many many engineering and development directors anybody who manages engineers is Constantly trying to manage new hire bias and preferences And so a big pain point is as new employees come in they have a set of tools and technologies Especially engineers DevOps engineers and developers. They care a lot about the tools they use and they're very They're very partial to the things that they use And so as new folks come in They can often look at the suite of tools that an organization is using and not be happy about them They can often want to bring their own new tools in or it could just be a blocker to hiring in general if if a company is not using technology that Engineers want to use then engineers are just going to go somewhere else where they can they can work with tools that they Enjoy and they can work with technologies. They're excited about So this can be a blocker to the hiring pipeline and it certainly creates friction for new engineers that are coming in You can do a lot of work and a lot of relational work to get everybody standardized on a tool And as soon as you're bringing in new engineers, they they're gonna, you know rage against whatever the Existing set of things are and you know want their own things. So that's a big pain point. That is a continual continual thing director of DevOps needs to manage Another pain point can be Legacy tools can have limited functionality and so they can be trying to accomplish something and the tools they have if it doesn't have that capability That slows them down that can be a huge pain point Similarly poor integration of different tools So this is especially managing different tools from different vendors or even from the same vendor that are not designed to work together This can be a huge pain point Starting up new projects means you have to integrate all of those tools together Not just once but continually having to do that and those integrations between those different tools can be very brittle so they can break easily and You know cause the need for continual maintenance and so this is a this is a cost-to-pay of constantly needing to maintain You know poorly integrated tools Sometimes even needed to define that customer integration and then even to own it and maintain it that can be a pain point Towards that end lack of automation or manual processes is also a pain point. So anything that needs to be done manually You know the director of DevOps is constantly looking at what are we doing manually? How can we automate that to make it faster and to make it more stable and more? Uniform more uniform more consistent They care about the stability of the production code So what are the barriers or the blockers to a director of DevOps coming in and wanting to adopt new tools? Well, first of all like any role is the internal politics You know as you know, I already kind of mentioned new developers coming in that you know have a preference for their you know tools Existing folks, you know, just have a preference the users want to use what they want to use So there can be internal politicking Management could be particular to a certain tool set or turn certain technology or It could just even be folks are just measured on different things and they have different needs and so You know the security team might have different needs and desires from the development team or Different needs and desires from the management team And so all of those different parts of the organization can be at odds with each other And there could be a lot of politics that need to be played Especially the larger the the enterprises the more this comes into play Talent as I already mentioned Not only using technology to attract talent, but if you have talent and they are familiar with a particular technology Then there's a there's a high degree of pressure to use that technology because you have You have people and human resources that are already skilled and adept at that technology so having that right skill set and Being able to make effective use of your tools rather than having to train and rather than having to learn and rather than having to come Come up to speed on the new tool set that can be a blocker to adopting new technologies Simple unfamiliarity, so I'm familiar with DevOps as a whole so in the broader scheme of all things DevOps can still be relatively new. So the the director of DevOps You know often has a need to to evangelize and justify their role within the org and show progress and so You know trying to get buy-in from multiple folks can be a blocker and also this can diminish The the desire to to have risk and wanting to go more with proven tools So that they can they can show the value A huge a huge blocker and a huge pain point for director of DevOps can be meeting everyone's needs so they're obviously tasked with um, you know owning the delivery pipeline and This needs to this needs to be um This needs to meet everybody's needs across the org so different groups can have different preferences for tools or even just different needs Um, depending on the language the programming language they use or the technology requirements. They have, uh, you know If they have a if they have a tool that supports deployment for and and You know software code quality and testing Of of their particular set of technologies Um, then they're very very apt to stick with that and they're not going to want to adopt a new tool Unless it supports all those requirements And not just the requirements for their team, but they're tasked with the requirements across the org Uh, another blocker to deputy tools could be the fact that today they're not may not be measuring Or they may have a very minimal set of of measurements And key performance indicators kpi's that that that they have a hold of so As they want to justify their role as they want to show progress Um, you know, it may be hard to tell them. Well, you have a you have a problem with something. You're not moving fast enough Uh, they might feel that they might feel they're not moving fast enough But they don't have the measurement and they don't have the they'd have an instrumented The the measurement in place in order to show how fast it is and then in order to show progress And um, that may be a prerequisite to adopting new technologies Rather than just wanting to adopt the technologies. They want to know can they show can they show improvement? Uh, finally, uh, depending on the uh, Depending on the industry in particular healthcare in the u.s. And abroad financial services Um, you know any place that's dealing with money, uh, you know, or just depending on the region Um, heavy compliance requirements, especially the larger enterprise The more likely are to have their own internal compliance standards That are not regulatory, but just that their security and compliance team Want so that things are uniform and is that they mitigate risk? um, and so in larger the larger the organization the more likely they are to have Uh heavy compliance requirements and that can limit your choices And also even smaller organizations and heavy heavily regulated industries can kind of suffer from that from that blocker to adopting new technologies Uh, so what is a purchasing journey generally look like for a director of dev ops? Well, the first thing they're going to want to do is understand the needs from their different stakeholders Uh, you know, they're going to want to understand the the developers needs. They're going to want to understand management needs they're going to have um different organizations, uh, or different groups from from development to operations to qa That have different focuses to security um And they're going to they're going to want to anticipate, uh You know These different barriers. So maybe it's from the security team or the compliance team or from the it team, uh, they have to manage and just they just actually have to understand the needs first before they can even manage them Then they're going to have, uh, you know a research and evaluation phase um, where they're going to they're going to look for They're going to look for tools and of course Those that are that are popular that are easy to understand are going to close the top Um, and so once they kind of have done some research and evaluation, they're going to want to build a business case Uh for why we want to adopt this and so this is going to be showing value propositions Showing how much it's going to cost and what the return on investment will be How adopting this tool or technology can support the enterprise the strategic initiatives, uh that are in place um, and uh, they're going to want to show, uh, Potentially some type of roadmap to say how long is going to take to adopt this and how soon are we going to recoup these costs? uh, those those types of uh, you know build that case together and then, uh, They're going to want to get buy-in from all of their various constituents before make a recommendation up the stack To the uh, to the person within the organization who has purchasing decision, uh, and and has the the budget approval Um, depending on the size of the organization, you know, it may it may go up or down the stack So, uh, what are some things that you can tell, uh, you know Somebody who's in a director of dev ops role or dev ops leader role within within an organization What can you tell them about get lab? Well kind of think about these things that we've just discussed or things that i've just talked about Uh that are you know, what is this person like? What do they care about? You know, what are they trying to accomplish and play to that? What are their pain points and tell them how you can alleviate those right? So here's some recommended messaging the first is that developers love get lab So one of the pain points of the director of dev ops is that they want to make sure they can drive adoption They want to you know, manage new users coming in and not liking what's there um And by and large developers operators folks that use get lab love get lab. It has a great user experience Uh and it actually eases the drive of adoption So they're they're going to care about standardization throughout the organization great user User organization great user experience. It's going to help drive that adoption And they're going to care about pleasing their constituents, you know pleasing all these kind of different organizations Great user experience helps for that and they're going to care about, uh, you know getting this out great user experience similarly, uh The they care about simplicity and standardization Uh, and they want to they want to reduce the brittle complexities of of broken integrations that uh, that that Cause extra time to maintain So a single application because get lab is a single application for the complete dev ops lifecycle This is going to simplify their tool chain or it's going to it's going to, uh, eliminate the tool chain if they adopt to get lab end to end Uh, probably not eliminate tool chain all together They're going to use some other types of tools somewhere But in terms of their dev ops lifecycle because get lab can eliminate that dev ops tool chain Um, it can it can reduce or completely eliminate that that integration complexity They have one tool that does that does the job end to end. Uh, that's that's a powerful value prop uh On the other hand that could be very very scary Uh, if they say oh, I've just spent three years integrating all of these disparate tools together I really don't I don't want to rip or replace everything tomorrow. That sounds really painful. I don't want get lab Well, you don't need to adopt every part of get lab all at once because get lab has world-class integrations There's no need to rip and replace so a lot of organizations just start with source code management Uh, and then they gradually adopt other parts So for example, they might then move to the continuous integration of get lab And so there you can start with one part of get lab and gradually adopt it And as you adopt more of get lab you can see more benefits from it Um, so that's a really powerful attribute that you um when you use it all together It's very simple and powerful. Uh, but you don't need to use it all together. It actually functions very very nicely Uh in component parts. So that's very uh, that flexibility Uh is That shows value to this persona So, uh, another thing that they care about again is is innovation and speed, but they also want stability And so get lab delivers both of those. First of all get lab delivers very very fast pace of innovation This is going to future proof their technology, right? So not only when they adopt get lab today are they getting very very, uh, cutting edge technology very Very very, uh, modern features But get lab ships Every single month new features. So, um, we're one of the top 30, uh, fastest You know fastest shipping open source organizations according to the cncf. So, um We ship very very fast. We move very very fast So we know how to empower other organizations to move very very fast as well And in this sense get lab can serve as a strategic partner With with the businesses that we work with To enable and future proof their their innovation because not only is get lab going to have the features that they need today but Get lab is also continually innovating and going to have the features they need tomorrow when they need them without having to wait Because we move quickly At the same time, uh, get lab has amazing features for strict security governance Uh, so this is shipping. This is agility with resiliency, right? This is shipping fast and shipping stable Uh together and having the best of both worlds So because you can deploy on prem and have full You know full control with security side on sso one set of One set of user permissions instead of having to manage users across multiple sets of tool chains By having one application and only having to manage one set of user permissions That gives you a lot more control and of course get labs, uh, automated security functionality allows you to ship software that is More stable more support more reliable more secure But also at at speed Because it's automated Finally, get lab is going to help support some of these strategic initiatives in particular, uh organizations that are looking to go cloud native And whatever point they are at that that that adoption whether they're just adopting dev ops or whether they're um, you know just moving to microservices or whether they You know, they're a robust cloud native organization Get lab is designed for kubernetes And it is a is a very very powerful tool there. So it is going to help them, uh drive Drive those strategic initiatives by adopting get lab as a technology Um, so that in a nutshell is the director of dev ops