 Hi, my name is William Chia. I am a product marketer at GitLab, and this is a customer persona video. Now, a customer persona is a generalized profile, a way of looking at a role within an organization, and what are some common attributes of that role? What are some common ways that people in that role think about things that they care about, thinks about things that are painful to them, and by understanding those things, you can have some empathy for people in that role, and you can speak specifically to the things that they care about that might be different from other concerns of other roles within the organization. Now, that's not to say that specific people don't have very unique needs, depending on their situation, which they might, and so a customer persona profile is not going to apply generally to everybody, but in general, in most cases in most organizations, a customer persona is going to give you an idea of what those types of people tend to care about. This is a video about the head of IT. Now, the head of IT, what does this person do? Now, this role could be a director or a VP, or somebody who is just a leader within the IT organization. What do these people tend to be responsible for and care about? This is somebody who tends to validate the way that they are doing it. This is somebody who is not necessarily in their purview, but because they're responsible for running and making sure the infrastructure is there to keep that tool up and running and doing maintenance on that tool, doing upgrades, IT is responsible for that. So, they're an influencer and somebody who cares a lot about what developers are doing and what they're doing, but they're an influencer and somebody who cares a lot about what developers and operators are using within the organization because they have to support it. They are potentially responsible for budget. So, sometimes they would be under the CIO or sometimes they're in the ops or the COO, but in generally, the IT may recommend budget up or the head of IT just may be responsible for the tool's budget and maybe the owner of that budget. They are going to support a technical infrastructure that's using the day-to-day businesses, day-to-day affairs of the business, and their goal is to deliver software interfaces that are robust, predictable, and available to all employees. So, in a sense, they're providing tools as a service to their organizations. A lot of IT organizations, and in particular the head of IT, is going to think about the people in their organization as their customers. That's their relationship or at least that's the way they think about their relationship often. So, they can maintain both cloud-based platforms and stand-alone platforms. And one thing that is key is that within the IT role, they're very, very often concerned with mitigating risk and with being conservative. So, in difference to other roles that may be more concerned with innovation and driving things forward, this is not necessarily what IT cares about. IT is going to care more that things are stable and that they're working and that people are being serviced and that things are up. When things are down, that's bad for IT. So, they're not necessarily always concerned with being on the latest and greatest and much more concerned with mitigating risk and keeping things stable and running. In some companies, they may maintain the tools themselves. The IT organization is responsible for installing, upgrading and running that software, making it available to others. In other organizations or in other scenarios, they're more than happy to hand that off to the engineering org to run and operate themselves. And so, this is a place where different organizations can be different. Sometimes, they're an influencer. Sometimes, they're an owner. Sometimes, they are responsible for running and maintaining that tool. Other times, they'll hand that off to a particular team organization. In most cases, the IT organization is going to be very pragmatic. So, they want to know what are the resources required? What's the project timeline? What's the budget? Carrying less about what are the shiny whistles or the new functionality that I can do? They want to know the details. And then, they're also going to want to understand about the product roadmap. So, there is a mentality, buy and hold, sort of speak. They want to have a tool. They want to adopt it. They want to have broad adoption across the organization. And then, they're not going to want to change that for a while. That's a lengthy process. The more disparate tools there are, the more things they have to support. So, they are concerned that the technologies that they're using and the tools that they implement have robust organizations behind them. They're going to be around for a long time and have robust roadmaps. That's something that they care about so that they look at the tools roadmap so they know it's going to support their own organization. So, what are the drivers? What are the things that these folks care about? So, they're not typically involved in driving an entire overall process. They're usually concerned about the component which is providing those services to their users. In this sense, within the role of an influencer and the IT buying cycle, they're concerned about preventing additional strain on existing resources. They don't want to implement a bunch of new stuff that the folks in their org then need to go and support. They don't want to have too much diversity in their portfolio so that then they have to support all these different tools and that causes strain on their staff. They're very, very concerned with ensuring security and keeping within budget. Again, this is like mitigating risk. They want to support and service the organization. In some organizations, IT as a whole and IT leaders in specific, often the way that they're measured and judged can even be on the organization's net promoter score. Essentially, with the organization being the users of the tools or the customers of IT and their support of those tools, they're measured on how happy those users are. Sometimes, not always. In other organizations, it's not that extreme. But in most case, most IT leaders care about their users. They want to make sure their users are supported. That is their predominant concern. And in many profiles, they're going to care about what kind of strategic value am I adding to the org? How am I growing skill sets in the organization? Traditionally, IT is seen as a cost center. It's something like we need technology so we need to pay for these tools. But often, sharp IT leaders are looking for ways to say, how am I driving strategic value or how is my organization driving strategic value for the business so that it's not just a cost center but it's showing how they're providing value. So what are their challenges or their pain points? So a huge pain point of IT leaders is shadow IT or essentially tools being used without approval. So different folks within the org just spinning up and running whatever they want to run. And this happens in every organization at every size, somebody somewhere is running some shadow IT. And this can be a huge pain point on a few different levels. So first of all, lack of visibility is also a pain point. If they don't know what's happening, then it can cause problems. I remember in particular, somebody once in a company I was in spun up like their own DNS server and put it on the network and it brought down the whole network because somebody was running some shadow IT and there wasn't the right security processes in place to shut that down. And so it can be something as painful as that where a rogue user using a rogue application, just trying to get something done but because they're doing it not approved by IT, it causes a bunch of broader problems or security vulnerabilities. It can be that severe or it can just be the sense of people are using different things and they want it to be supported. So as long as it's working, as long as things are good and they're happy, then they don't bother IT. But as soon as there's a problem or as soon as there's bugs or as soon as there's something starts to break, then they're going to go to their IT organization for support and now the IT organization has to go and support all these different tools. So that can be a pain point. The IT organization is going to, like many personas, want to balance agility with stability. So they're going to want the organization to be able to move quickly but they're also going to want things stable. Here in general, most folks that are going to be in the head of IT role generally are going to care a little bit more about the stability side of that. They are going to want to maintain competence. This is a pain point. Technologies are always quickly evolving. Things are shifting so fast. It's very, very difficult for IT leaders to make sure that their organization is always trained and always competent to support the latest technologies. This is a key pain point. Managing the staff resources, not only making sure their existing staff is confident but make sure that they're completely staffed and have enough staffing to support all of the new tools. That can be a pain point. Mitigating risk is a huge concern for IT leaders. In particular, they want to prevent security incidents, as I described earlier with shadow IT can be a security problem. Or with many different tools or with folks adopting tools, basically licensing costs can run over budget than what was planned. An IT leader is going to be concerned with mitigating those types of risks. Mitigating security risks, mitigating budget risks, and others. So what are some of the barriers or the blockers for ahead of IT to adopting a new technology like GitLab? So first of all, there could be perceived security risks. So there's always a risk with adopting any new tool. And even though GitLab is extremely stable, it's extremely secure. It even helps to drive security. The perceived notion that anything new has security risks, and it does, any new tool that's adopted needs to know how it fits into the organization so that security risks can be mitigated. But anyway, that perceived risk can be a huge blocker. The availability of resources with the right skill set can be a blocker. So depending on the organization's maturity, where they're at in their maturity, if they are just beginning the journey of DevOps or if they've been doing it for a long time, it can just be hard to still staff to find folks that have the skills to be able to implement DevOps. As in the broader scope of all things, DevOps is still relatively new, even though to all of us, it's been around forever. So internal politics, again, like almost every persona, but especially for those that are in leadership positions, internal politics is going to be a huge blocker if they cannot get alignment across the organization between leaders, between different functions. That's just going to be a blocker to adopting a new tool. Like many of the personas in many roles within the organization, things are not always measured. So lack of key performance indicators or KPIs are going to be a problem. So if they want to implement a new tool, in order for them to justify this new tool to say, this new tool is better than the old one and better by this amount, you actually need to measure what you're doing today and you need to know that you're missing the mark in order to then justify adopting a new tool. And the fact that that type of measurement or instrumentation is just often not in place is a blocker in many personas, including the head of IT. Like many personas, heavy compliance requirements. So in large enterprise organizations, the larger the organization is, the more internal compliance standards they're going to have in order to mitigate risk. They are going to have more rules that need to be followed and in highly regulated industries. So this might be healthcare or finance or just any industry that has a high amount of regulation in order to move in that organization, you're going to have to comply with all of those regulatory standards and that can slow adoption. That can be a blocker adoption regardless of the size. Finally, an interesting one is that for the head of IT, for the project timeline, often if it's too aggressive, they're not going to want to approve or support that. They want to move at a measured place. They want to mitigate risk. They want to maintain some stability. They want to know that they can staff and support it. And so if there's someone within the org and they have an initiative and their timeline is too aggressive, they'll likely have trouble getting buy-in from the head of IT. So what is their journey look like of adopting new tools? Where are they at in the buying process and what does their journey look like? So the first thing that the head of IT cares about is they want to understand why is a new solution necessary. So they're likely looking at the existing stack. They care a lot about supporting the existing stack. They care a lot about keeping their staff trained and competent and servicing users. And so if things are running well or even if things are just running okay, they don't have a lot of need to go and adopt new solutions. So they're going to want to know why we adopt a new solution. They're likely going to challenge whoever the recommender is. So usually somebody within the org is going to want to implement some type of new tool. And so for the head of IT, they're usually going to challenge them to say like, has the research and the evaluation process that you've done, is it sufficient to mitigate all the risks? And the head of IT is going to assess many of those risks. So for them, they're going to want to understand the details of it. What's the execution? What's implementation? How will it be supported? What's the roadmap? What's the budget? Those kind of details are things that they're going to want to care about and understand. And when they understand those things and when they are sold on the solution as an influencer and a key stakeholder, then they're going to support the recommendation going up to the VP of engineering or the CIO or the COO, depending on how the organization just happens to be structured. But they're going to move together with the folks and support that recommendation. So what is some potential messaging that you could use when talking to folks who are in the head of IT role or IT leadership, director of VP IT role? So the first thing that folks in this role are going to care about is strict security governance. This is something that GitLab in particular excels at. Not only GitLab itself is a very secure application, because it's a single application, there's a single set of access controls across all of your users. You don't have to manage multiple access controls for multiple different applications. So because there's, you can say, here's somebody and they have access and they have permission to do certain things and that's consistent for many users across the whole lifecycle instead of having to use different tools. That's very secure and that's great. There are attributes of GitLab such as the fact that you can deploy it on-prem and you can, you know, even if that's on-prem, even if that means, you know, in your own cloud you are deploying it yourself, you're managing it yourself. So you have a lot of security and control over that. That's great security governance. But also, GitLab ensures the governance of your application security, right? So because GitLab has automated security checks, because we have static application security testing and dynamic application security testing, these types of automated security text built into the CICD pipeline, that ensures the security of your application. So not only is GitLab secure and allows you to govern the security of how GitLab is run and accessed and managed, also using GitLab to deploy your software gives you an extra layer of software governance to deploy your application in a secure manner. So those things are things that the head of IT really cares about and really loves and is why GitLab is a great solution for them. Reducing complexity is also something that they care a lot about. Again, they don't want to manage a bunch of different tools, so especially if they can be on the same tool for their issue management and their source code management and their CICD and their monitoring by having one tool that does all of those things that greatly reduces the complexity, that greatly reduces the integration complexity, greatly reduces the plugins by simplifying all of that in a single application that complexity reduction makes the head of IT's job a lot easier. The fact that we have a huge open source community and that we ship software very fast, very, very consistently on the same day every month, that we have a fast turnaround time for bug fixes, this is something because they care about stability, they care about that, can I support this? Can I keep this up? They care a lot about uptime, they don't want it to go down. So the fact that it's open source and there's a huge open source community fixing bugs and even our enterprise customers are a community that when one enterprise customer has an issue or a problem with that code, then they can even submit a patch, right? And all of our customers benefit from that. So that fast turnaround time for bug fixes, the stability of our software, that's something great. Of course, 24-hour support, the fact that we're used by 100,000 organizations, used by several Fortune 500 companies, the larger enterprises that you can recommend, those are gonna play well. And also that they care about predictable costs. So the fact that they're paying for, our licensing is per user, as they add users, they can have a predictable cost model. This is gonna be messaging that is gonna play well. So that is the head of IT.