Incubation Engineer's Playbook

Incubation Engineer’s Playbook

This playbook contains useful tips and tricks an Incubation Engineer may employ for SEG and project success.

Structuring each Project page

Each Incubation Engineering project has its own handbook page which is linked from our list of current projects.

The following sections are should be included:

Problem Statement

Outline the problem that we’re trying to solve for our users.

Vision

How do we intend to solve the problem? What is our overall vision for this project and how it will fit into GitLab?

Milestones

What is the iterative approach that we’ll be taking for each project? How do we measure and demonstrate success? Link to epics and issues as required.

Go to market strategy

Outline our marketing strategy. How do we intend to find early adopters, build communities, and get potential users interested in our projects?

If you’re building a feature that should have a distinct name then please reach out to #marketing for assistance, and take into account our Product and Feature Naming Guidelines.

Jobs to be Done (JTBD)

JTBD is an important part of the process of establishing an SEG. Not only does writing job statements help the SEG to clearly identify their areas of focus, but it also helps to communicate the roadmap and rationale to the rest of the organization and the broader GitLab community.

Each SEG should add a section to their handbook page and create a table with 3 to 5 job statements for their area. Each row in the table should include the following columns:

  • The job statement
  • A maturity rating (can be empty initially)
  • A link to a confidential research issue
  • A link to a public roadmap issue or epic

Job statements should be written from the perspective of the user and describe the problem they are trying to solve. As in “When [situation], I want to [job], so I can [outcome].” See the JTBD page in the UX handbook for guidance on writing job statements.

The Maturity Rating should align with how maturity is measured in GitLab (minimal, viable, etc.), and should be measured using the same criteria as described in the Product handbook.

The Research Issue should be a confidental issue in the SEG project with information that has been gathered by the SEG or other sources and should capture what has been learned about a specific JTBD. This can include notes or recordings from customer conversations, competitive research, or any other public industry information.

The Roadmap Issue (or Epic) should be a public resource for the SEG to communicate the planned roadmap and current state of development.

An example of this structure can be seen on the Mobile DevOps Handbook Page.

GitLab Product Development Group affinity

List the the product development groups, if any, that the SEG project may impact as a link to the appropriate handbook page. In the early stages this may not be known and may change as the SEG project evolves, please update when there are changes.

References

Links to articles (both internal and external to GitLab), issues and epics that provide further information on our approach.

Glossary

It’s important to use the correct market terminology, and to define terms that may be unfamiliar to readers.

Converting an incubation backlog project to an active SEG

In order to maintain consistency, the process below should be followed when starting a new SEG from an incubation backlog project:

  1. Request “Owner” access to the Incubation Engineering group from one of your fellow department members.
  2. Create a new subgroup within the Incubation Engineering group. For example: mobile-devops
  3. Create a meta project within that new group. For example: mlops/meta
  4. Create a twice montly update issue in that new meta project. This issue will replace the existing backlog project issue and be used to post bi-weekly demo recordings from the new SEG. For example: jamstack
  5. Add all labels from the original backlog issue to the issue you just created. For example: original issue | new issue
  6. Add the new project to the seg_issues_list in the handbook direction generator module in the handbook. See this MR for an example.
  7. Close out the original backlog issue with a comment pointing to the new weekly update issue (example).
  8. Make sure the project maps to an existing stage and feature category, or create new ones if needed. For example: Add No-code Automation SEG stage and feature category. Feature categorization is mandatory in RSpec examples to identify the group owning this file.

Video demos / updates every two weeks

Every 2 weeks a meeting between the CEO and VP of Incubation Engineering is scheduled. In advance of that meeting Incubation Engineering team members are expected to showcase their work in a short video. Beside the YouTube guidelines, there are some guidelines for said video:

  1. Add your video to the playlists, and remove your older video from latest
  2. No customer information should be displayed
  3. Video should be public unless it shows confidential information
    1. if it does show confidential information, remove those parts and make it public
  4. Videos should be around 3 minutes, think of it as your elevator pitch
    1. If you need more than 3 minutes, you can still do that but don’t put it in the playlist Incubation Engineering - latest
  5. Quality should be 1080p or higher so content on screens shared is still readable

Playlists

There are 2 playlist in general:

And then there are the SEG specific playlists, you might need to make one and follow the naming convention: Incubation Engineering - <SEG>

Shadowing Field Marketing Events

Incubation Engineering team members benefit from shadowing customer / prospect events. This is aligned with the FY22-Q4 Engineering OKR “Increase focus on customer results..”.

Field marketing has welcomed all Incubation Engineering team members to shadow upcoming field marketing events. These events are conducted with new prospects, existing customers and individual GitLab / DevOps enthusiasts.

Incubation Engineering team members may discover issues for upcoming events, and may request an invitation by commenting in the event’s issue.

The following issue boards are to be used to discover upcoming events:

Highlighting EMEA because majority of Incubation Engineers reside here. Other regions can be discovered in the Boards dropdown by searching for “Field & Corporate {region_name}”.

Additionally, Field Marketing has active Slack channels where events are planned and prepped for. If useful, please consider joining:

  • #emea_northern_europe_fieldmarketing
  • #emea_central_europe_fieldmarketing
  • #emea_southern_europe_fieldmarketing

…on Slack. Other relevant channels may be discovered via Slack search.

User and customer conversations

