How customer empathy drives better engineering performance with Ravi Sahu of Strayos

Transcript

Ledge: Ravi, thanks for joining us. It’s really cool to have you.

Ravi: Thank you, David. I’m happy to be here.

Ledge: Can you give a two- or three-minute intro of yourself and your work to let the audience get to know you a little bit?

Ravi: Absolutely! I’m Ravi Sahu and I’m the founder and CEO of Strayos and my background is in enterprise software. I’ve been building software for the last fourteen years. I graduated with a computer science degree from India and then worked for different Fortune 500 companies globally in Europe, Canada and, in the last eight years, in the U.S.

I started Strayos with the passion of my old work that I was doing which was in data and the machine side of bringing that to the new industries like heavy industries, most especially mining.

At Strayos, we are transforming how the mining operations get done in the drilling and blasting utilizing sensors as well as the drones. So we have built a platform. It’s a 3D visual intelligence platform using artificial intelligence and drones to reduce drilling and blasting cost that happens on a mining site on a daily basis.

Ledge: That’s amazing. There are so many places to go with that. How or why did you get into mining? How did that even come up and where did you see the opportunity for the technology?

Ravi: That’s an interesting question because I don’t come from the mining industry. There is no background where I’m exposed to any mining industry.

So how I stumbled into was basically kind of a problem, a problem that got me excited; and the way I stumbled into the problem ─ I had an early prototype about the computer vision that started as a side project taking the images, reconstructing 3D models ─ just the side project that I was working on.

During that time, I was also pursuing an MBA degree in Washington University of St. Louis and one of the innovation project was to basically come up with an idea and build a business in two days.

I submitted this with a group of my other teammates and, fortunately, one of the team members had a mining background for the last thirty years where he sold his last business on the blasting side. So when he saw my first prototype, he said, “Wow, is this just a side project or are you doing something else with it?”

I said, “This is a side project” and he said, “This can be taken to the mining industry. There’s a lot of potential use cases here that can be immediately applied.”

And he explained the problem. I was not convinced but, then, we started talking to real customers or real industry partners and they said, “This is a real problem for us and if we can do something about it that would move the industry forward.”

The more I kind of dived into it and the more I talked to customers and understood the real pain, I felt that this is not just a side project and I needed to do something about it and make it solve the real problem here.

That’s how I got into the mining industry. I started visiting the real mining sites and seeing how the jobs get done. For the last two years, it’s been an amazingly crazy journey of learning everything about drilling and blasting, learning everything about mining and geeking out with the rock mechanics and geotechnical attributes and how what we can do with that in building algorithms get them better results.

Ledge: That’s amazing! It’s like the perfect entrepreneurial story. You didn’t even know you solved the problem and then people really wanted to pay money for it. I love that.

Previously, off-mike, you and I talked about the way that you sort of have a unique program where you train through internships and you have field time for the software engineers.

I would love if you talk about that because, I think, a lot of times, there is difficulty in getting software engineers particularly close to the customer; and that’s not even in domains that are sort of advanced in the field as mining.

How do you do that because I think that learning is really important for anyone who has a customer-focused problem and for engineering teams?

Ravi: That’s what we see in this industry. It’s not just about building a product and understanding how users use this product but also having the sense of empathy about how the users go through when they’re using the product and how much basically this problem ─ what we are solving ─ is cutting down the time that they’re spending in the mining site but also removing them from the harm’s way and also having an empathy towards their job.

That’s why Strayos is not just about hiring the engineering talent who are great in building products but also finding this talent who cares about going into the field and spending time with the real users who are literally boots on the ground working day in and day out in the mining and quarry site. They’re pretty smart people. They’re pretty well tech oriented and they come from an engineering background.

But, a lot of times, they don’t get a chance to talk to the actual technology people who are building and writing this product or building this hardware for them. So connection is not there, and that’s what we think is important when we started to build out this product; we need to do this in a way that we are embedded with them.

When we started seeing this happen, we were very aligned with not only the users’ but we see a greater adoption.

So instead of just hiring the engineering talent in a way that we go out and look for candidates in the job boards or source out to the recruiters, we started doing basically an internship mentor program through various universities. We started to partner with them to basically bring in the interns and go through the usual training. Instead of just platform-driven training, we also going to through entire domain knowledge training. Then, if you feel really passionate about being associated with the industry, then you are a right fit for us to be converted to full time. And that’s where we have seen really great results.

From the talents, we’re not only good in building the products but also aligning with domain. And if they see that “What I’m building is actually changing people’s lives on the field” and they see the greater impact, then those are the great talent for us then.

