It appears eBay may be feeling the heat from increasing user complaints about glitches on the platform, prompting Chief of Staff of Seller Experience, Valeri Yee, to stop by the eBay for Business podcast this week to discuss how eBay handles new feature rollouts and technical issues on the site.
Griff introduced the topic, and their guest, with a caveat to set the bar for expectations low - remember, every site deals with bugs...it's inevitable!
Griff: Every website, no matter where it is, how big, how small runs into the occasional code bug, it just happens. It's inevitable. Remember that most websites are dynamic. They don't get to shut the website down for six months while they build new code base.
But it's not the inevitable bug that matters, it's how the website manages to deal with them and how quickly they deal with them. And that's what we're gonna talk about today and joining us to help us get some insight into this topic is Chief of Staff of Seller Experience here at eBay. Valeri Yee, welcome back Valeri.
"But it's not the inevitable bug that matters, it's how the website manages to deal with them and how quickly they deal with them."
Valeri introduced herself and gave some background on how eBay's technical teams handle code updates and those darn inevitable bugs.
If you don't understand all the "agile" "scrum" tech speak, don't worry - as CEO Jamie Iannone would say, it's all just part of eBay's magical tech-led reimagination!
Valeri: I have been at eBay almost 19 years, which is crazy to think about. I have watched the product evolve from when we didn't have native app.
Griff: Which is mobile.
Valeri: Yes, sorry, mobile. Yes. And we were on just a few countries. It was just much smaller. It was actually, it was fascinating. We had one huge code base and when we completed code it took us six weeks from code complete to live to site back then. And now we launch code like three days a week.
Griff: I didn't know it was six weeks back then.
Valeri: It was, Yeah. It was kind of crazy.
Griff: It used to be every six weeks. It's now three times a week. How does that work? How do we roll it out?
Valeri: So we actually are, we act as independent scrum teams. We practice the agile methodology. And so each scrum team, usually it's anywhere from six to 12 to 14 engineers and they work on a particular section of the code base and they're the subject matter experts in that piece. And there are many, many, many scrum teams across the organization and they all launch code on demand as they need to.
So in certain areas, in in seller experience and the listing tool for example, they launch code three days a week. But some teams may launch code daily, just depends. Some have a a weekly schedule. It's up to the code actually it's up to the team. They get to decide.
Griff then asked Valeri to take us through a typical experience where a bug is reported, escalated, and finally (hopefully?) resolved.
Griff: We had a recent code issue for Memorial Day. It's known internally I guess as the Memorial Day code bug?
Valeri: Just, it happened, that was just the weekend it happened. Unfortunately on a holiday weekend.
Griff: Can you take us through the timeline of how it was discovered and then the solution?...
...Valeri: So for the specific advanced listing tool bug, there was an issue where for some of our users it was appearing blank on their browser. It was a very small subset of sellers and it was on Memorial Day weekend, of course the team was notified via customer support monitoring and they worked the holiday weekend, they reproduced the issue and immediately rolled back the changes that were made on the Friday. And it's standard procedure to roll back the previous version you had to ensure the minimal customer impact...
...Griff: Beyond taking the reports and rolling back, is there anything the team does kind of proactively to see if they can figure out what's going on?
Valeri: So yeah, in this particular case actually what they did is then to find the root cause of the issue. 'cause we knew something was going on, the team added some additional troubleshooting tracking to the code. We don't do this for everything because the code would be super bloated and super slow.
...So for this specific case, they made four code changes on that Friday and that were made to Listing tool.So to find the culprit, the team relaunches one code at a time, they closely monitor it with the additional tracking data to try to pinpoint that issue. And so of course it was the fourth one that had the issue.
I watched them do it on Monday or sorry,. Monday's a holiday. So they did it on Tuesday and they did it on Wednesday. And then Thursday night I was in the office super late, it was like 10 o'clock at night, a bunch of us here still working on it and I'm in San Jose and they were, it was actually kind of fun for me, not fun for them, but I'm sitting there witnessing this whole process of watching them literally roll the code on one, you know, they're monitoring it on one monitor and then the second monitor is watching the like error codes...
...And because of this, eBay has a minimum standard as which web browsers we support. So in order to protect us, and I mean you as the customer and eBay as a company, the latest versions of browsers are always safer from a a security standpoint and also from a functionality standpoint...
...But in this particular case, the fourth culprit was a code change that was refactoring a portion of that code to utilize the latest technology for the web browser. And what this meant in reality was that the older browsers didn't understand what that new code command we were using was because that code command literally didn't exist when the browser version was created. And so it got to that code command and went, I dunno what this is and it went blank...
...The reality is that a small subset of customers were using an outdated browser and that they were the ones that were affected...
...And so it's really frustrating for them obviously. And it's frustrating 'cause everyone else is going, I don't have this problem so I do not know how to help you. So that's the inside sort of scoop of what happened on the Memorial day when the Advanced Listing Tool went blank for a few users.
I hate to break it Valeri, but that was not the only or even the worst bug that happened on Memorial Day Weekend.
So why did she go with the smaller blank listing tool issue instead of the much more widespread and disruptive Memorial Day Weekend glitch that randomly relisted sold items and increased quantities without seller input, causing many canceled orders and bad buying experiences?
Maybe it's because they could blame the blank listing tool issue on sellers simply not updating their browsers instead of drawing attention to a much larger problem eBay later admitted was caused by an error on their side when releasing an update to international shipping options.
Also pro tip for Valeri - suggesting users should check the eBay System Status page for issues may not be the best bet when it is notorious for almost never being updated to reflect documented widespread outages and disruptions.
Back to Griff's original statement - ""But it's not the inevitable bug that matters, it's how the website manages to deal with them"
Sellers have become all too accustomed to eBay ignoring, obfuscating and only paying lip service to problems when they become too big to completely deny, usually followed by gaslighting or blame-shifting to avoid any hint of accountability.
If this podcast episode was meant to show how eBay manages to deal with inevitable bugs, it was an accurate portrayal - though likely not in the way they had intended.
eBay had a golden opportunity here to pick any one of the many recent major bugs that have impacted users on the platform, address it seriously and win some points for transparency.
It's disappointing, but not surprising, they failed to do so.
What do you think of how eBay deals with "inevitable" bugs and how quickly they respond to technical problems? Let us know in the comments below!