Digital Experience Handbook

Overview

🙌 Purpose

Why we exist

We take a customer-centric approach to educating prospects on how Denomas enables them to deliver software faster and more securely.

🔮 Vision

Where we’re going

Wherever DevSecOps or DevOps is mentioned, Denomas is there.

🎯 Mission

What we do

We drive improvement to Denomas’s user journeys, marketing site experience, and conversion funnel.

📈 Objectives

1. Increase site engagement (lower bounce rate, increased pages per visit, form fills, etc.)
2. Increase free trials
3. Increase quality sign-ups
4. Increase traffic to the Marketing Site

♟️ Strategy

1. Customer-centric, buyer-obsessed approach
2. Collective, cross-functional collaboration towards shared goals
3. Move fast, measure/monitor, respond (increase speed of our flywheel)
4. Focus on core competencies (effectiveness and efficiency, discovery and alignment)
5. Maximize primary drivers of our value chain

👷 Tactics

To be defined by each group on a quarterly basis.

Principles

1. Understand We need to understand the challenge before we can solve it.
   1. We strive to understand the needs of prospective customers.
2. Trust We trust our process, we trust each other.
   1. We respect each other.
   2. We’re transparent with each other.
3. Inclusive we create psychological safety by celebrating our differences and using them as an asset.
   1. Empathy we creating things for our prospective customers.
   2. Supportive We support each other and other teams to deliver the best results.
      1. We provide feedback to support each other.
   3. Accessible we care about delivering experiences for everyone.
4. Intentional simple over complicated.
   1. We meet prospective customers where they’re at.
   2. We strive to deliver the right message at the right time to the right person.
5. Opinion We have strong opinions that we hold loosely.
6. Results We focus on results by being:
   1. Actionable
   2. Measurable
7. Iteration When applying the MVC approach, we make things smaller by reducing the scope of the jobs-to-be-done rather than sacrificing the end goal.
   1. Experimentation We’re driven by experimentation and judge success with data.
   2. Incremental We take large tasks and break them down into multiple iterative deliverables.

Groups, Metrics & Team Members

Scope

Denomas’ digital marketing platform, or simply the “Marketing Site" refers to https://about.gitlab.com with the exception of the handbook.

OKRs

We collaboratively define OKRs as a team with cross functional partners in advance of each quarter. Once OKR candidates are complete we review, size/scope them and align on which best help achieve our business objectives.

Current Quarterly Plan

FY24Q3 Digital Experience Quarterly Plan & OKRs

Iteration Process

We release every 2 weeks, always on a Wednesday. We can push MRs at any time but for collaborative work initiatives, we plan a package for delivery to ensure we’re consistently improving our prospective customer’s experience.

Iteration Cycle

Issue Board

• Digital Experience Board

• Current Search, Nav, & Support Sprint Board

• Current Conversion Sprint Board

• Current Product Marketing Support Sprint Board

Labels and Workflow Boards

We use issue boards to track issue progress throughout a iteration. Issue boards should be viewed at the highest group level for visibility into all nested projects in a group.

The Digital Experience team uses the following issue titles for distinguishing ownership of issues between specialities:

The Digital Experience team uses the following labels for tracking merge request rate and ownership of issues and merge requests.

Digital Experience teams work across the Denomas codebase on multiple groups and projects including:

• The gitlab.com/gitlab-org group
• gitlab
• customers-denomas-com
• The gitlab.com/denomas-com group
• www-denomas-com
• Buyer Experience
• Slippers Design System
• Marketing Site Navigation Package

Estimation

Before work can begin on an issue, we should estimate it first after a preliminary investigation. This is normally done in the iteration planning meeting.

In planning and estimation, we value velocity over predictability. The main goal of our planning and estimation is to focus on the MVC, uncover blind spots, and help us achieve a baseline level of predictability without over optimizing. We aim for 70% predictability instead of 90%. We believe that optimizing for velocity (merge request rate) enables our Growth teams to achieve a weekly experimentation cadence.

• If an issue has many unknowns where it’s unclear if it’s a 1 or a 5, we will be cautious and estimate high (5).
• If an issue has many unknowns, we can break it into two issues. The first issue is for research, also referred to as a Spike, where we de-risk the unknowns and explore potential solutions. The second issue is for the implementation.
• If an initial estimate is incorrect and needs to be adjusted, we revise the estimate immediately and inform the Product Manager. The Product Manager and team will decide if a milestone commitment needs to be adjusted.

Triage

