Personas

Roles vs personas

Personas describe the ideal target for GitLab. They help us define our messaging and marketing delivery. They are theoretical people to target. By defining their concerns and where they go for information, we can best spend our marketing dollars and sales efforts by focusing on this ideal target.

Roles are distinct job titles. These are the real people you will encounter while selling. You will find a contact at an account with a specific role. Understanding the challenges faced by each role in IT, along with what they care most about, is helpful to deliver the right value proposition to the right person.

Personas

Personas are a generalized way of talking about the ideal target we are aiming to communicate with and design for. They help us not only define our messaging and marketing delivery, but also our product. Keeping personas in mind allows us to use the correct language and make the best decisions to address their specific problems and pain points. GitLab has both buyer and user persona types.

Buyer personas

We are iterating on updates to buyer personas on this Buyer Persona page.

User personas

User personas are people who actually use GitLab. They may or may not be the person in the organization who has the authority and budget to purchase GitLab, but they are heavy influencers in the buying process. Users personas are created from data gathered from UX research studies. If a new user persona is needed, or an existing persona has to be updated, see our handbook guide on How to Create a User Persona.

How do user personas interact?

While user personas are often distinct individuals it is equally important to understand how multiple personas interact as to understand the workflows and motivations of individual personas. As a result we will also consider:

  • Organization Archetype
  • Persona Composition
Organizational Archetype

Organizational archetypes describe how organizations have structured their software development process and teams. They help us understand common structures and the resulting types of interactions that the personas in those structures experience.

We’ll build out descriptions of common organizational archetypes as our research continues and introduce new personas that fit into these new organization archetypes.

It can happen that a persona from one organizational archetype will have similar jobs-to-be-done, or other characteristics, as one or even multiple personas from another organizational archetype. Describing all of them will help us understand the differences that could otherwise go unnoticed and make better-focused decisions during product development. Learn more about the organizational archetypes GitLab is addressing.

List of User Personas

We describe the following personas in terms of the jobs they do, their motivations and frustrations. Understanding our users through this lens helps us contribute to a product that supports their workflow.

  1. Parker, Product Manager
  2. Delaney, Development Team Lead
  3. Presley, Product Designer
  4. Sasha, Software Developer
  5. Priyanka, Platform Engineer
  6. Janell, Enablement Advocate
  7. Sidney, Systems Administrator
  8. Rachel, Release Manager
  9. Simone, Software Engineer in Test
  10. Allison, Application Ops
  11. Ingrid, Infrastructure Operator
  12. Dakota, Application Development Director
  13. Amy, Application Security Engineer
  14. Isaac, Infrastructure Security Engineer
  15. Alex, Security Operations Engineer
  16. Cameron, Compliance Manager
  17. Daphne, Data Scientist
  18. Mia, ML Engineer

Personas across stages

Our personas span across stages (see table below for a depiction of how our user personas map across stages). Understanding how our personas map across stages helps us understand how to collaborate cross-functionally to support their needs.

Note: To change the table above, team members can edit the Google Slide deck.

Parker (Product Manager)

  • Alternative Job Titles: Program Manager, Project Manager, Technical Product Manager, Head of Product
Job Summary

At the center of many facets in product development, I am responsible for shaping strategic visions, translating them into actionable plans, and ensuring that our products meet user needs and deliver real value. While my role extends beyond tactical responsibilities, I recognize the critical nature of managing day-to-day tasks which drive successful execution, even though they may not be my favorite part of the role. I strive to create strong relationships, align teams towards common goals, and ensure stakeholders buy-in to the vision for successful product development. My toolkit must include data-driven decisions, market awareness, effective communication, and a clear strategic vision.

Motivations
  • Solving Complex Problems and Delivering User Value: I find deep satisfaction and motivation in tackling challenging problems head-on. My drive stems from the opportunity to develop innovative solutions that meet user needs and create real value, culminating in a richer user experience and making a positive impact in the day-to-day lives of our users while driving value and increasing revenue for my organization.
  • Taking Products from Concept to Launch: The process of taking a product from concept to launch excites and motivates me. I get satisfaction from taking part in the evolution of an idea into a fully realized product, navigating challenges, guiding development, and observing the impact with users.
  • Adapting to Change and Achieving Alignment: I’m proud when I can adapt to shifting company objectives and maintain effective communication with my team. I am always working to achieve alignment across teams, knowing that it fuels our ability to achieve ambitious goals and innovate together.
