 I have one slide today. So it should be fun. I think I've got 40 minutes, right? I should keep an eye on the time. So it should be good. Hopefully also interactive. We'll see how it goes in Finland. So hi, I'm Jeremy. I lead Red Hats Open Innovation Labs here in Europe. And I'll tell you more about what we do as I present. A little bit about me. I'm actually half Finnish and half Northern Irish. And I live in Paris. So I'm like the ultimate mix of everything. And unfortunately, I don't speak much Finnish because my mother is one of those wonderful Finnish ladies who married foreigners. And I grew up outside of Finland. So but it's really nice to be here. It feels like home when I hear everybody talking, even though I don't understand you. So culture. Culture isn't real, right? It's not really a thing. It's like a shadow. A shadow isn't a real thing. When I put my hand, the shadow is there. It's kind of like what we look at in culture in organizations. But actually, I would say that I would define culture as how we do things is actually what defines culture. So me moving my hands is causing the shadow. We look at the shadow sometimes in our of things that are being done in our organization. So in order to change culture, we need to change how we do things. I think it's really as simple as that. I think that as we change how we do things and how things get done, then we can start to create cultural change. The other thing I wanted to tell you a little bit about is why am I talking about that at Red Hat and what is the Red Hat Open Innovation Labs? I'll start a little bit with that. So the Open Innovation Labs, where a lot of people, when they hear that, they think two things. Firstly, they hear the word labs and they immediately think that we have lots of hardware and servers and that, oh, that's my screensaver. I'll turn that off. It's probably my battery actually going into power saving mode. So a lot of, I'll put it into the, so it doesn't go into screensaver mode. So they think that we've got all these cool gadgets that we're, we've got iPads. I guess how many of you in your companies have an innovation lab in your company? Every company has one. How many people are shutting down the innovation lab in your company? That's like innovation labs like a big trend and now companies are actually shutting them down because most companies' innovation labs aren't actually like producing anything they build these things, cool things, but then they never get into production with them and actually change the business model. So what we do is really different. So we don't have, we do have actually some data centers. Not really. We have some racks in a Red Hat data center, but that's not really what we're about. We're actually more about this. So OpenShift, which we're all here chatting about, is super, super cool technology and it represents game-changing technology for our businesses, like game-changing capabilities for our business. And yet most of our organizations are not really optimized to be able to take advantage of the power of that technology. When we in IT suddenly tell a business user, I can deploy into production safely five times a day for this app. They don't know what to do. They're terrified of it. We hear stories from our customers where the business users then say, can you guys slow down a little bit because you're going a bit too fast? Now hopefully some of you might be thinking that's like a dream for me and my organization to get to that point, but we have seen people use technology to achieve that. And really, the thing is, so what we're doing in the Open Innovation Labs is we help our customers do this kind of cultural change. We're helping our customers' teams go through some kind of a transformation. So while we use cool technology as part of what we do, we're actually also focused on cultural change. And in particular we do that team by team within our customers' organizations. The way I describe this, because it sounds kind of out there and weird and doesn't make sense, it's actually really simple if I use an analogy of learning to cook. I'm not a great cook. I like to cook, but I'm not very good. I've watched a bunch of TV programs. I bought some books. In fact, I have a shelf of books at home. I kind of watched a few YouTube videos and sometimes in that experience I've, how should I say, I've got a little bit better. I can follow recipes and things now. But I recently did an evening team building exercise with a chef. And that was really cool because I learned some stuff. So if you haven't done one of these before, I did one in Paris. Great place to do cooking lessons with a French chef. They're very bossy. But I mean, I learned a lot again in that evening experience, but it was still kind of like playing with the idea of cooking. So what we do is a little bit different. It's like going into the kitchen of a Michelin star restaurant and being part of that kitchen team, the cooks and the chefs in there and spending four weeks, six weeks, eight weeks, 10 weeks, 12 weeks, up to 12 weeks in that kitchen. By spending a really long time in a place like that, when you leave that amazing restaurant, the kind of food that you're going to cook in your home kitchen is going to be really different. And you're probably going to optimize your home kitchen in a very different way, different equipment, different tools, different process. And I mean, ultimately, the whole point of it is to cook better food. So kind of this is what we do in Red Hat. We're kind of taking the best of Red Hat's culture and DNA, the way that we write software as a company, and taking the best of from both the way that our engineers build open shifts and work in communities. And what we've seen is best of breed within the industry. And we've created an experience like that, except it's not just for you to go into one kitchen, but actually to come as a team, come as a whole team. And because it's not free, I wish it could be, but because it's not free, you actually come with a real business problem. And I'll describe a little bit more about the business problems that people solve. But you come with a business problem and a team, and we actually match one-to-one Red Hat people to the customer's people. And then we go through, you know, four, six, eight, 12 weeks of what we call a residency. And our residencies happen everywhere in the world. So you'll have heard that we have an open innovation labs in Boston. We have one in London. We have one in Singapore. But we've done a couple here in Finland already. So no one in Finland wants to leave their families behind for four weeks to travel to London. So we create pop-ups here. We've done a couple. One was in a customer's office. Maybe they'll tell you about it. They're here. We should ask them. Someone's waving over there. So definitely asked the guys from Elisa. I guess they're not that anonymous. Yeah. So definitely asked them about that experience. And that was a pop-up inside the customer's own office. But we still actually took over, actually the basement almost. But we took over a part of their office and did a bit of a makeover. The other one was done in the GE healthcare office that was here. It's like a co-working space. And there was about a 10 minute walk from the customer's, their main office building. And so the pop-up is kind of how we do this. Because obviously nobody wants to travel. So for me, the location's not that important. I think the secret of it is just taking this team out of the day-to-day environment. Wanted to share an answer to a question I gave recently to a customer that asked about what we do. So I think that in a lot of your organizations, people are talking about we need new skills. We need new types of people in our organization for this new digital world that we're moving into. And they don't always trust us for that. They think that they have to get people from outside to do it. So someone asked me that question. And I said, you know, they said, like, how long does it take to change our people? And I was like, well, first of all, I don't think we change your people. I think it's not like that. And I thought about that a little bit more. And I said, actually, the change from how they operate in your office and in their environment and when they come into one of these pop-up labs, I think it's about 24 to 48 hours as the trust starts to get built between the team. And so personally, what we believe is that the context, the environment that you're a part of, is really, really important. And that's what allows these people to change it. I think how many of you know this concept of Theory X and Theory Y? A couple of hands, not a lot. So there's this concept of Theory X. Theory X is that you're all very lazy. And that the only way to get you to work is to motivate you through money or beatings or some kind of discipline. And that ultimately, we can't really trust you, right? Doesn't sound very good. Theory Y is that actually, we're all very motivated and passionate about the things we do. And that if we can harness the right kind of passions and motivation, we can trust people to make decisions. And we can delegate authority to everybody to make decisions. And I think the source of this theory is quite old. Most companies are built around Theory X. You have layers and layers of management. You have experts management that reason over the system and tell the workers how they should do. And this comes from Taylorism. Frederick Taylor is a, trust me, you'll know where I'm going in a second. But Frederick Taylor is this guy from the Industrial Revolution that started timing people and how they did their jobs in factories. And he started to optimize how the factory workers started to put cars together and put different types of things together. And the big idea behind that is that we can't really trust people and that you need experts to reason over the system. Most of our companies are quite large organizations that, for the startups, you don't fall into this category. So for the guys who work in little tiny companies, you definitely don't fit into this. But for the big companies here that own a whole market, you have either a majority market share or significant market share or maybe you work for a government organization. So you're part of a monopoly. The Taylorism is really how organizations are run. The thing is that actually what we're starting to realize is that that's not how people are motivated. And that system is fundamentally flawed. And actually, the good news is that I guess factories and the car manufacturing in particular has already totally killed this myth of Theory X and Taylorism. That's why we have the Toyota production method and Lean manufacturing. They have already recognized that Taylorism doesn't work. So if you go into, you know, the Toyota factories, anyone in the production line can walk over to something called the Andon cord and they can pull it and the whole production line stops. And they trust everybody in the factory to do that. And that's because they actually delegate responsibility down to people and they teach management to do things called Gemba walks, which is management have to go to the work. And management have to understand and see the work in progress. And the way that they're doing things in Lean manufacturing is very different. So our organizations, most of them need somehow to adopt some of these ways of working. And so what we're doing is kind of taking the cool technology tools and actually showing organizations how to implement new kind of cultural ways of working by using these tools in better, much more exciting ways. So if we think about like continuous integration, I mean, some of the exciting stuff that you guys have been presenting on are about like the business value that you can achieve by being able to make code changes faster. That's some of the cool things that containers allow you to do. So continuous integration and continuous delivery is one of the big things. And actually what we're trying to do within the labs is actually helping our customers, we kind of almost like sometimes act as a dating agency between ops. Devops is sometimes they're called now and the devs and the business and we're kind of bringing them all together. For some organizations, they're really far progressing down that and there's a bunch of them here that are really advanced in that. For some of our Red Hat customers, they're really, really the opposite side. So that's one significant part of what we're doing in the labs. And I'll probably tell you a few more stories. Just wanted to tell you a little bit of some of the applications that we're building. We've been building mobile apps, little web apps, some kind of not so little web apps that can touch thousands or millions of users. And we've also been doing some cool things around brownfield migration. So one of the big challenges with OpenShift and I've seen this with some of the stories here is you don't just want to put greenfield applications onto OpenShift where you're building from scratch for this cloud native world but you're actually wanting to take very significant old applications and move it onto the platform. So that's something that we're doing as well. And just to give you some tips on that, so we're using things like metrics-based process modeling for brownfield applications. We actually model how work is done today and how that application gets from dev all the way through to production. And then we actually focus on where the biggest pain points are in that application and we try and compress the time down. So some of our customers tell us, well, getting a VM, that's three weeks. Why? Let's do it a different way. So greenfield and brownfield. And then the other thing I should say is we've done some really cool stuff and we're doing some really cool stuff around. Recently, we're experimenting with customers doing things like windows containers. So we're working with our friends at Microsoft. We have a very early beta or I would say alpha program for windows containers and OpenShift. And so we're doing some work where we're having both windows containers and Linux containers running in the same cluster. And we've been doing some super, super cool stuff around GPUs and actually, you know, running on bare metal and getting using GPUs to do things like running gaming engines within the cluster to be able to model real-world problems. So there's some really fancy use cases. I would broadly say that our customers are kind of coming in three different ways. One is that customers are doing that transformation thing I talked about. So what we're doing when we're talking about transformation, I want to show you some stuff in a second. I don't just have one slide, but I wanted to show you some of the stuff we're doing. So what we're doing is everything that we do in Open Innovation Labs to help our customers transform, we're actually trying to also, because we're an open source software company, we're also trying to open source all of the ways of working, all of the methods that we use so that you can use it within your own organization yourself. So when it comes to like the transformation use case, we're partnering often with our customers who are trying to do agile or DevOps or digital transformation. So that's one key bit. We then have customers who, their current processes, when they're trying to build a new application, how many of you in your organization, this is a story, I have a new app, IT knows, the business is coming to the IT, I need a new thing built, and it turns into over a million euro project and at least 18 months to get into production. How many have that problem today? Okay, just like only five honest people. But every project turns into that. So we call that like kind of a disrupt use case where we're actually showing often actually more the biggest challenge we found is actually showing the business that this is possible. We know in, I guess we're all geeks, mostly geeks here, right? We know that it's possible. We always, our minds are always blown at how these projects can take so long. And so what we've been doing a lot recently is just actually going earlier in the cycle with our partners in IT, Red Hat's own partners in IT, and helping their business guys go through a facilitated process to be able to launch these apps faster. So we've built a whole bunch with customers where within six weeks we actually have something that, well, I would say within a few weeks we have something that's in front of the users, but within six weeks we have something that can actually run an open shift and you can actually expose to the internet. And most teams are capable of taking what we've built within a month or two after that and actually putting it into production. And that's really fun. I call that like a speedboat, getting something out there really, really quickly. It's kind of the opposite of these castles that most of the organizations we're part of today are. Castles are built to defend a position. They're not really built to move out, but the thing is about castles is the world changed and we don't build high walls around our cities anymore because technology has changed. And so most of these organizations are having to be able to launch lots of speedboats. And then the other use case that we're doing a lot of, obviously, is customers adopting open shifts. So if you're early in your open shift journey, the open innovation labs residency is a wonderful way to get things right. I think like four years ago when we started this, even I would say that we could be honest, like us in Red Hat didn't really know how to help our own customers adopt this technology in the right way. And I mean, some of our early adopter customers have talked about their journey, the pains, the challenges they've had. We've now taken a lot of those learnings and built it into sort of the way we do the open innovation labs today. So we do funky things like we actually do a double residency with customers where we have one kind of track of that residency is the infrastructure team building their on-premise open shift cluster, getting it ready for production. And they work in a very agile focused way to get like a minimum viable production environment. But we have their first app team also in the same room, both teams doing demos to each other every week, and they're building either the first app or the first migration of the app onto open shift. And what we're doing here is we're bringing the people who maintain the cluster, who do the cluster ops, more in closer contact with their customers, developers, right? And getting them to do this kind of like demos to the developers to say, look at what we're building for you. That's kind of cool. And then we're getting the same, the app team to do demos to the business. And we're showing the business how a feature in open shifts like, you know, AB or blue-green deployments can actually help directly to a business problem that they're facing. Like, I want to be able to deploy two different versions of the application, and I want to test which version of the application converts more users to my system. Really simple. And obviously, as Istio comes into the product, we're going to do more sophisticated stuff with Istio, being able to segment traffic across different versions of applications, being able to do things like feature flags, segmenting different bits of traffic directly down into micro experiments in production. So we're doing all sorts of cool stuff like that with customers. And I call that like the road trip. A lot of our customers today when they're adopting OpenShift are not today, but in the last four years, a lot of our customers, buying OpenShift is kind of like buying a Tesla, right? It's a car. It drives. So you think you know it, but it can drive itself and it's electric. And so the thing is, like, how do you know that the Tesla is going to really be good in your day-to-day life? It's a good question. So most of our customers have taken the Tesla and they have a steam engine that is everything is running on today, and then they force the Tesla and they weld it on top of the steam engine and they say, well, all those security things that we do today, we're going to make OpenShift do all of that. And then they kill the Tesla. And then they ask, Red Hat, why does your product not do what it's supposed to do? I'll give you an anecdote. How many of you know about Pivotal Cloud Foundry? Or you can be honest, we're okay. We know you must know about them, right? So the others are probably asleep. And we had a customer who had a big OpenShift deployment and they actually had a dev team who had been experimenting with Pivotal. It happens. And they said, well, Pivotal Cloud Foundry has this thing called CfPush and you can, developers can just push their source code and then it gets deployed. I was like, oh, cool. We do that, too. It's sourced to image and we can do that. And they went, yeah, we turn that feature off. And I know there's lots of good reasons why you would turn off sourced to image and theirs was security and so on. But ultimately, a lot of the things that the way that we approach deploying OpenShift is also a cultural change in the way that ourselves as an organization need to deploy it. So what we've tried to do now is create a more of a prescriptive journey for people going through their first OpenShift journey, which we've learned significantly from people in this room who, far further along the line, and maybe some others. And we found that to be really, really interesting. So I wanted to share, and there will be time for questions, but I wanted to take a second actually to share a few things that we've been doing that you can take away from all of what we've been doing. So I told you that we were open sourcing everything that we do. So we've created this cool library called the Open Practice Library. And so these are not all, but we've been in the process of open sourcing this over the last two months. This is based on a number of other open source frameworks. We've been basically creating a practice library. So ways of working for yourselves that you can use that kind of codifies the methodology that we use so that you can actually use this in your organization and actually maybe our secret agenda is not so secret, but we want you to contribute to this as well. So the idea here is rather straightforward in some ways. How many of you guys know about Scrum? Scrum is everywhere now, right? So kind of Scrum is like this delivery loop here, right? All the practices in Scrum, daily stand-ups, showcase, sprint planning, all of those things, backlog refinement, showcase, all of those events are kind of like this delivery loop. And we like this framework or this thing we call it's called the Mobius Loop. We really like it because it introduces another loop, which is the discovery loop. And what's good about the discovery loop is that within it, you kind of say, well, why am I doing this? Who am I building this for? What are the business outcomes that I'm trying to achieve? And what are the hypothesis or theories that I have to achieve those business outcomes? And so you go through this discovery loop to generate options. And then you have the options pivot. And essentially with the options pivot, you're entering and sometimes the options pivot looks like product backlog, right? I mean, the product backlog is a set of options that you build. And hopefully those things actually make a difference to your product. So we go through the delivery loop. And in the delivery loop, we're building, but we're also measuring and learning. And at some point, what I like about this loop is you make a decision here in the options pivot, do I keep building? That's where the screensaver's turned off again or coming on. Do I keep building? Or have I actually established something here that I need to now to actually measure or do it go through another discovery loop? So it's pretty cool. There's a whole bunch of practices in here. And I'll just show you impact mapping. It's a fun one that we use. So for each of these, this library isn't meant to be a how to, but actually a collection of kind of, also if you think about golf, it's kind of like a collection of golf clubs. And we tried to show you where to use your golf clubs. And we're looking for more donations. So each of these has basically how many people you need, the time and how difficult it is. And the kind of participants why and when. And rather than telling you how to use it, we actually link back to the original material for most of these practices. And we would really welcome, if you're using a practice that's really useful in your organization, please, please, please fully open source. Please donate those to us. And hopefully you'll find this useful. We're actually working on something really cool now where we're actually building like an interactive discovery loop, or sorry, interactive loop. And you'll be able to kind of pick practices and compose your own process, which is kind of cool. So definitely recommend that. This is all under its own GitHub repo. And the reason we put it under its own GitHub rather than one of the Red Hat ones is we don't, and there's no Red Hat branding on it. This is an upstream community project. We don't really want to have Red Hat owning it fully. We want it to be owned by a community. So there's a really cool Gitter chat page that's connected to this that you can sign into. There's a bunch of cool stuff. And actually, you can either send pull requests, because all of this is a static website with Hugo. If anybody knows Hugo, no. It's very cool. Static websites are the future. And so, basically, we have actually a CMS workflow on top of this. So that's one thing I wanted to show you. The other thing I want to show you is have a little browse around our own GitHub page. We have a bunch of cool stuff in here. And I wanted to show you some stuff that could be really, really useful, because we found it useful. So the first one is this thing called Labs CI CD. So when we were taking our customers on these journeys, quite prescriptive journeys, one of the first things that we had to do for every team in OpenShift is continuous integration and continuous delivery. So we built kind of like a pretty cool starter CI CD project. There's a bit more info about it. One of our guys in the team, actually his wife, drew some of these hand drawn logos. But basically, this is a quick start. If you're starting out with OpenShift, obviously it contains Jenkins and pipelines within it. But whenever you want to do anything more sophisticated, you end up building a lot more scaffolding on top of that. So this is really cool. Super cool. And what we find is that most of our customers are actually ending up having to build something like this for their developers. So being able to provide an out of the box scaffolding for your teams is really great. And we've also pre-built the pipelines with a bunch of clever stuff in here. So things like SonarCube, we've got OWASP and a bunch of security checks that are kind of out of the box in the pipeline. So we have a number of external contributors to this, but I would love it if you guys also contributed back to this. It's, I think, really helpful for you guys. So, funny thing, when we were preparing our, when we've been building the Open Innovation Labs, we had to actually prepare our own Red Hat consultants to work with you, our customers. And a lot of our, you know, our consultants, you probably, there's, I think there must be some here, but you've also worked with them. I mean, some of them have helped you build some of the platforms that you've got. And the thing about it is that our consultants are super awesome, but have also, primarily, they mostly go on site with our customers and they work as an individual within the customer's organization. And what we wanted, the way that we work in the Open Innovation Labs is really different. We're working as teams, we're doing a lot of pairing, mob, mob learning. There's a lot of different practices and ways of working. So we built this course, it's a four or five day course, called the Labs DevOps Culture and Practice. So what we did was we have a little bit of technology within there and this is the technical workbook. So the funky thing about this is I think you can tell what the theme is, but I'll read it out. The manual menace, attack of the pipelines, revenge of the automated testing, and can you tell the theme yet? And enslaved hope, the non-functional strike back, return of the monitoring, the cluster awakens, and the last unicorn developer. So basically what we did was this is the technical part of the exercise and I'll point you where the slides are and everything else. So basically what we did here was we interleaved a course that involves teaching people all the cultural practices that you see in the Open Practice Library. So impact mapping, event storming, user story mapping, priority slider, social contracts, all of these kind of funky things and we actually also built a technical workbook to just basically introduce people to the simple things of using OpenShift from a developer perspective and some of them are actually based around test driven development. So it's not just purely CICD and things like that on OpenShift. Check this out. It's also on GitHub, of course. So this is the GitHub page. It's under the Red Hat Open Innovation Labs, RHD Labs GitHub page. All the slides are linked to here, though. I have to tell you, we use Google Slides inside Red Hat and we're trying to get basically all of that out into something like Reveal.js so that it's a code and that we can then accept more contributions from you guys. But the PDFs are definitely there and if you email Jeremy at redhat.com, I can give you the PowerPoint version of it or whatever. So this is really cool and this is really good because if you're trying to get 120 developers or 500 developers or, I don't know, some of our customers have 3,000 developers or 10, some of the customers we work with have more developers than Red Hat as people. That's kind of crazy when a customer has more developers than we have employees. And so we run this. We do about 24, 25 people in a class. It's about the limit that we can do with quality. But this is a great way to get a large number of developers quickly through and enabled on the platform. One of the cool things that we're doing now is we're actually, as part of our customers who are trying to scale out OpenShift internally, we're actually offering this. And the way we offer this is we're not really interested. We have a whole training organization and they actually just came on this course last week to see how that Red Hat training can turn this into a product. But one of the challenges of that, and Tony, by the way, is one of our facilitators on it. One of the challenges that you have to, as a facilitator, you're talking about your own DevOps experiences as part of that. So what we're doing is we actually want to help our customers to be able to run this course themselves. We're not really interested in running it 20 times in your organization. We really want to run it two or three times or four times until you can run it yourself and contribute back to it. How am I doing for time? Another few minutes. Cool. Let me show you some more cool stuff. Do you know that Red Hat has communities of practice inside Red Hat? So you guys are also building communities of practice. So all of the Red Hat communities of practice, most of our source code is on this Red Hat COP GitHub organization. The reason I wanted to show you this, definitely check out all the other cool stuff, because we have a couple of things that could be useful for you. Let me start with the basics. So CASL, as the Americans call it, like they say CASL, I don't know. Basically, this is our container and automation solutions lab. So we have what the little rack I told you about earlier, we took most of that automation that we built and we open source states, Ansible automation. So we're not putting any kind of, this is not production ready, but if you're building simple stuff with OpenShift, this is a super cool Ansible repo for doing all sorts of clever stuff on OpenStack AWS and Google Cloud and soon to be Azure, because Microsoft gave us, were very generous and gave us a bunch of credits to be able to get this working on Azure as well. In fact, this might be a bit out of date, but this is a bunch of really good automation that you can please do donate to it or steal, that you're welcome to do whatever you want. It's full open source, but this is really good. So we use this to build our own clusters and that's quite nice. The other thing that I wanted to share with you more is this thing, which doesn't have the greatest readme file in the world, but this OpenShift supplier is actually super cool. So basically, isn't everything cool? This is actually a way of putting kind of your projects in Ansible and being able to apply them into a cluster. So check this out because our customers who we've shown this to really love it. And actually it, that we're evolving this a little bit more. I probably want to show you another webpage. I hope this is useful. I've got one more minute. Uncontained. So Red Hat's consultants are building this website. And Uncontained, there's a bunch of links down here to more of this stuff. Basically Red Hat's consultants work with you guys. We learn a lot from your crazy, funky environments. And then we go back into the COP and we build this stuff. One of the things that we're doing here is not just focusing on ops, but we're actually also trying to help you with developers. So the OpenShift supplier is a key part of this. Being able for a developer to be able to codify their application in Ansible. Definitely explore and play with it. And this last one is a bit early, but within the COP folder you'll find something called Pathfinder. Well, the documentation is a bit like, check out what Noel wrote and all the rest. This is a tool to, if you have a large legacy estate with OpenShift, sorry, no, if you have a large legacy estate with hundreds of applications, how do you actually do an assessment across all of those applications? So Pathfinder is a tool that you can run that basically it's an assessment tool that asks you a bunch of questions about your applications. And we've thought long and hard about the questions, but it also then gives you a visualization. When you've asked and filled in the form for every application, you get a visualization of your entire estate. And then you can see, oh, which ones are the low-hanging fruit? Which ones are the ones that maybe I should leave behind? And it's a really great tool. What I would say here is it's kind of really early days for us inside Red Hat, but definitely speak to someone you know at Red Hat to get in touch with the guys behind this for a demo or to use because this is going to be really powerful for migration. That was kind of mostly what I wanted to show. Definitely come and check us out and get up.