Julian: Hey everyone. Thank you so much for joining the Behind Company Lines podcast. Today we have Nick Durkin, the field CTO of Harness.io, a continuous delivery as a service platform designed to make deployment easy, safe, and repeatable for everyone in engineering. And DevOps organizations. Nick, thank you so much for joining the show.

As we chatted before, I'm so interested in your background in particular because a lot of, when we're building companies, when we're building products it's always nice to get under the hood of what are the mechanics behind it from an engineering side and also from a structural side and how you maintain the flow of building, how you reiterate on products.

Maintain a dispersed team and have objectives and goals and people who you want creative. So many things that I want to ask, but I guess my first question is, I was looking at your background. You went from engineer and started managing teams and started investing and then jumped back into working on a project.

What about Harness made you jump back into, really getting your hands dirty and starting to build something complex and and honestly just revolutionary from what it's doing in terms of a technology and accessibility standpoint. Well,  

Nick: awesome. And genuinely thank you for having me on.

It was interesting. So Joie our our CEO approached me and he had just sold AppDynamics to Cisco. And he was actually wanting to solve a problem that was near and dear to my heart. And I said to myself that I wanted to be in, in a company that was doing artificial intelligence. It was doing ml, but not just any type of AI in ml.

I wanted it to be removing the worst part of people's jobs. Yeah. So I don't wanna be taking away the best part of their jobs, right. I wanna be able to do something that's actually removing the worst. And so we started talking about this massive problem that we had in software delivery that, build, from code to artifact.

It was somewhat of a solved problem. . Yeah. But artifact to customer became a huge challenge and every company was doing it differently and every company had massive processes and war rooms and situations, and it just took a massive amount of time. And this was a problem that every single customer had.

And so it was one that was finally ripe for the taking because we had picked so many patterns and we'd kind of come down to a very subset of, different clouds and different technologies that we're using and now it was, the time was. And this is why I think it was a massive passion. Cause this is a pain that every company's dealing with, every engineer is dealing with.

No one wants to sit and babysit deployments. No one wants to waste the time doing, all those menial tasks that genuinely don't add value to the business. And so if we could make any progress in that at all. Right. It would be massive for the entire industry. And that's really why we got started with Harness.

Julian: Yeah. And what in particular are the problems that arise? Or is it just the prema, the time that it takes to, go from artifact to customer? Or like I said is there anything in particular that a lot of companies face when going through this transition and what are those?

Nick: Yeah. I think every single company reaches for velocity, so we want to go. And what we do is we go use our CI tool that we already have. So we go grab a Jenkins or what have you, and we extend it. We use a whole bunch of open source tools and then at some point in time we actually start going fast.

But we realize at that point we have to govern it, right? We have regulatory reasons, we have security reasons, we have audit and compliance reasons, and now we have to actually govern this thing that we've made go so much faster than we used. And it becomes really challenging, right? That's when it gets hard.

It's not going fast. It's actually going fast in a way that makes it easy for people to do the right thing, and it makes it hard for them to do the wrong thing. And that's where it becomes really confusing. If a company can actually solve for velocity and governance, they can put appropriate guardrails around it, then traditionally we see an issue with quality because now we're deploying so fast everywhere, all over the place, in the appropriate manner.

But there's not enough people sitting in a knock to know what broke what. Yeah. And if a company can even solve for that. So now you can solve for velocity and governance and quality. Now, traditionally, people are deploying all over the place, over provisioning everywhere, leaving things up and running, and we have a huge efficiency issue.

And so really when we designed Harness, we wanted to solve the entire software delivery life cycle, but we wanted to make sure no matter where you're at on that journey, Right. Whether you are, trying to go fast, whether you're trying to govern it, whether you've now governed it and you have quality issues, or whether we're genuinely trying to re, bring that in for efficiency standpoint.

You have and pardon the pun. You've got a safety Harness there for you. Yeah. ,  

Julian: no. Good fun. And what happens? Like what are some effects if you don't kind of have your governance in check and then obviously the efficacy or the efficiency issue I can see with multiple things running at the same time, it just kind of, there's constraints obviously with all technology and the speed.

But in terms of governance, what are some, some bad outcomes that you might see if you're not creating the structure around it or there's these guardrails as you mentioned around it, that a company would encounter if they were just. Try to go as fast as possible.  