Frustrations
  • Being Stuck in a “Project, Not Product”, Management Role: It’s demotivating when I find myself primarily functioning as a project manager, focusing on tracking tasks and timelines rather than the dynamic and strategic responsibilities that come with being a product manager. This hinders my ability to address customer needs, devise effective market strategies, and maintain a clear product vision, which drives my job satisfaction.
  • Wasting Time, Development Capacity, and Ultimately Money: Wasted efforts and resources on products that fail to gain traction or meet user needs is disheartening. I feel frustrated when we invest in solutions that go unused or lack a clear purpose, especially when there is little meaningful user value or overall product success.
  • Inability to access project status quickly: It can be frustrating when it is difficult to obtain the status of work efforts and I am forced to spend time chasing status. Timely awareness of project status, especially when it is off track, is crucial for my role because I need to ensure people invested in delivery are informed if we will not meet our commitments.
  • Balancing Product Vision and Capacity: I am constantly trying to make the most of our team’s capacity to execute on our product vision. It’s a challenging juggling act to ensure I am making the right decisions on what comes next to maximize our ability to deliver compelling value to the market.
  • Unpredictable Timeframes, Feature Delays, and Deprioritization: It’s frustrating when I’m tasked with providing clients and stakeholders with a reasonable timeframe for the delivery of a feature since development cycles can be unpredictable, and change is inevitable.

Delaney (Development Team Lead)

  • Alternative Job Titles: Technical Manager, Software Engineering Team Lead, Technical Team Lead, Software Development Director, Development Lead, Head of Development
Job Summary

I am responsible for meeting with the product management team to discuss and schedule features, so we can convert concepts into practical solutions. I ensure that capacity is properly estimated, create program specifications, and often mentor junior developers.

Motivations
  • When discussing feature requests, I want to receive clear requirements from the product and design teams, so my team can deliver on time and reduce back-and-forth communication.
  • When assessing team resources, I want to see a history of how accurately developers on my team have estimated their capacity, so that I can assign them to the right tasks.
  • When important deadlines are approaching, I want all team members to reliably update our tools, so that I can track progress without having to search for relevant information in other communication channels.
Frustrations
  • It can be difficult for my team to do thorough code reviews in a reasonable timeframe, while still making progress on their own assignments.
  • When demand surpasses our current capacity, it can be stressful to resolve issues while not creating new ones that result from hasty work.
  • I am not always aware of the best way to explain technical limitations to stakeholders who are not involved in the development process.

Presley (Product Designer)

  • Alternative Job Titles: UX Designer, Interaction Designer, UI/UX Designer, UI Designer, Experience Designer
Job Summary

My goal is to translate the product’s mission into an effective, empathetic, and efficient user experience. I am responsible for understanding user needs and product requirements, in order to conceptualize and design the graphic elements and components needed to shape the user interface. I collaborate primarily with product managers and developers, in addition to working with other stakeholders such as UX research and marketing.

Motivations
  • When a deliverable is requested, I want to have clear, up-to-date requirements that I can reliably refer back to throughout the design process.
  • When collaborating with other designers, I want to be able to see who has edited a file so that I can confirm whether changes were made intentionally.
  • When presenting deliverables to stakeholders, I want to be able to make updates to a design without having to edit a series of files in various tools.
  • When developers are implementing my designs, I want to easily keep track of changes that go live in production, so that I can alert them of any needed fixes.
Frustrations
  • It’s frustrating to have to create a file in one tool, export the file, create a prototype in another tool, and use a separate tool to handoff the design to developers.
  • It can be difficult to ensure that stakeholders are looking at up-to-date designs, when carrying out an iterative feedback process.
  • It can be challenging to get access to more resources, when my company does not have a defined way to prove design value to stakeholders.

Sasha (Software Developer)

  • Alternative Job Titles: Software Engineer, Application Developer, Digital Solutions Developer, Consultant, Database Developer, Mobile Developer
Job Summary

I spend the majority of my time focused on completing planned development tasks, with roughly 30-40% of time taken by meetings, planning for the next sprint, and fixing bugs or customer requests as they arise. I work off of issues and have a regular stand-up with my team.