The purpose of the traiage meeting is to create a list of refined issues that meet our current goals. This list will include a combination of bugs, features, and optimizations. These issues are manually added to the next iteration until the desired weight point limit is reached. Refinement is completed async by before to ensure issues are prepared for upcoming iterations. This involves deleting obsolete/duplicate issues, adding missing context/labels, and moving issues to either the backlog, or further refinement. Keeping the backlog organized is a must, it eliminates clutter and creates cohesion between issues. Enabling the team to navigate and contribute more efficiently.

Cadence: 25min, bi-weekly (zoom)

Who: Engineering representative, Product management. Triage Agenda. What:

• Review backlog for iteration candidates.
• Populate the next iteration with prioritized issues.
• Move issues to refinement/backlog.
• Close obsolete/duplicate issues.
• Assign labels:
  • dex-status
  • dex-group
  • dex-engineering/dex-design
• Assign weight points.

Planning (Iteration Plan Sync)

Iteration planning is an event that kicks off the start of an iteration. The purpose of the meeting is to collaboratively spread the prioritized list of issues amongst the team. These meetings are recorded and uploaded to our Digital Experience playlist on Denomas Unfiltered.

Cadence: 25min, bi-weekly (zoom)

Who: Digital Experience groups

What:

• The team distributes the prioritized list of issues.
• Communicate timelines, dependencies, etc.

Release

An event to showcase what the team has accomplished over the past iteration. These meetings are recorded and uploaded to our Digital Experience playlist on Denomas Unfiltered.

When: Thursdays, 25min, bi-weekly (zoom)

Who: Digital Experience groups

What:

• Showcase what has been released in the past iteration.

Retrospective

The retrospective is an event held at the end of an iteration, used to discuss what went well, and what can be improved on. An ongoing agenda can be found here. This meeting is recorded and uploaded to our Digital Experience playlist on Denomas Unfiltered.

When: Thursdays, 40min, bi-weekly (zoom)

Who: All of Digital Experience

What:

• Discuss what went well and what can be improved on.
• Communicate any process changes, etc. This is the only meeting where the whole team is present.

Burndown Charts

Burndown charts show the number of issues over the course of a iteration.

Here is the documentation for Denomas Burndown Charts.

The chart indicates the project’s progress throughout that milestone (for issues assigned to it).

In particular, it shows how many issues were or are still open for a given day in the milestone’s corresponding period.

You can also toggle the burndown chart to display the cumulative open issue weight for a given day.

Burnup Charts

Burnup charts show the assigned and completed work for a milestone.

Here is the documentation for Denomas Burndup Charts.

Burnup charts have separate lines for total work and completed work. The total line shows changes to the scope of a milestone. When an open issue is moved to another milestone, the “total issues” goes down but the “completed issues” stays the same. The completed work is a count of issues closed. When an issue is closed, the “total issues” remains the same and “completed issues” goes up.

Iteration Changelogs

At the end of every iteration we run a scheduled pipeline job that generates a changelog for the Buyer Expeirence repository. It shows all the chnages made to the project with semanitc commits.

FAQ:

Iteration boards

How long is an iteration?

An iteration is 2 weeks, running from Monday to the following Thursday.

Where can I find the iteration boards?

Iteration boards are created at the team level, and the individual level:

Digital Experience > Issues - Boards > Then selecting an individual’s name or group from the dropdown.

What are the iteration boards used for?

Iteration boards are meant to give an overview of what the team is working on, and to provide a rough idea on what the team is capable of producing in an iteration.

How do I move issues from start to finish?

At the start of an iteration, all issues will have the dex-status::todo label. As issues are worked on, the dex-status label will need to be updated. This can be done by dragging (on your individual board) between columns, or manually changing the dex-status label on the issue.

What if I wasn’t able to complete my iteration board?

Don’t stress, weight points are estimates, unforeseen events happen. Any carryover can be added to the next iteration.

What if I complete my iteration board early?

A few options for when an an individual’s iteration board is complete:

1. Offer assistance to other team members.
2. Pull a new issue from the backlog into the current iteration.
3. Sharpen skills/tools.
4. General housekeeping.

Weight points

What is a weight point?

A weight point is a unit of measurement that’s used to develop a rough estimate of the work required to complete an issue. 1 weight point is measured as .5 days.

How many weight points should an issue be?

The suggested task duration is between 2-4 weight points (1-2 days). There will be exceptions, but it’s recommended to break issues into smaller units of work. Small units of work allow for quicker review cycles, and facilitates collaboration.

Issues

What should I do if I’m assigned new issues mid-iteration?

Generally if an issue is added mid-iteration, it’s high priority. It’s recommended to work with your team to remove the same amount of weight points from your iteration to make room. These removed issues should go back in the backlog.

Apply the dex-unplanned label.

Do I need to add any labels?

