Meet an InOrbiter – Florencia Grosso

At InOrbit, most of our time is spent thinking about robots and how to make them perform better. But part of that vision includes robots and humans working together – without the human factor, robots are just a collection of metal and plastic parts. Here is another in a series of posts highlighting some of the outstanding humans on the InOrbit team, also known as InOrbiters. The posts aim to share details on some members of the team, what drove them to work here, and what they find most interesting about robotics and the development of the InOrbit platform.

Today we sit down with Florencia Grosso. Flor is a Customer Success Engineer and a Sr. Roboticist at InOrbit. She works closely with both the engineering and the customer success teams. She lives in Buenos Aires, Argentina, and has been with InOrbit for four and a half years.

Let’s start with what drove you into robotics?

As an Electronics Engineer, Robotics is an area that I've always wanted to explore, as it was both futuristic and enigmatic to me. I like solving problems, and working on a platform meant to help orchestrate fleets of robots is definitely a challenge. When I describe my job I usually say: "Imagine the future, do you picture robots in it? Well, I work in the service of that future".

I am also very interested in AI and biomedical engineering. Robotics are fundamental to helping us enable or restore the functionality that people may have lost, for example, the capability to communicate with the world or move around.

How did you end up at InOrbit then?

You know I actually wasn’t planning to work in Robotics initially. I was planning to work on Machine Learning and computer-brain interfaces. So maybe some Robotics, but really Robotics related to Medicine. Then I came back home to Argentina after working abroad in Germany and the industrial development is just not that big here. So I started looking for a position as an Electronics Engineer.

This profession is more about hardware, working more with devices, and when I started looking for a job there weren’t very many since we don’t produce much hardware in Argentina. Sure, there are jobs to repair, but some of them said you need to be a man to do repair work… and I was very mad at that. But then I found a friend who worked at Ekumen who shared my resume and helped me get a job there. I found I liked software when I started working on it. At Ekumen I started working on partner projects with InOrbit. So I ended up working closely with the team here. Eventually, I came on board at InOrbit.

So what’s something you love about your role at InOrbit?

I love working with robots as much as I love working with the people around them. From engineers to operators, everyone has something to share. I’ve found many experienced people willing to teach me what they've learned so far to help me grow.

This is an ecosystem that moves at a fast pace and there are a lot of questions to answer. We rely on each other to move forward.

What exactly does a Customer Success Engineer do? 

One of the huge advantages of being with InOrbit for four years is that I know A LOT about the product. I work directly with customers. Our customers may need help with integration or implementation. I always push them to make their ramp-up as smooth as possible. I try to understand what they really need, and what we can offer to make their pain points go away. One of the things I also really like is pushing them forward. I make sure customers know we are available and ready to help, in a timely manner. I am on the front line with customers, and I know how to translate what customers need to engineering. So we can prioritize, adapt, and help as needed.

How easy or difficult is assessing pain points with new customers?

Often new Inorbit users don’t know what they need. Sometimes they just generally have an idea that they need a tool. Other times they come and say they want something very specific, but the truth is they may need something else and we have to work with them to understand each other's intent more clearly. Still other times they come with some ideas, and as they explain it, I can see as an engineer how we can do this or that to adapt to meet their specific needs. It really depends on the customer though. It's an exercise in learning to understand what people really need, even if it's not exactly what they’re asking for. One of the tasks I take on is asking a lot of questions of our users to help guide them.

Have you found that we usually have the tools customers need?

I don’t really ever feel like I have to say “we don’t have that” when it comes to tools. I identify if it’s something we have, something we have but may need some customization for a particular customer, or something we could develop based on the need presented. Once in a while customers ask for something that's not on our roadmap, but that's when I like to ask them to explain why it’s important to them. That’s how we can identify if there is a larger need.

Can you give me an example of that?

Sure, when working with robot actions, we initially only supported the triggering of a script but found that even if the action had been well-defined customers often wanted to modify their robot actions in small ways here and there. So we moved towards supporting parameterized actions as a feature. That was a big team effort, but the need came from the user base.

And are there examples of smaller projects that made a real difference to InOrbit users?

Last year we had these customers who wanted to test InOrbit using Docker containers, so we built an image for them to do that with our agent. It was only like one or two days of work but three or four InOrbit customers ended up using it and found it super helpful. You know the InOrbit Agent is like the entry point to our platform, so if a client is blocked on that they’re not going to get very far.

So how do you define success when working with InOrbit users?

Even if it’s only a short amount of work, being considerate of every ask, and being responsive is very important. Even if it’s just debugging with clients, to help them get their robots InOrbit, that’s a success. Also, I’ve worked with a lot of customers who started out using a free version of InOrbit and over time they’ve come to realize the value we add to their deployments and have upgraded their service.

Guiding and educating with our onboarding is really critical. Our platform is so big now, and our tools can offer so much depth to InOrbit users, it’s not that they’re complicated, it’s just that understanding how to use them to their full potential is something I can really help with.

Really the challenge is that people who engineer and operate robots understand that they may have a problem, but don’t recognize that there may be a better way. That InOrbit can help. When I get a chance to help, that’s a success.

What’s the best InOrbit feature that users don’t take advantage of?

So there are a couple of things that often aren’t being used to their full potential. Dynamic Collections are huge because they allow you to organize your robots and understand the status of your fleet just with the information your robot is already publishing. Dynamic Collections are really great!

Like with a standard Collection you can see a group of your InOrbit robots, organized by labels and tags, but it’s all manual. With Dynamic Collections, you can avoid all of that tedious manual tagging. If you’ve got a growing fleet this feature is critical. You don’t want to have to manually change a tag on every robot in your fleet every time you push a software update. Instead, the Dynamic Collection will operate on smart rules to automatically tag and categorize a fleet

Also when our users really dive into Incident Management, especially with Advanced Incidents now they can automate a lot of processes that they couldn’t before. In some cases, robots are still so new to end users that they feel like they have to have a person actively monitoring their fleet all the time, when in reality with the proper tools they can wait until the system pings them on Slack to notify them of a new incident. Then, for many autonomy exceptions, the users may even be able to resolve it right from their phone. These tools are very powerful.

How does InOrbit stand out from other start-ups you’ve worked at?

I started here as a very young engineer, and I have been able to grow a lot. Working with this team is great. Julian is a very generous person who has always helped me grow. I also love that I’ve been able to wear many hats here. Yes, there is a rhythm and it’s fast-moving. Maybe that’s not for everyone, but once you adapt to it, it’s really great here.

Finally, what do you think is the most exciting thing about robots today?

I find it really exciting that robots are capable of performing operations that are hard for humans, such as rescuing people in disaster zones or working in hazardous environments like hospitals. The pandemic has triggered the need to accelerate the development of these devices and the future will definitely benefit from it.

Thanks to Flor for taking the time to chat. It’s great to get some insights into the InOrbit development and the customer mindset. Connect with Flor, and the InOrbit team right here.

InOrbit is always looking for new InOrbiters. If you’d like to join our team, check out the latest job openings at InOrbit.

* Please note, this interview has been edited for length and clarity.