Motivations
  • When I’m planning work, I want to have better communication between stakeholders, so I can deliver something they really need and use.
  • When I’m on-call, I want to be the expert on some part of the system, so I know that I’m a valuable part of the team.
  • When collaborating with a large number of developers, I want to see a record of everyone’s changes, so we can pinpoint and unwind mistakes.
  • When I’m pairing with my teammates, I want to learn new tools and skills, so I can keep growing in my career.
  • When I’m making changes, I want to deliver secure and performant code, so I can ensure the integrity of my organization’s software is not compromised.
Frustrations
  • I’m frustrated when requirements change after work has already begun on a project.
  • I’m frustrated when work is inaccurately scoped, because it causes stress and eats into time planned for other work.
  • I’m frustrated when I come across brittle code and something that should be an easy fix requires a lot of rework.
  • I’m concerned that by taking longer than expected on a task I may be judged or seen as blocking others’ work.

Priyanka (Platform Engineer)

  • Alternative Job Titles: DevOps Engineer, Operations Engineer, Systems Engineer, IT Consultant
Job Summary

My job is to enable the developers to focus on the business code only. To achieve my goal, I write pipeline definitions, deployment templates, CLI tooling to be used by development teams, so the software delivery process is streamlined across organization. Beside building out these features and fixing potential bugs, I educate and support the development teams around topics related to our pipelines or target infrastructures, so they can build, deploy, and release as efficiently as possible.

Depending on the organization and/or need of the development teams, I am part of a central platform team or a member of an application development team.

Motivations
  • When developers plan a project that requires my support, I want to be notified, so I can avoid unnecessary reactive work.
  • When I resolve problems, I want to be able to track impact and other important success metrics, so I can raise my profile in the organization.
  • When I create a solution for developers, I want to see it being used, so I know that my contributions are reliable and valued.
  • When I’m facing a new or novel challenge, I want to whiteboard it with a teammate, so I have the satisfaction of helping solve a problem that has no manual.
  • When I’m advocating for a new process or tool, I want to point to a metric or test, so I can support my case with something objective.
Frustrations
  • It is hard for me to quantify my efforts and convince others of time that will be saved in the future by investing time in proactive tasks in the present.
  • I’m frustrated by the avoidable crises, caused by a lack of communication, that derail my work and burn up my resources.
  • I dislike frequent context-switching and being responsible for some tasks that I feel I am not good at, because of the many hats my job requires me to wear.
  • I’m frustrated by the politics of convincing people to adopt my recommendations.

Janell (Enablement Advocate)

  • Alternative Job Titles: DevOps Evangelist, Developer Productivity Engineer, Developer Advocate
Job Summary

My job is to enable developers to ramp up the learning curve of modern DevOps practices - including when that adoption is not compulsory. This can include new work management, new tooling and navigating the modernization of their applications into the cloud. To achieve my goal, I write and maintain automation code that can be directly consumed by developers as dependencies as well as scaffolding templates to be sure new projects are off to a good start. In addition to CI/CD automation, this frequently this involves support for cloud deployment, kubernetes manifests and any other associated parts for a wholistic approach to moving teams onto modern application practices. This technical work frequently involves exposing company specific things to developers as an easy to use ‘service’ - for instance, registering their application with our company-wide Configuration Management Database (CMDB).

My job also includes being an active champion and evangelizng development teams to leverage the new assets and ways of working - this involves treating my work as though it were a product or service - managing it to be stable, fixing bugs, taking feature requests and creating and promoting release information. This also includes workshops, managing communities of practice and creating peer Q&A platforms.

My manager has developer productivity and enablement as a strong focus and is very interested in how our efforts accelerate onboarding to our next generation application frameworks and also how we contribute to the long term productivity gains and business value generation of the teams that adopt our enablement.

My job also includes influencing not just technology, but also processes and culture when they might inhibit adoption of modern application and DevOps practices and technology.

Developer enablement plays such a critical role in the efficient onboarding of developers that I generally have strong input on tooling selection as I screen it for the ability to allow us to extend it.

Depending on the organization and/or need of the development teams, I am part of a central enablement team or a member of an application development team if the team’s work has a large enough scope.

Motivations
  • When I build for developers, I need to accommodate a broad set of ways of working - our organization is too diverse to try to put everyone onto a single set of enablement assets.
  • When I build dependencies for developers, I need them to be able to version lock on them so that I can safely enhance and fix the code while not creating problems for their production deployments.
  • When I release new versions or entirely new functionality, I need it to be discoverable by developers - although we maintain email campaigns, we can’t rely on everyone consuming the information this way and it does not help new hires.
