Intergalactic Incident Management

Video size:

0:09 Miko Pawlikowski

Alright, so hello and welcome to another exciting episode of Conf42Cast. My name is Miko Pawlikowski, I'll be your guide. And today my guest is Robert Ross, the CEO of FireHydrant. How are you doing, Robert?

0:21 Robert Ross

I'm doing very well. How are you?

0:23 Miko Pawlikowski

Doing great. Okay, I was tempted to call you Bobby Tables immediately, because I've kind of been thinking about it a lot with the XKCD reference. Is that okay? Can I call you from now on?

0:33 Robert Ross

Please, please do. It's been my nickname for over 10 years at this point. It's my GitHub, my Twitter, my Instagram. I think it's my LinkedIn. So yeah, I'm very accustomed to that name at this point.

0:45 Miko Pawlikowski

So how did it start? Did you just pick up a random XKCD and were like, 'Oh, I'm Robert, this is Robbie, let's do that'.

0:52 Robert Ross

It wasn't even my choice, actually. Back when I was 19, I was working as a developer and two of my colleagues, three of my colleagues actually, started calling me Bobby Tables, because I think that was around when that comic came out. And one of the guys that changed my nickname since then, is actually my co-founder and head of engineering at FireHydrant now. That's how it started, I gained a nickname as a young adult, and it just hasn't gone away.

1:24 Miko Pawlikowski

That's awesome. Because pretty much I think everybody I know knows the reference. So you know, that immediately gives you familiarity. So kudos for that. One other thing that everybody notices when they look up your trail on the internet is that you talk a lot about reliability. Pretty much everything, every piece of content I've seen had something to do with reliability so far, be that a blog on the FireHydrant, or your YouTube video portfolio. So maybe a good place to start would be to define, kind of tell us, why reliability is so important to you. And what it even means, because it's one of those things that everybody knows where it is. But if you were to define, it might not be that easy. So what's your take on that, Bobby Tables?

2:08 Robert Ross

My take on reliability is, I mean, if we kind of look around the world, reliability in software is more and more critical. We're using software right now to produce this podcast. And we're going to be using software to then publish this, and we use software to pay our bills and check our bank balances. And really, right now we're seeing software become more of a utility, than kind of like a nice to have. It's becoming almost as important as the water from our faucets and the electricity from our outlets. We expect it to just kind of work now, because we're so reliant on it. And when you're reliant on something, that thing we kind of have expectation of reliability of it working consistently. And what we say a FireHydrant is that reliability is not a an engineering metric. It's actually a business metric. And the way that we explain this is that, if we have an outage, and we have a high expectation for reliability for ourselves, but really, I should be saying, "when" we have an outage, people aren't going to be saying our customers or users people looking at our product, they're not going to say 'the FireHydrant engineering team is having an outage'. This is not the way that we kind of think about products and brands, when they have outages, we say 'the company is down', right? So FireHydrant is down, or Slack is down, or the New York Times is down, right? Whatever the company is, we don't really think of it as a consumer of that product or technology as an engineering problem. We think of it as like a business problem. So that's why reliability to us, it's much more than engineering. It's beyond that. Legal needs to get involved, marketing gets involved. Almost every department at a company gets involved from massive outages. Many companies are paying millions of dollars in SLA refunds because of outages in the last couple of years. It's becoming an expensive thing for companies to experience these. So I mean, on the topic of like, what is reliability to me, us, my inner circle, it kind of extends beyond software. It's: do people perceive you as being reliable? And it's kind of an interesting metric. Reliability is not something you actually get to say. You don't get to say we're reliable. If a customer doesn't think you are reliable, you're not reliable. It's a weird kind of thing that you just have to be so reliable and so trustworthy to your customer base that they will kind of give you that, like badge, that you are reliable.

4:57 Miko Pawlikowski

Absolutely agree with that and also what you mentioned by the client, it's easy to kind of lose that badge with a single incident, which kind of adds to the pressure of that. And obviously, depending on what kind of company or what kind of business you do your reliability metrics or understanding of that is going to be very different, right? Do you work with any particular types of companies? Or are you like flexible enough to kind of work from anybody, either from banking to, I don't know, dog walking?

5:29 Robert Ross