Nick: Sure. I think, you can talk to some of the large financial institutions and they'll tell you specifically they spend more money on fines than they do paying out dividends because they didn't actually meet their regulatory and their software delivery. Yeah. So, that's a huge one right there.

One of the, one that's interesting and one of the reasons we even built a feature flagging tool that allows you to do this in a governed pipeline fashion to enhance the software delivery lifecycle, was a company called Night Capital. They owned what, 18% of the Nasdaq? 18% of the nasdaq. And in one day, because of a bad feature flag, they were bankrupt one day.

Wow. Right. We actually, at Harness, we took our largest outage, and I'll be honest about this, we took our largest outage because we flipped a feature flag right when we did a deploy. and because it wasn't audited, because it wasn't governed cuz it was a database toggle that someone flipped. We went, we deployed, it went poorly.

We rolled back. Cause we're really good at it. We eat our own dog food or I think marketing prefers me to say that we drink our own champagne. I think that's the preferred mechanism, . But the end of the day we use all our own tools. So we rolled back. No big deal. Yeah. Still it was broken and it took us hours to figure out that in, in tandem we had a feature flag that was flipped and we didn't realize it.

So at that point we said this has to be governed across the entire. The entire software delivery life cycle. So from the moment codes written all the way through to production, every part of this needs to be audited, needs to be governed, give people easy paths and guardrails to make sure that it's easy for them to do the right things and hard to do the wrong things.

Julian: Yeah that's so, yeah. That's so fascinating. And I'm curious in terms of your background, obviously looking through it's very much tech forward, it's engineering, but it's also this solutions engineer component that I think. Such an interesting cross between, the sales motion, customer success, but also engineering the kind of, the ability to really enable customers to use technology to the best ability.

What were the teachings in, those previous experiences that, led you to kind of focus on, a type of technology like this, and where were you seeing essentially the struggles from the adoption goes? I think a lot of companies build really cool products and software, but. the adoption of it and kind of Harnessing all the features really is reliant on the service that companies have to onboard their customers. What were the issues you were seeing and what in particular about solutions are engineering? Are you passionate about because of your experience?

Nick: Sure. I think this is one of the things that actually allows companies to be massively successful because you can build the best technology on the planet, but if no one uses it, it doesn't matter. And so one of the things that I think we've done right is that we have been extremely customer focused, right?

Almost, maniacally focused on customers. Since day one, we hired our VP of customer success before we had a customer. And we did this because when we were building something, we decided not to be an, if you build it, they will come company. We don't randomly just build things, right? And in fact, we use our own technology.

We'll actually feature, flag it out to our customers and we'll go ahead and say, okay, how do you like this? Like, is this what you were looking for? And we'll garner that feedback from our largest customers. And so because we've been largely customer focused, one of the things that we want is we want to build a product.

It didn't need massive services. Cuz if you're doing software delivery and your product needs, hundreds of thousands of dollars of services work, it's not really a software product. It's really just a services engagement. And so one of the things that we wanted to do is we wanted to make sure we had a team of experts that could show our customers how to easily onboard.

Yeah. Give them the shortcuts, give give them the cliff notes, if you will. So they didn't have to read the whole book. And to be able to start easily onboarding the. . And so that's what we've really been focused on and that's what the team's been built on, is really empowering people to be able to use the software in the most efficient way possible.

But not necessarily be, the hands on keyboard that sit at a company and get a badge, right? That's not the intention if we're gonna sell. Software. If we're gonna build software, it needs to be something that can be usable. Yeah. The teams can actually start adopting.  

Julian: Yeah. And when you kind of break down and create the Cliff notes how do you view that? Like what, in, in what perspective do you write from? Are you thinking about it from a customer standpoint? Like structurally? I'm always curious on, on how companies kind of derive the solutions and make them simplistic enough to communicate to clients and customers. Sure. Because I think that's one of the biggest challenges.

We think about checklists, or even in emails, you wanna make things simplified and type, but you don't want to take out the information that's important. Yeah. How do you kind of go through writing the procedures that will translate well to customers?  

Nick: Sure. So one of the things is. There's two thi, two key concepts that I like to use when dealing with any customer. And it's pain, right? So what is actually causing pain in the business? So what is that burden to have? What's that worst part of the job? What are the things that they're genuinely disliking? and if you can attach to pain, that's the first part.