Frustrations
  • It can be a challenge to maintain awareness of all DevOps tooling product features that I can opinionate for our team - this includes all templating functionality, all pipeline security controls and all deployment functionality.
  • I’m frustrated by members of my team and development teams that do not maintain appropropriate versions and version management discipline as I am then accused of being the source of production problems.
  • I’m sometimes frustrated by the burden of maintaining custom training or other enablement content to articulate how our DevOps processes work within our tooling.
  • It can be very challenging to provide standardized, end-to-end enablement for specific new patterns since each team feels that all of the organic elements evolved into their currently approach are absolutely necessary - it’s hard to get them to simplify by reconsidering not just their DevOps code - but their team processes as well.

Sidney (Systems Administrator)

  • Alternative Job Titles: Systems Engineer, Database Administrator, Infrastructure Engineer, Site Availability Engineer, Site Reliability Engineer
Job Summary

I maintain and scale our infrastructure and configurations, and my priority is to automate as much as possible. When needed, I also build servers and help developers deploy to them.

Motivations
  • When I get asked for help multiple times on the same task, I want to automate that task, to save time and avoid mistakes in the future.
  • When I’m on-call, I want to receive tiered notifications, so that the true emergencies don’t get lost in the noise.
  • When I’m releasing an improvement, I want no one to notice, so I know that it has gone smoothly.
Frustrations
  • I’m frustrated by the large volume of reactive work that I face.
  • I’m frustrated by the number of channels (email, Skype, SMS, Slack, pager) on which I receive on-call notifications.
  • I’m frustrated when I get inundated by requests from people who have not followed the correct process.
  • I’m frustrated when developers do not implement my recommendations, and I’m responsible for fixing their preventable problems anyway.

Rachel (Release Manager)

Jobs to be done
  • I am responsible for coordinating a deployment to production. I push the last button in our pipeline; i.e. changing the load balancers to point to the latest deployment.
  • I coordinate the release by defining the scope and tasks for delivery.
  • I am in charge of external communications around a release, especially assembling changelogs or release notes.
  • I organize a response room if necessary to bring in everyone that may need to support a release
Motivations
  • I want a smooth deployment
  • I want to make sure everything in the pipeline will work, because it’s the last thing that happens before it’s moved to production. If you ship something into production that shouldn’t be there, that can be catastrophic.
  • Every time the CI/CD pipelines run to green or catch issues when needed, I can sleep calmly.
Challenges
  • Dealing with archaic infrastructure, such as slow connections and outdated equipment, can make it difficult to ensure everyone has the files they need to contribute and manage the pipeline.
  • Ensuring enough developers, Product Managers, etc. are available to support projects.
  • UI testing isn’t automated so that takes time out of the testing process.
  • Coordinating all the different teams across a release can be challenging and requires a lot of follow up to ensure they play their part when they should.
Tools
  • GitLab
  • JIRA (for tickets from non-technical users)
  • Trello (for planning issues and communication)
  • Slack (for communication)

Simone (Software Engineer in Test)

  • Alternative Job Titles: Software Development Engineer in Test
My role

I’m a software engineer in my organization with a keen interest in quality and the skills necessary to promote it. My objective is to help build quality into the development process and promote ownership of quality across every team. To accomplish this, I develop tooling to support test processes and quality reporting. I also write tests at every level in the test pyramid. I groom my organization’s tests to make them both efficient and effective as well as help grow a quality mindset across departments.

Jobs to be done
  • Develop and maintain test frameworks: I need to provide the engineers in my organization with one or more well-maintained test frameworks that facilitate writing tests at the appropriate level.
  • Provide tooling and reporting to facilitate quality: I need to create and maintain both tooling and reporting that allows developers to more easily accomplish quality-related tasks and provide feedback to engineering and management.
  • Perform quality planning with counterparts: I want to interact with my engineering counterparts on a regular basis, tracking what is coming up for development as well as what is happening now and what is being delivered. Knowing this, I need to be able to identify both the riskiest and most important work being done so I can provide quality feedback at the appropriate time through performing code reviews and having discussions about both the design and implementation of the features.
  • Manage Test Environments I also provision and maintain test environments that are representative of the software being used in production. Through these environments testing can then occur that is as realistic as possible and catch issues earlier.