Ledge: Great! I love that because you can really develop that customer empathy from the ground ─ literally from the ground in your case and not even metaphorically.

For all of our super technologist listeners particularly on the ML and AI side, talk about the technology, the stacks that you use, the way you actually deploy this stuff from code to field.

Ravi: Absolutely! From the technology standpoint, how we deliver the product is through the cloud-based software as a service and our front end is in the latest version of Angular JS and the backend is Ruby and Python. We basically use Graph QL API as an engine and we deliver high advanced JS like ASX which is basically 3D data. So we build our own 3D-renderign applications to deliver these large ASX in web browser.

And then, from the data processing perspective, the image processing that happens when we are acquiring the data through drones or through any other camera sensors ─ we’ve built the entire stitching engine on C++ and, after that, any segmentation and classification machine-learning pipeline is in Python at the moment.

We use JS for their frameworks and machine learning tools, mostly TensorFlow and Keras. That’s how our stack looks like. And we use some open-source components on the JS side as well as some Python library scale.

Ledge: As the founder, it started with your technology. I imagine you’ve moved into engineering leadership and company leadership and business and all those things. How has it been moving away from maybe spending all your time in code and delegating that? How do you manage the growth of the engineering team?

Ravi: I started as a lone wolf kind of thing where I was doing everything. I like building products so I was really passionate about not letting it go. I needed to do everything and getting all in little details. So that was the hardest transition for myself ─ going from each little detail of the product to, now, letting really talented people do their job and trusting what they’re building and what decisions they are making.

It’s great for the technology and the architecture itself.

To answer your question as to the growth perspective, I mentioned that even from the internship talent perspective as well as the leadership team that we hired and the technology, we had a mindset about coming up with a proposal and approach and seeing how they would do if they would actually propose that for their own company, treating that as their own company and how that would turn out.

Building that micro entrepreneurship within themselves, that is an idea we have in the company ─ that if you are proposing this architecture, if you are building this module, you go and run completely and independently and create a micro team, maybe have a another person working with you and deliver this product or deliver this small feature.

It doesn’t matter where you are or whether you’re just an intern or you just joined the company or you’re a junior developer. And that kind of gives the sense of responsibility and the impact that they can see immediately; and that’s what kind of have let me scaled the engineering talent fast.

I think it’s mostly about what they see that the impact has been great so that helps in scaling fast; and through that process, we have found that the same talent go and find another talent or bring in more engineering sources.

So I realized that when they start to see not just the flexibility and independence they have in working on the stack but also see the impact immediately, we see that basically the circle feeds itself in terms of the scale and the engineering growth.

Ledge: What are some really nasty engineering problems that took longer to solve than you hoped, just big speed bumps in the journey?

I think we all get wrapped up in remembering the best stories. What are some of the crazy things that you had to solve that just didn’t go well?

Ravi: I have lots of those, by the way. We’ve made a lot of mistakes but I think we have learned from them. One of the biggest speed bumps, I would say that almost derailed our product roadmap was in January 2018, almost a year ago.

We decided to do an architecture, basically a complete shift on how we deliver the data. It was more of going to an enterprise architecture mode. We built the first version of a product; as you always kind of hear from everybody, the first version of a product looks great but as you kind of approach towards the bigger enterprises, they have different requirements; they want different workflows.

We decided to tweak our architecture ─ not just tweaking our architecture but also completely creating an enterprise workflow where any size of data can be onboarded; any number of users can create internal workflows. That was the idea which we called as the “site-based architecture.”

That was a massive undertaking in itself to just re-architect the whole thing and also use different stack as well moving from Angular 1 to kind of a completely new version of the Angular.

And the way we started approaching is we thought that everything would work greatly with this architecture. We didn’t realize that the way we designed the workflows and the architecture, the users were pushing in almost under one site ─ basically what we called as the “different mining site.”

Under one site, they were pushing fifty, sixty data sets per day. And then, you have to visualize the entire fifty data sets in one geolocation; and each data size is about two gigabytes.

And so, you can see almost a hundred gigabytes of data that you have to visualize as it’s loading instantly; that was the enterprise workflow that anybody can come in and visualize whenever they have done the projects and instantly, it will load. That was the idea.

While it didn’t work, it started crashing things and we started to figure out why it was happening. So we had to almost spend about one and a half months tweaking that whole thing and writing compression algorithms to take care of that first; and we basically went back to the users who were not ready to get this new workflows and a new architecture out and we had to hold it off.

So almost one and a half month of gap was there to just let our users either use the old version of the product or wait for this to be released.