User and customer conversations are considered to be an important part of product development, and they are equally important when it comes to Incubation Engineering projects. Direct conversations with users will provide insights into their perspectives, expectations, and behaviors that would not be possible otherwise. Incubation Engineering team members should look for every opportunity to discuss their projects with users and leverage what they’ve learned to inform JTBD and influence product direction.

Incubation Engineering team members should aspire to be involved in at least a couple of conversations each month. These conversations can take many forms - from direct conversations, to joining customer calls with folks in other departments, to conversations at a meetup or conference.

Take advantage of GitLab resources with guidance on how to facilitate customer interviews and look for opportunities to join calls with other product leaders to learn about their approach.

For Incubation Engineering team members not familiar with customer conversations, it is perfectly okay to simply shadow calls and to say nothing throughout the call. Introduce yourself if invited, and help GitLab team members by keeping notes.

Those comfortable with external interactions may offer their services to the Field Marketing event lead by means of answering questions and interacting with the participants when the GitLab speaker requests support.

Quality & Support Guidelines for Incubation Projects

  • Is your feature behind a feature flag? It’s preferrable that it is.
  • Can your feature be visually labeled as an incubation or experimental feature without distracting / taking away from the GitLab user experience?
  • Error messages / stack traces / logs may indicate that this is an incubation feature.
  • Before feature flag roll-out, is the feature documented in sufficient detail? Documentation is the first resource for users and support agents working with the feature.
  • Pro-actively reach out and make introductions before feature roll-out / general availability.

Security Guidelines for Incubation Projects

Incubation Engineers should familiarize themselves with the GitLab AppSec Review process and preferably have the AppSec review triggered early for each merge request when appropriate.

Incubation Engineers are often required to create prototypes or demo applications as they are iterating on ideas and gathering feedback. Below are some security guidelines to keep in mind while building these applications:

  • Code for prototypes and demo projects should be hosted in the Incubation Engineering specific gitlab-incubation-engineering-demos. This is preferred because projects in a subgroup will inherit configurations from the parent group (group access tokens or group CI variables for example), which can result in unintended behavior when an project hasn’t accounted for the inherited configurations appropriately.
  • Prototypes and demo projects should follow GitLab’s Secure Coding Guidelines.
  • Use of Personal Access Tokens is discouraged, Project Access Tokens are often sufficient.

UX Engagement with Incubation Projects

For UX support, see how Product Designers engage with Single Engineer Groups (SEGs).

Releasing Features

When releasing features, ensure you engage the Application Security team if your feature matches the guidelines of what should be reviewed, and follow the guidelines for documentation.

Write a Release Post

Once you expect your publicly visible feature to be in the next release, it’s time to write a release post. Start this process as early as possible, it’s easier to move it to the next review cycle than to rush the process.

Due to the SEG-nature of our group the process is slightly different from the default. As you wear both the Engineer’s and PM’s hats, the process is faster, but you’ll also lack a second pair of eyes. Check out the PM Contributors section of the release post Handbook page for the default process. Here is a Incubation-adjusted TL;DR:

  1. If you created a feature issue that used the [feature issue template] (https://about.gitlab.com/handbook/product/product-processes/#feature-templates), use the release post item generator
  2. Alternatively, create your Release post MR manually
  3. Go through the “PM release post item checklist”. Note that in Incubation Engineering you act as both the PM and EM.
  4. The only required reviewer is the Technical Writer for the Stage/Group your feature is located in. See the Tech Writer Assignments to find out who that is.
  5. Other Reviewers are optional, but it’s recommended to add the PM for the group of the feature for visibility.
  6. Since you are also doing the EM work, you can self-merge the Release post once approved by the TW.

Tools Incubation Engineers Use

Video Recording and Editing

  1. Zoom - Allows you to record you, your screen and participants
  2. OBS - Allows you to record your screen
  3. Final Cut Pro - Video editing
  4. iMovie - Video editing
  5. Kdenlive - Video editing
  6. Loom - Allows you to record you, your screen, edit, and other things
  7. Descript - Video editing, can remove your “ums,” “uhs”, “you knows”, and other filler words

Code Editors / IDEs

  1. Jetbrains IDEs
  2. Visual Studio Code
  3. Sublime Text
  4. Vim
  5. GitLab Web IDE

How do I…

Add a new API endpoint?

This MR gives an example on how to add a brand new API endpoint

  1. Code under /lib/api
  2. Entities tests under requests/api/entities
  3. API tests under /requests/api/
  4. use ApiGuard to assert api permissions

Get Community Engagement?

Engaging with the Community and getting feedback is tricky when starting an SEG, and more so if the SEG focuses on an area GitLab has not previously engaged in. Here is a list of things that have helped others find communities:

Communities

Find the Discord and Slack channels of your community and engage in conversations.

Polywork

To recruit external users, creating “Opportunities” in Polywork is a useful resource. But: asking for interviews straight away is too high a level of engagement for users. A more successful strategy is to create a Google Form without too many freetext questions, then linking it as an Opportunity in Polywork. Polywork embeds Google Forms, so the users don’t have to leave the site.

If you ask for contact details for follow up questions, you have a set of recruits that may be more open to follow up in-person interviews if needed. (Note: Contact details are PII data. Do not use it beyond the usecase indicated on the form, do not save it elsewhere and delete immediately after use. Refer to our Privacy Page for details)

Last modified February 5, 2024: Fix security-engineering to product-security redirect (9c36c658)
View page source - Edit this page - please contribute. Creative Commons License