Skills & Personal Traits
  • Focused: Has a great focus on quality and what it means in an engineering role
  • Adaptable: Can think like a developer and an architect
  • Curious: Enjoys learning how things work or taking things apart
  • Technical: Enjoy building tools (has coding skills)
  • Passionate: Loves improving tools and processes and advocating for quality
  • Effective communicator: articulate both verbally and in writing
Frustrations
  • Flaky tests
  • Long running test suites
  • Not being able to reproduce issues due to lack of representative test data
  • Unstable infrastructure
  • Not being able to give earlier feedback on development work
Key Tools
  • Tracking, documentation: GitLab Issues
  • Communication: Slack, Zoom, GitLab Issues
  • Real-time documentation: Google Docs
  • Terminal, coding environment: VIM, VS Code, or RubyMine with Ruby, JavaScript, Terraform, and other supporting languages
  • Test automation frameworks: Implementations of testing tools suited for my products
  • A cloud management console: To access the infrastructure (Google Cloud Platform, Amazon Web Services, Azure)
  • Environment Provisioning: Terraform and Ansible
  • Triage and mitigation:
    • Docker - to reproduce issues and emulate environments
    • Accounts for different environments - for testing and infrastructure
    • Data repositories and generators
    • Logging tools
      • Elastic Stack (Elasticsearch, Kibana, Beats, Logstash)
      • Sentry
      • Prometheus
Collaboration with other teams
  • Development teams
  • Product teams
  • Infrastructure
  • UX teams
  • Support

Allison (Application Ops)

Alternative Job Titles: DevOps engineer, Lead developer, Site Reliability Engineer

My role

I have responsibility for ensuring the application I own is accessible and performant for its users. I wear an Application Ops hat, but I also wear a Software Developer t-shirt.

Jobs to be done
  • I want to be able to deploy to production and non-production environments automatically without requiring action from other teams.
  • I want to use my selected deployment tools so I can predictably understand what “deploy” means.
  • I want to deploy following the company best practices set out by Priyanka, the platform engineer so that we minimize the risk of a new deployment.
  • I want to get up-to-date, real-time information about the system components I own so that I can be assured about the performance and health of the applications I own.
  • I want to be notified about potential problems with the applications I own, so that I can act avoid downtime and degradations before they happen.
  • I want to roll back or roll forward from erroneous deployments so that I can keep my systems functional.
Frustrations
  • As a consumer of a monitoring platform, I’m frustrated when my apps instrumentation doesn’t report in the monitoring systems
  • I’m frustrated when I can’t determine the root cause of the monitoring system’s errors.
  • I’m frustrated when I need to use multiple tools to identify that there is an issue.
  • I’m frustrated about processes that slow down deployments.
  • I am frustrated when I can’t trust the data coming from monitoring systems (false negatives or false positives)

Ingrid (Infrastructure Operator)

  • Alternative Job Titles: Systems Engineer, Database Administrator, Infrastructure Engineer, Site Availability Engineer, Site Reliability Engineer, System Administrator
My Role

I have responsibility for providing, maintaining and operating the shared infrastructure which my application development teams utilize to develop, test, ship and operate software more quickly.

Jobs to be done
  • When I set up new infrastructure, I want to do it in a programmable way, so others can review my changes and we can repeat the steps if needed.
  • When I own an infrastructure resource, I want to keep it up to date with security patches, so I can sleep well at night.
  • When I own an infrastructure resource, I want to assure that it serves its purpose well, so I fulfill my SLAs.
  • When I own an infrastructure resource, I want to be mindful about its costs, so that I can run it within budget.
  • When I support developers, I want to automate the integration points, so I will not become a bottleneck in their processes.
  • When I’m on-call, I want to receive tiered notifications, so that the true emergencies don’t get lost in the noise.
  • When I’m releasing an improvement, I want no one to notice, so I know that it has gone smoothly.
Frustrations
  • I’m frustrated by the large volume of reactive work that I face.
  • I’m frustrated by the number of channels (email, Skype, SMS, Slack, pager) on which I receive on-call notifications.
  • I’m frustrated when I get inundated by requests from people who have not followed the correct process.
  • I’m frustrated when developers do not implement my recommendations, and I’m responsible for fixing their preventable problems anyway.

Dakota (Application Development Director)

Job Summary

Dakota is a key IT leader who manages and leads several teams of developers supporting a specific set of business applications. See the buyer persona and Engineering Director Persona research for more details.