We work with so many different companies. We work with consumer companies, we work with large B2B SaaS companies, really anyone operating software, at really any scale has a potential use case for an incident management tool. It could be us, it could be you know, wherever it is, but any company operating at some level of scale. Maybe the benchmark is they have a few customers, like that's probably already enough to start caring about reliable software. So really, we work with teams of all sizes and multiple industries.

6:05 Miko Pawlikowski

So your sound like someone who does a lot of this. So if you were to come up with like a pizza recipe for reliability, what will be the ingredients in that? What goes into that?

6:19 Robert Ross

How much dough do we have? This is gonna be a big pizza. I mean, it really depends on your business. If I were to have a recipe for reliability, wow, this is... I might make friends, I might make enemies with the way I answer this, so I'm thinking a lot about it. I think the first case that I would really go for is making sure that everyone understands what reliability kind of means to your business. The first ingredient is 'buy in', making sure that everyone is bought in to this concept of reliability as not an afterthought. It is built into your products, it's built into your processes. And even if your systems fail, building in certain processes for your customers to know that something is broken, like all of that has buy in from customer success to marketing to legal, again, reliability is a business metric. So first first ingredient, 'buy in'. I think second ingredient is partitioning off what your customers would complain about, and understanding the impacts of those things when they are down. And we call them 'functionalities', that's the term that we use. I've heard 'product areas', 'product feature', or whatever you want to call it, that's fine. But really being able to break down your application to what the value is that you're providing to a customer. And the reason I think this is valuable in this recipe that I'm coming up with right now is that if you don't know why people are using your product, or the things that can break. Or really the things that if they were unavailable, your customers would come running at you with pitchforks. You can't possibly build a reliable system, because you don't even know what needs to be reliable. And you don't even know what level of expectation your customers have for that thing being reliable. A classic example is, is it okay for an email, a daily update email to be an hour late? Probably, in most cases. Is it okay for Forgot Password email to be an hour late? No. So like, being able to understand the functionalities that your application provides. And honestly, it's gonna be a lot, it's not a small list. That's probably the second ingredient. So we're gonna buy in, we have knowing what can break and the expectations are like the what users are using that thing for, and why it's important to them. And then I think having an understanding of what breaking is. And this really starts to dive into like service level objectives, service level agreements. There's a bunch of great companies doing things for this, like Nobl9. They're helping companies kind of understand the impact of the systems when they are down and the agreements that they've created for themselves and for customers when they're broken. I think that you have to know what the state of good is, like a measurable thing. And that's where an SLIs and SLOs kind of come into play. And then I think the third thing is ownership. Or fourth thing, I can't count, off by one error. Ownership is like, if no one owns anything, nothing will be reliable. If there's a certain thing that breaks and nobody actually owns that thing, you're gonna have a tragedy of the commons, where people will kind of look at it and go, 'Who's gonna fix it? Oh, someone will fix it', and they're gonna go do their own thing. So you have to have someone and you explicitly say, these functionalities, when these SLOs are not meeting their criteria, you own fixing that thing. And a lot of this is, you know, abstract and thought. But I think that if you have those four ingredients, and I would probably add a fifth ingredient, which is...

10:18 Miko Pawlikowski

FireHydrant.

10:18 Robert Ross

I could say that. But no, I think that the fifth ingredient is, knowing what to do and the expectations when something is unreliable. What is that process? Are you responsible for fixing it? Or you calling the fire department, are you calling 911? And then at that point, you should buy a FireHydrant. But that's all I'm gonna say about that.

10:42 Miko Pawlikowski

I was kind of looking at you counting fingers and I saw kind of the shadow of previous experiences. Can you share some anecdotes like you know, your favorite go-tos that you bring up at every family gathering about reliability? What's the most spectacular one that you can actually disclose?

11:03 Robert Ross

