Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Development Department

On this page

Vision

Attract and retain happy customers and make customers successful by products of rich features, high quality, fast performance, trustworthy security, and reliable operation.

Mission

The development team strives to deliver product requirements fast, resolve customer issues timely, win with open source community jointly, streamline engineering process for efficiency, and enable data-driven operation and enhance transparency through metrics.

The development team is responsible for developing products in the following categories:

Team Members

The following people are permanent members of the Development Department:

Person Role
Christopher Lefelhocz Senior Director of Development
Stan Hu Engineering Fellow
Tim Zallmann Director of Engineering, Dev
Chun Du Director of Engineering, Enablement
Dalia Havens Director of Engineering, Ops
Bartek Marnane Director of Engineering, Growth
Tim Z. (Interim) Director of Engineering, CI/CD
Todd Stadelhofer Director of Engineering, Secure
W.H. - Todd Stadelhofer (Interim) Director of Engineering, Defend

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Person Role
Katherine Okpara UX Researcher, Development

How We Work

Onboarding

Welcome to GitLab! We are excited for you to join us. Here are some curated resources to get you started:

Cross Functional Collaboration

Often times, certain issues can be resolved more efficiently through cross functional collaboration. Should such an issue arises, the following lightweight process is followed:

  1. Add the label arch review to the issue.
  2. Raise attention in Slack #arch-review.

Note: once the label is added, the issue will also appear on the development department board to receive appropriate attention.

Working across Stages

Issues that impact code in another team's product stage should be approached collaboratively with the relevant Product and Engineering managers prior to work commencing, and reviewed by the engineers responsible for that stage.

We do this to ensure that the team responsible for that area of the code base is aware of the impact of any changes being made and can influence architecture, maintainability, and approach in a way that meets their stage's roadmap.

Development Headcount planning

Development's headcount planning follows the Engineering headcount planning and long term profitability targets. Development headcount is a percentage of overall engineering headcount. For FY20, the headcount size is 271 or ~58% of overall engineering headcount.

We follow normal span of control both for our managers and directors of 4 to 10. Our sections and groups match as closely as we can to the DevOps Stages to best map 1:1 to Product Managers.

Continuous Delivery, Infrastructure and Quality Collaboration

In late June 2019, we moved from a monthly release cadence to a more continuous delivery model. This has led to us changing from issues being concentrated during the deployment to a more constant flow. With the adoption of continuous delivery, there is an organizational mismatch in cadence between changes that are regularly introduced in the environment and the monthly development cadence.

To reduce this, infrastructure and quality will engage development via Availability & Performance Grooming which represents critical issues to be addressed in development from infrastructure and quality. Issues on this board are tagged with gitlab.com and infradev labels. A director from development will be assigned to groom the board, work with product/infrastructure/quality to set priority/severity of issues, make sure they are assigned and worked, and escalate where necessary for resolution.

Grooming will happen on a weekly basis and involve a member of infrastructure, quality, product management, and development.

Rapid Action Issue

In cases where infrastructure needs a more general resolution to a problem, an issue can be opened for "rapid action" (and labeling them rapid action). This is typically around a shared infrastructure resource that is running towards capacity (as examples Postgres and Redis). Often in these scenarios we need several teams to dig in and solve smaller pieces of the problem to reduce load. In this situation, open an issue with the title "XXXX rapid action", give a description of the general issue you want to take pressure off of, and label the issue with infra/dev. If you know the section/groups which need to focus, also include that. An example issue to this process is the following: Redis Rapid Action.

Note: This process includes both escalating issues to be addressed immediately as well as deferring issues that are not critical. When an issue is not critical, it may be removed from the board by removing the rapid action status.

Email alias and roll-up

  1. Available email alias (a.k.a. Google group):

    Managers, Directors, Sr. Director's teams: each alias includes everyone in the respective organization.

  2. Naming convention:

    team@gitlab.com, examples below -

    • Managers: configure-be@gitlab.com includes all the engineers reporting to the Configure backend engineering manager.
    • Directors: ops-section@gitlab.com includes all the engineers and managers reporting to the director of engineering, Ops.
    • Sr. Director: development@gitlab.com includes all engineers, managers, and directors reporting to the senior director of development.
  3. Roll up:

    Groups roll up by the org chart hierarchy -

    • Engineering managers' aliases are included in respective Section aliases
    • Section aliases are included in Development alias

Infrastructure Escalation Process