Motivations
  • Business Satisfaction: Delivering consistent and predictable business results.
  • DevOps transformation: Transforming my organization to create new value with DevOps processes and tools.
  • Team building: Growing and improving the team through my managers.
  • Process excellence: Ensuring that my team have the tools, training, and resources to successfully deliver the business value.
Frustrations
  • Reactive versus proactive: Urgent roadblocks, organizational issues and emergencies make it difficult to manage time and workload.
  • Context switching: There is a large amount of content to cover across all of my projects and teams.
  • Creating business cases: Securing budget for new strategic initiatives and resources for her team is labor-intensive and time-consuming.

Amy (Application Security Engineer)

  • Alternative Job Titles: Application Security Analyst or Specialist
My Role

I am responsibility for assessing potential business-critical vulnerabilities, performing code reviews to focus on security best practices, and verifying security fixes in the environment.

Jobs to be done
  • When I set up new assessing vulnerabilities, I want to understand the potential threat a particular vulnerability represents to my organization’s assets, so that I can prevent the threat from occurring.
  • When I am reviewing feature proposals or a code author’s code, I want to ensure the new code will not introduce security vulnerabilities in my organization’s assets, so that there are fewer business critical vulnerabilities.
  • When I am reviewing security fixes, I want to verify there are no remaining threats to the organization’s assets, so my organization can be confident about its security.
Motivations
  • When I’m monitoring my vulnerability dashboards, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.
  • I want to make sure to run all necessary security scans before code is released to remain proactive.
  • When on the job, I want to stay up to date on the latest information and education in information security, so I can grow in my career.
Frustrations
  • I’m frustrated by the large volume of vulnerabilities that I face.
  • I’m frustrated when I am not provided enough time to assess all of the vulnerabilities I face.
  • I’m frustrated when code authors do not provide enough documentation or context related to the security of their code changes.
Collaboration with other teams
  • Infrastructure security teams
  • Development teams
  • Compliance
Resources

Isaac (Infrastructure Security Engineer)

  • Alternative Job Titles: Infrastructure Security Analyst or Specialist
My Role

I am responsibility for creating and maintaining security tools, monitoring production environments, and assessing security tools to ensure my organization’s assets are compliant with the security requirements.

Jobs to be done
  • When my organization has a new security policy they must follow, I want to create security tools to ensure my organization’s assets are compliant with the policies, so that I can prevent the threat from occurring.
  • When reviewing a code author’s code, I want to ensure the new code will not introduce security vulnerabilities in my organization’s assets, so that there are fewer business critical vulnerabilities.
  • When assessing my organization’s assets, I want to verify there are no uncompliant areas in the organization’s assets.
Motivations
  • When I’m monitoring my dashboards, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.
  • When evaluating the security of production environments, I want to be more proactive than reactive, so I can anticipate potential threats or vulnerabilities before the bad guys do.
  • When I’ve done all I can do proactively, I also want to be able to enable reactive tools and investigate the data from them as a final layer of defense.
  • When on the job, I want to stay up to date on the latest information and education in information security, so I can grow in my career.
Frustrations
  • I’m frustrated when internal development teams are noncompliant with a security policy by subverting a security policy or a security tool I created and maintain.
  • I’m frustrated when internal development teams do not respond in a timely manner to fix new vulnerabilities detected in a production environment.
  • I’m frustrated when code authors do not provide enough documentation or context related to the security of their code changes.
  • I’m frustrated when development teams are resistant to security changes.
Collaboration with other teams
  • Application security teams
  • Security operations teams
  • Development teams
  • Compliance
Resources

Alex (Security Operations Engineer)

  • Alternative Job Titles: Security Operations Analyst or Specialist
My role

I’m the firefighter of the Security team. My objective is to prevent malicious attacks and mitigate active risks to my organization as they pop up, as quickly as possible. In order to do that, I develop detection tooling that generates trustworthy alerts, and take part in an on-call rotation where I serve as an Incident Responder.

“I need to be jack of all trades: When SecOps get paged, it could be about anything, and there’s a high probability that the incident concerns something you’ve never dealt with before. The sky could be falling and there’s a lot at stake and so the role of a security operations person can be pretty stressful.”