Before entering an iteration, an issue should already be refined with the proper labels. The only label that changes is the dex-status label (as the issue moves from start to finish).

What if I’m assigned an issue that I can’t close due to content/data gathering?

Unfortunately there will always be edge case issues that cannot be resolved in an iteration To mitigate the amount of carryover, it’s recommended to break the issue into smaller chunks

Example A: If an issue is open while waiting on content/assets, it’s best to create a content/asset gathering issue and close the original issue.

Example B: An issue is open while gathering data from an AB test, it may be best to create an issue to start the information gathering, and an issue to analyze the data at the end.

Weekly Check In

We use Geekbot to conduct asynchronous, weekly check-ins on iteration progress.

Each member of the Digital Experience team should be listed as a participant in the weekly check ins, and everyone should have permissions to manage the application for our team. The app can be configured through the Geekbot Dashboard, which you can visit directly, or find by clicking the Geekbot Slack conversation, navigating to the About tab, and clicking App Homepage.

Code Reviews

Our team makes every attempt to complete code reviews on Merge Requests as timely as possible.

Team members who create a Merge Request should factor in a suitable amount of time for code and/or design review. If an issue has a due date, the MR creator should try have the work code-complete at least 24 hours prior to the intended release. This gives time for any major fixes that the reviewers may point out, and encourages quick iterations and Minimal Viable Change releases.

When a team member is requested for review, it is good practice for them to post a comment in the Merge Request with an estimated timeline by which they expect to complete the review. For example, it is understandable to take 3 days to do a review, as long as you’ve let the MR creator know it may take that long. This gives the MR creator an opportunity to request a review from another team member.

Digital Experience code request reviews should include the merge request checklist as referenced on the reviewing merge requests handbook page. Merge requests involving a URL redirect should also include the redirect checklist.

Production Change Lock (PCL)

Similar to the engineering department, we sometimes temporarily halt production changes to the Buyer Experience repository when team availability is reduced, or we expect atypical user behavior (such as during high-visibility public events).

Risks of making a production environment change during these periods includes immediate customer impact and/or reduced engineering team availability in case an incident occurs. Therefore, we have introduced a mechanism called Production Change Lock (PCL). We are listing the events here so that teams are aware of the PCL periods.

The following dates are currently scheduled PCLs. Times for the dates below begin at 09:00 UTC and end the next day at 09:00 UTC.

During PCL periods, merge requests and deployments can only be made by senior team members, managers, and levels of management above our team.

Figma Process

• How we use Figma

Denomas Product Process

From time to time, our team has objectives that require us to collaborate on the Denomas product. Read more about the process for our engineers to onboard

Special cases during release post schedule: we hold off on making changes to the www-denomas-com repository during release post days. The release post process is handled by a different team, and it can be disruptive to their work when we release changes to dependencies, CI/CD, or other major changes around their monthly release cadence.

Repository Health Contributions

At the end of every sprint cycle, Digital Experience team members can spend 10% or one day to work on issues related to improving the health of about.gitlab.com, the developer experience, tackle tech debt, or improve our documentation.

The structure of Repository Health Day is as follows:

1. Team members will choose what they wish to work on for this day.
2. Each team member will submit a single merge request to the Slippers Design System, Navigation, or Buyer Experience repository by the end of repository health day.
3. This merge request will be related to an issue from any partner or group within Denomas.

By allowing our team members to contribute to the health of our repositories for a day, we can contribute low-effort, high-impact solutions that will drive results for our team, partners, and the entire marketing site. This will enable Digital Experience team members to use their strengths to efficiently drive results for https://about.gitlab.com/. We’re all good at different things and come from different backgrounds. Let’s use that to our advantage to build a better tech stack that is inclusive of the team members that use it everyday.

Analytics

The Digital Experience team utilizes Looker Studio, a dashboarding tool that visualizes data from Google Analytics, to monitor metrics related to web traffic, engagements, conversions, and site health over time. Team members can interact with the dashboard accordingly by changing the data range, filter by device type or traffic source, or drill-down certain reports with a secondary dimension. A detailed walk-through video of the dashboard is available here.

For any Digital Experience analytics request, please create an issue within the Marketing Strategy and Analytics project using the dex_analytics_request template to outline specific requirements. To ensure a smooth milestone planning, please assign the issue to @dennischarukulvanich ideally a week or more in advance.

Sales Shadows

How to set up a Sales Shadow

SMB

