It’s 8 p.m. on a Saturday. You’re at home relaxing, watching a movie, decompressing between hectic work weeks. Suddenly, your phone buzzes. Then, again. And again. By the time you reach for it, you see multiple messages that all say variations of the same thing:
“Something’s up with our site, it keeps crashing.”
Now, depending on who your IT partner is, you have some different options. One is that you wait until Monday during working hours to address the issue. But remember, it’s Saturday night. That means your site will be broken for a minimum of 36 hours — far from ideal. Unfortunately, if your IT vendor doesn’t offer after-hours support, this is where your list of options ends.
If they do offer after-hours support, it’s as simple as making a phone call or sending an email and you’ll be back online in no time, right? Ideally, yes. However, it’s not always as simple as that. Traditionally, application maintenance and support services teams are staffed with junior software engineers who are essentially using bug fixes and backlog work as on-the-job training. It’s a pretty sweet deal for them — they get to cut their teeth on real products while learning how to address a fairly broad array of issues as they arise.
But what does that junior staffing model mean for your crashing product at 8 p.m. on a Saturday night? If the issue causing the crash is something the junior support staff is unfamiliar with, it may mean a significant delay in getting things back up and running. Again, far from ideal.
And that’s just this particular incident. What about next time? Your IT partner may have been able to get your site up and running, but what happens in September when your companion iOS app doesn’t work with the latest iPhone or iOS version? Do you scramble to find an iOS developer to learn your app and make updates? And curses! In October, the new Pixel phone messes up your Android version.
In most cases, those are your two options — neither of which fixes the problem or your product in a timely manner. When we began building out our continuation engineering team, we set our sights on designing a support model that’s efficient, more reliable, and frankly, easier to execute.
So, how did we do it? By staffing our continuation engineering team with superheroes.
Okay, so maybe they’re not actually superheroes in the traditional sense. (Well, except for our Senior Cloud Engineer Yulia who can be seen above shooting an arrow from a galloping horse. She might be an actual superhero. We’re suspicious.) But what they lack in radioactive superpowers, they make up for in their ability to quickly solve any software problem that arises.
Our continuation engineering team is comprised of hand-picked, senior-level people who are all well-versed in multiple technologies, industries, and system configurations. System Administrators, DevOps, QA, Front and Back End, Mobile — you name it, and our team has experience in it. They all know multiple languages and have been around long enough to find a bug with their “Spidey sense”. In fact, they have 192 combined years of experience or an average of 12 years each. This depth of knowledge and expertise allows every member to really take a big-picture look at a problem and nail every detail — all while working quickly and efficiently.
Additionally, our entire support staff is cross-trained so when an inevitable 8 p.m. Saturday night incident rolls around, you’re never without someone who knows your product and how to fix it. Everything gets properly documented so that team members can swoop in and save the day when future bugs occur.
While all of this sounds great when talking about a hypothetical crashing app scenario, how does it actually look when put into practice? Here are just a few examples of what our team of superheroes has been able to accomplish for our clients.
Out With The Old, In With The… Old
A client who was new to MentorMate brought their existing product to us that was built on a long-discontinued third-party platform. Since they had no interest in investing in an entire rewrite of their e-commerce platform, our team instead supported it as it was. However, once they became a client, we were not only able to support it but enhance it as well. We managed to fix some fairly vexing issues that even the platform vendor had trouble solving.
After a client introduced a new financial product, they shifted their budget to focus on marketing and sales to promote it. They reduced the size of their MentorMate team, moved into continuation engineering, and began working part-time with one primary developer. That developer, in turn, could work with other technologists like mobile experts or QAs on an as-needed basis. This allowed the client to still support their product while investing most of their budget into promoting it.
Handling Unexpected Growth
A client with a newly-launched social media app experienced a massive, unexpected surge in traffic due to a, shall we say, less-than-riveting internationally televised sporting event (aka that wildly boring Super Bowl earlier this year). As it turns out, when people are bored, they look at their phones a lot. Who knew? The client put out the MentorSignal and our on-call staff was woken up. They had the system stabilized in no time and continued working on it the next day to make permanent adjustments to the configuration so future surges wouldn’t cause further issues.
Our team has supported several clients through the acquisition of their product or company. Transitions to new management and processes around rebranding, product, and third-party software integrations are rarely easy. The acquiring company brings their own values and interests to the product which can cause unwanted changes or conflict. To ensure that everything runs as smooth as possible during the transition, MentorMate provided technical continuity while everything else was being figured out between the internal teams. This meant that, while a lot was happening behind the scenes, the end-user didn’t experience any disruptions using the product.
What’s In A Name? Turns Out, Quite A Bit
Following a mishap caused by improper file naming, a client came to us with a critical component of their system inoperable. Our team took parallel approaches to restore and rebuild the service as quickly as possible. This resulted in not only a fix to the issue but an upgrade to the underlying technology as well.
In each of these scenarios, our team of experts delivered fast results and minimized client frustration by fixing things right the first time. Just like Yulia, we hit the target right away rather than going through an arduous trial and error process. Ultimately, that should be the goal of any application development delivery and support services team. Unfortunately, that’s not always a reality if the team is comprised primarily of junior development staff instead of (near) superheroes.
For continued reading about Continuation Engineering, check out our newly updated guide: You Built An App. Now What?