Co-Founder and CEO of Sevco Security J.J. Guy joins Emily Omier on the Cloud Native Startup podcast to discuss the challenges, lessons learned and building a solid team culture here at Sevco Security.
Highlights:
- Introduction to Sevco and how it fits into the security product ecosystem. (:0016)
- What creates friction across the entire IT organization and why it is taken for granted. (5:05)
- J.J. shares ideas that he considered but then ultimately rejected and what he would have done differently. (10:39)
- The fascinating challenges around enterprise products in security. (17:44)
- Key lessons learned and how J.J. applies them to Sevco Security. (22:50)
- The challenges of developing a new product in a new market segment. (27:23)
You can listen to the audio podcast on The Cloud Native Startup.
The following is a transcript of the segment with J.J.
***
Emily:
Hello, and welcome to Cloud Native Startup. I’m Emily Omier, your host. And today I am chatting with J.J. Guy, who is the CEO and co-founder of Sevco Security. Thank you so much for joining me, J.J..
J.J. Guy:
Hi Emily. Thanks for having me today.
Emily:
Cool. So the first question that I have for you actually, is there’s lots of security products out there and I often think when somebody says, “Oh, I have a security product.” It’s almost meaningless because there’s so much that goes into security. So my question for you is how does Sevco fit into that ecosystem?
J.J. Guy:
Great question! I’ll say don’t tell the world, but I’m not even sure we should call ourselves a security product, but more a general IT product. We just happen to be security guys that have recognized a need in the market and are going to fill it. I’ll back up a little bit and give you a background of why we started Sevco, to give that some more color.
I was, most recently, part of the founding team of Carbon Black, an endpoint security product. And that was of course, a fun ride through that company’s explosive growth. But one of the challenges we recognized there was that no one knew how many devices they had inside their enterprise. We were a product that was licensed by a number of endpoints under management. So at some point you always have to ask a client, “okay, how many do you need a license for?” Determining that number was always harder than you might expect. And it was not uncommon for somebody to say, buy 50,000 endpoint licenses of Carbon Black only to go through the deployment processes and realize they had deployed to 60,000 machines. And the root cause analysis was usually something like, “oh yeah, we acquired that company four months ago, we forgot.” From outside the IT organization, that’s the kind of data point that everybody assumes you just take for granted. You assume someone knows, but no one appreciates the complexity of getting the kind of answer.
Bring that back to security, and I think part of what’s happening is security shops, in general across industry, have matured to the point now, but where they’ve been trying to make sure their security controls such as Carbon Black or whatever their end point security control is, or their patch management controls or, or, or… Are actually deployed everywhere across the enterprise. And they’re recognizing that’s a hard problem. You can think of it as the denominator problem. They’re trying to get some fraction, a measure of efficacy of how widely they’re end point security controls are deployed. And you know the numerator of that fraction, it’s whatever’s reported in the console him, but getting the denominator of that, that turns out to be a hard problem. And that’s what we’re here to address.
Emily:
Interesting, that sounds like the kind of problem it sounds like you encounter, I would have assumed that this was not that challenging.
J.J. Guy:
Yeah, exactly.
Emily:
Yeah. It seems kind of basic. So tell me a little bit more about Sevco? How would you describe what Sevco does?
J.J. Guy:
Well, so if you go take that idea of: from the outside you’re surprised that it’s actually a hard problem – every organization has got a dozen different ways to measure in an inventory of devices inside the enterprise, and none of them are wrong but they all just report a different subset of the total. If you go ask the guy who runs Active Directory, which is a common source in many organizations, and he’ll give you one number, you go ask your endpoint security guy, he’s going to give you another number. You can go ask a patch management guy, he’s going to give you a third number. You go ask vulnerability management guy, and he’s going to give you a fourth. And all of those are slightly different. Understanding what the total is from each one of those four observations itself is hard.
And then that’s further complicated by the fact that every organization has got a seasonality to those numbers. Like imagine an organization with 10,000 employees. You get hundreds of people joining and leaving the company every single day. You get machines that break and get taken out of service and reintroduced to service, loaner machines coming in. You get that laptop underneath the desk that only comes out every few weeks when somebody travels. That makes each one of those numbers reported by an individual console a moving target, much less when you try to overlay those on top of each other. The approach we take is not to measure devices directly. The general thesis here is everybody’s got plenty of ways, we’re not going to add anything new to that and folks don’t need another way to measure inventory of devices inside the organization, we’ve already got plenty. What they need is help making sense of the tools they already have. And so we import inventory from all of those existing devices inside the enterprise, and then we make sense of it and present those into a common view.
Emily:
And why does this matter? How does it manifest as a pain aside from, “Oh, we thought we needed to buy 50,000 licenses and it turns out we need 10 grand more.”?
J.J. Guy:
Right.
Emily:
Or alternatively, I suppose, “We bought 50,000 and actually it turns out we’re paying for 10 grand extra.”
J.J. Guy:
Yeah, and paying for 10 grand extra happens all the time. Because of course, nobody wants to go through that procurement pain again, so customers frequently round up. But the most acute problem that folks are experiencing today is end point agent deployment efficacy and whatever their security controls, patch management and endpoint security, are the most common and making sure they’re deployed everywhere. Increasingly, security personnel are recognizing that their organizations are getting popped, not because their endpoint security agents aren’t good enough, or their patch management procedures are too slow or ineffective, but they’re simply not there at all. And we see evidence of this starting to emerge. The Verizon data breach report just last year and had that remark about patch management efficacy, and then the couple recent breaches of Equifax, for instance, is a good example. And you go read the Senate reports and there’s a US Senator railing the Equifax executives for not having an accurate asset inventory. I never would have thought I would see a US Senator talking about asset management and the importance of asset inventory, but it’s right there in the congressional record. It’s amazing to go through and read.
But back to kind of the opening statement of, I’m not even sure that we should be called a security product. Once you get past that consideration of, I’ll say, the acute pain of making sure your existing security controls are deployed everywhere they need to be. But well, then you start to understand how foundational inventory is to everything else. It’s been CIS Control number one in the top 20 CIS Control for years. And every time we as an industry sit down and think through methodically, what are the foundational pieces of a security program that we need to implement? It always starts with an accurate inventory. And when you’re working off bad data for just your day-to-day procedures, no matter whether it’s your asset management, patch management, ticketing, the alert correlation inside the SOC, et cetera, et cetera. Inventory, and having an accurate inventory is a foundational element and the lack thereof is creating friction all across the entire IT organization. But we take all that for granted because we’ve never had an accurate inventory for so many years, that’s starting to change. And we’re starting to recognize that with our clients, it’s super exciting.
Emily:
And so what was the moment when you went from seeing this in your experience at Carbon Black, that this was a challenge that customers had? What was the moment when you were like, yeah, this is a challenge I see people having and I want to solve it, and I think I can solve it in a way that’s profitable for me?
J.J. Guy:
Yeah, there is not a moment of inspiration, with that this is a problem that has frustrated me for years. It really goes all the way back to my time in the Air Force, I cut my teeth in the Air Force Blue Team. And part of what we did was vulnerability scanning. This was the early 2000’s, like in what were the vulns of the time? Admin no password and SA no password. Those were Microsoft shipping their devices with no local admin password or Microsoft SQL server that didn’t assign a password to the SA account. And those were very common vulnerabilities that were just hard to stamp out across an enterprise, as large as the United States Air Force, they had 50,000 unclassed systems at the time connected across 132 separate enclaves.
But the local procedures used by every base did a pretty good job, but there were always machines they missed. And we had developed our own scanning procedures to help augment those and provide some checks and balances and validation of the existing local controls. And it was a tough problem, but we also recognized that it was all based in our ability to even discover the devices, like you can’t even scan it to know if it’s a vulnerability there. If you don’t know it exists. And getting an accurate asset inventory then, and we were a crack team of consultants with our own tools that we constantly iterated on, that was a hard problem.
And that continued through Carbon Black, we saw evidence of that. And we saw a number of clients DIY-ing platforms like this in-house, folks would import the inventory from active directory. They would import from Carbon Black, they would import from SCCM and then put them together into a platform similar to what we’ve built. But one of the things I’ve learned here as my career, as a startup guy now is that one, there’s lots of ideas out there to solve. And many of them are very, very good and would have a material improvement in the security posture of our networks, but it doesn’t matter how good your ideas are unless there’s critical mass of industry that agrees with you and is ready to devote their resources to solving these problems. Well, you don’t have a business. But when we got Sevco going, the process was more about iterating through the list of potential problems to solve and making a judgment of which one of those was the timing right for the overall market. What problems are people ready to solve? And this emerged as top.
Emily:
So just out of curiosity, tell me about some of the ideas that you considered and then rejected?
J.J. Guy:
Oh man, I’d have to go back through my notes and pull those out because that ends up being a long list. And I hadn’t thought down that path in a while. Fundamentally, I’ll say most of those did revolve around this idea of, I’ll say, basic IT. I have long believed that we as an industry have been too focused on the sexy attacker and stopping an attacker at the moment of compromise, and maybe detecting the moment of compromise. And we’ve spent all this time developing fancy devices and fancy algorithms and products to increase our detection capabilities or to try to continue to stop attackers. But in reality, there are a whole slew of basic IT practices, just the blocking and tackling of IT, that if we improved those, like all the rest of our security procedures would work much more effectively.
I certainly believe the next big thing in IT security is going to be a Renaissance in basic IT practices. And that continued investment in security independent of IT is reaching the point of diminishing returns because we’ve got so many gaps in discipline and the core platform of our computing networks. So most of the ideas ended up revolving around that general theme of where and how we could improve operational discipline on just the basics of users and device and software management.
Emily:
It strikes me that, and it’s so much of not just IT security, but IT best practices and really best practices for anything else, it’s very easy to get stuck on the shiny new thing and neglect the basics when you really would get a better outcome if you just did the stuff that’s pretty boring, but did it really well consistently?
J.J. Guy:
Yes, that’s right. And any professional sports coach knows this, even the greatest Superbowl teams still practice their basic drills of blocking and tackling, and that’s the kind of stuff that gets them to the Superbowl.
Emily:
And so what do you see as the difference now? What have you done differently at Sevco than some of your earlier startups? And what are the lessons that you’ve learned and how have you been applying those lessons?
J.J. Guy:
Well that’s a topic, a huge topic. And when I think back upon, I’ll say the first days of Carbon Black, which is my entry in his startup world, coming out of the government, I was in the government for 10 years, as a fed before entering into the commercial world. We’ve learned a ton and where to start in the spectrum of how to build a company, how to build a product, how to build enterprise class products and the suite of various customer needs and personas. That within the scope, maybe of your conversation and program here one of the interesting elements would be building the platform. When we started Carbon Black, we built that as an on-prem product because at the time, and that was, we were making that decision in late 2012. We had judged the security industry, especially in enterprise was not yet ready to adopt cloud.
And after Carbon Black ended up becoming the CTO of JASK and that platform ended up the same. It started as an on-prem platform, or at least a platform hosted in the cloud with the ability to deploy on prem. And it was for the same reason, we judged in that time, let’s see that platform got built out in ’16, I think for the initial architecture. But that the enterprise security world was not quite ready to adopt the cloud yet, at least broadly.
And we ended up shifting with JASK and making a decision go all in, on cloud-native and everything that went with that sometime early ’18, I think it was and did a fabulous job rebuilding that entire architecture and here with Sevco, we’ve been cloud native right from the start. That still adds friction of while in general, the enterprise security world is adopting cloud and preferring it for SAS applications like us. There are absolutely still pockets and it’s super painful to get on a call with somebody who wants to adopt your platform, there are no other alternatives in the market, but yet their organization as a whole still has challenges adopting cloud products.
Emily:
And what would you say? What did you have to learn at Carbon Black and then additional iterations, moving from working for the government to running a company? What were skills that you had to learn?
J.J. Guy:
Of course, there’s a bunch. I was lucky, I’ll say from coming out of not just the government, but the military as an officer. Because I had plenty of leadership training and the military spends a lot of time on core leadership training. And not until I got into this commercial world did I recognize how special that was, and was surprised by what I’d considered to be, I’ll say basic principles of leadership that were missing sometimes in what otherwise would be considered senior executives. So I was lucky to have a great foundation in that. And I’d been running teams for a number of years when we started Carbon Black. My last team, the government, I had a hundred engineers, all exploit developers, reverse engineers and kernal programmers, and that was a great team. And so many of those core skills of leadership and management were squared away.
And I think in the commercial side, one of the things that I’ve spent a lot of time learning has been the difference though between I’ll call it engineering or building software and building products. And that’s a nuance that not many software organizations really get, especially in the enterprise space, especially in the security space. That there is a large difference in distinction in building features of a product and having an engineering team that just does what they’re told with no deep understanding of customer problems and developing products. Those are lessons of the organizations that are more consumer-focused and have adopted very well. Google, Facebook, Netflix all have product development cultures that have done a fabulous job. But those lessons are still trickling out into the broader commercial ecosystem, certainly into the enterprise space.
Emily:
Why do you think that is? Why do you think the B2B software, particularly enterprise focused has trouble thinking about this feedback loop as extending, not just it does your feature work, but also does your customer like it, do they use it? Why is that an issue, particularly in this space?
J.J. Guy:
Two things come to mind. One is that enterprise products, especially in security are in a relatively narrow domain where gaining an understanding of your customer and their problems, a deep understanding of your customer and their problems, is very difficult. Contrast that with something like, I don’t know, Airbnb or Slack, those are products that everybody in an organization can understand, use and appreciate, and they can put themselves in their customer’s shoes very easily. Well, as soon as you start building enterprise class products or products in a niche, or a very specialized domain, it is really difficult to understand your customer very deeply. And part of the magic in developing products and wonderful products that delight your customers, as opposed to just building software is having the engineers, building the platform, deeply understanding your customer problems.
That takes a lot more work. But when you’re in a narrow niche domain, especially in the enterprise space, that has a lot of challenges independent of the core problem they’re solving that also have to be designed around. And so it takes a lot more coordination, communication, internal empathy, and deeply understanding your client, which just comes with time. The other element that comes to mind is control. I’ll take page from the book of Marty Cagan here, he runs the Silicon Valley Product Group and has been a product management consultant in Silicon Valley for a number of years. And he recently released a book called Empowered, where he sent around the idea of empowered product teams is what it takes to build successful products. And that idea of empowerment is very, very important.
You’ve seen it in Netflix with the culture of freedom and responsibility. But it’s not new to Netflix, Robert Townsend wrote about it in 1965, I think it was when he wrote Up The Organization and he was president of Avis Rent-A-Car. It’s fascinating to read that book and reflect on today’s modern cultural principles, because he could have been writing about Netflix. And it is very modern thinking in terms of today’s corporate cultures, they are still not broadly adopted, once you remove all the anachronisms from a book written in the sixties. But he devotes that, he credits Douglas McGregor, that was a professor at MIT that talked about theory X versus theory Y of management. And the predominant theory at the time of theory X, I’d imagine a well person here with their arms crossed over their chest and the X, pushing people away. The theory was that workers needed to be, you can crack the whip and tell them what to work, what to do, tell them exactly what to do, give them the hours they need to be there, punch the clock men.
And the theory Y, by contrast was that people wanted to work and they want to have fulfillment in their day-to-day job. It’s the company’s job to help provide them, what Netflix would call the context to not control and provide them the context of the business and allow them to make good decisions. That requires, building successful products requires empowered product teams. A culture of empowerment requires the organization letting go a little bit and losing a little bit of control. And that’s a very scary proposition. And I’m still shocked that not more organizations across the world have adopted that, and that’s especially true in I’ll say, high control enterprise organizations.
Emily:
Yeah. So it sounds like just to paraphrase, make sure I understand, one of the challenges that a lot of companies that are developing particularly security products, but anything that’s really an enterprise product is that the engineers developing it are not ever going to be a consumer of the product. In contrast to say a lot of commercial products, the engineer who was working at Airbnb is going to be able to use the product and be pretty much aware of whether it’s meeting a needs or not have somebody in that situation. But the gap is much bigger when you’re talking about an enterprise product.
J.J. Guy:
Yes. You got it.
Emily:
Cool. I think that’s really fascinating. One question I had for you actually is what would you say some of your mistakes you’ve made have been?
J.J. Guy:
That’s a long list, Emily.
Emily:
Well, you can weed out any that are horribly embarrassing, but top three or four? And maybe actually, we all make mistakes, the most interesting ones are really the mistakes that we learned something from.
J.J. Guy:
The one that comes to mind here, the decision to build Carbon Black with an on-prem platform, in retrospect, you could clearly call that a mistake. Carbon Black was successful, no doubt about that, we did a fabulous job. But by the time we got to IPO, which was nearly 10 years later, CrowdStrike had emerged at the same time and taking a cloud native approach. And by then the broader markets had started to recognize not just there was this set of next-gen endpoint security platforms. And that we were going to displace McAfee and Symantec, but also that there was this new thing called cloud. And by building an on-prem software product, yes, we were better than McAfee and Symantec and those legacy platforms because we had built a next-gen endpoint platform, but we weren’t cloud.
And as a result, the multiple that CrowdStrike managed to achieve in the public markets and any other vendor that managed to position themselves as a cloud security player was significantly greater than what we had managed to achieve with Carbon Black. We, in retrospect to that, the key lesson there is that we didn’t peer far enough into the future, or we didn’t think carefully enough about all the aspects of the business. We focused too narrowly on being a next-gen endpoint platform and not appreciating everything else that went with it. And by the time we got 10 years down the road, the results demonstrated that.
Emily:
And how have you been applying that lesson at Sevco?
J.J. Guy:
One of the most acute is to say with confidence we’re a cloud-native platform and everything that goes with that. And then when that creates friction, to say with confidence, “I’m sorry, but we’ll be here when you and your organization are ready.” More broadly it’s understanding and appreciating that there’s a lot of say, secondary considerations when building products, but that it can have a material difference. Another area that we’re getting right, that was a mistake with Carbon Black was, and this is related to cloud-native, is multi-tenancy and having a mature tenancy model, right from the start that allows us to address the use cases of managed service providers, as well as the mega large enterprises. The world is a complex place and the idea of one tenant per company who works for a relatively narrow range of the market.
And when you get to the large enterprises, you’re going to have the European division, the American division, the South American division, and each one of those divisions of the company needs to operate independently because of not only their corporate structure and how they’re organized and their roles and responsibilities, but also increasingly today, data privacy laws that require that kind of segmentation internally. But inevitably there’s going to be some overarching corporate reviews, and certainly when it comes into this space of security that requires visibility across all. That requires some kind of tenency model and visibility across systems and across organizations.
Same thing’s true with MSPs, they’re going to have hundreds of them and if you have a fixed cost to every tenant that is going to rapidly put a floor price on the overall platform, and then you’re not going to be able to accommodate those small clients. By not accommodating those small clients, you’re not going to be able to accommodate the needs of the MSSP. That’s another element we got right here with the design of Sevco right out of the gate, because I got an engineering team that’s been to this rodeo once or twice before, we’ve got the scars to show from having gotten it wrong and are making sure to get it right this time around. And that’s already showing dividends even as young as we are.
Emily:
And what would you say you’re struggling with now at Sevco?
J.J. Guy:
It’s probably, what’s the most important problem to solve? This is a relatively new market segment. Nobody knows what to call it and the set of adjacent kind of problems that we can address or improve inside an existing organization is very broad. It’s a little intimidating for me. Both my prior startups, Carbon Black and JASK were organizations that only appealed to the sophisticated security buyer. So we were selling to security teams, working with security teams, and larger security teams at that. The organizations that were large enough to have a dedicated staff to security. This particular problem we’re solving here with Sevco has a much broader appeal. It’s often times a security team that calls us and says, “Hey, this is super interesting. I need you to come talk with us.” But those initial calls and demos end up having 40 or 50 people on the phone, and there are six or eight different teams from across the entire IT organization that are all interested in the data we’re providing and how they can use it within their team to help improve their day-to-day procedures.
J.J. Guy:
And of course, none of those is perfect, we can improve on any one of those different use cases. And the two challenges with that from our standpoint is one, prioritization. Which ones are the most important? And that, which ones are the most acute problems to solve? And then two, would be simply the mechanics of how to solve it. This is not a product that we can design in a lab and then unleash on the world, this is a product that we have to design in conjunction with a large number of partners that are trying to rebuild their IT organizations. And that’s hard because it requires us as an industry to think differently. Now, sometimes here I talk about . . . we talked previously about siloed data as one of the core challenges in this whole asset management space. And we should not be surprised that we have siloed data because we have siloed teams inside the broader IT organization.
This is Conway’s Law applied to IT. Now that Conway’s Law is, John Conway was a computer scientist back in the sixties. He wrote a number of different papers on security in general and software development. And part of what emerged from that was Conway’s Law. And that anecdote there is that the architecture of software is going to reflect the lines of communication of the organization that built it. And you see evidence of that time and time and time again, which is why, here we are 70 years later and it’s still getting referenced in a cloud native podcast, even though that’s typically aligned with software development, it applies to IT as well.
We’re siloed in our data sources because every one of those teams is siloed and their roles and responsibilities. The AD guy for instance, has a different number than the vulnerability management guy, has a different number than the patch management guy, because that’s how those teams are structured. And that’s the roles and responsibilities they’re given. There is no persona in your typical IT team that has an overarching responsibility for all systems. We’re seeing the traction and, or at least I’ll say the interest or the problem realization in general from the security team, because they’re the ones who have that overarching view of all the systems inside the enterprise.
There’s a fascinating conversation unrolling in organizations across the world right now where independent of Sevco and how we come into the mix. When the security teams recognize this asset management problem, it’s IT who has the responsibility in general and they go to their IT organization and say, “Hey guys, what are we going to do about this?” Or it starts with, “Hey guys, how many devices do we have in the enterprise?” Help me measure the deployment efficacy of Carbon Black, for instance, or CrowdStrike or Sentinel One, whatever the case may be. And they’re met with deer in the headlights look, because that’s a question no one has ever actually asked. And from there unfolds an interesting conversation where you start to get some common alignment in the requirements and an understanding of the importance and a realization that is not something that the IT organization is postured today to provide.
And then that unfolds into a conversation of, what should we do about it? I’ve talked to hundreds of CISOs and CIOs over the course of the last couple of years getting Sevco going. That’s always a very fun question to ask because it gives you deep insight into many organizations and where they are on just understanding the new organizational model that is necessary in order for them to achieve the outcomes they need. Just a trend that has emerged there that I’ve seen a dozen times in the last six months is the CISO taking responsibility for infrastructure and all those end-user devices to pull that under a single organization to try to gain some of those commonalities and have the organization reflect the actual needs of the system.
Emily:
Yeah. It strikes me, as you were talking about this, that part of the problem. And in fact, part of the challenge in developing a product is that it’s not just a technology problem. There’s also in this particular domain, there’s a big element of people, of how people work and how they communicate. And that is part of why it can be so challenging to understand exactly what technology you need to have in order to address it.
J.J. Guy:
Yes. And the solutions are not going to be just technology, but also processes, procedures, people, org charts, and who’s responsible for what. And from my perspective in building a product, we have to build a product that solves the problem. But since it’s so closely related to the org and it needs to be for the orgs that we all want to be. Everyone is at a different level of maturity and everyone wants to have the most mature in the organization in the world and be squared away. And our product has to be built with that in mind. But at the same time, we all recognize we’re not there today and it’s going to take us time to get there. And the product also has to be able to accommodate orgs and how they exist today and fit into those workflows and then help us all grow towards the more mature path. At the same time, none of us know exactly what that’s going to look like.
Emily:
This has been fabulous. J.J., I want to sort of start wrapping it up, but before I do so, first of all, where could listeners go to learn more or connect with you?
J.J. Guy:
Yeah. So we can visit our website SevcoSecurity.com. There’s a blog that has got plenty of information and a 90 second demo video right there on the front page.
Emily:
Excellent, fabulous. And if you had one piece of wisdom that you wanted to impart to listeners, what would it be?
J.J. Guy:
It’s all about the team. It’s all about the team. Take that idea of empowerment and empowered organizations and recognize the importance of people and the quality of culture and team and get them pointed in the right direction, get them passionate about solving problems. And then just let them unleash that’s the whole, like you’ve heard that tagline before, culture eats strategy for lunch or something along those lines. Nothing more could be true and I’ve seen evidence of that and every company that I’ve been part of to date.
Emily:
Fabulous. All right. Well, thank you so much for joining me, this has been a really fascinating conversation.
J.J. Guy:
Emily, it’s been a ton of fun. Thanks for having me.
Emily:
Thank you.
Emily:
Thanks for listening to this episode of Cloud Native Startup. If you’d like to learn more about positioning, messaging, and go to market for open source and Cloud Native Startups, head over to my blog, PositioningOpenSource.com. You can also join the conversation on Twitter. I’m @EmilyOmier and you can feel free to reach out on Twitter or on my website and blog with questions or comments. If you enjoyed this episode, also, please share and help more people discover this podcast. Thank you, and we hope to have you next week.