And then it has to be easy to consume. So great, I've got pain, but if it takes more pain to take care of that pain, not, that's not gonna work for anybody. Yeah. And so it's really about actually making sure what you have Right. Drives benefit. One of the things that I've always found that's interesting is if you're gonna go and change the way people do business people will actually.

So, yeah, what I mean by that is if you go help someone at a company and truly change a culture and change the way that they're doing business, and if you give hours back to their engineers, if you give them their nights and weekends back, if you remove, like I said, the babysit of remove babysitting deployments, if you remove running tests if you remove all these pains, now you've got people that actually genuinely implement you, not even where you're at, but even where all their friends are.

And so one of the biggest things. You have to have people that, that want to use your product. But more than that, you have to have people that want to actually talk about it. Yeah. The only way you do that is to make them successful.  

Julian: Yeah. That I, you echo what a lot of founders kind of discuss on the show, which is really being when they're building something.

Right. customer centric and taking the feedback and really kind of being evangelists or advocates for those customers to make sure that, they're ticking off the, or checking off the boxes for not only their needs, but also their next to haves as well as you kind of go and reiterate through that process being that you have such a large team, you're working not only.

The worldwide field engineering team, but post sales, engineering and the portion of the product. How do you manage, such a large team and what I guess my more specifically, how do you delegate the responsibilities in a way that is easy to know, understand and is clear to, the employees that you have working for you to create this, I'm assuming a really positive team environment. What are those, how do you delegate those responsibilities?  

Nick: So I think there's two ways of thinking and one of it is management and one is leadership. . And I think if you talk to anyone on my team, they'll tell you specifically, I don't tell them what to do. I hire really smart people and I try to figure out what I can get out of their way.

Yeah. And I think it's important that we realize the reason that we want these people here at this company is cause they're massively valuable and they bring assets that I don't have per se. And so that's not a downside on me, but let's go fill it. Let's go grab people that do have those expertise so that they can run and let's empower them.

, right? Give 'em an opportunity. One of the things that we have, we don't talk about failure, right? We go ab test everything. Yeah. And just cuz it doesn't work doesn't mean it's a failure. I mean, it's the same concept. , Elon Musk, he launches a rocket, right? It blows up and everybody's like, oh, this is awesome.

We now know how to get the first 15 feet off the ground. Next one, we're gonna go further. Right? Yeah. It's not a failure. And so if you go with that mentality where it's a safe place to try new ideas and try new technologies and different processes, right? Give everybody that same opportunity, give 'em that, that opportunity to ab test.

You look at the data. I think it, it creates a community where people want to do their best work. Now where they're forced to do their best work.  

Julian: Yeah. How do structurally, I guess, more so how do you set the expectations then for what is needed to be accomplished and then but also incorporate that creativity?

It seems like it's a cultural thing that you've developed, but I guess more mechanic. How is it set up? Is it, check-ins during stand-ups? Is it reiterating values and mission statements? Is it going over and having one-on-ones with every team member? More so for the founders out there that are looking to build, really strong cultures and teams that are high performing.

And what I mean by high-performing is, I think what you mentioned there, which is enabling people to do what they do best and getting out of their way.

Nick: No I think that's it. I think one of the things that we do really well here, everyone's accessible. Meaning if you want to have a conversation with myself, if you wanna have a conversation with the CEO or the cro . you can get on the calendar. Every two weeks we get in front of the entire company and we talk about all the progress, good, bad, or ugly, and there are some ugly ones, and then there's some great ones. But the thing is we are gonna share and be open and honest and transparent with everything.

And that way it also encourages the company as a whole to again, not have that fear, right? We're gonna stand up in front of the entire company and talk about where we're at. And like I said, most things, most times things are good, sometimes they aren't. But if you do that and if you can have that visibility or that, transparency, then it encourages your folks to do the same.

And I think one of the things too is that, understanding, we try to make everything measurable. So we go and one of the things that I truly believe in, and this is something that's important, is you incentivize the behavior you want. . , if you want people to, to only, work on specific projects or specific modules, or if you want them to do specific, tasks with specific types of businesses, then that's what you incentivize, right?

