Digital native start-ups that disrupt an industry and quickly gain share from competitors can also face obstacles and growing pains along the way. Ben Clark, the chief technology officer of Casper Sleep and a former executive with Wayfair, joins Bain's Cesar Brea to discuss his experiences at the fast-growing companies, including how to structure resources to balance tackling short-term opportunities while continuing to evolve their platforms.
Read a transcript of the conversation below:
CESAR BREA: I'm very, very happy this morning to be talking with my friend, Ben Clark. Ben is the chief technology officer of Casper Sleep. And we have known each other, going back -- I'm thinking it's like 20 years at this point -- back to when, in a former iteration of my life, we pitched you when you were at Digitas, back in the day. And we've kept in touch since. And I've learned a ton from you. So I'm very grateful to be able to have this conversation with you yet again this morning, and this time to be able to share it with a bunch of other people.
So first off, how are you guys doing home front? Everybody doing all right, safe?
BEN CLARK: Home front is good. You know, we're hunkered down for the pandemic in my house in Massachusetts. And like a lot of people, I think we've been able to take advantage of the silver lining of the pandemic, which is spending more time with my family than I've been able to do than before.
BREA: Yeah, fantastic. Well, I'm very glad to hear that. And on the flip side, how are things at Casper overall? Tell us a little bit about what's going on broadly.
CLARK: Casper's good. You know, we're a public company now. So there's some things that I just -- you have to wait. You can review our earnings calls over the last -- since we went public. And I can't say anything about upcoming.
BREA: No, totally, totally.
CLARK: But I've been the CTO of Casper for the last, coming up on two years. And it's been just a tremendous experience and journey. I have a wonderful team full of colleagues. And we're trying to help the world sleep better.
BREA: Now, tell me a little bit about, for those people who don't know as much about Casper, tell us a little bit about it. What should we know about the firm?
CLARK: Yeah, so it was founded in 2013 and launched in 2014, and had this big splash as a fast-growing start-up with this sort of "bed in the box" e-commerce innovation which disrupted that industry.
And then, in 2017, we started to put our toes in the water of both retail stores, our Sleep Shops, and retail partnerships or wholesaling. And so now we're an omnichannel retailer, I guess you could call us, digital-native tech- and marketing-forward kind of company with a tremendous product line that we've invested a lot of thought and care into. And we have this mission of just helping the world sleep better. And we're all pretty excited about it.
BREA: Very cool, very cool. I can certainly -- sign me up for that mission. That's something I could use a little bit these days. So tell us a little bit more about your job, like what you're responsible, that side of it.
CLARK: Yeah, so CTO at Casper -- CTO can be different things at different companies. But in the case of Casper, my job has two big parts. The first one, I'd say, is product-focused start-up CTO, if you will, except we're not a start-up anymore. We're now a public company.
And then the second part is all the responsibilities that CIO and a CISO would have, including IT and information systems of various kinds on the back end. And those are two very different things. But they have to all kind of come together. And the fact that we have all these retail stores means that IT has a kind of physical dimension, since 2017 for the company and since 2019 for me, when I joined, that wasn't a part of my life at Wayfair, my previous employer -- it was all digital all the time -- but is very much a part of my life at Casper.
BREA: So before we get further into what you're up to and how you're doing it and all the things I want to cover there, I did want to ask you a little bit about sort of your overall professional journey and experience, and how you sort of got to this latest exalted role and everything. Take us through a little bit about your background and experience to get here.
CLARK: My checkered past?
BREA: Yeah, exactly.
CLARK: The long and winding road to where I am now. Yeah, so as you said, I started out at Digitas a little more than 20 years ago. That was a great sort of experience where I learned a lot in my early career. Then I took sort of a jag into tech for Wall Street, just being a consultant at firms that had blue-chip financial services companies as their client.
Then I lost that job in whole 2008-2009 thing. But in retrospect, it was the best thing that ever happened to me, because I consulted for a couple of years. I worked for a bunch of companies. But two stand out in retrospect: StyleFeeder, which was a terrific little start-up that was acquired by Time Inc., and Visual IQ, which eventually became Nielsen Marketing Effectiveness.
And then my last client was Wayfair. In 2011, I got a little gig which shortly turned into a full-time job as head of Customer Recommendations and Search and Recommendations. And then I got promoted to be chief architect a few months before the IPO, 2014. Then I managed a bunch of big departments for the next five years. And then I became CTO of Casper in 2019.
BREA: Very cool. Very cool. I remember also when our paths actually intersected back in '08-'09 at Visual IQ. We were both fortunate to have a chance to spend some time with that team. So that's very cool.
So one thing that we like to ask in these conversations is kind of what thing that you've accomplished professionally you're most proud of. And also, on the flip side of that, what's the single biggest kind of learning opportunity you've had that has shaped how you approach what you do today.
CLARK: Sure. Yeah, so I think that's pretty easy. I'm not going to -- I could talk about things at Casper if I could be completely open about them.
BREA: Yeah, no, I get it.
CLARK: But I'm not going to do that. So ... the things that I did in my first couple of years at Wayfair were a really interesting challenge. And what I'm proud of is that I was able to add some meaningful things to the technology there, Python web services that kind of channeled data science into the website, and .NET and Java services in an environment where the thing that Steve Conine, who's the CTO/founder of Wayfair and a good friend of mine, had built was a tremendous e-commerce platform on SQL Server and PHP.
And to be able to sort of add some things that made a difference, I think, but being respectful of what was there and not reinventing any wheels that didn't need to be reinvented, that's a neat trick. And sort of it's easier, as an architect, to say, "Well, you know, let's just junk this..."
But first of all, I wouldn't have been allowed to do that at the time. And secondly, it would have been a terrible mistake. The core of Wayfair was and is just a super-valuable thing that Steve built. Being able to come into a founder-led company and help in that way was just a -- I'm very proud of it. And it was a meaningful thing to me.
Now, when it comes to challenges, I got to say, the wild start-up phase in my life has all of those that just stand out. Because the thing about the problems that you have in those kind of situations is they're so existential.
So StyleFeeder was founded by a good friend of mine who I worked for during that period. And you got these competitors trying to eat your lunch all day long. And then, out of nowhere, you get the sort of Death Star of a Google algorithm update which can do things like take away 90% of your traffic overnight in a business like that.
So those things, they teach you things about uncertainty and what feels like -- maybe this term gets abused, but it sure felt like a black swan event to us when it happened. And there was more than one. And you know, that one was the biggest, but there were other things like that. And that stuff is just hard. You're on your own. There's nobody to call, nobody to complain to. And you just got to kind of figure out a way around or through the wall that's been put up in front of you.
BREA: Yeah. So you almost sort of zero-base your expectations in those cases and just say, "OK, we've reset the machine. Now what do we do?
CLARK: "Do have to create a completely different company now?" Those kinds of things will -- you remember those. I remember that one, that's for sure.
BREA: One of the things you did while you were at Wayfair that I really liked -- and this speaks more toward the organizational side and how you -- a key being successful and these companies being able to attract the right set of skills and experience and talent. And one of the things you did was to set up a Wayfair Technology Blog. And I routinely point people to this as an example of really good practice. Because I think what it does is it's sufficiently technical that folks who are there for that actually get benefit from it. But then it's also a signal to the market about who you guys are, who you work with, who you want there.
And I wonder if you could comment a little bit about how you viewed it, what role it played in how you tried to shape and lead that organization. I know it had lots of contributors and everything. But I'm just wondering if you could talk a little bit about that.
CLARK: Yeah, well, so first I have to say I didn't start that thing. That was already there when I got there. So there was already a well-established culture of using and contributing to open-source software and writing about it. And that's not the only topic on the Wayfair Tech Blog, as you know. But that's a leading topic.
And it was really Dan Rowe, who is, I think, to this day, a principal engineer at Wayfair, another good friend of mine, who was the person who introduced continuous deployment to Wayfair, as I recall correctly, and who wrote about that or other people wrote about accomplishments where he was the main sort of technical driver. And so it was already this tremendous thing that was attracting super-talented people and just kind of channeling the authentic voice of what was going on there.
And I did have the privilege of being the editor of that blog for several years. And then it got to the point where there was too much going on. And we needed to get all of it out -- all that engineering, analytics, data science, all this stuff. It's amazing what was going on at that place and still is.
And then I hired a former tech journalist to be the editor for that ... And I just think, when you're doing what a sort of platform tech company like that is doing, that having one of those things to really talk to the world about the engineering culture and the innovation culture there is just a very important part of your identity.
BREA: Yeah, there's a big principle around "show, don't tell." And I think that was a good example of just, by sharing what you guys were up to, you didn't need to sort of say how great you were. It sort of spoke for itself in that respect. So I thought that was really cool.
Different topic: So I remember, a while back, we were -- I'm thinking it was Cafe Nero on Columbus Ave. And I remember one of the things that I've learned -- I think I've learned a lot from you over the years -- has been, in a world where we talk a lot about Agile and Agile sprints and sort of pivoting all the time to sort of get something, there was an element of really thinking ahead toward thinking about how you would manage, for example, capacity surges, thinking about refactoring your codebase. We've since also talked about how things like Sarb-Ox compliance has sort of shaped how you sort of do things.
All this is around the topic of thinking ahead and how to actually do that practically in an engineering context. I wonder if you could talk a little bit about how you think about those things and how they shape your job now, like literally how far out you plan, what factors you bring into the picture that may go beyond what we talk about in Agile land, and how to balance a planning mindset with maintaining the sort of Agile mindset that you want to have in the kind of environment that you're in.
CLARK: Yeah, it's a good question. You know, obviously I personally find it difficult to keep those two things in my mind very present at exactly the same time. So you have to just have some discipline about coming up for air after you get down in the weeds on a regular cadence. So you can structure that however you want.
At Casper we structure it in terms of quarterly planning. But we really try not to just look ahead three months. During that quarterly planning, we're sort of coming up for air, reflecting on what we just did, thinking about where we want to -- pushing out the envelope however far out we have been thinking.
Can we try to think out a little further? Pressure test that. Why do we really need to know what is going to happen in two years? Are we are we overengineering? Are we doing something where we should actually be more focused on the short term than we are? Because you can make mistakes going too far either way.
So I guess what's the Achilles heel of Agile? Architecture and design, the sort of big-picture thing, great at making these tiny optimizations. And you can't run a modern shop without it.
You mentioned stocks. I mean, .... we were just chatting about this recently. Because we just went public at Casper. So first-year stocks is a thing that I've definitely been thinking about. And it poses a risk to dynamic companies that have all of a sudden matured really quickly. If you bring in the wrong style of controls that are appropriate to traditional software development, then you can have kind of a digital untransformation happen in your company, which is the last thing you want to do. You're in this company that, thank goodness, is a digital native, so does not have to go through a digital transformation ever.
But some companies do find a way to bumble their way into the worst of both worlds, where they have this scale and crazy things going on. And then they introduce overly onerous ways of doing things, when really you have these high responsibilities to the public markets to make sure you get it right and all these things. And there's nothing incompatible about these modern development techniques with doing that. And you have to be careful about how you meld those two worlds.
And so we've done that. And we've continued to try to take a kind of two-year-plus view of where we're going with the technology stack.
BREA: Yeah, so for example, just broad requirements that you keep in mind and sort of chip away at as you do the day-to-day work then, I imagine.
CLARK: Yeah, I mean, when I was at Wayfair, Wayfair was just scaling so fast all the time. So it was very focused on that. Don't be eBay during that famous incident, where their Oracle database went down. This was many years ago. eBay's a tremendous platform now. But they had a big, monolithic Oracle database, and it fell over for like four days, this famous thing. And just don't let that happen. So that's something that you just have to have to watch when you're at one of these wild-ride tigers.
At Casper -- Casper's a super-fast-growing company too -- but I'm more focused on the complexity. Like do I have the components that I need to try to solve these business problems? Problems present themselves in different ways along those lines.
BREA: That leads me to ask two questions. One is, when you mention orchestrating all this complexity, there's a technical aspect to that, independent of any specific technology choices you've made about architecture and things like services-based architectures, and modularity, and all those things.
So I'm interested in learning a little bit about how you think about that today. And then, in conjunction with that, there's the question of how you sort of organize your teams to go after that. Like how you guys sort of structure resources to sort of balance tackling short-term opportunities versus continuing to evolve your platforms.
Either order or any order you want to take those. But I wonder if you could just comment about how that challenge of managing that kind of complexity is kind of reflected in how you think about architecture and organization.
CLARK: Yeah, it's a good question. I don't know that I have anything too profound to say about it. I guess I'll just say that I do try to -- I work with my direct team to think pretty carefully about what the smallest unit of both code and people is that can really go at a problem and solve it.
And if the answer to that is one person working alone, with just somebody to review his or her code, then that's the best answer. Because it's easy to follow that kind of thing.
And then when you get to bigger units, it becomes a more complex question. So when I say complexity about Casper, I'm primarily concerned with doing the omnichannel thing right. Not a lot of companies do that really well. So when we have something that spans the entirety of our direct-to-consumer business, then that's a group of people who can really see all of that.
If it spans the entire company, including retail partners, then it's even bigger. So ... as I get older and pull myself out of the technical weeds, I find more and more value in really thinking hard about how to define the shape of those things for both the code and the people. And that's kind of how we think about it.
BREA: So breadth -- I imagine, also, the stage at which a particular product may be at, it may be that you can move more nimbly, and in smaller groups, early. But the bigger it gets, the more you've got to have, everything from testing to deeper investment in engineering and so forth.
CLARK: Yeah, I mean, I think, when we have these complex things, we marry the lean start-up/lean enterprise kind of school of thought with planning by just getting a lot of people involved in sort of initial planning, having an, "OK, what really is the MVP for this? What's the minimum viable product?" And you get as small a team as possible to go off and do that. And then everybody else knows that they're on it. And they don't have to worry about it. And then they come back. And then, "OK, did we really learn that we can go as wide with this as we thought we could?" And if the answer is yes, then it's sort of game on.
BREA: Yeah. So obviously, from my perspective, I'm within the sort of enterprise technology force. I'm particularly interested in advanced analytics applications and model pipelines and so forth. So the question here would be more around, first of all, if you can describe some of the major pipelines you support there, some of the major prediction endpoints, that would be helpful. A little bit about how they work, data they use, and so forth.
But then I want to ask more about how do you treat that? Is that just part of your overall engineering organization? Do you have a specialized group for that? How does that interact with folks that may be in different parts of the organization? So broad question but what do you got and how do you do it, what it boils down to.
CLARK: Yeah, I mean, I've been the kind of data janitor for the last 10 years.
BREA: That's what they call a data steward in other places, I understand.
CLARK: Right. Data steward. That sounds better.
So there was this brief period when I was at Wayfair when I hired the first quant and managed that. But for like a year, because I'm not that good at math. And so we needed to hand that off to people who are really good at math. And during--
BREA: You just crushed the hope of a lot of people who are really not good at math. But anyway.
CLARK: Well, you know, I don't know. But that both during that period and for the entirety of the last 10 years, both Wayfair and Casper, I think there is a way to run that kind of operation that has emerged as a solid pattern that most people who are running these sort of advanced analytic shops would sort of recognize. You have this kind of big central area where all the data is flowing into. And you have -- people choose different tools. But I've been getting a lot of benefit out of Airflow-based pipelining, this combination of batch and streaming with things like Airflow and Kinesis or raw Kafka-based things.
And then what comes on top of that is Jupyter notebooks running on Kubernetes. And then you get into the part of the question that I think you'd really like me to answer. Because I know what you're really interested in or some of the things you're interested in. But from my perspective, I'm going to say, yeah, am I aware that the analysts who are in a separate organization -- so the data engineering rolls up to me.
Analytics is separate, as it is in many companies. And they have XGBoost and logistic regression and then all these kind of tools, kind of building blocks, available to them. And they put that together into the pipelines that allow us to sort of look at our clickstream, look at all the kind of things that you would expect.
Beyond that, I think they'd be cross with me if I said --
BREA: Oh, no, don't worry. I'm not going to get into that. But I think one of the interesting questions is like how far you pushed that sort of boundary layer between the data engineering piece and the analysts. Like are you maintaining almost like a feature store for them, pretranformed elements and things like that, that they might anticipate? Or are you just happier to kind of keep things at a more raw level and let them have their own sort of way with the data in a sense?
CLARK: Yeah, that's a good question. Yeah, I think the building blocks of that, you've got the kind of plumbing and ETL and streaming pipelines. And then you've got data modeling. And then you've got more advanced things like feature extraction and whatnot. And just inside baseball of the org, I've had people in my org running all of those things.
And where I draw the line in a different organization, just I'm not sure it really matters that much. But that's about where the line is. Like would you go with a true tech side of a combined engineering analytics data science AI capability? Would you push the true tech side even farther than that? I mean, if you're Google and you have Jeff Dean at the head of it, maybe you would.
BREA: Yeah, right, right. He gets the keys to the property.
CLARK: That's an unusual situation.
BREA: Exactly, yeah. I think what I read in that is that the answer really does depend in part on the capabilities of the people that you have in these different groups. Some groups just need more support, and others less so.
CLARK: Yeah, or just where you want to draw the line, how you want to organize the work. There's some discretion there.
BREA: So let me then flip it away less about you guys and think more about your advice and guidance for people who are thinking about things like data and analytics transformations. Because you've worked more in the land of organizations that are sort of natively further ahead in that regard. But you've also got a broad enough view of the world that you have a lot to say on this topic.
Or for that matter, not just data and analytics, but more broadly, this digital transformation stuff, what do you wish that people knew -- executives would know -- so that if someone like you were to be working with them you could be much, much more effective? What do they need to know to make your job easier and more productive? So jumping into that.
CLARK: I don't know. It's a good question. I mean, I think even companies who are lucky in a way, that they either started with fully cloud-based things so that they could just jump into a platform of either Google, BigQuery as a centerpiece, or Amazon Web Services-based things with, typically, Redshift. There's a lot of people who are using different platforms these days, slightly higher-level than that, that get a lot of value. But that's really my responsibility to make sure that either you put that stuff in if it's not there, or you continue to tend to it if it is, as it was when I joined Casper.
I'm not sure I have any advice that they don't already know. I mean, the savvy business leaders that I know are just sort of keenly aware that of all these things that we're all wrestling with. Just like drowning in data but not enough information. What questions are we really asking? How can we shape our -- I'm always thinking about how I can shape my communication as a tech leader to paint the art of the possible to them, tempering it with realism, and get them to be just really engaged with those questions and asking questions that then can kick up projects for me and my team where we're able to add a new data source that we haven't mined for information and start to do something with it that's really going to help move the business forward.
BREA: Yeah. There's an element of that, which I think is really powerful, which is that the things that they need to do is to get the questions right. It's almost like if they're too vague, if they say, we want a digital transformation, order me one of those, I think it feels like it would be harder to work with that.
Because then you really do have to do the work of shaping what that means. And that inevitably slows down, a little bit, the expectations for immediate impact that you can have as opposed to maybe working with a team that says, "All right, we know we want a 'digital transformation.' But for us, the key strategic priorities are A, B, and C. Can you help us fix those out of the gate?"
CLARK: Yeah, I mean, I think if somebody were really asking me that question from a company that wanted to go through it, I wouldn't presume to advise them myself. It's more like I'd want to put them in touch with my previous colleagues from Wayfair or my current colleagues from Casper to just say, "what's it like running these places? And what are you asking for that they can really give you?"
Because being at these two founder-led companies that have gone public while I was there over the last 10 years, you're just really blessed in who you're working with, mostly on the the business side.
BREA: One thing I wanted to ask you -- and again, feel free to answer this to whatever level of specificity you'd like -- but how much of this effort is about moving to a cloud architecture and simplifying your life a little bit in terms of being able to spool up what you need and not, to move at the pace of things, versus how much of it, would you say, goes beyond that, to almost sort of culture change, when we're talking about one of these transformations?
CLARK: Yeah, that's another good question. I'm starting to forget everything I ever knew about going to the cloud.
CLARK: Because Casper was pretty much 100% cloud.
BREA: It was already there.
CLARK: Long before I was there.
BREA: That, in and of itself, then, is actually really interesting. That is an interesting statement.
CLARK: So in the early days of it, there were two things going on. There were the people focused on cost, where it was very clear that, for companies with super-elastic workloads, that either going cloud-first or cloud-only made a ton of sense.
And then, secondly, there was just the nimbleness thing. If you happen to be in a place where you needed to be spinning up lots of different types of things on a fairly frequent basis, then there's just no comparison. And speed is just the absolute be-all and end-all.
But it's funny; that's not the case with every business. Wayfair, for example, did not go to the cloud for a surprisingly long time. But did it need to in those days? The technology stack, until we started adding all those crazy things that I was talking about, it was pretty predictable. You just needed to buy a couple more servers at exactly the same time. I'm simplifying, of course.
But I don't think they were late to the party at all. They just started using it when it started to really make sense. And they started to be doing things where some of that made sense. And also they had elastic and semielastic workloads as well.
So those are the two factors. But once in a while, I talk to people who have been all cloud, all the time since the beginning. And they've gotten to such scale. And they have a base workload where reserved instances don't quite do it for you anymore. And they're standing up data centers now.
BREA: Yeah, yeah. Our experience right now is sort of similar, actually, that people are being less evangelistic, either pro or con. It's more just a practical decision based on some requirements.
I want to come back to people -- what you're looking for in the engineers that you hire, what has been a constant in answering that question over time, and what's changed, and how much of that you actually find in the resumes, and once you're talking with folks, what you probe for.
CLARK: Yeah, well, OK, we look for it in the resume. We look for it in the GitHub history, more than to the point.
BREA: Oh, no, very interesting.
CLARK: I mean, that's the real way to find people. But I mean, I don't think I'm looking for anything different from a lot of other people. I'm looking for the learning bit to still be on, you know what I mean, and to be really powerful. I'm not super keyed on educational background. As a self-taught programmer myself, I'd be a hypocrite if I got too computer-sciencey on you in that way.
And I'm just looking for people who are incredibly good collaborators who can really figure out what's needed and not have that kind of fanaticism of overengineering that shiny object, but who are able to really get in there and take pleasure in building things and solving real problems that people have. They're going to make people's lives better, whether it's just business partners across the aisle or, if they're really thinking about it the right way, the company's customers. And just helping them, one way or another, get a better night's sleep.
BREA: Exactly. Actually that comment about the public portfolio as resume, I think, is actually really telling these days. There's advice there for a lot of people embedded in that.
So different topic -- trends. Obviously you could follow a thousand things. But for the stuff that's relevant to your business, what's interesting? What's new and interesting that you're tracking that you think might be relevant? And maybe, as a general question, how, when you think there's something interesting going on, what's your approach to actually testing the waters?
CLARK: Yeah. So I mean, the first one is pretty easy, I think. It's just the health and wellness trend. And this last year of a certain kind of focus on health and wellness and a certain kind of focus on suburbanization has been a thing that's definitely -- we're thinking about it at Casper.
BREA: How many Zoom calls happen with people's beds in the background?
CLARK: So those are the trends I'm keyed into. That's for sure. The way the day-to-day of tech intersects with those can feel a little abstract for a number of the problems that we're coming to grips with. But when you step back a little bit, it's not so abstract at all. We're trying to see what's going on out there and just orient everything we're doing.
BREA: I would think things like maybe like IoT and then thinking through all the network architectures that you need to basically collect that data and sort of process -- ah, there we go. OK, good.
Tell us about it, the glowing orb. Oh my goodness.
CLARK: The Casper Glow, you know? Yeah, so this is our piece of consumer electronics, which I think is just incredibly cool. And it's sort of unassuming sophisticated tech. I love that about it. There is an app which controls it, which I'm very proud of. My team wrote it. But you can also just control it by twisting it around. And it's a super-helpful thing.
The way it works is you turn it on, which, as I was showing you, you can sort of do this. And then you can turn it off. And you can also twist it to dim it.
But by default, it gradually dims down over 45 minutes, I think, is the default. And then you can use the app to tweak it so it's 25 minutes or this kind of thing.
And it just helps you relax. It just helps set that mood in the bedroom.
So you asked about things ... So I guess that's my answer.
BREA: Have to ask -- is there any sort of data that comes out of that that's interesting? I mean, even if it's not, it's not obviously tracked at a PII level. But what do you learn from it?
CLARK: Well, actually, that is, technically speaking, not a connected product. It is a thing that we sort of purposely really drilled in on that you don't need the internet. You don't need --
BREA: Ah, thank God. Right, exactly. That's the whole point -- unplugging.
CLARK: And so we don't look at that in that product, other than crashes and that kind of information. Because if it's failing people, we would want to know that and be able to respond to it with our excellent customer service. And so yeah, so that's my answer to that question.
BREA: One last question for you. So aside from all I've learned from you personally, you've also been an adviser to us. And we're very grateful for that. I'm just wondering what advice you would have for a firm like ours as we try to be helpful to executives like you. What are the sort of top three things you'd be looking for or asking us to do? What would you advise?
CLARK: I've been at a bunch of places where we've had outside consultants in. And the best of them have provided me and my colleagues with a fresh pair of eyes on a problem that we've maybe been wrestling with.
Some of us, like myself, have done some consulting in the past. But if you're in a role like mine, you're primarily an operator. And so you've got these processes and people and things doing their thing in front of you. You're sort of observing that and tweaking it, trying to make it better, and once in a while coming up for air just on your own and thinking about the big picture.
But at the right moment, getting a fresh pair of eyes when you're doing that second part, and helping us think through maybe a different take on something -- consultants make proposals, operators make things better. And I think there's a healthy sort of interplay with those two.
BREA: Very cool. Well, we've had beers in person, virtually in person, safely distanced, the variety of them. So now that spring is here, I'm going to declare that we need to book another one of those into the calendar and have a chance to talk about these things and other things that have nothing to do with this in more depth.
But I just wanted to thank you. This has been really, really fantastic. Certainly a lot of insights here about how to go about things. But also, I mean, given the really impressive range of things you've accomplished, we appreciate the chance to learn from that. So thank you, Ben.
CLARK: Well, thanks so much. It's a great pleasure to be with you today.