The Incubation Engineering Department focuses on projects that are pre-Product/Market fit. The projects they work on align with the term “new markets” from one of our product investment types. They are ideas that may contribute to our revenue in 3-5 years time. Their focus should be to move fast, ship, get feedback, and iterate. But first they’ve got to get from 0 to 1 and get something shipped.
We utilize Single-engineer Groups to draw benefits, but not distractions, from within the larger company and GitLab project to maintain that focus. The Single-engineer group encompasses all of product development (product management, engineering, design, and quality) at the smallest scale. They are free to learn from, and collaborate with, those larger departments at GitLab but not at the expense of slowing down unnecessarily.
In FY25 we will continue to mature some of our key projects and to contribute to new opportunities within the AI sphere to build upon the capabilities that GitLab offers. Our current batch of projects are building customer value and interest and achieving significant monthly growth milestones. Our aim is to reach a level of maturity with these projects that allows us to graduate or reassign these groups to new opportunities.
Our success is tied to the community of developers and users that can benefit from our features, and strong collaboration and engagement with those groups is a key focus for this year. As our team matures, we need to be mindful of setting a culture of innovation and results. We do this through encouraging experimentation and autonomy, whilst being collaborative and transparent to internal teams and external stakeholders. The Incubation Engineering team is unique within GitLab in that the team members are not working on shared problems, but have the same challenges and shared experiences. We should ensure that successes and failures are documented and shared amongst team members to help each other grow and to minimise the inherent isolation and stress that can be part of this role.
Investment Framework
The aim of the SEG’s in the Incubation Engineering Department is to get ideas for new markets into the Viable category from our maturity framework. Ideas that we successfully incubate will become a stage or feature within the relevant areas of our product, with full Product, Engineering, UX and Infrastructure support for future development.
In some cases we may invest in an SEG and then decide to acquire an existing product or team in the same area. These situations are disruptive, but unavoidable, and we will work closely with the affected SEG to adapt.
In order to determine our investment into an SEG, we use the following assumptions:
SEGs have a 25% success rate (as opposed to 5% of VC funded companies), due to the existing market reach and technical foundations of the GitLab product and the culture, processes and support from the wider organisation.
SEG’s mature categories at a 50% faster rate than regular GitLab Category Maturity features, due to the narrow focus of our investments.
SEG’s ramp up revenue as good as the best startups in the world (5 year to $100M ARR)
A new market in our product roadmap is a long-term bet to help us expand our Serviceable Addressable Market (SAM) over a 3-5 year time horizon.
We look at areas that fit within our company mission that we currently do not service and have one or more competitors that have validated the customer need. Our criteria for entering these markets is that there is at least one competitor that is attaining over $100M annual recurring revenue, or at least 3 venture capital funded startups that have taken over $5M in funding. We track our understanding of these markets via this internal document.
We also manage projects that may not fit the above definition, but are well suited to the SEG model that we use as they require a degree of experimentation with significant risk of failure. These are significant defensive roadmap items that are important to work on to maintain our market share and competitive advantage in an area, but we cannot yet justify funding a larger R&D effort.
The Incubation Engineering Department is not suited to deliver regular roadmap items as they are typically smaller in effort, have less risk of failure, and have less scope for experimentation to determine product/user fit.
Approach
Key to the success of Incubation Engineering is the ability to iterate on ideas quickly and move on when we can’t find customer traction. We should be able to ship ideas and grow their usage quickly.
Each project should be able to identify a vision and ship working code within the first month after inception, and then have regular monthly goals of continuing iteration and usage growth. SEGs that aren’t well defined will require research to determine a direction. This research phase should include updates to the SEG handbook page, epics/issues, video update(s), and code where that makes sense. We should be aiming foremost for customer results, and not shipping features (even if they show usage) that don’t demonstrate clear customer value.
Each SEG page has a list of the targets and progress for each month, and these should also be demonstrated in a monthly showcase.
Our key focus is to ship software, we do this Iteratively and Transparently in an Agile way, concentrating on having something that works as soon as possible that we can build upon.
For each of our Investment areas, we aim to showcase our progress using the Engineering Demo Process. On the tracking issue for each area, each SEG should provide a status update and a link to a video of the current functionality. We should aim to develop a scorecard to help grade our progress against each of the key features we are trying to develop, and include this in the update.
We do this in order to ensure alignment with impacted teams at GitLab, to provide opportunties for Collaboration from interested GitLab team members, community members, and users, and finally to demonstrate Results.
Mid Month Update Video
Around the 15th of the month each SEG should provide a short update video that covers the following key points:
What progress have we made? Each week we should be moving closer to our goal of having a Viable product or feature.
Current Usage and Used Feedback We should strive to measure usage of our ideas from the beggining. How is the adoption of the idea we are working on?
What have we learnt? Either through technical research, experiementation, or feedback, do we better understand the problem we are trying to solve?
What new decisions do we need to make? Have we identified any new opportunities or options that need wider consultation to help address?
What is our next focus? Our next demo is in a week - what do we want to showcase?
What is the recommended video duration? We strive to maintain an “executive briefing” format for these videos, thus keeping the length around the ~3 minute mark.
End of Month Showcase
At the end of the month, we should have a monthly showcase which demonstrates the current state of each project and future plans, and does not assume any prior knowledge of the progress or vision.
Conventions for SEG Videos
When uploading a video to our YouTube channel, we should:
Make sure they are public
Use a consistent naming convention for the SEG. Take these as inspiration:
“Incubation Engineering - Mobile Ops - Update 4”
“Incubation Engineering - Breach and Attack Simulation - Update 2023-02-21”
“Incubation Engineering - Service Desk - January 2023 Showcase”
Add the video to the Incubation Engineering playlist, and the playlist dedicated to each section
Add it to the specific Incubation Engineer direction handbook page
When an SEG is ready to be handed off to a product development group or other team inside GitLab, there will necessarily be some handover required. Product development groups who are going to be taking over the SEG can accelerate their work by borrowing the Incubation Engineer. This will allow full-time and continuous support for up to 3 milestones.
GitLab is the one DevOps platform. Teams use GitLab (SaaS or self-managed) for development, planning, collaboration and automation. However, digital transformation is incomplete without cloud adoption.
Thus, Cloud Seed — a collaboration with Google Cloud — makes it trivial to consume cloud services from GitLab.
Capabilities
Generate Google Cloud Service Accounts
Service accounts are authentication credentials that can be generated from the GitLab web interface
Used for a wide range of integrations and automation with Google Cloud services
Deploy to Google Cloud Run
Cloud Run is a fully managed deployment platform for containerized applications
Setup automated deployments to Cloud Run via the GitLab web interface including support for Preview Environments
Every Git commit, branch and tag is automatically deployed to the appropriate Cloud Run service environment
Provision Google Cloud SQL databases
Provision popular database instances easily from the GitLab web interface
Support all major versions of PostgreSQL, MySQL and SQL Service
Generate instances, databases and users to be used with deployment and test automations
Airflow is the de facto tool for data teams to schedule and execute ELT pipelines, Machine Learning pipelines,
DevOps tasks and really any task that requires scheduling. Its cronjob turned up to 11.
About the Application Performance Monitoring (APM) SEG
The APM SEG aims to integrate monitoring and observability into our DevOps Platform in order to provide a convenient and cost effective solution that allows our customers to monitor the state of their applications, understand how changes they make can impact their applications performance characteristics and give them the tools to resolve issues that arise.
This group is split into three APM’s that will focus on each part of the architecture:
Threat Insights group in the Govern stage handles Vulnerability Management, Dependency Management, and Software Bill of Materials which all are great segues into targeted BAS scanning.
Vulnerability Research group in the Secure stage will provide benchmarking of our own scanners which can be augmented by extended coverage. The GitLab Advisory Database can be used as a source of threat intelligence for lining up vulnerabilities to target for emulation.
Scope
Running exploits to confirm vulnerabilities is inherently risky. We must be intentional in how we define what is in scope or out of bounds for assessments.
We have an existing Dependency Firewall category which aims to prevent any unknown or unverified providers from introducing potential security vulnerabilities. This SEG will work closely with that group to accelerate the development of the Dependency Firewall feature, and integrate closely with the work taking place on the Dependency Proxy.
An initial MVP may be to implement NPM Audit with a UX that allows a user to specify an allow/deny list against criteria for the container registry. Criteria can include checking for missing author name, email, or look for the existance of specific licenses. We can also add rules to stop dependencies being downloaded immediately after an author change, as an example.
This SEG aims to provide a developer portal for our customers, hosted on GitLab, that is a conduit to various metrics, tools and documentation. Examples include:
Infrastructure health
Metrics such as MR numbers, service desk requests, open issues etc
Our aim is to improve GitLab’s capabilities for customers deploying applications onto Salesforce by integrating our DevOps capabilities. Our first iteration will be to build visual pipelines specific to the Salesforce CI/CD requirements, and develop community templates that can quickly help developers manage their end to end test and release requirements.
The objective of the Five Minute Production (5MP) incubation project is to make (non-k8s) deployments trivial for GitLab users. This includes, but is not restricted to, AWS and Google Cloud as deployment targets.
The KPI is at an acceptable level compared to the threshold
2
Attention
This is a blip, or we’re going to watch it, or we just need to enact a proven intervention
1
Problem
We'll prioritize our efforts here
-1
Confidential
Metric & metric health are confidential
0
Unknown
Unknown
How pages like this work
Data
The heart of pages like this are
Performance Indicators data files which are YAML files.
Each - denotes a dictionary of values for a new (K)PI. The current elements (or data properties) are:
This guide provides guidelines and best practices for how to properly position an Incubation Engineering project, and what needs to be accomplished in order for a project to mature from Experiment to Beta to Generally Available.
Establish an Experiment
The first step when releasing the first iteration for an Incubation Engineering project is to establish the experiment. See the documentation for more details on what makes a GitLab Experiment.
2022 - May 17th, 18th and 18th - Amsterdam, The Netherlands
The team got together in the Mindspace Dam office at the heart of Amsterdam, spending three days together sharing learnings and brainstorming paths to success.
Retrospectives
Post-event retrospectives were held to help the team reflect on the offsite.
Bartek
Good
Team enjoyed meeting each other, and I could see lots of conversations on overlap between different SEG’s.
Great retrospectives from each team member on the challenges they faced in Incubation Engineer, all unique and helpful to the wider audience.
In budget!
Bad
Prework could have been better structured, presented (@sri19 did a great job here)
Try
Requests for more team building / social activities.
Stay in the same location
Janis
Good
An agenda focused on sharing and validating visions
Closed setting allowed being open about issues and problems
A really nice setting I found inspiring
Natalia visiting was great
Bad
random interactions were short and limited to food breaks
the ’loose’ agenda felt at times aimless
Try
co-locate everyone
add a team building exercise
set goals beforehand (“Building relationships” is a great goal, but writing it down might have lead to a different agenda)
set an agenda with varying intensities to make engagement easier
Fred
Good
Was nice to meet everyone and built relationships
Better understanding of what everyone is working on, struggling with and thinking about (more details than written)
Random conversations
Bad
It was exhausting, maybe due to the fact of working remote and not being used to meeting people
First room was not suitable for all day activities due to the lack of air-conditioning and proper / ergonomic chairs
Try
Less ambitious agenda, we skipped over a few items due to not enough time
Preparation of items, we should really focus on activities that can not be done remote / async
Eduardo
Good
Everyone got here and got back safely!
All lunch places were great
Better understanding of each ones struggles
Bad
Being in the city some of us live created mixed experiences, I wish I could have enjoyed the team more beyond the dinner and meetings, but I had personal things to do meanwhile.
Personal, and related to my neurodiversity, but the amount of time in a meeting room really burned my energy out. Discussions with too many (5+) people are the most exhausting for myself, and by the end of the second day I was just existing there. Smaller groups could have helped.
Try
A city new to everyone
More activities together, rather than panels. Or activities that tie in discussions (eg case study/pair programming). I really wish we could have done a scavenger hunt, boat or simply play some boardgames.
For things that require reflection, it would be better to give more time. For example, on the CREDIT exercise, coming up with an achievable goal for change in 5 minutes won’t bring the best results: perhaps we could have done half of it before lunch, and the other half after lunch to give more time to discuss. Breaking up into smaller groups would have slashed the time as well, specially on the Time Horizon activity (which was a great activity)
Hannes
Thanks @sri19 and @bmarnane for all the work that has gone into organising this. This was invaluable for me in terms of onboarding, but also to connect with the team and company.
Good
I really liked all the insights into the various projects, what problems folks are dealing with, but also what goes well, how you embed yourself into the wider organisation and even how to see things from a completely different angle (partner, customer, product, …).
Bad
I think the presentations need to be more structured. We need to find a balance of on-site preparation and shorter presentations, but I believe this part needs to be more efficient (not necessarily faster). I suggest following some sort of template (What I am doing?, How I am doing it?, Roadmap/Next, Problems, Asks, AMA). I also liked the original idea of having some sort of a small working group.
Try
Us being in completely different domains does not necessarily mean we can’t help each other validating ideas. I think we could benefit from a dedicated session where we try to provide input and give feedback on the roadmap/vision in general.
Darby
Overall, it was a great offsite, and we accomplished a lot in just a few days. I’m excited to see how the Playbook idea materializes over the coming weeks.
What went well?
The whole team was able to attend in person
There was a good mix of focus time, social time, and personal time
What could have gone better?
I liked the Time Horizon workshop, but I thought it could have been more effective with some pre-work. We didn’t track many asks, which would have made it more impactful. I didn’t feel as well prepared for those sessions as I would have been.
I think people staying in different areas created some logistical challenges and led to missed team bonding opportunities.
What could we try for next time?
I think it would be helpful if everyone stayed in the same hotel (even local folks) or the same neighborhood. IMO this has worked well at other conferences and GitLab events I’ve attended.
A little bit of pre-work could help folks switch from coding mode to thinking of things from a higher-level perspective.
Istio is an open source service mesh platform that provides a way to control how microservices share data with one another and allows users to run distributed applications at scale.
Istio solves connectivity challenges inherent to distributed services:
Routing traffic correctly between distributed applications
Providing retries and failsafes for connectivity issues
Connection security
Observability of connectivity and traffic flows.
Our aim is to provide Istio support to help our users easily deploy server-less applications and manage them from within GitLab.
This group’s mission is to enable Frontend developers to build, deploy and manage externally facing, static websites using Jamstack architecture in a simple, configurable and scalable way.
Frontend engineers should be able to use GitLab as the primary place to manage Jamstack Frontends.
Low-code and no-code are two distinct concepts that target different personas and require separate product strategies. This page presents low-code and no-code work streams in two sections.
At GitLab, issues and MRs are the backbones to project planning and delivery. Project managers typically have processes to update issue assignees, labels and other statuses based on certain triggering events and conditions. However, these repetitive takes do not scale when the orgnization grows and become counterproductive and error-prone.
NOTE: The MLOps Incubation Engineering project has become the MLOps team. These pages are left fir historical purposes, but are not actively maintained. Please refer to the MLOps team page for updated information.
The future roadmap for Mobile DevOps will look to mature the build, sign, and release capabilities that exist today while introducing new features to support the test and secure stages of the process. Below are the items we look to address in coming releases.
Our aim is to integrate monitoring and observability into our DevOps Platform in order to provide a convenient and cost effective solution that allows our customers to monitor the state of their applications, understand how changes they make can impact their applications performance characteristics and give them the tools to resolve issues that arise. APM is a core part of the DevOps workflow as it shows the direct impact of deployed changes.
The goal of REID was to ship an MVP to enable real-time collaborative editing of issue descriptions. This would also serve as the foundation for building additional real-time collaborative text-editing use cases at GitLab.
A user should never have to leave the GitLab application for tasks like pair programming, collaborating on isssues, merge requests, tech designs and RFCs.
REID has been developed following the principle of progressive enhancement.
The Secret Rotation SEG is a Single-Engineer Group within our Incubation Engineering Department. Our aim is to create a secrets management solution that automatically rotates secrets in both CI pipelines at runtime, as well as into an already deployed running application. We can iterate towards this solution by integrating with existing well known tools.
The Self Healing Dependencies group aims to provide users/developments with automated assistance that helps them to keep their dependencies updated.
In GitLab we understand which customer repositories and containers are affected by problems or vulnerabilities with an underlying library used by your code. This allows us to create a merge request that fixes the issue. We will merge automatically, deploy and monitor the changes. If we detect any problems, we will rollback and make an issue for the user to investigate.
This page provides a comprehensive overview of Server Runtime and catalogs relevant links and pages. It is created and maintained by @shekharpatnaik. The Server Runtime SEG Single-Engineer Group is a part of Incubation Engineering Department.
About Server Runtime
Server Runtime is aimed at engineering a performant, scalable workspace experience & productizing it as a customer offering. When this comes to fruition, we envision being able to bring to bear a workspace experience that is browser and platform agnostic and lets GitLab users build, run and test their code right within the GitLab platform. We see this as a viable product idea to generate revenue for the company & to transform the IDE experience for engineers. Competitors in this space, currently, are GitPod and Codespaces.
Our goal is to provide a complete, yet lightweight and customizable customer support solution that seamlessly integrates with the GitLab ecosystem and brings customers, support staff and developers closer together.
Mission
Make Service Desk useful for professional support teams so they efficiently and effectively work through their support issues.
Helping organizations build a professional and on-brand customer support workflow that grows with the business.
Making Service Desk an integral part of the GitLab support workflow by providing the tools our teams need.
Helping managers and support ops automate repetitive tasks for their support staff.
Increase awareness of the capabilities of GitLab Service Desk and how it can help our customers handle customer support.