Make sure that the way that we're paying people, the way that we're incentivizing people, matches up to what you actually want them to achieve. It's very simple to go, why isn't that happening? You look back, you're like, well, I'm not incentivizing that. Like, we're not giving bonuses for that work. We're not we're not thinking about that capacity. And when you do that, every decision people make again, is driven by that incentive. And so that's one of the things that I think is also key to it. So be open, be honest, be transparent. Encourage that with your teams and then incentivize the behaviors you want.

Julian: Yeah. Do you have an example of a behavior that you incentivize?  

Nick: Sure. So I think one of the things was if you look at our solutions architects who go in and kind of post sales and actually help some folks design some architectures and lay out plans to go forward we were originally only incentivizing them on renewals.

. So meaning as long as that person renews, great. You're getting. What was more valuable is actually, hey, we've got a lot of different products that we sell. We've got a lot of different modules that can be beneficial. That we could have them looking at as well. So when we're architecting designing it for what the possibilities could be, that wasn't happening cuz we weren't, we were not incentivizing that behavior.

As soon as we change it, hey, guess what? We're gonna do this across. All the new modules as well as the renewals now brought new conversations. . And so it just simply changes a mindset for people.  

Julian: Yeah. Yeah. I mean, it's so simple, but it makes sense in, in, in kind of using the objectives and goals to, and incentivizing them to kind of create this perpetual, machine that essentially creates the behaviors and essentially get the outcomes that you're looking for.

I guess early on with with Harness. You've been working on the project for over almost, what, six years now. How do you balance talking, thinking about hiring? How do you balance or know when, excuse me, to hire people who have more like startup skills and maybe more skills that are catered to a deficit that you have, individuals who have a particular skillset and or technical in certain areas. And so it's kind of maybe not sure if it's more focused on filling the gaps. And then when do you kind of transition from that to building a more larger team with, a diverse amount of skillsets?

when do you know when that transition is? And how are the individuals that you hire different from, kind of startup or smaller teams to when you're scaling and growing to a larger team?  

Nick: So I think this's an interesting question and I think I've seen it done poorly and then I've seen it really well.

Yeah. Right. And one of the things that a lot of people do is they almost make a hard cut where they go, great, we've gotta to startup people. They're willing to do everything. They're going wear every hat. They're, quote unquote the full stack developer throughout the gamut. And that's all. . And then there comes a point where we have to scale and we want to increase output and people make an entire switch.

And what I think we did really successfully here is that we have both organizations running actually at the same time. Yeah. So we have our S P G, our special projects group, so it's all of those people that genuinely. Love that early startup mentality are willing to bend, shake, things are coming in at rapid pace from different customers, from different pieces, and we still operate under that capacity.

So we're actually still able to achieve those really quick outcomes for our largest and most important customers. On the second hand, in order to build new products and new processes and all these pieces, I have to go and staff up to make sure that we can. A constant for that.

And so we actually run it as two separate teams. And that was one of the things I think we've done successfully here, that I, maybe I can look at other ones where when we kind of made that switch and the, the early stage people said, you know what, this isn't for me. I'm gonna go somewhere else.

That I think is a huge change here. And I also, I contribute that to one of the things, Jo, the, our founder, has done as well. , when you go and you build a successful company, people wanna stay for those four years with their vesting stock. Yeah. And you'll see oftentimes after four years, people are like, okay, thank you for playing onto the next.

Right. Diversify employment. Almost like, you would your investments, but instead here intelligent enough to say, Hey, , after you've done your four years, let's have a re-up program to make sure that you have an incentive again, to stay and continue to build something amazing. So it's also been massive as well.

Julian: Yeah. What is that program in more specifically?  

Nick: Yeah. The reality is I think a lot of a lot of founders. don't look at the long term game after four years. And so when they're planning their investments and they're planning their rounds, they don't actually put in extra equity to be able to hand out to people who are here for longer periods of time.

Yeah. And so it's one of the things that I think it just. Again, it goes right back to incentivize the behavior you want. You want people to stay here, you want them to continue with that goal, right? Make it their goal, right? It's a lot easier to dedicate your life to something that you are a part of. than it is to dedicate yourself to someone else's dream. Yeah. Make it part of their dream.  

Julian: Yeah. I love that mentality and it's such a simple philosophy. I, at this point in time with Harness and, obviously you're you've grown such a larger mountain in the past six years and you're seeing a lot of traction.