So I've worked for a couple of companies my career, I worked at DigitalOcean. In the past, I forgot namely, HR, where I was a staff SRE. And probably one of my favorite problems that we had all using an example from namely, I have two quick ones I'll share. One day, we saw that we were in a moratorium, the code moratorium, we weren't deploying anything new, no features are being released around in between, around Thanksgiving time, to the end of the year. And the reason that namely did that was because as a payroll tax software, a lot of people are off boarding off of namely, and onboarding onto namely, around that time, it's in HR world, that's called 'year end, year start'. It's the busiest time of year for these companies. It's basically the highest risk time for something to break. So we are in our moratorium, we're in the office, and I'm on the SRE team. And suddenly, the whole thing just goes down. And it was an interesting time, because as an engineer for a number of years, the first thing I always looked for is, 'well, what changed? What did we deploy?' And we were saying, 'oh, nothing deployed, we're in a moratorium'. Okay, well, something changed. Did our data center get hit with a meteor, like what happened? And we're diving in. And the problem this is where ownership came to, was a problem is because there was no one, the application itself was broken, it was serving five hundreds. So at that point, is that the application team that should be responding to this? Or is it the SRE team that should be responding to this? So naturally, everyone responded to this and said, and then we had, in typical Thanksgiving form, too many cooks in the kitchen. And we had everyone was giving their theories and just as you have a lot of red herrings, and this outage went on for quite some time. And eventually, we realized that our Postgres database instance memory was getting super high, it wasn't out of memory, but it was climbing. And that actually put, I put the instance into, it was using more CPU cycles as well, because it was doing more work. And we were using an instance class of AWS that had four CPU credits. And we have exhausted the CPU credits. So that meant that our CPU suddenly grinded to a halt a little bit. And queries that were previously working very well, weren't. And then what we realized is that our memory was also going up at the same time, because we weren't deploying. We never hit this memory problem, where it was exhausting resources, basically, on this instance, because we were always deploying. Which was deploying our application, you might be wondering, well, if you're deploying your application, how does that affect your databases memory? Well, it turns out Ruby on Rails, our framework of choice had a problem where it was creating multiple prepared statements against our database. That uses a lot of memory and Postgres, because it's a new prepared statement per connection. And there were 16 connections per pod. And it was just a lot of prepared statements. But there was a Ruby on Rails bug that involved like date queries, or something like that. It was like a really, it's a known Ruby on Rails bug. So if you're on like Ruby on Rails 51, maybe you go look for this bug. And then eventually, we eventually realized because the graph would like do this every two days and we realized, oh, that's when we deploy on Tuesdays and Thursdays. It was this like, crazy situation where a lot of people responding to the incident. Everyone in customer success was also in our incident channel. We had like 100 people responding to this incident, all because we didn't deploy. And that was really the crux of it. So, when I say like, my recipe is honestly based on incidents like that, where nobody knew what to do. And yeah. And I said I had another one, but I think that one kind of captures a lot.

15:21 Miko Pawlikowski

I think that one will do. And it feels like a very good segue into incident response in general, right? If one goes to a certain firehydrant.com website, it seems to suggest that what we call 'incident response' is broken. Is that a true statement? At least the way it's done today.

15:44 Robert Ross

I talked to a lot of engineers, and when I posed the question, 'what's your incident response process like?' A lot of the time I'll get, I get like a set Edom of answers here. I'll get "we don't have one", "it's chaos" or "it's outdated in confluence", those are like the three answers I get. And sometimes it's "we need to add a incident response process". That's like the other category that you know. Yeah. So a lot of people tend to respond with "it can be better". I think that incident response is not a set it and forget it thing, it's going to evolve. Because your systems are going to evolve, your team structure is going to evolve. You're going to replace an application from Ruby to Go. Or if you're going like micro, if you're breaking microservices, that was super contrived example, but it happened multiple times in my career, like your incident response process is going to constantly evolve. And companies need to like recognize that. Really, all of your processes are going to evolve. But saying this is our incident response process. I mean, it's gonna change. So our headline on our website is really to talking to that.

16:59 Miko Pawlikowski

Fair enough. One other thing that I liked on the website, in the blog category, was about throwing away post mortems. And there was a few good options, I think my vote definitely goes to 'downy whoopsie'. It's a good alternative. But what's wrong with post mortems?

17:20 Robert Ross

So if you look at the term 'post mortem', the definition for it, it usually involves, depending on which dictionary you look at, it's gonna involve word death and dying. And 'post death' is really what post mortem means. And the problem that I have with that is that people aren't dying, usually, right? Like, there are few software companies that it is a life or death situation. And maybe at that point, if they have that type of incident, maybe you do actually call it that. But for the most of us, in our roles and position, post mortem actually doesn't fit what you're doing. Actually you're running a incident retrospective, you are looking at what happened during an incident, the timeline of events, the multiple hypotheses and theories that were running around during the incident. Like you're running a retro on a shorter period of time that causes pain for people. So that's why I think post mortem is just isn't a good term. And actually, there was a gentleman in Toronto that was telling me this, that their whole company was actually getting rid of the term post mortem. And I kind of latched on to that as an idea. Because databases are hard to change. Our database still actually has the table post mortems. But we actually relabeled our entire website, the interface to that database is actually retrospective everywhere now. And I'd love to change it at some point. But schema changes are hard.

