I thought it was gonna be terrible being on this stage, but it's actually almost nice that I can't really see you guys, because I'm super nervous, because it's the first time I've talked outside of Illinois. So thank you for keeping the lights up as high as human possibility. So it's actually kind of neat to go directly after somebody who's working with a bootcamp, because I'm almost sitting on the opposite side of that equation. I work with a consumer finance company, we're a billion dollar company, we're IPO, we've got over a hundred engineers, and what I'm working with is not folks who are brand new to the field, or at least not exclusively that. And what I'm working with is trying to get people over the course of their careers with us, which two, three, hopefully four years, they need to keep getting better at the things they're doing. So it's really interesting, just listening to that last talk, the fact that they start learning the algorithm certainly really early on, and hopefully in computer science school, however you come to the field, my job is to continue and hopefully get to the point where you are a better craftsman year after year. So my company, it's a consumer finance company, which I put at the bottom actually, because I think that's the least relevant part of this. It almost doesn't matter what industry we're in. My suspicion is that people in really every other industry, and I've worked startups and other companies have exactly the same issues that we do. We are fast paced, which is sometimes euphemistic for going at a breakneck pace. I think that that's true, but I also think that there are also a lot of positive qualities to what we do. As a competitive company, we have to ship or we shut down. And so all the things that we're trying to do, the attempts at getting better at what we do are in the context of a company which is regulated, which has to ship. And so there's really no compromising on that point. So we have Rails code bases starting at 1.2. We actually started at 0.7. And because we're a startup at the time, we wrote lots of terrible code, and we're massively financially successful. And so we couldn't get rid of the code because it was making a lot of money. And so that code base has been pushed up over the years and managed to find itself locked at Rails 1.2. And so we did what any normal person would do. We attempted to rewrite it from scratch because that's totally an intelligent thing to do. And so now we have two large code bases, one of which is on modern Rails, thankfully. And so we're coming from a pretty wide technical platform here, so all the way between Ruby 187 and Rubinius, we actually, Brian Shirai is a member of the team, so we have the Rubinius guy. So it's a really interesting technical platform. And then we hire a ton of green developers. So for historical background on where I'm coming from in my position, and I'll actually even hop to the next slide, I took this position at Innova maybe about a year ago, and in the time that I've been in it, we've grown from 80 people to about 120 people in the engineering department, which with attrition is actually about 50 people being hired, which is what I normally will categorize for people as a bad idea. It is just not intelligent to hire that many people that quickly. But we were IPO-ing and we felt the need to expand. And so I, from my background, so I've been developing for a dozen years of work, public sector, private sector consulting and all this, worked at this company for four and a half years, so three and a half of the time. And we decided that we should probably teach those 50 new people the stack. We should probably teach those 50 new people about our culture, about all the things that we wanted them to know. And so I stepped into this position as the manager of internal learning. I don't expect that you'll do this, but I do think that there is value in understanding the path that we took and how it shaped our culture as a company, because I think that the lessons from that are really applicable to, again, a really wide swath of companies. That was an interesting pop. And just a note on that, so I am not a teacher. I think that that's okay. I've been trying to learn from books because I'm an engineer. I think I can reinvent other people's professions by reading a book. But in all seriousness, it's okay to be not an expert at this. So when I started on this, really no history in education, thankfully a lot of history in development, but a lot of this stuff can be picked up as you go along. A lot of this stuff will either really obviously work or really obviously not, so don't fret not being a teacher with any of this. So how many people here kind of, how many people here, first of all, ship on day one? This is my favorite, like, everybody's job posting. Yeah? Whose job posting says they ship on day one, but they don't actually? Okay. There's an idea that comes hand in hand with that, and it's kind of learning on the job.  This is an appealing system for a lot of reasons. You don't feel like you've wasted any time, you feel like you're really only learning the things you need to learn, but my contention, which is backed up by history here, is that it's really not the best way to learn. What I've found with folks as they do this is, A, they mimic the bad patterns that you might have on your Rails 1.2 code base. They don't tend to learn a wide swath of things, and so what you get, for instance, is maybe UI developers are loading a whole bunch of active record objects, and so they don't really realize the way that they're querying, and you run into these kind of really obvious problems if you understand that n plus one problem is a thing, you could Google this, but in the ad hoc learning method, it's not something that you really run into, and so I'm gonna argue that that's not really the right way to do it, and this is of personal importance to me because I, of course, then needed to justify that my job existed because if I could put people into a team and then they would just sort of learn everything, then I actually shouldn't exist, which doesn't mean that I should make something up, it means that my job shouldn't exist, and so for me, I wanted to get the reasons right on why it is we should have formal learning, and why it is that we should spend our time and spend our money and take away from aggressive deadlines in order to learn more Ruby, because it's not good enough that we like it, it's not good enough that it seems like something we should do, we should really start to justify this with real reasons, and so the reasons that I've got here, the first one is really just attracting amazing engineers. The biggest thing that I've seen in my time building this culture is that the people who I really want to work with on a day-to-day basis who do a fantastic job shipping want this as a part of their job. Does anyone not want to learn as part of their job, right? So those of you who are really good at your job, I would like to work with you, and so hopefully you'll go towards places where that's the case, and so there's a culture thing here which, coming from a company, I want to hire people, I don't want you to be able to hire them, so I want to have a better learning program than you do. Reduce attrition. Senior folks, it's really interesting. When you get into a job, and I found this actually being four years at a company, when you get into year three, it's really, really common to kind of run up into this wall of learning new things. So on the first day, there's all these libraries and all these things you never used, even if you're on the same stack, it's a whole new set of gems and a new architecture in that. Three years in, brick wall. What we want to be able to do is move the organization forward. A, we want to be able to change the platform, but B, we also want to give you the opportunity to be looking at things that are beyond where you're at right now. So we can alleviate that, and with that, we can retain employees, which is another fantastic thing. Bus factor. Does everyone know bus factor? Cool, so for anybody who doesn't know it, the idea is how many people on your team would need to be hit by a bus before you're poached? Hopefully it's a large number. In a lot of cases, it's a very, very small number, and so we want to increase that bus factor and make sure that there are at least a handful of people that know any given system. There's another point away from the ad hoc system because what often happens is that if I'm the expert on the payment system, then I get all the payment system bugs. I learn so much about the payment system, and then when I get smacked by a bus, they're like, oh man, nobody has any idea what was going on, and so we can offset that. Bring fresh ideas into the organization. Again, the platform should shift. We should not feel like we're locked in. Ruby of five years ago was not in the place where it is today, and not taking advantage of that is a shame. And then reducing wasted effort, which is hopefully self-evident. This is kind of the play to the business is we're gonna be faster than we were before. So a non-exhaustive thing, a list of things that don't work, so I have tried in the past to get more training time. I have talked to a lot of people who feel really strongly that they would like to spend more time on this, but I find that we are often very ineffective, and so I wanted to get out of the way very quickly some of the things that aren't gonna work very well. Me a while back, we really just need to make this a priority. So this is shifting the blame off onto somebody else who is not me to say, if you would tell me to learn, then I would learn and I would be really good at my job. This doesn't work. The CTO and the CEO have other things they're worrying about. These people that you're appealing to probably don't really understand the issue in the same way that you do, and by shifting that responsibility off onto them, it's not gonna be successful. I haven't seen this model really work. Somebody can come tell me how great their CTO is, but in general, I don't think that you can shift it onto somebody else. We could pause our current deadlines for a couple weeks. Again, we are in an aggressive shipping schedule. This is just a non-starter. There's no way to do this. We're dedicated to investing our people who are in a crunch right now. Has anyone ever heard this one? Like, we really love you guys. Once we're done with our crunch, we'll get into this. The crunch never ends. You ever notice that? So this is another thing where if you wait until the right time, there's never gonna be a right time. So what I'd like to propose to you guys is how to build a culture in three phases. And these are based on the things that I saw as an engineer at Innova. And the caveat to that is that my people are not your people. My company culture is not your company culture. Take everything that I say here with a grain of salt. We tried, of all the things that I list here, we probably tried three times as many. I'd like to try a lot of things. So keep in mind the spirit of what we're trying to accomplish. Keep in mind the types of constraints you're under, but your approach has to be different. And there is no precise answer to exactly what's gonna happen. So the first phase is building credibility. So this looks like is that in most companies, especially once they're a little bit more established, people have gotten a bit comfortable. There's resistance to actual learning. It's this idea, well, I had to learn it by jumping into the pool, then you should have to do the same thing. People are mostly learning in a kind of ad hoc manner. This is a pretty common phenomenon. If there is training, which usually there isn't, it's probably a wiki page. Or in my case, it was a 800 line shell script that didn't quite work. About 90% of the instructions were correct, and I was hoped to intuit where the rest of them went wrong. And so it's pretty disorganized, but hopefully there's some help getting people on board. There are the last bullet on here. There are probably a couple people in any organization who really care pretty passionately about learning. And this is a really fundamental thing, is that in the beginning, there are probably only a few people who are willing to step outside of their normal roles and their time and take the risk to actually get this stuff happening. So this will work for us. Like I mentioned before, do not pass this off on someone else. If you care, you are responsible for it. If you care and it doesn't happen and you didn't try, you are responsible for it.  Think opportunistically. So early on, since you have no credibility, we need desperately to have victories. So think about the things that are really easy wins. So say there's one library that if people actually knew was in the system, they would do a better job of programming. Teach them that one. It's easy to see the output of that thing. It's low effort. It's low risk. So those are the things we need to do. Low time and effort investment, like I said, we can't afford to spend more time or everyone's gonna tell us no. And then focus on improving people in their primary roles. This just goes back to the idea of being able to demonstrate really quickly that you are having an effect on people. And what you need early on is to be able to say, look, Tom isn't writing terrible tests anymore because we told him how to use our spec. And that's the kind of thing we're looking for early on. So what we did there was we did a lot of meetups. We actually ended up running some of those meetups but open book policy, I'm not actually gonna read over every one of these things. If you take a look at them, it's all stuff that is, again, really low cost and it's stuff that a couple people can opt into. I don't need the entire department to opt into any one of these things. I can have maybe five or 10 people do the job and it works. I just wanna highlight a couple of those really quickly. The open book buying policy, this is, if you take away anything else from this talk, this is like the most dead, stupid, easy investment you can make in people. So our policy that we came up with is if you're willing to ask me to buy the books, I'll buy multiple copies of the book. If you wanna buy Sandy Metz's book, I'll get five copies and I'll put them on the shelf. And if those copies disappear because I'm not asking people to bring them back, I'll buy five more copies. Over the course of last year, we bought about three books per engineer. It's 360 books, it's about 10 grand. That is the easiest, dumbest investment you could possibly come up with. And I can't pick the books because I don't know everything about what needs to happen. And so when people come to me and they say they need the angular book, I can make that happen and I can spread that knowledge to the rest of the organization. So copies are already waiting for you. Not particularly expensive, like it really just is not expensive enough to matter. I will say people don't read all the books they ask for.  There's really no way around that from what I can tell. I am a fan of paper books. In this case, a lot of people tell me you should have bought all ebooks. What I've noticed is that they don't read about 95% of the ebooks that you buy. So I'd rather take the slightly higher hit rate and just buy them used and feel a little bit better about that. New hire buddies. So you may or may not do this informally. It's great when a new hire comes in and they have some relationship in the company. Maybe they know somebody that's already there. If we can't have that happen organically, let's cheat. Let's just assign everybody a buddy in the organization whose job it is to tell them the bathroom code and tell them who to talk to and tell them where to go for lunch and keep them involved. Again, very little expenditure does not mean that everybody has to buy in. We just have to find a couple role models who we can put in that position. And it's a really fast way to get people up to speed. This starts to solve this problem of not knowing which libraries are out there to solve this. They can say, oh, I'm trying to solve this problem. And you can say, oh, we've solved that three times before. This is how we already did that thing. And so that's a really nice and easy one to do it. Also as a pressure relief valve, I think that case is like some people like me are really neurotic. And so if you get really neurotic in a new job, it can be nice to have somebody to talk to. So that's a really nice side effect. So the dangers of this is that inertia. Inertia is bad. And it's really hard once your organization has been around for a while to get people to the idea that they should be learning these things.  The vulnerability of being a learner is a really important thing. And if you don't have a culture that encourages learning, it feels really tough to ask questions or to speak up and say, I don't understand this thing. Help me learn this thing. And so we need to try to lower the risk of speaking up. And that's something we have to work with really early on. And then low credibility, if you do stuff that fails really early on, everyone will remember that. And then they'll try really hard not to remember the things you succeeded at, which is why we focus on high success rate when we don't really have that culture built up yet. Which brings us to phase two. Let's say we've done that for a while. We've had a lot of these hopefully high impact, cheap things. Hopefully at this point, our new hires are learning a lot. They have buddies, they have books, they have maybe slightly better onboarding and they blog about their onboarding so that they can tell other people what they've learned. People wanna take control. This is a big one. We really had a nerve when we started doing this stuff. What I started to get was folks coming to be saying, I'd really like to do more of this learning in my team. But the rest of my team is really recalcitrant. And so I don't know how to do it. And so in the same position I was before, they don't know how to take control of that situation. Some teams maybe start to learn as a group. We had maybe 12 teams. I think two of them had some kind of structured time as a group to learn things. That was fantastic because that's something that we can use to effectively just shame the other teams into doing the same thing. Small, somewhat organized onboarding. At this point, we had some documentation. We had a little bit better list of the kind of things that you would wanna know. But we didn't really have a completely formal system. And then instead of having one or two people, you've probably got one or two people that are still driving the big part of the change. But you've got a larger core of folks than the rest of the department who are really interested and so they're willing to do the legwork. So what we'll look for us now is to broaden our scope. So look ahead and start to anticipate need. This is the next awesome parlor trick is when my boss says to me, I need everyone to or this group of people to know Ember and I say, well, I already got the book and I already started training with them. Makes you look really smart, makes you look really credible. So that's a really good trick. Opportunities that take a while to pay off. So remember in phase one, we can't do things that are riskier that take six months to pay off. In phase two, we can start to look at stuff that takes a little bit longer. One of the big things that you can do is cross training for various roles. So in my company, we separate UI, database, backend dev and test engineer. So I just cross train as many people as possible on these things so that if you are a database developer, the Postgres community is quite frankly just not all that great at testing relative to the Rails community. So if I can teach my database developers the philosophy of test engineering, I get a freebie there where they get better at testing at the database level. So roping in more internal collaborators, like I said, find the people who have the will to do this but don't know exactly how to get started and figure out how to get them started and then seed good role models. This is a really important one. People tend to absorb the characteristics of the people next to them. And so if you have a group that really is not living up to this, find the person who is just like fanatically, like trollishly into learning all the time, put them in that group. And even if they have a lot of static to start out, they will move towards each other in a way that will be totally helpful to the entire group. So like I said, we ended up hosting meetups, which is fantastic. Speaking at them, which is actually why I do this so that I can tell people when they tell me that public speaking is hard but they're full of it. Internal workshops, we started doing, so in the first phase you could do something like a lunch workshop. One hour, low investment, pretty easy. Half day workshop, way better. A little bit tougher because again we have to be able to demonstrate that output but now we have a little bit of credibility under our belt. Dedicated onboarding process is a big one. But let me skip ahead to a couple that I actually want to look at. So juniors as teachers. So if you remember from the first photo with the buddies, that was actually our group of interns. We assigned to them some folks who were maybe like a year and a half out of college. And what we did when we got a concentrated onboarding program is we took these same interns who looked to be about 12 to me. And we took the super senior engineers of 20 years and we had the interns review their code, which is really, really hard on your ego because they did it to me too. And so the interesting thing is when you started learning you get these younger folks who actually are really up to date on specific things and it's a really good way to help them grow because when they're right, they're right and that helps their confidence and when they're wrong hopefully the more senior person teaches them why it's better do it the other way. But this has actually been a really successful approach for us is to take folks who learned something recently and then force them to teach it by way of code reviews. It's a little bit tough on the way of organizational knowledge because sometimes there are really good organizational reasons not to have done something, but overall it's been a huge victory. Their pain tolerance is low. It's my favorite way to think about this. If you think about it when you've been in an organization again for say two, three years you don't remember what hurts, right? You've been doing it for so long you spend 40 minutes doing something that should take 10.  And so when you have people who still have low pain tolerance, use that low pain tolerance. Cause your young people pain, quote that on Twitter. And use that lack of pain tolerance to have them point out to you the things that you can fix because you don't see them anymore. Does that make sense? And then weekly tech talks. This is my favorite part of my job actually. Every week there's a standing appointment. You can't see it in this picture. There's usually about, there's about 100 people that attend and you get 15 minutes to talk about whatever you want. It's a great way to introduce people to the idea of teaching others. More importantly, it gets four new ideas into the organization every week. That's fantastic. And an hour again is not all that much time to spend. So the only danger here is we have to curate this thing, right? Like as somebody who's helping run this, I have to find people, convince them that it's not super scary to talk in front of 100 people, which it is. And then get them to actually prepare a presentation. And so there's, you have to hold onto that credibility but as long as you can, when you have interesting stuff we have people talking about, you know, programming arduinos to drive robots with Wiimotes. We have people talking about wearable fashion. We have one guy whose entire plan is to put a plant on every single desk in the entire department. That's his only goal in life is to have each person have one plan. It was one of the best talks I've seen in a really long time, because he really, really loved the subject. So this is just a really great, again, not very expensive way to get this, to get new ideas moving around in the department. So dangers. Like I said, there's still a couple of people who are really forming the core of this initiative at this point. Losing those people really hurts. And if you do lose those people there's a lot of danger in people kind of like blowing it off and taking a step back and you lose that momentum. That's really tough at this point. The perception of wasting too much time. This too much time thing is not, it's not the actual rejection. They're not actually telling you you're wasting too much time or if they think they are, they're wrong. What they're actually saying is that they don't see the value for the time you're spending. And so now that we've started looking at things that might take a little bit of time to actually return that reward we have to go back and justify it. And at this point you're gonna have to basically look at the output, start looking at some kind of quantifiable way to say this is how much we're getting out of this thing. So that you can push back on that perception because we're not wasting time, we're investing time. And we have to convince people of that. And if you don't, then you get clamped down. That's no good. And then the old guard in this case may be too comfortable. So the old guard being the folks who've been there, there's always like those five people who've been there way longer than you have. They're pretty sure that the way that we're doing it right now is the perfect way to do it because they've been doing it for six years and they probably get really good options. And so the old guard are really, really comfortable in this case and that's again something that I've seen in every place. And so a lot of this change ends up driving from folks who are newer or less experienced because again, they have lower pain tolerance because they can see the way that things are no good. So phase three, you've been doing this for a while. You've got weekly tech talks, you are hosting meetups like you were rocking it. At this point, what we wanna do is to start to cement that culture. I've got this cool, the roots are actually a parable for what we're talking about. And what that looks like is people start to see learning as a normal part of their job. This is the secret judo of learning culture is when people forget that there was ever a time when they didn't learn as part of their job. When people start to understand learning as a requirement for what they do at work. At this point, you no longer have to be the one or two people who are driving it. At this point, everybody's driving it because everyone expects it to be part of what they do. So momentum and reputation, that's a huge thing. And then so dedicated training for new and existing is an important thing. You remember before I said new people are the driver early on. Later in the game, you have to really open your existing people because over time most of your people are existing employees, not new employees if you're doing it right. And so they need to continue learning as well because we're not done because there are new libraries all the time. You might be doing it on ERB, maybe you need to learn Hamel and Slim. And that's something that you can't just wait until you get enough new employees to bring Hamel and Slim into the organization. And then it's an act of chaos of new ideas. Chaos is a good word for this. It is a double-edged sword. It is fantastic to have so many good ideas floating around for how to solve problems. It is a problem when people implement it four or five different ways. This is the problem I would like to have. I am perfectly willing to cope with this problem, but you have to be aware going in that it's not as streamlined as being dictated in your direction. People take this in whatever direction they want and that is a good thing, but you need to manage that process actively as a team. So make them forget that learning was never not part of the job. It feels like demunigation. It's, that really is the key to the whole thing. Make it part of people's job requirements, honestly. Everybody gets involved. At this point again, it's just a passive part of your gig. Whether that's just code reviewing different groups, whatever it is. It's always part of what you do. Try riskier things without destroying momentum. This is my favorite part, because I think that there's really cool stuff we can do once we have momentum and credibility. Once we can actually expend resources, I think there's really interesting stuff that we can do that fundamentally makes our jobs way better. That this sort of ad hoc, maybe I learned on the weekend stuff, just never gets to. And so that's the stuff that really is the payoff for me. So dedicated training, open source contribution. A lot of you probably did that earlier on. My company was not huge and contributing back. So for us, this was a big move to being out in the community. Apprenticeships, I'm not gonna talk a lot about code spikes, but what I mean by that, we don't do 20% time per se, but we do take time now to write code explicitly that is not particularly productive, that we may just toss out. And that's something that now we can't even say, like, oh, well this library's gonna be great at the end of six months. We have to say, well, the library's trash, but I learned a lot of things about it. And that, again, is a very strong assertion and something that hopefully we get to be able to make. So dedicated training program. This was the biggest thing that I did. We ended up creating a framework and open sourcing it. It's called Level Up Rails, and it is a comprehensive way for all our new and existing employees to be up to date on all the things we expect them to know, which means that if they've been working on Rails 1.2 and would hopefully like to get out of that situation, we have the ability to teach them to do all the modern stuff. We have the ability to teach them the philosophy of test engineering. It lets people cross different jobs, get different job titles. It makes it faster and easier to get people inside of the organization. It is a huge time commitment. They do not deliver productively for six weeks when they join the company. I'm still like, I would love to find a way to ship on day one and maintain this, but if I have to pick between them, I will take people who instead of inflicting bad code on the code base on day one, come to it knowing all of the right things to do on day six weeks in one. So the last thing on the bottom here is another really interesting one that I've heard from a lot of our candidates. If you aren't aware, most of the people in this room have imposter syndrome, and most of the people in this room are not actually imposters, it's interesting. But when people look at applying to jobs, I think there are a lot of folks who say, who probably will never apply to Google, not because they don't qualify, but because they feel like really smart people work at Google and then they'll figure out that you're not actually one of them, right? And a lot of those people are really smart and so I'd like them to apply for me because they think that they don't, they can't work at Google. And when they come and they see that we're willing to train you, that we're willing to bring you up, it is okay to not feel that you're gonna come into this job 100%. We've actually got a ton of really good candidates who have said to us like, I was worried because I come from not Rails, I come from Python or I come from whatever else. And that's been a massive benefit for us. And then my favorite, favorite, favorite part, our apprenticeship program. We realized that by learning to teach people, by learning to take somebody from not knowing the platform and have them know the platform, it actually opens us up for an entire extra set of candidates because these people who are juniors, sure I can teach them, but it also means that I could take a half step over here and take people who aren't even really at the space of being juniors. So we took two apprentices. They, to be blunt, they failed our technical interview because they were not up to our level of juniors. And we created a new job for them. And their job for six months was to learn our stack. And these are people who, we don't just take whoever fails a regular interview and put them in the apprenticeship. We took people who were twice the culture fit of everyone else.  And we hadn't been able to address that market before, and now we can. Because we can take the time to have these people and have all their mentors, they have two buddies, they have like three managers, they sit and they pair with everybody. And this is a just fantastic win on top of just being the right thing to do. And so this was the really big payoff for me in turning us into having the right culture. Every time I walk, I get static, which I think is why it's... So the danger, long-term payoffs are hard to measure, but the costs are immediately evident. You will always have to work to justify what you do. We started our apprenticeship program very, very slowly so that we could keep the costs low while we prove that it could be a thing. I would love to have ramped it up faster, but that's something we just have to pay attention to so that people don't question our credibility on the front. Nobody feels personally responsible anymore to push on the culture, which means the big danger at this point for it going away is just fading away. So that's something that we still have to pay attention to. The chaos, like I said, could be really painful and then losing the habit. So we are highly regulated. We had a situation at one point where literally half of our engineering staff were working on the same project and it was a half step above sleep and a half step below food, right? And so that's really tough to hold onto that habit. So I'm gonna give you a quick anecdote. I actually, between the time that I was accepted to this talk now, I quit Innova. And there's a reason, don't worry. This pays off, don't fret. So I did that because I wanted to go teach this kind of stuff to other organizations and because I was really confident in the culture. And on the day that I left, people actually came in and took over every single one of the things that I've been doing as a manager of internal learning. I'm not sure whether that position will continue to exist or not because at this point, even people who have only been in the field for four months feel empowered to take control and push out on the culture of the company. And that's something really powerful. And that's something that really says to me that we're doing the right thing. So my parting request to you, please do something. If you are interested in learning more at work, don't push it off to the CTO. Don't wait for somebody else to step into that thing. Just like pick something. Pick, go have coffee and a book club. Like pick something, just do it. That's it.