You're in the news, you're working on extremely I think technology that, that creates such an efficient, fast process. , companies to, create strong relationships with our customers through the enabling of the technology. Tell us a little bit about the traction, what's exciting now and that you've accomplished this year and what's gonna be exciting for the next couple years in terms of what you're working on and how you.

Expect to affect not only your current customer base, but also future customers that will be utilizing your product.  

Nick: Sure. I think, five years ago we wanted to solve continuous delivery. So we wanted to solve from artifact to customer, and that's what we were laser focused on. And what we found is that after we did that successfully for folks.

They genuinely like, man, that's amazing. Can you do that same audit? The compliance piece, the robust access control, all this thing can you do for the whole software delivery life cycle? And we're like, what heck, why not? And that's where we went. And what the difference was is for the last five years I felt like I had to tell people why they needed continuous delivery.

Why you need to fully automate your software delivery life cycle and this. , especially here, like AWS reinvent and even at our own conference unscripted, we found now for the first time, everyone knew why they needed that. In fact, everyone's switching not just from point solutions. They want a full platform to be able to handle this for them.

Yeah. And those didn't exist. They didn't exist five years ago. And so that's what we see is truly, and you'll see people talk about DevOps moving to platform engineering and actually we we see it holistically, but that's also why we made the change three years. To go to a platform. We saw that ahead of time knowing that's where the market wanted to go.  

Julian: Yeah. Yeah. What are some of the biggest challenges that Harness faces today or risk that Harness faces today?  

Nick: Yeah, that's an interesting question. I would've said it would've been the economy. But a lot of what we do actually gains efficiency for customers.

So it's been a, an actual wonderful tool for us when we can go. Give you hard dollar savings and increase efficiency of your best engineers. What business wouldn't want to do that? , in fact, that's right now what CTOs and CIOs right now are looking for. Yeah. And so, what we thought was going to be our largest challenge actually now is one of our biggest assets.

Julian: Yeah. Yeah. If everything goes well what's the long-term vision for Harness?  

Nick: So when we started building this Joti sold his last company. To Cisco sold AppDynamics to Cisco, and one of the things that we talked about is we wanted to build this to IPO and to go and to take public and have people be in New York and ring the bell.

And I think that's our goal. That's my goal, right? I'm writing a book, alpha ipo, and that's the intention. Like go from no product with an idea. And take it all the way through these motions as you grow and you reach those different stages and you have to make those changes. You have to make them a mental change of going from, building a product to building a team.

, right? You have to go from those mental challenges of building one product to building a platform. . And I think those are the things that very few companies are able to do. And and it's one that we're enjoying doing quite well.  

Julian: I love that. I love that. And obviously I think what I saw is you're on your series D, so, maybe the IPO soon.

I'm not sure what the timeline looks like for that. But I guess for the founders out there and people building products and teams and thinking about the evolution of what they're working on I think a lot of. Companies or maybe outsiders view, funding rounds as milestones of achievement or milestones of growth.

But I think when the more I speak to founders and I learn myself is that's not necessarily the case. There's a lot of other things that delegate or contribute to why you have to shift your focus or when to shift your focus. What in particular at Harness has, those moments been for you all and how did you identify?

Okay, this is what we need to do at this point in time. Is it, setting certain measurements and once you hit those, you're transitioning or is it kind of, going with, customer feedback or what the market's kind of telling you to focus on? What in particular helps you all decide on where to grow and where to move and what direction?

Nick: Yeah. I think that's one of the things we do quite well is it's all data driven. So one of the things is. We, just like my third grader went and learned the scientific method, we do the same thing. We hypothesize, we go test it. We like, it's the same software delivery process, but this is how we do business.

And so you go with an assumption that, you'll build a point product and that might take you a year or two to get the right amount of customers, to get the feedback, to then be able to turn it into a platform. Some people never actually get to a platform, and so there are these defining moments that you're shooting for.

But what you'll find is that customers will try to guide you in a. And I think, I wanna make it clear, it's, they will try to guide you in a direction and you have to take all of that information with the understanding that comes from opinions that have been built over a very long period of time for those businesses.

And if you take it without understanding, one of the things. . We listen to all of our customers and we aggregate that information, but what we do is we also bring it back to them. . So I don't just go and build exactly what a customer says, I listen to their problems, I figure out their why.

We get deeper into what they actually need, and we try to triangulate that with our customers. And I think that's what's allowed us to successfully grow. and start building accordingly. We're also not, we're willing to fail if we build a product, if we build a module and it doesn't work, that's not bad on anybody.