18:53 Miko Pawlikowski

Well, you should definitely add an option on the website to switch it to 'downy whoopsie'.

18:59 Robert Ross

Downy whoopsie. I like that site seance as well.

19:04 Miko Pawlikowski

Okay, so we've been kind of, you know, walking around the aisles of reliability incident response, and you've vented at some of your frustration, so let's hit now directly at the hot FireHydrant and to tell me how is it different from the other offerings? How is it different from things like pager duty, for example? What's the unique offering I guess?

19:27 Robert Ross

Yeah, we're building an integrated reliability platform. We are focused on incident management a lot today. But we also have an awesome service catalog component to our application as well. That involves change events and really like deploys, deploy tracking, built into the application. And we don't build anything into our product, we try as best as we can to avoid building siloed functionalities. We don't want to create something that doesn't improve the experience of existing functionality. So when FireHydrant first started the first parts of FireHydrant work was actually not Incident Management. The initial bedrock of the application was service catalog, it was the first database records created, was the first thing that the application had. And the reason for that is because to have appropriate Incident Management, at least in my opinion, when this was on a side project, before we became this company that we are today, we always wanted to know which services were impacted on which environment. So we built service catalog into FireHydrant, and then that just directly influences our incident management functionality. And then service catalog also has changed events that can link to services in the environments that they're running on, which then also get pulled into Incident Management automatically if something happened recently. So FireHydrant will actually say, 'Hey, did you know there was a recent deployed to this service on this environment, that you've opened an incident for?' We're building it in a way that nothing in our application doesn't enhance or magnify something else in it. And I think that's a pretty big differentiator between us and other software vendors out there. We think that reliability, again, is a business metric, it touches so many parts of the business that you can't build, like featured silos for reliability, they have to all interact with each other.

21:29 Miko Pawlikowski

And what's the deployment model? Because that's always tricky with this kind of stuff that basically knows everything about what you're running. Is that software as a service kind of thing? Can you run it on prem? What's the deal?

21:46 Robert Ross

So we're exclusively a software as a service, we operate and host all of our application.

21:51 Miko Pawlikowski

Okay. And another question that came to my mind when you were describing that, I wonder who's like the primary person that you actually sell this kind of software to? Because I suspect that there's at least like two groups, right? The decision makers, like managers, whoever, who we say, 'Okay, guys, we should be using this and bring it to the team'. Or just the software developers who are kind of upset or SREs who are kind of upset things are no better, and might suggest that. What's the best case scenario for that working in these two cases? Or maybe other cases that would be more popular for you?

22:31 Robert Ross

Yeah. So our wires, I mean, the people that use our tool the most are really like the engineering team, the people deploying applications and operating them. And the people that will help us integrate into the existing processes and things like that, that'll be a leader of some sort. Maybe it's a tech lead, maybe it's a manager, but we've worked with incredible teams that the FireHydrant tool itself was implemented by the engineers. And that's why I kind of love what we're building is that we are our audience at the same time, and not a lot of people get the say that when the with the products that they're building. I love working at namely, great company. I am not passionate about payroll and tax software and benefits. That is not my calling, I couldn't tell you what features namely needed, right? I could build them, I could have someone say we should probably build this gross bonus calculator. Cool, I wouldn't have been able to come up with that myself. But with FireHydrant we get to say, 'You know what I wanted in my career, five years ago? I wanted this thing'. And that really resonates with people that are looking at our software, you can kind of look at FireHydrant, as an engineer and SRE, whoever, and go, 'Oh, this is built by someone that had this problem'. And that's why we kind of resonate the most with the ICs within an organization and anyone technical, anyone that's ever written code, we can have a full blown candid conversation with those people about our tool.

24:03 Miko Pawlikowski

From engineers to engineers. Awesome. And yeah, and that kind of naturally flows into the question about, so what's the startup life like? Starting things, growing them up, actually those series be fresh out of the process. How is that going for you? What's the best, the worst?

24:24 Robert Ross