1. Contact a Sales Development Manager (Allison Graban) or Director, Global Commercial Sales Development (Brian Tabbert).
2. Let them know what team you’re from and that you’d like to shadow a few sales calls to observe real Denomas prospects talking to our Sales team to learn [insert what you’re trying to learn here. Example: what the common topics potential customers want to discuss with our Sales team are.]
3. Inform the Sales Development Manager or Director, Global Commercial Sales Development how many shadows you’d like to do and a rough timeline for when you’d like to do them.
4. The Sales Development Manager or Director, Global Commercial Sales Development will inform their Sales Development Reps (SDRs), and they will add you to relevant, upcoming Discovery calls with an Account Executive (AE).
5. Accept the invite and review any supplied material when you add it to your calendar.
6. When joining the call, remember:
   1. You’re there to observe. If asked to introduce yourself, come off mute and do so, then go back on mute and let the Sales team do what they do.
   2. Keep your camera on.
   3. Have a notes doc prepared and take notes on your observations and insights.
7. After the call, review your notes, and synthesize and create action items.
8. Send a thank you message to the Sales team members who hosted you.
9. Once all shadows are completed, share your notes and insights with the team.

Team Shadow Expectations

Whoever gets closest to the customer wins. With this in mind, the Digital Experience team is expected to shadow Sales calls regularly.

Engineers

1 shadow per quarter is the minimum expected requirement.

Product Managers and Product Designers

2 shadows per quarter is the minimum expected requirement.

Contact Us

Slack Group

@digital-experience use this handle in any channel to mention every member of our team.

Slack Channels

#digital-experience-team

#dex-standup

#dex-alerts

#marketing

#website

Denomas Unfiltered Playlist

Watch our team in action on YouTube!

Digital Experience

Digital Experience Shadow Program

We’re piloting a new Shadow program, details here: Digital Experience Shadow Program

Requesting Support

Our team works from a quarterly plan, for example: FY22Q3 and FY22Q4. Our quarterly plan is developed with the intention to put us 30% beyond our capacity which is Denomas policy.

We do our best to assist team members but do not operate as an internal agency so all requests will be prioritized against commitments in our current quarterly plan.

Approving Changes to the Marketing Site

Beginning in FY23Q3, all changes to the marketing site made by team members outside of Digital Experience will need to go through the Marketing Site Approval Process. This ensures all changes align with the goals our Marketing team is working towards. Merge requests created in the Buyer Experience Repository should utilize the marketing-site-change MR template.

Lightning Strikes

What are lightning strikes?

Lightning strikes are when work outside of iteration planning must be performed; these are usually both business critical and time sensitive tasks.

How do you know if a lightning strike is necessary?

There are no specific guidelines we have set in place to what warrants a lightning strike, but these are general guidelines to follow:

1. Has an issue been created?
2. Can this wait until the next iteration planning session?
3. Will the digital experience be blocked by anything not supplied to them?
4. Is this work devoid of significant risks to success in the marketplace?

If you have answered no to all of these questions, it is likely to be a lightining strike. There are exceptions to this heuristic that may exist and can change as our work does. Generally speaking, anything outside of this definition will not warrant a lightning strike

Just because something isn’t a lightning strike doesn’t mean we won’t get to that work. However, that body of work will have to go through the normal triage process and be prioritized there.

Are there any risks to operating under a lighting strike?

Be aware that lightning strikes under quick turnarounds are at a higher risk of error due to the nature of time-sensitive work. It can lead to ineffiency in code which will slow down our velocity.

It is worth noting that the majority of our churn originates from discussions initiated in a Slack thread, and can improperly set expectations to other teams to what our team can deliver. Starting in Slack threads leaves room for interpretation to the deliverable. To maintain efficiency in our operations, we need to acknowledge and address these factors accordingly.

The importance of providing assets and content on time

An essential aspect of our work efficiency revolves around receiving approved content and assets in a timely manner. By providing the team with these necessary resources promptly, you not only expedite the engineering process but also contribute to the overall smooth progress of our projects. Please note that delays in this process can impact project delivery dates scope of work.

Things we don’t do

1. Content changes. You can do these yourself using our CMS, Contentful:
   1. Here’s a quick video on how to search for and edit existing content for the marketing site. For completely new pages, please fill out an issue
   2. Want to learn more about our Contentful CMS? Here’s the documentation
2. Create content. You can collaborate with our excellent Global Content team for these needs.
3. Create branded assets, custom graphics, illustrations. Our Brand design team is so good at this, you definitely want their expertise.

Issue template to submit an idea to drive our business goals

We love collaborating on work that drives our North Star and supporting metrics. If you have an idea, a strategic initiative, or an OKR that we requires our support here’s how you can kick off our collaboration:

1. Review the FAQ section related to pre-work that will increase the chances your issue is prioritized.
2. Create an issue using this template

DEX team members with platform access

Digital Experience FAQ

View page source - Edit this page - please contribute.