Jobs to be done
  • Manage incident response: When I am on-call, I need to respond to and manage incidents as they pop up, so as to mitigate the risk to my organization as quickly as possible.
  • Real-time documentation: As an incident unfolds, I want to document as much of what is happening as possible, so that later on I could use that information as part of updating or creating a runbook, and possibly creating an RCA (Root Cause Analysis).
  • Building detection tools: When I’m not on-call, I want to build tools that enhance our detection and alerting capabilities, so as to improve my organization’s security stance.
  • Short-term project management: As an incident unfolds, I want to assign tasks and coordinate the work of multiple individuals across my organization, so I can move as quickly as possible to remediate the risk.
Skills & Personal Traits
  • Great ability to divide my focus effectively and deal with interruptions, such as new alerts, new data, and urgent requests from colleagues
  • Good at thinking quickly on my feet and maintaining my composure in stressful situations
  • Can think like an attacker as well as a defender
  • Enjoy building tools (has coding skills)
  • Passionate about improving processes
  • Effective communicator: articulate both verbally and in writing
  • Enjoys the variance of SecOps work
  • Feels relatively comfortable with handling unknown unknowns
Motivations
  • When I’m monitoring my dashboards for security alerts or incidents, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.
  • When security testing, I want to be more proactive than reactive, so I can anticipate potential threats or vulnerabilities before the bad guys do.
  • When I’ve done all I can do proactively, I also want to be able to enable reactive tools and investigate the data from them as a final layer of defense.
  • When on the job, I want to stay up to date on the latest information and education in information security, so I can grow in my career.
Frustrations
  • It is cumbersome to edit description of timeline in real-time, and it’s especially difficult to do in hindsight. Often the timeline documentation isn’t completed.
  • Often important parts of the info I need in order to handle the incident are either not communicated fully, or are being communicated in an unstructured manner which makes aggregation and searching difficult.
Key Tools
  • GitLab Issues: Tracking, documentation
  • PagerDuty: Initiation standpoint, where pages are sent through
  • Slack, Zoom, GitLab Issues: Communication
  • Google Docs: Real-time documentation
  • Terminal, coding environment: Mostly Python, some Go - for building and/or running tools
  • The Hive: A security incident management tracking tool
    • Cortex - part of The Hive, allows for easy automation
  • A cloud management console: To access the infrastructure
  • Various tools for triage and mitigation:
    • Docker - to reproduce security issues and test approaches
    • Accounts for different environments - to test against
    • ELK stack - to go over logs
    • Stackdriver or BigQuery - long-term storage, used for incidents that are open for a long period of time
Collaboration with other teams
  • Infrastructure
  • Legal
  • Compliance, AppSec
  • Support
  • Development teams
  • Various SMEs

Cameron (Compliance Manager)

  • Alternative Job Titles: Compliance Program Manager, Audit Report Analyst, Audit Events Analyst
Job Summary

I’m in charge of ensuring that our organization’s use of third-party software adheres to internal company policy. This can consist of the SDLC, access management, change management, and a multitude of other policies. I interface regularly with our internal compliance, audit, and/or security teams to deliver the information they need for our organization’s compliance program.

Jobs to be done
  • I need to be able to provide our internal compliance teams with evidence artifacts that help my company maintain a positive compliance posture.
  • I need to find tools that enable my organization to manage our compliance program and mitigate risk within the application and its use.
  • I need to create effortless processes for compliance so that my team will remain productive and efficient while meeting obligations for our primary job responsibilities.
Motivations
  • When I’m supporting an audit, I need the information to be available quickly and easily so I can reduce the time and disruption involved in the evidence collection process.
  • When I’m managing my teams and projects, I need to know I’m not introducing unnecessary risks so I can protect the company from liability.
Frustrations
  • I’m frustrated because it’s difficult to find, aggregate, and report on all of the necessary data for audit purposes.
  • I’m frustrated when tools do not have features that give me peace of mind about our organization’s compliance posture.
  • It’s challenging to compile data in a format that’s efficient and valuable to my internal audit or compliance team.
  • It’s challenging to build custom tooling and services every time we identify a gap in the compliance posture of our tools.

Daphne (Data Scientist)

  • Alternative Job Titles: Data Analyst, Machine Learning Engineer
Job Summary

I collect, preprocess, and analyze data to derive insights and build predictive models.

Jobs to be done
  • Collect and gather data from multiple sources.
  • Clean, transform, and preprocess data for analysis.
  • Explore and analyze data to derive insights.
  • Build predictive models to solve business problems or make data-driven predictions.
  • Update models with new training data to maintain their relevance.
  • Collaborate with ML Engineers to deploy models and maintain data pipelines.
