What Leo saw at GitLab, 2. One fault, three hand fixes, and the team that removed them
In January 2020 GitLab's support team ran a two hour Salesforce to Zendesk sync by hand two or three times a week to correct one fault. Leo joined three separate hand fixes into one problem. 27 days later, GitLab's team removed them, and the commit says why.
We gave Leo GitLab's public handbook exactly as it stood on 31 December 2019, and nothing later. This is the second thing we want to show you that it noticed, and this time the story has an ending.
GitLab had no part in this
We used GitLab's handbook because it is public and openly licensed (CC BY-SA 4.0). GitLab did not take part, and nothing here is GitLab's view of Leo. Every quote below links back to GitLab's own pages and commits.
The claims, and where to check them
| Claim | Where to check it |
|---|---|
| A two hour bulk sync was run by hand two or three times a week to correct one fault in the Salesforce to Zendesk sync | GitLab's Support Ops page, 31 Dec 2019 (the page at that commit) |
| That is roughly 200 to 300 hours of sync a year, by GitLab's own figures | Our arithmetic: 2 hours, 2 or 3 times a week, 50 weeks |
| On 11 Jul 2019 GitLab opened a project for the fault, "PROJ: ZD<>SFDC Sync Issues" | GitLab's epic 107 |
| On 20 Nov 2019 the hand bulk sync was written into the handbook as the workaround | GitLab's commit 46257a54 |
| On 27 Jan 2020 the hand process came out of the handbook, "not used anymore after new integration" | GitLab's commit 4f6a88c8 |
| On 18 Apr 2020 the new sync was documented | GitLab's commit e1338d3f |
| Leo read the whole 911 page handbook in about 3 hours of reading, for US$113 | Leo's own run log |
The work as it was
GitLab's customer records lived in Salesforce. Its support tickets lived in Zendesk. A sync carried each customer across, with its support plan, so that a ticket from a Priority customer was treated as one.
The sync had a fault, and the Support Ops page said so plainly: "all our new organizations in Zendesk are created with a Starter GitLab plan (even if they are Priority customers)."
So the team worked around it. "We run a Salesforce to Zendesk bulk sync twice or three times a week... The process may take around 2 hours." A daily script checked the two systems for mismatches. And when an organisation still showed the wrong level, an agent edited the account's support level in Salesforce to something else, saved, set it back and saved again, to force a resync, then tagged that customer's open tickets by hand.
What Leo saw
The fixes were written on different pages, by different hands. Leo joined them into one account and named what they had in common: "Three hand fixes now cover the same fault: the Salesforce to Zendesk sync puts the wrong support level on organisations." It also noticed that the handbook named support levels four different ways across four pages, and that two pages disagreed on when a ticket alerts the account's manager.
The way forward
Leo laid out one way here: improve the sync itself. Fix how the ongoing sync maps the support plan, and all three hand fixes go at once, and so does the window in which a Priority customer's tickets carry the wrong service level.
What happened next
On 27 January 2020, 27 days after the snapshot Leo read, the bulk sync section came out of the handbook, with the reason in the commit itself: "Removed as this process is not used anymore after new integration." On 18 April 2020 the new Salesforce to Zendesk sync was documented. By 2022 it had a named owner and a backup, and by 2023 its own code project. None of the later pages mention new customers landing on the wrong plan.
When a business takes a path, Leo's card records it, even when nobody tells Leo. We played GitLab's own commit back into Leo the way a connected repository would. The card matched it to the way it had laid out, dated it the day GitLab made the change, and kept GitLab's reason in GitLab's words.
The difference is time
Leo did not cause this. GitLab's own team had seen the same fault and fixed it. That is the point, and the difference is how long it took.
| When | What happened | How long after GitLab opened the project |
|---|---|---|
| 11 July 2019 | GitLab opens a project for the sync fault | |
| 20 November 2019 | The hand bulk sync is written into the handbook as the workaround | 132 days |
| 31 December 2019 | The handbook Leo was given | 173 days |
| 27 January 2020 | The workaround comes out, after a new integration | 200 days |
| 18 April 2020 | The new sync is documented | 282 days |
Leo had none of GitLab's tickets, meetings or context. It read the whole 911 page handbook cold, in about three hours, and joined three fixes written on different pages by different people into one root cause, with the fix at source. In that same read it mapped 458 of GitLab's processes, with ways forward for 306 of them.
To be fair to GitLab's team, 200 days is how long it took to act, not to understand: they had diagnosed the fault by July. The claim here is narrower and still worth making. From documents alone, with nobody pointing at the problem, Leo reached the same root cause in hours. And while the workaround stood in the handbook, from 20 November to 27 January, the bulk sync alone was about 40 to 60 hours of hand work by GitLab's own figures.
What this does not show
The handbook shows the hand process going and a new sync arriving. It does not show how much time the change saved in practice, or what else the new integration needed. The hours above are GitLab's own figures multiplied out, not a measurement.
Leo learns how a business really runs by reading what its people write and talking with them, lays out the ways the work could go, and keeps the choice with the people who make it. When a path is taken, its card records it.