Live from New York, it's theCUBE, covering Inforum 2016, brought to you by Inforum. Now, here are your hosts, Dave Vellante and George Gilbert. Welcome back to New York City, everybody. We're here live at Inforum, Inforum 2016. This is theCUBE, SiliconANGLE's flagship product. We go out to the events, we extract the signal from the noise. Jonathan Lair is here, he's the managing director at Workbench, the New York City-based VC. Jonathan, welcome to theCUBE. Thanks for having me. So, first of all, tell us about your firm, Workbench, but especially your background. Love that story. Thanks so much. I'm a co-founder and managing director of Workbench. We're an enterprise-focused venture fund based here in New York. And really, the most differentiated value we bring is our deep corporate network, where if you think about early-stage enterprise startups, the most impactful thing you can do is connect them early and often with potential buyers. Everything from getting feedback out of the relationships to, hopefully, POCs. And beforehand, I was in the office of the CI at Morgan Stanley, where we would meet hundreds of startups here on behalf of the firm to see which solve pain points internally. And then for those that did, we would help them navigate the procurement process and get onboarded. And you were saying that you observed the shift in your work, in your stack. Your stack was transforming. How? And in what ways? Sure, so I was very fortunate to have that role at Morgan Stanley because banks annually spend about 62 billion dollars on IT and they tend to be the earliest adopters of new tech due to competitive pressures and whatnot. And in my role at Morgan, I saw firsthand really the way that startups were able to find use cases that legacy vendors weren't able to solve. Take any buzzword out there, whether it's big data, cloud mobility, security, et cetera. The paradigm had shifted while I was there. And if you needed to process more data, let's say, a lot of the legacy vendors just choked up and they were too expensive. So it created an opportunity for new vendors to come in targeting really specific use cases where they could showcase how they could do things better, faster, cheaper, and then the bank would end up adopting that tech and working with them. So you mentioned something in there that sort of caught my interest. Big data. From what we understand, a lot of the big banks put down, say, 10 or 12 node pilots of Hadoop. And it took a lot of skills to get going. What were some of the key use cases that put them into production? And now, how are they evaluating what to do on premise and what to do in the cloud? Sure, so there's a few questions. They're number one, I would say, when we were first looking at Hadoop and now as the banks continue to look at things like Spark, like Goldman is pretty active in, and I think even speaks at Spark Summit, for instance. It's really about starting with the use case, which is the very New York-centric point of view. Hadoop and all these other technologies are very interesting and have a lot of potential, but realize from a bank's perspective, they spend a lot on existing infrastructure. They're locked into certain contracts. They have employees with certain expertise, so the way we had went through it at Morgan, and I'm sure most of the banks do, is what are the use cases where we're struggling, or this can shine and really let us do things that we couldn't do historically? I can't comment on what use cases in particular got things to production, but it was really understanding where do your legacy, really, data processing methods and data storage ways not necessarily scale to meet your needs, or not even let you do some sort of analysis that you wanted to do. Now, in terms of things like working on-prem versus the cloud, a lot of it has to do with data, in terms of is it PII, is it public data, is it customer data, whatnot? And from there, these days, the banks are getting a lot flexible, and I think the rest of the 421,000 is following suit, where it's kind of understood as this is where the world is going. We have to make it work, and for folks even without regulatory compliance needs, they're getting a lot of extra power out of it, being able to work in the cloud. So we obviously have a presence, SiliconANGLE in Palo Alto, John Furrier's out there, spends a lot of time at the Rosewood Thursday nights. That's where all the VCs hang out, but New York, notably, has really come of age in the VC world over the last decade, far surpassed Boston, which used to be pretty competitive. What kind of startups are coming out of New York, and how has New York been able to compete so effectively in tech? Sure, so since we're out in forum, I'll focus really on the enterprise ecosystem here, which if you think back really to 2012, as MongoDB was really growing and getting a lot of emphasis on the ecosystem, as you had Buddy Media get acquired by Salesforce, those were some of the early data points that showed that we have some potential here. And now fast forward to 2016, we have over $2 billion in aggregate in VC funding for just our enterprise startups in New York, which is a great number. And that includes areas across infrastructure, data analytics, things within AI, security starting to creep up here, and it's really an amazing ecosystem. And what I think makes us most unique is that you compare both top-notch technical talent, but also with domain expertise. So whether it's someone like X.AI or Kazisto, which are playing really in the AI trend going on, with X.AI focusing on really enabling automated meeting scheduling, Kazisto offering a digital assistant for your banking app, both of them were able to leverage really Columbia, NYU and other talent here in data science, but pair that with domain expertise. Another big trend that we have going on here is actually infrastructure. So we've had a lot of web-scale companies here, whether it's everyone from AppNexus, the big ad tech company here, Tumblr, Etsy Square, Google and Twitter opened engineering outposts here, and we're starting to see those folks kind of leave those past lives and see that with this web-scale experience, they can actually solve enterprise use cases. So it's been amazing if you look at a company like Cockroach Labs to see a 25-person company just in New York City, fully based here, solving an amazingly difficult challenge for databases to basically bring a Google Spanner to the masses. And interesting, Google Spanner is a whole another conversation. But so you mentioned two companies off camera, V-Armor and Tamer, those two companies that you help fund, right? Is that correct? Yes, so at Workbench we invest across the country and we also have a physical workspace to grow the community in New York, which we can touch on in a second. But if we think about companies like V-Armor and Tamer, they're solving massive pain points for the enterprise. If you look at V-Armor right now, if we could say the last couple of years were the year of CASB, this year really is focused on cloud infrastructure security and V-Armor is the leader in the pack led by the CEO Tim Eads. And what they're able to do for highly virtualized environments in terms of really the visibility and then the protection through micro-segmentation, it enables unparalleled ways to protect your enterprise and specifically the data they're in. And if we then look at Tamer, they're taking a problem that you couldn't even throw enough humans at, which is really around data aggregation, data cleanup, data cataloging, and they're enabling big companies to save millions of dollars by aggregating business cross data silos and then having that unified view can now run analytics on it. So one of their great use cases has been around procurement to enable a unified view of all your suppliers and then figure out where do you have redundancies where you can cut costs. So it's been an amazing time in the enterprise right now. So what's the funding climate like? I know, again, the West Coast, B rounds are getting tougher, money's getting a little tight, VCs are a little nervous, maybe not publicly, but privately. What's the climate like, the sentiment like in New York City? Sure, so maybe it's heresy to say but we're actually excited by that because the tightening of the belts on the VC side means that there's going to be really a flight to quality. But if you look from the enterprise side, as I just mentioned from my background at Morgan Stanley, there is about, if you look at Forrester, $700 billion a year in software spend, right? Gartner pumps that number up even higher. There's unprecedented disruption across these stacks where these large corporates need these new technology solutions to keep their businesses running, right? Fortune 1000 isn't going to disappear tomorrow. So there's this huge opportunity where for the best companies, they're going to break through the noise. And actually, in my opinion, having less me too means that the leaders can be able to hire easier without having to compete for talent as much. So from our perspective, it actually is healthy for the ecosystem. So, Jonathan, let's put this in the context of Infor for a minute. Yep. One of their big initiatives is predictive analytics. Another is, you know, Internet of Things are really more the industrial Internet of Things. What do you see growing up in the ecosystem and how do you see that being applied to enterprise application vendors if they are the primary channel for these new technologies to get into established enterprises? Sure, so if we start with predictive analytics, I think that there's a huge need to really empower people beyond IT, right? And predictive analytic built applications that come in with really a pre-built focus, have had their algorithms tuned to unique use cases, enable business people to really get to work and be more productive leveraging that. So whether it's a startup or Infor doing it for an industrial client, I think that's actually a huge opportunity right now. If we look at industrial Internet of Things, it's still in its nancy, which is healthy, of course, for an ecosystem, but things like even what standards will be, how we're going to view use cases internally and how infrastructure investments will be made, right?  So I think there's an opportunity here for both startups to do some cutting edge work around streaming data and security for IoT, but there's also place for a lot of big tech companies here to step up and really develop stacks that will enable things to be built off them. Yeah, the disruption is amazing. I think you also invested in CoreOS, if I'm correct, right? So you're obviously seeing a lot of innovation in that space. VMware certainly changed server virtualization, hasn't been able to apply that to application containers and so forth, which have been around forever, but now you're starting to see this whole DevOps culture emerge in a new way. Maybe talk about that a little bit. Yeah, so if we back up at a higher level to quote Alex Polvi to CEO of CoreOS, there's really a trend called GIFI, which is Google infrastructure for everyone else. They face the biggest data challenges. The hardest core processing needs, right? The most distributed applications and that expertise now folks have since left Google and people are trying to mimic that for the masses. So CoreOS is a wonderful example where they're working closely and commercializing Kubernetes, which is Google's open source technology for really running and orchestrating containers. And we think that Alex and the team are really poised to do this well because unlike some of their competitors, they started with security focus from day one. So when they talk about their tectonic stack, which is really an end-to-end solution for a corporation to leverage everything from microservices to containers and really enable a more agile developer base, CoreOS is really leading the pack and doing a wonderful job. You think Docker would be more challenged to sort of bolt on security? So I think that everyone's realizing that security is going to be key for enterprise adoption. Docker is of course a wonderful company. They've been really more focused on the developers to date and a few weeks ago they released a swarm kid, which really is kind of their play against Kubernetes and messos. So look, it's a huge market. We're in a once in a decade ship to be the next VMware. So I think there's a lot of room out there but we obviously put our chips behind CoreOS and what they're doing for Kubernetes adoption. Yeah, we've had those guys on and Alex has actually been on the queue before and doing some cool stuff. And like you said, the market is just so enormous. The ecosystems are just exploding now. You're seeing a huge focus on developers. Talk about developer leverage and the importance of developers from a startup's perspective. Sure, so I think that whether you're a startup or a corporate, developers kind of rule the world now. I have a friend, Lenny Pruss at Redpoint that actively blogs about this and really what's going on is developers kind of used to be the second class citizen, right? And you would talk about bottoms up adoption and really kind of maybe not think it could happen but look at Twilio's recent IPO, right? A purely developer driven company. It showed how big businesses can be built in this space. And for our perspective, when we were talking I actually spoke at CoreOS's summit here back in December up on stage talking about adoption of containers. And when I had Goldman and B of A on stage what really blew my mind versus my Morgan Stanley days is in the past it was let's talk about TCO, let's talk about ROI and what money are you tangibly saving? The name of the game now is really about agility. It's around collaboration between developers. It's really about being able to get things done quicker and smoother and really look at the end of the day all these banks like to call themselves software companies. The broader Fortune 1000 likes to say we're big startups trying to move quickly. If they're going to do so they need to enable their developers to lead the charge. We make a Facebook and what's going on inside of Facebook both with applications, media. You know a lot of talk about Facebook basically taking over the media world. How does a firm like yours look at Facebook? Sure, so candidly I think we're a little bit shielded and it's a little bit outside our purview. What we look at from Facebook is things like the open compute project and all of their amazing open source contributions to the broader ecosystem. When you have a focus on things like media and bias I mean you catch me for a beer and that's a very interesting conversation to have around are we going to be subliminally messaged to think one way versus the other and what happens with media. But really from our perspective it's about their world-class engineers and looking at some of the challenges that they face. What are they solving and what's the applicability of some of those challenges to the broader 420,000 community. As opposed to Facebook as a competitor to the software startups. That's not our future. I wouldn't treat it as such. I think that Facebook really and Google and Amazon are all kind of competing in different ways across everything from advertising to if you look at Google versus Amazon now in the hosting world and things like that. But none of our folks maybe you could say Slack is competing with Facebook's for work concept but I don't know anyone who's really been putting a big push behind the Facebook for work. So it's really interesting that you talk about sort of the Googles spinning out engineers who then build software for the enterprise. And we've talked about here and elsewhere developers sort of ruling the universe and every startup says their strategy is land and expand. So they don't have the capital intensity of building up a data center and they say we're going to go essentially viral so we don't need a big expensive sales force. But has any startup actually really hit scale without having a sales force to take developer adoption and take it across the enterprise? So I think that a lot of people who would naively say land and expand you can build huge companies off that unless you're in Atlassian which kind of successfully did that. And the reason they get so much attention is because I think they're the only ones that have successfully pulled that off. Really it's a function of for the early days in your company life cycle when you're targeting maybe individual teams you could have a small sales team or you could go bottoms up if you're selling a developer tool but it's really focused on what's the right go to market approach for your company. So a database company is going to want to go bottoms up through developers if you're selling a BI tool maybe it'll go top down if it's going to be used organization wide or at least go to the team heads. And what I think has happened in IT is we've really had a big shift where over the last five years we've moved from CIOs making purchase decisions to really now it being line of business heads. So we've seen a lot of companies successfully attack those people who actually control large budget dollars. But with our New York centric point of view and really understanding how the enterprise works I think it's naive to say only relying on land and expand for the most part. That's interesting you say Atlassian is really the only example I mean do you not consider that too big like a Splunk or a Tableau certainly service now has succeeded with that. So maybe early days they did that but look I knew all those sales guys when I was at Morgan Stanley right to land the banks you needed. I'm talking really all the banks were using Atlassian and didn't really have dedicated sales people. Of course as you get bigger you need the support capability but I would say yes Splunk is a good example in the early days that did a lot more of that but it can't be your only strategy you will need enterprise sales teams to help navigate those organizations Excellent, Johnathan we're out of time but that's really great story. I'll give you the last word Inforum your relationship with Infor happening in New York City close it. Yeah so we're talking here about New York and great going on. It's amazing that such a multi-billion dollar tech company fully behind if you look over there the cameras can't catch it but we've partnered with them on a startup alley to showcase some of New York's best startups both work bench companies as well as the broader ecosystem and it's amazing that they've been so forward thinking to connect them with their 8,000 customers that are in attendance and really led by Charles to make this a place where we can have amazing technical talent in New York and great things happening. So it's great to have them here. Johnathan thanks very much for coming on theCUBE and sharing workbench's story. Thanks. All right keep it right there everybody we'll be back with our next guest is theCUBE we're live from New York City we'll be right back. Thanks. Sometimes losing a value to