Yeah, the best and the worst. So I think like a little bit of context, the joke that I like to say is that I accidentally started FireHydrant. It was a side project. It was something I was building for fun, nights and weekends, early morning coffee at 5am. And I like just started building this thing and it just happenstance, right place, right time raised a series seed for this and then that's really what started this company and my two co-founders, Dylan and Dan joined. Being totally honest and know competitors are going to listen to this and maybe weaponize it, but that's fine. But like we have no idea what we're doing. Like we were in the earliest days of startup, we were first time founders, you know, we wanted to build just a great product. That's all we really thought about was product. And we started by just heads down product, I think that we started to learn just how many acronyms there are in, like B2B sales, GTM. I remember at one point, I had to look up like what GTM meant, go to market. And then all the other acronyms like SQL MQL, you just kind of get overwhelmed with non-engineering things. And that started to happen, right around May of 2019, is when we started to like, Okay, we're going to start to like, push this, we're going to try to sell, make some sales here. And that's when I became a salesperson, a transition from engineering into sales. That was challenging. Because one of the things that I've learned in this wonderful journey so far is that it's when you're good at something, you want to keep doing that thing that you're good at, right? You don't want to, at least for me, and I discovered that I always found myself like meddling back in the code base, I kind of always found myself like, I don't want to send this sales email. So I'm gonna write this pull request for this feature that I want to build. That would just happen and happen. It took a long time to actually like, pull myself away from writing code. And I'll be honest, I still have a hard time with that. I think I actually shipped a PR today for something that was super small, I swear. Not giant new feature. And I think that that's been one of the hardest things and is a low some days because I love writing code. It's what I want to do. I like constructing things. I like building things. And it's hard to kind of change your mentality, right? Like, I'm not building a codebase anymore. I'm building a team, I'm building a process for scaling this organization. I'm building a company. I'm trying to build a great company. It's systems thinking. But without the code editor, it's it's also one of the most rewarding things. I mean, we've grown up to 68 employees, most of which we've hired during a global pandemic. I mean, when the pandemic started, I think we had nine people. And now we're up to 68. That's a feat. I mean, that's a lot of people to hire remotely over zoom. That's a lot of interviews. And met most of the company I have not met in person, that has been a wild challenge, but super gratifying to build the company that I wish I could have worked out and that my co-founders wish that they could have worked at. And that's what we're trying to do, that is kind of our Litmus test. Is FireHydrant a place that we would want to work at as a software engineer, as a salesperson as a marketer. Right? That's, that's our Litmus test. And that's what we kind of ask ourselves as much as we can to see if this is still the place that we would want to work.

27:53 Miko Pawlikowski

Love it. And I mean, the growing part of that during the pandemic, that's probably a topic for another episode entirely. But, I'm always thinking like, that can't be more awkward, reviewing a PR from a CEO here and there. Do I tell them off for that?

28:14 Robert Ross

I encourage people. We have a great engineering team, and they don't hold punches back. And it's great. I kind of love it, actually. Yeah, this abstraction is bad. Yeah, you're right. Okay.

28:29 Miko Pawlikowski

All right. Sounds like a great place to be. And sounds like you're enjoying being the CEO after all, right?

28:38 Robert Ross

Sorry. Yeah. I mean, I did not. If you had asked me three years ago, which was when FireHydrant would have still been a side project right about now is when the fundraising surface recede, I don't think I would have ever have said, 'Hey, we are working with these companies. And we have 68 employees, and we're going on podcasts now'. Like, there's just no way I would have predicted any of that. So it's super exciting. I feel incredibly fortunate. I am very fortunate to be in the position that I am and and working with the team at FireHydrant.

29:13 Miko Pawlikowski

Awesome. Yeah, very happy for you. So since we're at it, lets me try to extract a little bit of, you know, golden nuggets for anybody who might want to follow your path. And, you know, in general career advice apart from don't know what to do. So if you were to like, give some actual serious advice to someone who wanted to be like, following an adventure like yours, what would be like the most important piece of advice that you would give them?

29:41 Robert Ross

