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

Configure Frontend Team

On this page


The Configure frontend team works on the following Configure stage groups & GitLab projects:

Team Members

The following people are permanent members of the Configure Frontend Team:

Person Role
Jean du Plessis Frontend Engineering Manager, Configure
Mike Greiling Senior Frontend Engineer, Configure
Jacques Erasmus Frontend Engineer, Configure
Enrique Alcántara Senior Frontend Engineer, Configure

Stable Counterparts

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

Person Role
Grzegorz Bizon Staff Backend Engineer, Serverless
Taurie Davis Staff Product Designer, Configure
Ahmad Sherif Site Reliability Engineer, Manage, Monitor & Configure
New Vacancy - Seth Engelhard (Interim) Engineering Manager, Configure Orchestration
Nicholas Klick Engineering Manager, Serverless
Daniel Gruesso Product Manager, Configure:Orchestration
Dan Davison Senior Test Automation Engineer, Configure
Evan Read Senior Technical Writer, Manage, Verify, Configure, Growth
Thong Kuah Senior Backend Engineer, Configure
James Fargher Senior Backend Engineer, Configure
Hordur Freyr Yngvason Backend Engineer, Configure
João Cunha Backend Engineer, Configure
Tiger Watson Senior Backend Engineer, Configure
Matt Kasa Senior Backend Engineer, Serverless
Alishan 'Ali' Ladhani Backend Engineer, Serverless
Alex Ives Senior Backend Engineer, Serverless
Magdalena F. Backend Engineer, Serverless
Viktor Nagy Senior Product Manager, Configure:Serverless Group
Maria Vrachni Senior Product Designer, Configure

Group focus

We work with both the group::orchestration and group::system backend engineering teams and to facilitate focus and priortization our team members are assigned to one of the two groups. Being assigned to a group doesn't mean you will exclusively work on that groups' work.

The intention is to allow the frontend engineers to focus on a smaller part of the product and optimize their learning and time spent in meetings. We also plan to rotate team members between the groups every few months.

Current group focus:

Team member Orchestration System
Mike Greiling  
Jacques Erasmus  
Enrique Alcántara  

Backend & Frontend Issue Collaboration

Our team follows the GitLab workflow guidelines for working in teams.

Given a reasonable sized issue, that requires UX, frontend and backend work, the preferred way to collaborate on the issue is as follow:

  1. Once an issue is labeled, workflow::ready for development , backend is usually able to start working on the issue.
    1. This is a good time to discuss and clarify interdependency between backend and frontend
  2. Most of the time, only once the issue is marked as UX Ready , is it ready for frontend development.
  3. Backend and frontend will work on the issue in separated branches
    1. Each will submit their own MR for review
    2. Frontend and backend will put the feature behind a feature flag
  4. Once both MRs have been merged, a third MR will be opened to integrate the work where backend and frontend will collaborate to:
    1. Remove the feature flag
    2. Add documentation
    3. Implement e2e tests for the feature

The above is a guideline and clear communication should be preferred over process to ensure the best collaboration strategy on an issue. For example on smaller issues, or where the frontend component of the work is minor, it may be feasible to work on the same branch.


Repos we own or use


Our goal is to move towards a continuous delivery model such that the team completes tasks regularly and keeps working off of a prioritized backlog of issues.
The team joins the weekly Configure and Serverless team meetings, to stay informed around the issue priority and knowing when specific issues are ready for development.

Once a team member completed their assigned issues, they are expected to go to the Configure or Serverless issue boards and assign themselves to the next unassigned issue in the list that has the frontend and workflow:ready for development labels.
The issues on the board are prioritized based on importance (the higher they are on the list, the higher the priority).
If all issues are assigned for the milestone, team members are expected to identifying the next available issue to work on based on the team's work prioritization (see below).

While backstage work is important, in the absence of prioritization the team will have a bias towards working on bug or feature categorized issues. The manager will also bring to the team's attention any work that is considered important/urgent to ensure appropriate attention is given to it.

Work prioritisation order

  1. Configure group stage issues
    1. Orchestration
    2. System issues
  2. Working group issues (for when a team member is part of an active working group)
  3. Docs project issues
  4. Pajamas Design System frontend issues

If stakeholders from the Docs or Pajamas Design System projects want an issue priortized above other work they should reach out to the manager who will in consultation with the PM make a determination as to when the work can be accommodated.