We're not getting fired for that. We're not creating a toxic culture about it. In fact, we tried it. We all had a thesis that it would work and it didn't. Okay, so we'll pivot. we'll change, we'll bring it in with a product. And when you create that culture, and that's what we talked about in the beginning, if you create that culture, that's okay.

Now you can do fun things. Yeah. You can do exciting things and you can test theories quickly. And it's not failure. Yeah. Right. It's just knowing now more than you knew before.  

Julian: I love that. What are you good at now that maybe, six years back even further you weren't so good at?

Nick: I think, you brought it up. I trust my teams entirely. I don't tell them what to do at all. And I will tell you, five and a half years ago, I wanted everybody to be a replica of me. I wanna clone myself. That's impossible. In fact, now, coming now. It's literally leveraging people's strengths. Yeah. I think that's the only way that you can actually grow to meet the demands.  

Julian: Yeah, I love that. I always like to ask this next question as selfish research, but also for my audience as well to get some bite size information or gems of, resources. . But whether it was early in your career or now what books or people have influenced you the most?

Nick: Great question. So, one book that I loved there's the, so Five Dysfunctions of A Team by Patrick Lencioni, as well as the Advantage by Patrick Lencioni were two great books that helped you, again, work with larger teams and actually, encouraging people and. Building teams rather than products.

Of course the Accelerate books and we get into, those are always fun reads. It gives you real insight. And this is where those measurements matter, right? When we're looking at our teams and we're putting measurements, right, we look at things that change failure rate. We're looking at, from ticket all the way through, like what is it taking and where those bottlenecks and if we're constantly measuring on.

metrics, we'll constantly get better. Yeah. If we focus on the wrong metrics, it doesn't matter.  

Julian: Yeah. I, this is a question that I recently thought about implementing and so I'll try it with you, Nick. But if you weren't working on Harness what else would you be working on? Is it a product?

Is it a particular industry? Is it something completely different? Music? But yeah. Well, if you weren't working on this, what would you be working?  

Nick: I do play bass for my kids' band, which is love that, so much fun. And I enjoy it. They're 10 and 11 and they're actually massively talented.

I'm the worst in the band, but at least give 'em a baseline. But I think, I've devoted a lot of my life to financial services and to taking highly regulated, highly secure highly compliant industries and helping them, and I think that's one area that I have a passion. , which is why you'll see a lot of that governance and the compliance audit ability and Harness.

But I've also always stated that I have to work for a company. It's either, in the IML or the automation space, removing the worst part of people's jobs. So that, that, that continues no matter what I do.  

Julian: Yeah. I love that. Well, Nick, it's been such a pleasure chatting with you and I know we're at the top of the show here but last little bit, as I always like to give our guests a chance to give us your plugs.

What's your LinkedIn? What's your Twitters, what is your website? Where can we find you? Where can, if we're a customer even, where can we find, Harness and be a part of the mission and get into the technology.  

Nick: Sure. And you can go see us at harness.io. We're large in the entire software delivery life cycle, both open source and closed source.

So, we help operate some of the CNCF projects around so Litmus Chaos, which is a chaos engineering project drone, which is the most loved open source CI tool on the planet. And then of course we have offerings that allow you. Tie those all together in an enterprise offering. We're designed and built, from the ground up as a software engineering tool for software engineers for administrators, for security folks.

And really our entire goal is to empower each team. So I no longer want the infighting with security and compliance and infrastructure and dev. Let's empower each. To do what they need. Let security write the rules. Let the infrastructure teams define where things can be deployed. Let the DevOps team define how it gets there.

And as a developer, I never want to see that software delivery platform, whether it's Harness or not unless something goes wrong. And then all I want is the information to solve the problem. And that's the goal of Harness and that's really what we're trying to do and change the industry. And that's what we're doing for folks.

Glad to help you guys out. Again, you can use our free offerings all you want, if you'd like to look at any of these. I've got sales engineers that can help you actually get started and going as well. So please go to harness.io. Take a look. I'm glad to help out.  

Julian: Amazing. Well, I hope you enjoyed your time Nick, and thank you so much for being on the show.

Nick: Absolutely. Thank you so much for having us. Glad to be here and love to come back anytime to talk about any of the topics.

Julian: Awesome.