And the chief of army staff, Lieutenant-General Farouk Yahya, has called on Kassina residents to assist security agencies with correct information on criminals. He made the call on Friday when he paid homage to the emir of Daorah, Al-Haji Umar Farouk at his palace in Daorah. He said providing such information would help in tackling insecurity in their areas. According to him, the criminals were members of the society who mingled with people in the market and other places. Therefore, it will not be difficult for the people to provide security agencies with correct information about them and their hideouts in the communities. The issue of security is not a one-man business, Yahya said. He adds that the army is also collaborating with other sister agencies in tackling the security challenges.


If I were to ask you what Breath of the Wild's most divisive in-game feature was, I'm sure most people would talk about how there is an item breaking system, the weapon durability, and maybe not even that you hate the durability, but there's no way to even repair your weapons outside of some core unbreakable weapons that you get from each territory, but outside of that, yeah, the weapons break and some of your favorite weapons you're sometimes afraid to use because you don't want to lose them, especially if it was really difficult to obtain a certain weapon. Well, what's interesting is that's not apparently what games radar writer Joe Donnelly, we're going to say writer, I don't know that this is the opinion of everyone at games radar, but they put up an article that I wanted to check out because they're talking about Tears of the Kingdom, and they're talking about how they want something to be different, how they want to try something different, and how they want Tears of the Kingdom to be different. It says Zelda Tears of the Kingdom looks ace, but I hope it drops Breath of the Wild's most divisive feature. You read that title, you start thinking they're talking about weapon durability, something that's been a topic of conversation for five or six years, but they're not. They're talking about climbing mechanics, and I want to go through this article with you guys and discuss it and give you maybe some counter points of what they're thinking because I think the climbing mechanic is one of the most brilliant things added to Breath of the Wild. So we're going to talk about this. We already know this is coming to Tears of the Kingdom. It's a feature that's already been featured, and they do mention that in this article. That being said, before we get into it, I want to remind you that our video and our channel is sponsored by EWIN Racing. EWIN Racing has amazing chairs for all types and sizes of people, from the little to the big to the super skinny to the overweight, the short to the tall. They got something for everybody, and they have a New Year's sale going on right now for 20% off. You can also use our code Nintendo Prime at checkout for 20% off as well. Either one of these will work. You get 20% off either way, and yeah, just check them out through the link down in the description. Alright, so as you're seeing here, it says, Zell of Tears of the Kingdom looks ace, but I hope it drops Breath of the Wild's most divisive feature. The latest Zell of Tears of the Kingdom trailer doesn't give too much away. One old mechanic has seemingly returned. I think it's a core mechanic to Breath of the Wild, but there we go. After 42 seconds of relative silent and a peaceful camera work panning and tilting around a network of sacred wall carvings, the Legend of Zell of Tears of the Kingdom announced itself to the world in a flash. The latest trailer for the much anticipated Breath of the Wild sequel, now with a new confirmed name, Should Link heaving upon two massive doors of crumbling stone before pegging it towards a sun-soaked ledge beyond which floating islands lined with golden trees stretched off into the distance. Without pause, the plucky protagonist thrust himself overboard with a form-perfect swan dive before we were shown the snippets of some of the stuff we'll be up to in the new Zell of the Game. This is, in essence, Breath of the Wild 2 in all but name due on May 12, 2023 for the Nintendo Switch. As revealed during September's Nintendo Direct with what looks like two separate planes to explore, one in the sky and another thousands of meters below, shouldering five years worth of hype since Zell's last outing, three since this game's first tease at E3 2019. Man, a lot of verbal garbage here. Look, I like to describe things as well, but a lot of verbal garbage here. Anyways, I'm excited to see how Nintendo goes even bigger than Breath of the Wild here, with hang gliding and skydiving, floating rock platforming, and the first proper sense of scale between the lower and higher reaches of this game world. There's definitely plenty to shout about from the latest trailer. But much to my dismay, one of the biggest bugbears from the previous game looks unchanged. Get a grip. Let's cut to the chase. Climbing in Breath of the Wilds is pants. I don't even... Pants are something we wear, right? Does pants have an alternative meaning I'm not aware of? As I kept reading this article earlier today, I started to understand when he meant my pants. But when did pants become something other than something that we wear? Anyways, there's just no two ways about it. An arbitrary stamina bar. A feature first introduced to action RPGs in the mid-1990s, also introduced in Skyward Sword for Zelda, but hey, what am I gonna... Let's not mention Zelda. Governs how far you can go in any direction. Before, once the bar is emptied, you lose your grip and plummet to the next flat surface, and you're untimely death in an instant, or you can have food or there's certain armor you can get that lets you climb even further. Let's not talk about all the mechanics behind climbing in Breath of the Wild. Let's just focus on one. Anyways, and again, there's so forward thinking in so many ways. One that puts exploration so front and center in both its narrative and moment to moment discovery, this throwback to such an archaic, awkwardly executed mechanic for me really puts a damper on the free-wheeling nature of Breath of the Wild as a whole. Stamina bars are a staple of the ARPG genre, of course, from Skyrim to Dark Souls, Neo to Elden Ring, but the restrictions they otherwise impose on combat and, say, sprinting from enemies feels less forced. Because in these moments, you're managing stamina as a depleting resource and you're not doing that while climbing. I mean, it's more realistic, I think, to have stamina while climbing because people can't climb forever before they fall. There's a reason most of us can't climb to the top of a rock wall. Like, it's not easy. It's pretty tiring. Even the world's most professional rock climbers out there will tell you it's a very tiring thing and there's some mountains they can't climb. Like, it's not easy. Anyways, that's another error there. I guess it doesn't matter that it takes a lot of stamina to actually climb in real life. You're working to overcome the loss of a commodity on the fly in order to succeed, which you are also doing with climbing. Anyways, ultimately, in these moments, you're being judged on how you play and how it plays you and you're being judged on how you chose and what you chose to climb and the way in which you're doing it. It's very, very similar to combat, but that's neither here nor there because to you it's not. Obviously, this is an opinion piece. So his opinion can't be wrong for his preferences, of course. All right, during tears of the kingdom's newest trailer, we do see Link climbing in various vertical structures, hauling himself up and down with the same labored weight shifting animations from the previous game. There's no sign of the dreaded stamina bar granted. But given the fact there's also no visible HUD throughout the trailers and entirety, my guess at this stage is that climbing is like for like this time around, probably it's a direct sequel. Yeah, they're probably going to use stamina and we'll have ways to increase our stamina like we did in the first game. All right, high rule. I realize I might sound like a grumpy old man here, but my reason for coming down so hard on this facet of Breath of the Wild, which is why they consider one of the most brilliant additions to exploration in a game is because it's so, so capable elsewhere. GameRadarPlus doesn't hand out five star reviews without good reason. And I suspect we'll be having similar conversations about tears of the kingdom when it launches in May of next year. Breath of the Wild's constantly breaking weapons are another of its most divisive features. And while I'm still on the fence about whether I love them or hate them to mark its fifth anniversary earlier this year, reminder, this article is written about September of last year. I wrote about how Zelda Breath of the Wild broke the mold and by me, by breaking its weapons, this design decision shook up the ARPG formula enough to earn my respect. Unlike Fallout 4, The Witcher 3 and a vast majority of other open world games that leverage talent trees and familiar role playing gimmicks. Breath of the Wild drops leveling up entirely. I mean, you could argue, increasing your hearts and stamina is a form of leveling up, but I hear you. Instead, in order to balance progression and difficulty, the durability of weapons plus the finite number of weapons we can carry at once puts a precise cap on how much damage we can deal at any given time. In practice, we therefore find ourselves constantly tossing away weaker arms as we discover new ones. And only by doing that can we hope to overcome the game's toughest baddies. Also, just pure skill. You can, with a tree branch, go ahead and head off to Ganon right away and and defeat Calamity. I'm just I'm just pointing out that there's a lot of skill involved with the combat in Breath of the Wild, which was very much appreciated. Something I'm not accustomed to seeing really since Zelda 2. Zelda 2 had a lot of skill in its combat, but anyways. The latest Tears of the Kingdom trailer admittedly doesn't show any bouts of combat, but I'd be happy enough with the return of perishable weapons. So this person likes durability. OK, cool. So as long as they are equally intertwined with exploration and discovery as per Breath of the Wild, stamina, tied traversal, on the other hand, can do one. Don't get me wrong. I'm proper excited about Tears of the Kingdom. I fully expected to feature on the Game of the Year list in 2023. Well, definitely climb in my own estimations. If it ditches, what I reckon is its forerunners, most frustrating and most outdated mechanic. And this is what I find really fascinating. Climbing anywhere is not a common mechanic in open world games. To be clear, Assassin's Creed has the ability to climb a lot of places, even in its open world nature, especially in towns. But oftentimes you can't just climb anything, anywhere, any time. And for the most part, outside of very specific surfaces, like inside shrines and obviously when it's raining, you can climb pretty much anything in Breath of the Wild. In fact, it was one of its most revolutionary exploration tactics in comparison to other games in the well, action, RPG, action, adventure, open world genre, right? It is very, very much at the core fundamental exploration level of the game and the stamina meter plays a huge role in that, not just in terms of, you know, your traversal climbing up, also your traversal in terms of using the sailcloth, other mechanics in the game like the slowdown when you're shooting arrows. It is so fundamental to the core of how this game, like Breath of the Wild functions, what he's essentially asking isn't to completely get rid of stamina, like let stamina exist when you're running away from enemies. Let stamina exist when you're shooting your arrows in slow motion. He's not asking for that to be gone. He doesn't want stamina to be used when climbing because he just wants to be able to freely climb anywhere all the time without restriction. And that is so fundamentally flawed to the way Breath of the Wild works, because everything in Breath of the Wild has its limits. The weapon durability has its limits. Even when you get the Master Sword, guess what? It has its limits. There are limits to everything in this game. Even the ancient armor, the limits is how many rupees you have. There are limits to everything. And to get rid of one of the core fundamental limits in the game really just breaks the way the game's intended to work. Climbing works the way the rest of the game does. There is a form of exploration here where you are rewarded for thinking ahead. He wants Tears of the Kingdom to be dumbed down. That's the way this article comes off to me.  It's archaic because, you know, climbing and stamina totally don't make sense together. Right? I'm like, if you want to think of me as talking about weapon durability, I understand how divisive that is. And I can make similar arguments for weapon durability, how it's actually a core of the game, but he actually likes weapon durability. So since he likes weapon durability, he's got to find something to nitpick in. For him, it's climbing. I get it. It's his personal opinion. No matter what I say, it's not going to change this writer's personal opinion. But it just bothers me. It just bothers me that somebody wants one of the core things that made Breath of the Wild what it is to change in a way that, in my opinion, sort of lessens how important climbing is. Without stamina affecting climbing, just the ability to climb all the time, infinitely, it fundamentally changes my approach to exploration in the game. And maybe I'm alone in this.  But to me, I found it to be enthralling. It gave you reasons to progress, reasons to increase your stamina bar, reasons to find the extra climbing clothes that make you climb a little bit faster, reasons to cook up stamina food. There are so many counters to this issue. But that's because the game makes you think and I don't want thinking to be gone. Okay, if I'm trying to climb something and I made a mistake and estimated how much stamina I have to make this climb and I was wrong and I didn't map out my climb better. I want to be punished for making that mistake. I don't want to be rewarded by just allowing me to freely climb anything everywhere like Assassin's Creed and even Assassin's Creed has limitations. Like in Assassin's Creed, there's not stamina when you're climbing things, but you can't climb everything. Press of the wild, you can. Even surfaces that make no sense to climb. So, look, I can't disagree with this article any more than the spot. Like when I saw this article pop up in my feet today randomly and I know it's from last year, I couldn't believe what I was reading. It is mind boggling to me. But you know what, maybe you agree. Let me down on the console. Do you agree with me? Do you agree with the author here? Just for full context, this is from GamesRadar and the author is Joe Donnelly. It was published back on September 14th of 2022. Its publication date is a little bit irrelevant, other than obviously noting that it was in a reaction to the Nintendo Direct. That reaction probably doesn't change today. The person that like climbing the last five years in Breath of the Wild. They're not going to suddenly change their mind when we haven't even seen anything else in the game. So you guys, I'm going to think about this down in the comments below. Had a little nice voice over gameplay video to kick off your day today. We'll get back to some normal content a bit later today.  Thank you so much for tuning in and I'll catch you in the next video.