The most important advice I can give you is your product will only feel as good as you feel. And what I mean by that is, don't overextend yourself. Don't work for 16 hours a day and think that that's going to like, do the trick. One thing that we've really focused on here is a work-life balance. And I don't think I could ever, I don't think I can recommend anything more than take care of yourself. Because if you take care of yourself, you'll be able to take care of your company, and your products, and the things you want to do. Any day that I am not feeling great, I will go focus on that, because that's my new problem. That's the new biggest problem I have is not feeling great. So if your company is maybe having problems, I would actually kind of look inside, like, 'Are you having problems? Do you need a mental break? Do you need to not work on a weekend?' And it's a it's a struggle, because I think that there's a hustle culture in at least the United States and in startups and venture backed companies, there's a hustle culture where it's almost a competition to see who works the hardest. That's not the game you're playing. It's an infinite game. There's a book called "The Infinite Game" by Simon Sinek. And he basically says that there's no timer. It's not like a basketball game. There's no timer. There's no known rules, right? So why there's so many people out there saying like, 'I work 16 hours, like it's a badge of honor'. Plenty of science out there says that you are not any more effective past eight hours at past 40 hours a week, like you were actually not more effective over time. So you might as well work 40 hours. And that was a long answer to a short question you gave me but I genuinely think that mental health and you operating at your best is the best thing that you can do for your company and your team.

31:37 Miko Pawlikowski

That's a really nice answer. And it's definitely coming from the CEO part of you. In that case, a bonus question for the coder in you, what's the most exciting tech thing, technology, language, whatever that's coming, that's worth following.

31:54 Robert Ross

Oh, man...

31:56 Miko Pawlikowski

Pick one.

31:58 Robert Ross

I'm excited to see, this is not gonna be tech or, you know, a framework or anything. And I'm sorry, I know that people love to hear it's going to be Go or Russ store and like Go's already kind of there. But, um, I think the next big thing that we're gonna start seeing in technology is like contract-driven development. And what I mean by that is, I think that we're going to start to see, effectively, schematics of software before software is built more and more and more. And really, hugely successful open source projects are built this way. Hugely successful companies are built this way. Lincoln, Abraham Lincoln has a quote is that he's given five hours to chop down a tree, he's going to spend four hours sharpening the axe. And I think a lot of software companies in teams are if they're given five hours, they're just going to jump into their editor for five hours. And I think the biggest shift that I see coming in software is planning, like sharpening that axe for four hours. And I think it's going to be in the form of design docs, I think it's gonna be in the form of API schemas defined first, either using swagger or open API spec, maybe it's G RPC service definitions, Thrift, whatever it is, I genuinely think that that's going to be the next thing that we're going to change in our careers. And it's going to be, it's just going to make better software. If everyone in the world show you that as a standard, like imagine trying to go build a building without blueprint. Good luck. So I know it's probably not the answer you're looking for. But I think that that's what's coming.

33:32 Miko Pawlikowski

That's a great answer. And I like to quote, and I'm totally stealing is from now on. All right. Well, listen, Bobby. All good things come to an end. This has really been a pleasure. Thank you so much for sharing all the nice little nuggets. And thank you for this exciting frank conversation. All the best for FireHydrant and time for you to plug at the end. How does one go get started? Where do they go? What's the best way to go from zero to FireHydrant?

34:06 Robert Ross

Fastest way is to go to a firehydrant.com and create a free account. You don't need to talk to our sales team. They're great. They're amazing. They'll certainly be happy to help. But I know that developers want to try the thing. So we encourage it, top right there's try it for free. No credit card required. You can use our API, you can use our TerraForm provider, the Kubernetes integration to get started really quickly. And you can start opening incidents from within Slack in the first you know, 10 minutes of creating your trial and managing and having great Incident Management, great retrospectives and a fully up to date service catalog all at the same time. So firehydrant.com. Also if you want to tweet at me or at our Twitter, it's @firehydrant and @BobbyTables for me personally, I'll happily answer questions.

34:56 Miko Pawlikowski

And for everybody who loves it so much they also want to wear a baseball cap like yours?

35:01 Robert Ross

I will put one personally in the mail for anyone that wants a cap or any other. We got socks, shirts, you name it.

35:10 Miko Pawlikowski

There you go. Yeah. And we have all been deprived of swag, because of the lack of conferences.

35:21 Robert Ross

Our joke right now is, if your thread pool is running low, come talk to us.

35:27 Miko Pawlikowski

Good one. All right. Well, thank you so much. Hopefully I'll see you another time for this. And yeah, all the best.

35:35 Robert Ross

Thanks so much for having me and chat soon.