Partnering for Engineering Success – Aravo Solutions Part II

VP of Engineering on mobile quality, scalability and teamwork

Interviewer: So what were the key attributes you were looking for when you actually signed up with a vendor like us? So I think you answered that question.

Eric Hensley: It’s related to those two, right? Absolutely. We needed a vendor who could scale. Quality was certainly a big deal then. Also, Aravo has a certain type of corporate culture. Aravo is a smallish company, but we have very large customers.

And so we needed a partner that embodied that sort of dichotomy in the same way that we did, where we could spin people up quickly. We could change directions quickly, but also give the appearance of a high degree of professionalism, such that our customers, who, like I said, are these huge Fortune 500 companies, remain confident in our ability to deliver, but also get the kinds of benefits that you expect from a SaaS type company.

Interviewer: Got it. So I’m going to get into some cheesy marketing questions. So what are the three words you would use to describe our service?

Eric Hensley: Okay. So I would say core competency, specifically in QA, sustaining engineering and support. Particularly, the first of those has always been the thing that comes to mind with Apexon, quality. So that’s No. 1, core competency and quality.

Second is certainly dynamism. We have a highly dynamic business here. I mentioned this a little bit already. But the ability to pivot, change what we’re doing in any given quarter and sometimes in any given month in our business, even though we have these huge customers, remains important. And a partner that can do this and can kind of roll with us in that way −

Interviewer: Right, reactive.

Eric Hensley: − reactive, exactly, sure, absolutely, reactive. And then, yeah, that would be it for that one.

Interviewer: Okay. And any specific value-adds that you can think of that our team did for you?

Eric Hensley: Excuse me for a minute on that one.

Interviewer: Go ahead.

Eric Hensley: You’ll have to ask it again. I’m running on water already.

Interviewer: No problem.

Eric Hensley: Not live.

Interviewer: It’s okay. So specific value-adds that we brought to the table, if you will?

Eric Hensley: So there are general value-adds and there are specific value-adds. I already mentioned, in terms of the Apexon competency and quality that you bring actually everything that you do for us is a specific value-add that is across all of the functions that you do for us.

We have people working on support. They have a quality mindset. We have people working on sustaining engineering. They have a quality mindset. Everyone at Apexon thinks about this in a way that isn’t necessarily common among technical professions that aren’t specifically quality-focused. That is a value-add.

The other specific value-add that we have is there are individual humans, team members who work for us who are just spectacular, who are absolutely dedicated to our business goals in a way that’s unusual among partners.

Interviewer: Right. What about frameworks and best practices? That probably will be covered in quality, but if you can throw some more light on that and how we’ve helped you.

Eric Hensley: Yeah, absolutely. One of the first things that we did when we brought Apexon in as a partner, on the technical side of things, is move to an Agile software development methodology. A partner that did not have a facility with Agile software development and a set of tools and experiences that allowed easy integration into an Agile software development methodology, which requires very tight integration between your product’s function, your engineering function, and your quality function, would not have worked for us.

Many partners can do software quality. Many partners can do sustaining engineering. If you’re a partner that requires traditional software methodology, whereby we’re generating a lot of specification, we’re doing integration for engineering, and then we are passing that to a quality team and stating upfront everything that needs to be validated or verified, that wouldn’t work for us.

And so a core competency and Agile software development, combined with that dynamism and reactivity that I mentioned before, allowed us to be very successful there.

Interviewer: Very nice. And any quantifiable metrics, in terms of reduced costs or increased operational efficiencies?

Eric Hensley: Absolutely. We maintain a variety of quality metrics. For example, we have a defect discovery rate. We have defect effectiveness. We maintain metrics around a number of defects found after major releases. All of those roll up into customer satisfaction metrics. All of those significantly improved, I would say immediately, when we moved the Apexon quality team and process in and have continued to improve since then.

Interviewer: I see.

Eric Hensley: There’s significant expertise there. Now, we’re doing the same thing with support. We are sort of working on improving our support processes here and just getting the leverage from the Apexon support team. And I’m immediately seeing improved throughput on support tickets, faster resolution times, and again, increased customer satisfaction from that.

The last one in our sustaining engineering team, this is a very − this is an unusually quantifiable engineering function, insofar as a lot of what’s done is brake fix, defect management, and the rate of defect management. The Aravo application is technically complicated. It has ten years of development against it, and it’s a configurable platform, and so defects are traditionally difficult to triage.

And, as the sustaining engineering team has increased its familiarity with our code base, our rate of defect management resolution has gone up several times, non-linearly, better than linearly. So I’ve been very happy with that.

Interviewer: Would you be able to put a number to it?

Eric Hensley: Yeah, absolutely. When I first spun out the sustaining engineering team, we were processing, per release − we release monthly, and we have two sprints per release, and we release monthly − sometimes three to five defects, right in there, sometimes one or two. As the team has become more familiar and our processes around that have matured, now, we’re up to sometimes 15 a sprint, and so, on the order of 30, which is a gigantic improvement −

Interviewer: Gigantic, yeah.

Eric Hensley: − without a significant change in resourcing.

Interviewer: Yeah, yeah. What about support? Any numbers there that you can quote?

Eric Hensley: Yeah. Our support metrics have − let’s see − we have closure rates, which we measure in terms of time, which are down about 30 or 40 percent over the last, I would say, three months, as our − basically, it was a matter of enabling of the team at Apexon to, I think, work in a more natural fashion for a support team. I think there was some − had some process difficulties there in the past. As we’ve enabled them, I think, to do their jobs more effectively, we’ve seen closure rates have come down dramatically −

Interviewer: Very nice.

Eric Hensley: − from sometimes − averages out, you know, measured in weeks, which is generally fairly unacceptable from a customer point of view, into…