Motivations
  • As a data scientist, my focus is on analyzing data and building effective models, rather than software development.
  • I aim to create models that provide practical solutions and drive business value.
Frustrations
  • Data access
  • Lack of computational resources
  • Lack of data and/or ML/AI literacy in the organization
  • Lack of streamlined processes and automations
  • Lack of data governance and ambiguity around policies, data ownership and data stewardship.

Mia (ML Engineer)

  • Alternative Job Titles: MLOps Engineer, ModelOps Engineer
Job Summary

I am responsible for building, optimizing, and deploying machine learning models into production environments.

Jobs to be done
  • Build, optimize and experiment with machine learning models.
  • Deploy models into production environments and integrate with other software systems.
  • Monitor deployed models, detect performance issues and drift. Retrain and update models as needed.
  • Optimize ML systems for scalability, performance, and efficiency.
  • Develop and maintain data pipelines and infrastructure to support end-to-end model and machine learning lifecycles.
  • Work closely with data scientist, software engineers and other stakeholders to deliver ML solutions.
Motivations
  • Build scalable, operatable ML systems.
  • Turn data insights into products.
Frustrations
  • Lack of automation and reproducibility
  • Limited compute resources
  • Lack of Expertise and Knowledge Sharing
  • Lack of organizational buy-in to adopt MLOps and ModelOps

Internal personas

Internal personas reflect the workflow, needs, and challenges faced by GitLab team members. These personas support and influence the work of GitLab groups that serve internal use cases.

List of internal personas

  1. Eddie, Content Editor (Internal persona)
  2. Dana, Data Analyst (Internal persona)

Eddie (Content Editor)

  • Alternative job titles: Content Marketer, Technical Writer
Job Summary

I am responsible for creating, updating, and curating content for my company’s site. I review and submit changes to existing pages and create pages to add new content as needed.

Motivations
  • When I need to improve existing page content, I want to quickly find the areas that need to be updated, so I can ensure that the content is consistent and up-to-date.
  • When I need to create a new page, I want to easily find the correct directory, so I can submit my changes to the appropriate location.
Frustrations
  • It’s challenging to know which pages need to be updated, when I am responsible for managing a site with a lot of content.
  • It can be intimidating to make content changes, if I am not used to working with technical editing tools in my workflow.
  • It’s frustrating to have to spend time figuring out where content lives in the directory structure, especially when making small changes.
  • It’s difficult to make bulk updates to a page without tools that allow me to find-and-replace content.

Dana (Data Analyst)

  • Alternative Job Titles: Data Analytics Consultant, Business Data Analyst
Job Summary

My goal is to deeply understand the lifecycle of data from various sources and model it in a way that fosters cohesive, accurate analysis. I am responsible for maintaining high quality data, building reports and dashboards, and explaining trends across data sources. I collaborate with stakeholders across the company, providing useful analyses and insights that empower them to build a stronger product and organization.

Motivations
  • When directors are assessing key performance indicators, I want to build dashboards with reliable data, so that they can have confidence in the conclusions drawn from the data.
  • When our product team needs to measure the value of our features, I want to see more granularity and context for patterns in usage data, so that we can develop a better understanding of how people are interacting with the product.
  • When important company initiatives are being discussed, I want to deliver queryable data and empower my colleagues to run their own analyses, so that they can use data-driven insights to inform critical decisions.
  • When my colleagues are working on projects requiring data analysis, I want to find ways to optimize queries, so that they can spend more time actioning insights.
Frustrations
  • It can be frustrating to work with data that is not properly structured and low in quality and confidence as a result.
  • It can be difficult to know exactly how to approach analysis, when my colleagues are not clear about the questions they have and why they want to explore certain aspects of the data.
  • It’s hard to trust the integrity of data, when inconsistent tracking results in missing context for key events.
  • It’s difficult to answer big picture questions about feature usage and user retention, when feature parameters and usage criteria aren’t completely defined.

Organization Archetype
What is an organization archetype? An organization archetype is a typical example of an organizational setup. In our case, we are specifically interested in organization archetypes relevant to how the organization might engage with GitLab. We’ve learned that roles of various personas change based on the specific organizational setup of their company. This handbook page captures the organization archetype we have identified. How do you use organization archetypes as a Product Manager?
Last modified March 25, 2024: Add ML personas to list (368fe3a9)