Ledge: So your cultural customer empathy ─ I wonder how did that help you present that news to customers and they were willing to still stay on board because if you haven’t had that and you didn’t develop those relationships with customers, maybe they wouldn’t have been as willing to remain on board? Did that happen? Did you find that the relationships were valuable?

Ravi: Absolutely! In this industry, I think the relationship is a prominent part in basically exchanging or doing any transactions. That definitely helped. They were generous enough to not only wait but also give their feedback in a way that during this time, we were constantly trading; and they were giving their time to test it out as well.

So that helped us in not only encountering other types of mistakes that could have gone when it did during that one-and-a-half-month period. So, definitely, the empathy plays an important role here especially for us. We lost two years.

Ledge: Sure. The way you treated customers to begin with, I’m sure, made a huge difference. That’s really fantastic. I’m sure you’re glad you made that investment.

One question I love to ask all the technology leaders that I interview is ─ at Gun, we’re in the business of finding and vetting and retaining the very best engineers ─ ten-plus years of production experience, many code examples, able to pass all the tests, able to have all the soft skills and great communications and excellent remote work.

We have a pretty complicated rubric for measuring those things and some heuristics that we keep track of in our process. Yet, we know that there are always other best practices.

With every tech lead I talk to, I’d love to know “What are your heuristics for hiring engineers? How do you know that you have the very best people? What do you measure? And what characteristics and skills are you paying attention to?”

Ravi: Strayos and especially the way I kind of think about hiring ─ now, I have also my colleagues and the engineering leads. They participate in the hiring decisions.

But I think hiring great people is really difficult. It’s so difficult to find great people, let alone hire them.

The heuristics that I have are ─ basically the skills and the tech stack and the past projects all sound great but I think the biggest thing that I look for is how hungry they are in learning things.

If I give them two days for a problem to solve, I’m not looking to get the problem to be solved itself but what I’m also looking is how much they have learned in these two days. That’s what I look for when I hire anybody new or when I’m making my hiring decisions because a lot of the things we are working in Strayos are new and I don’t expect anybody to know everything when they’re coming on board.

What I’m looking for is basically a learning ability in how they learn and how they are using that learning to create something in a limited period of time.

That’s one key item. The second is basically aligning with our value system. The value system doesn’t to be the same but it’s mostly alignment. So I look for that. when we talk. Those are things I look for whether they would align within the team or how much of the culture is there.

Ledge: Have you experimented at all with remote work or is it all on site?

Ravi: No. In fact, we have remote team members. For the first year, we didn’t have a remote team but in the second year, as we kind of scaled, we have built remote teams. We’ve learned lessons building remote teams as well.

I think there’s always a good balance keeping on-site team and the remote team ─ and kind of scale within the model because remote teams ─

For the past fourteen years, I worked for fourteen Fortune 500 companies and I worked remote teams all my life in my career.

For the startup, I think I had the hardest time building remote teams.

Ledge: So what are some of those lessons? I think this is a mandate at this point. There’s just isn’t going to be enough talent at all. Forget about enough talent locally.

What are the lessons? People are going to have to face this. What have you learned?

Ravi: I wouldn’t say it’s a lesson for everybody here but my experience is the remote-team part is, again, really treating them as a part of the team, that they are with you. And when we are doing the interview process or doing the onboarding process, they need to feel that they’re not a remote team member, only that they’re not in the same place. They’re just in a different office.

If we can develop those types of feeling, I think the remote team culture is successful. Standups are great but I think the other things that needs to happen is organizing basically a weekly lunch for them. Even though I am remote, we can do lunch with them from here. I think, a lot of the times, when we are in the same place, that doesn’t happen.

It’s kind of a more bonding activity and that is important for building a remote team.

Communication: Various tools that can be collaborated but I think if we don’t use them right, and that’s a part of the problem as well. We had some issues earlier when we were not using them right.

Again, I think the remote part is having a sense of understanding and what’s basically the ideal scenario and ideal working hours for them and respecting those boundaries because just because they’re remote, they’re not available all the time to answer the questions.

And it’s empowering them with more and more responsibilities in terms of the impact, what impact they’re going to be making.

The one thing that we have started to do for the remote teams as well is if we are doing maybe a customer visit or a conference, we bring them in from time to time even though they are remote.

Our trade shows, our key customer visits, our key customer workshops ─ in that case, they should be a part of all these activities when we are doing it together.

Ledge: Ravi, congrats on your success and the continued growth. This is a great story. Thank you so much for joining us and sharing your insights.

Ravi: Thank you, David. It’s really great to be here and it was awesome chatting with you.