1. The
GitLab Case
Case #14
Angelos Karageorgos, Camila Moreira, Viktoria Chalkidou

2. Background Open source coding platform founded in 2011
•1800 contributors worldwide • 39 countries
• customers: organizations and millions of users
Software development and operations lifecycle include:
• planning • coding • testing • getting feedback from the community
• releasing • configuring • monitoring
GitLab Community Edition: free for the first year designed for users
GitLab Enterprise Edition: premium paid version for B2B customers

3. CBIM Value proposition
Efficient coding platform free for users and premium solution for B2B
Relationship
Support their community
Transparent and open relationship
Position
Leadership in open source coding market
Expression
Informal
Contemporary
Transparent
Brand Core
Everyone can contribute
CREDIT: Collaboration, Results, Efficiency, Diversity, Iteration, and Transparency
Personality
Friendly
Open
Honest
Explain the elements of the matrix focusing on Core, Culture, Mission&Vision and Relationships which will be used to relate to the reputation elements later.
Mission: change all creative work from read-only to read-write so that everyone can contribute
Vision: allow everyone to collaborate on all digital content so people can cooperate effectively and achieve better results, faster
Culture
Collaborative
Supportive community
Competences
Efficiency Improve coding projects speed
©CBIM Urde 2014

4. Incident 23:00 UTC It’s late and he is tired. He is about to sign off.
He accidentally executes the command on a primary database!
23:35 UTC
Backup fails.
17:20 UTC
A software engineer is trying to fix a problem that block users from posting comments on the platform.
23:25 UTC
He has an idea on how to solve the problem.
To remove a directory from a secondary database.
23:30 UTC
Bang!
300GB of client’s data on GitLab.com
re deleted!
12:20 UTC
GitLab.com has to be taken down to try to fix the problem.
Storytelling: On January 31st, 2017 at approximately 23:00 a software engineer at GitLab was frustrated as he was trying to fix a database overload on GitLab.com since 17:20 without success. Due to this problem, many users were not able to post comments on issues and merge requests on the platform. It was late, and he was very tired, so he mentions to his colleagues on Slack that he was signing off. But he doesn’t and has an idea to fix the problem by deleting a database. He executes the command on a primary database and bang! He accidently deletes 300GB of client’s data on GitLab.com ! He and other engineers try to locate backups and they can not find it. They realized they would have to take the website down while trying to fix this huge mistake.

5. Crisis

6. would this affect their reputation among their stakeholders?
Question
How should GitLab communicate this incident to their community of users
and
would this affect their reputation among their stakeholders?
This questions is to guide the presentation of the scenarios. Do not start discussion here.

7. Scenario 1 Manage the crisis silently and internally
hide the outage and communicate that the website is down for maintenance
try to fix the problem as fast as possible
take the junior engineer out of the case and hand it over to senior developers

8. Scenario 2 Communicating product failure
take the website down stating a database problem that you are trying to restore
communicate the real problem in more details when the issue is solved without revealing that the cause of the incident
not expose the employee and the vulnerability of the system

9. Scenario 3 Go full transparent
share the situation in real time with the community
asking them for suggestions on how to fix this problem
keep the junior engineer involved in the case

10. Scenarios
Taking the role of GitLab’s managerial team, how should GitLab communicate this incident to their community of users and would this affect their reputation among their stakeholders?
Scenario 1
Scenario 2
Scenario 3
Manage the crisis silently and internally
Communicating product failure
Go full transparent
On the board list positive impact and risks of each scenario to guide discussion.
Assisting questions:
Should GitLab fire the junior engineer who deleted the database?
What would be the consequences of each alternative of action for their brand reputation?
How would the incident be perceived by their stakeholders?
Would we share the outage with the community; real time, later time or never?
Should they have different approaches to communicate the incident with each stakeholder group?

11. Action

12. Management Decisions Step 1: Act fast and now
Step 2: Explain all the details and keep the public updated
Step 3: Monitor your brand mentions
Step 4: Transparent all the way

13. Step 1
Act fast and now
The company decided to bring GitLab.com down and inform their followers on social media such as Twitter about it. A hashtag was used for this purpose with the name #HugOps. They also informed them that they would be performing emergency database maintenance.

14. Step 2 Explain all the details and keep the public updated
Created a Google Docs explaining in details what they were doing to fix the problem
YouTube livestream with their engineering efforts
Constantly updating their community on social media

15. Step 3 Monitor your brand mentions
Online monitoring all mentions of GitLab brand
Immediate response to every comment

16. Step 4 Transparent all the way
2 days later GitLab published a detailed explanation of the problem
CEO of GitLab apologized personally about the lost data incident of 300 GB which affected 5000 projects

17. Community Reaction
Explain the graph with the engagement when they made the first post on Twitter - Feb 1st and when they posted the Postmortem on their blog on Feb 10th.

18. Core Values
GitLab core values guided their actions and had a positive impact on their reputation
C-ollaboration
R-esults
E-fficiency
D-iversity
I-teration
T-ransparency
Reflecting on GitLab’s actions and how they were committed to their core values during the entire crisis.
Collaboration: Ask for help from their community which is formed by software developers
Results: monitoring live the process of problem fixing
Efficiency: full effort on restoring the database as soon as possible
Diversity: Keep the junior engineer responsible involved in the process
Iteration: Learn from mistakes and implement new procedures to avoid these type of mistake / Control access to primary databases
Transparency: Communicate the problem in details to their community/Apologize in public

19. Willingness to support
Reputation Elements
Trustworthiness
Reflected through its
community collaborative support and the company’s effective decisions
Relevance
Differentiation
Value proposition
Relationship
Position
Expression
Brand Core
Personality
Recognizability
Credibility
Willingness to support: Community’s actions showed their willingness to support the company during the crisis, by committing and providing
their valuable spare time to retrieve the lost database.
Responsibility: Working as a unified team, with
one common goal, co-creators and developers showed the real importance of GitLab’s
core values on which their community is built. Therefore, proving their commitment
and accountability of both the community’s as well as the company’s side enhancing
the element of responsibility of GitLab’s reputation.
Trustworthiness: GitLab channeling through its community collaborative support and the company’s effective decisions managed to
reflect and enhance their trustworthiness to all their stakeholders.
Mission
& Vision
Culture
Competences
Willingness to support
The community committed and provided
their valuable spare time to retrieve the lost database
Responsibility
Co-creators and developers showed the real importance of GitLab’s
core values proving their commitment
and accountability
Performance
©CBIMR Urde & Greyser 2016

20. THANK YOU!
Questions?