While it is true that there are few non-technical roles left in today’s business environment, it is notable that even folks outside of engineering use GitLab technology for collaborative project management. In this first part of our two-part series we outline the problems of siloed communications and how GitLab is structured to solve that for developers and everyone else. In part two, we’ll take a deep dive into how we used GitLab to manage an integrated marketing campaign and how our product marketing team uses GitLab for complex project management.
Imagine you’re trying to launch a new, integrated campaign. This campaign has a central message (e.g., "Everyone can contribute") and it pulls in representatives from many different teams – like social media, blogs, and field marketing – to create the designs and content that make this campaign a reality. The campaign structure is built and you’re ready to go – but wait – you’re working in a silo where communication between teams is challenging and there are strict rules about how information is conveyed.
Marketing programs manager Jackie Gragnola kicked off the “GitLab for Non-Tech & Project Management Use" breakout session at GitLab Contribute New Orleans with an icebreaker game that mirrors this very conundrum. Breakout group participants were assigned teams as they tried to rebuild a gumdrop structure, but with strict communication guidelines. One person could see the structure, and relay what the structure looks like to three runners, who then described the structure to one builder.
Needless to say, the inefficiencies mounted quickly.
"The problem was one person could use their eyes, one person could use their mouth, one person could use their ears," said Joyce Tompsett, analyst relations manager at GitLab and an observer/reporter in this game. "So, even though everybody had all the component pieces they were only allowed to use one function at a time and then there was no return communication allowed."
The “can’t see the whole picture” problem is a common one in every industry and the solution is to make collaboration painless. Collaboration is one of our core values at GitLab and it is fundamental to how we run our business and how we designed our tool. To understand how GitLab can work outside of software development it’s helpful to understand the underpinnings.
How GitLab works
Developing software is similar in concept to baking a layer cake. You need a really strong foundation to keep your cake upright, and each coating of frosting between the cake layers acts as the glue that holds it all together. The top layer of frosting makes sure that all of your layers stay in one place (and makes sure that the layer cake is looking like a cake).
A layer cake is a great analogy for how GitLab works as a project management tool.
"The frosting between those layers is like webhooks or APIs; they’re actually the integrations that make the two pieces of software talk to each other," explains JJ Cordz, senior marketing ops manager. "Each task that's above the next one can get more complex because it's building off the foundation that you've already put into place."
The difference between the typical DevOps layer cake and the GitLab layer cake is that every activity or function fulfilled by a different layer of the cake (i.e., discrete piece of software) happens entirely within GitLab. In the GitLab layer cake, everything from project planning to execution allows teams to collaborate together within a single tool.
Our description of the GitLab layer cake is actually how GitLab is structured today: With groups at the top, followed by epics, and projects that have issues, templates, etc. All of the layers can work together to build a fluid workflow, or they can be used independently.
"So all of those pieces together can actually standalone or you can put them all together and it makes a really awesome process in a workflow," says JJ. "You can actually have lots of teams working together to get something massive done, but you've broken it down into little pieces."
Project management within GitLab
If you want to start thinking about getting "something massive done" within GitLab consider these basic steps:
- Create a framework: Before diving into a new project, a good project manager will first define what the ideal state is and will then build a framework for achieving this ideal state.
- Assign directly responsible individuals (DRIs): The PM will assign DRIs to different components of the project. Each DRI is responsible for that particular component and is the person that you can follow-up with regarding that component throughout the project.
- Templatize repeated tasks: Keep things efficient with templates.
- Set service level agreements (SLAs) at each handoff point: Think about the due date and work backward to sort out how long different tasks should be taking.
- Write rules of engagement and fallback instructions
- Define the feedback process: Ensure that you have a place for people to ask questions, and make the room to iterate as you go along.
What does this look like in the real world? Our marketing team built a project management structure within GitLab that allows multiple teams to collaborate within the marketing group. Each team (e.g., corporate marketing) has their own project, where other groups and projects can live.
Epics – which represent projects that contain multiple issues – also live at the marketing group level rather than living within smaller team projects. The epics live at the marketing group level because oftentimes multiple marketing teams (e.g., corporate marketing, product marketing, etc.) will be tagged in different issues within a particular epic.
Efficiency is another one of our values at GitLab and the marketing team created templates within different marketing teams for repeat tasks to keep processes more uniform and efficient.
We also created a unified, global view that allows us to track the progress of various marketing projects. We have four labels: work in progress (wip), plan, review, and scheduled, that are assigned to a marketing issue that indicates the various stages. The labels allow Todd Barr, our chief marketing officer, and anyone else on the marketing team to see a global overview of various issues within marketing as they move from the idea to completion phase.
A global overview of all the activities happening in marketing, separated and labeled according to their current status.
The marketing team uses two-tiers for our epics: the highest level is the ancestor (formerly called "parent") epic, and below that is the child epic. There can be multiple issues associated with the child epic, but an issue can only be associated with one epic.
How the marketing team uses ancestor epics and child epics.
Now that you understand the basics of GitLab and project management within GitLab, watch the video on executing sophisticated and integrated marketing programs.
And don’t miss the second part of this series where we put the spotlight on our internal successes using GitLab for project management.
Cover image by Startaê Team on Unsplash.
