 I know some folks in here, if you don't know who I am, my name is Steve Greenberg. About a year ago, a little over a year ago, I founded a company called Resilient Scale. And we're going to talk today about growing your Cloud Foundry organizations. My goal for this session is to talk a little bit about some of the challenges, but also how we advise our customers on effectively growing their organizations, because it's actually a bit of a big challenge. I'll try to talk slow. I don't speak German. Apologize for that. But we do have a lot to cover. So how many people have actually seen the developer report from the Cloud Foundry Foundation that they put out in November of last year? Anybody? One. Wow, OK. It's available on cloudfoundry.org. And I highly recommend everybody go take a look at it. This report is aimed at looking at the developer market and talking about the state of that market. A lot of what we're seeing is actually the challenges that were highlighted in this report. The first thing that I want to talk about is 64% of the respondents for that report said that there is a real shortage of developers. And not only is there a real shortage, but it's a threat to their business. So think about that for a second. 64% of the respondents not only said there's a shortage of developers out in the market, but that that's actually threatening their ability to deliver business. Of those, 57% have said that they've already been impacted. They're having problems finding skilled people. Those are kind of scary numbers, right? I wanted to understand this a little bit more. And so I did a bit of an informal kind of experiment. And what I did is during one of our two-week customer engagements, I just started to make a list of all the things that came up. And I wasn't very diligent about this. But I started to make a list. And the first thing on that list was Cloud Foundry, because most of what we talk about is Cloud Foundry, right? But as I started to make that list, more and more things started to pop up. Actually, a lot of things started to pop up over this two-week period. And I'm sure there's tons of things that I missed. But these are all things that came up in the context of a two-week training around Cloud Foundry. It's kind of scary when you look at it, right? That is a massive mountain of information to try to keep a mental model of. And all we're doing is talking about Cloud Foundry. That's kind of scary. That tells us something, though, right? When we actually put that together, sorry, my clicker's not working. It tells us that hiring is actually extremely competitive. There's not enough developers out there, and how many of those developers can keep that mental model in their head? I know I struggle with it. I can't answer every question about all of those things. That's a really significant challenge. Sorry, I'm having problems with this thing. And what that means is that we really have to look within. We have to look to scale and build our existing teams. It's the only way. If you open 50 RECs for Cloud Foundry developers, how long do you think it's gonna take you to fill those? A long time, right? We have to use the resources that we have. Hiring's important, but it's not gonna be a way to effectively scale your organization in the short term. If we go back to this developer report, they said that training's the answer. My company does a lot of training. And I'm here to tell you that if you think training is the answer, you're probably wrong. It's an important aspect, but it's not the most important aspect. If you just go out and sign up for a class and think that that's gonna solve your problem, it's not. Culture is the answer. Establishing the right culture is the only way that you're gonna effectively grow a Cloud Foundry organization. And we'll talk about that a little bit. There's a reality here. Cloud Foundry's not a magic pill. I can take Cloud Foundry and I can do horrible things with it. I can be completely ineffective. There is no tool out there that will fix your broken culture. I don't care what that tool is, Cloud Foundry doesn't fix it. So again, my company does a lot of training. But if you don't address the cultural issues and the cultural aspects, everything that you do will be a waste of time and a waste of heartbeats, a waste of money. And I would actually encourage you to just not even try. So let's talk a little bit about how we advise our customers on building their Cloud Native organizations. Kind of broken it down into five things. You've gotta get going. Starting small is important. Cultural change across organizations is extremely, extremely difficult. I've seen customers go out and say, we're gonna take on 10 different projects all at once and what do you think happens? They can't enforce the culture and ultimately those projects end up failing. So we wanna start small because we can control small environments. It's really important that we also have the right goals. Have the right goals when you start with a small team. So I've seen a lot of companies have goals like, we're gonna train 200 engineers in Cloud Foundry. Well, that's a vanity goal. Why? Why are you training 200 engineers? It might be good for marketing. Even if you're a systems integrator, might be good to tell your customers we've got 200 engineers. It'd be a heck of a lot better if you actually had projects for those engineers. If you think that's a good reason to try to build a Cloud Foundry org, you're probably gonna fail at it. We want impactful goals. We wanna build something real, build a real feature, do something useful for your business or for your customers. It doesn't matter whether you're a systems integrator or you're an end user. So we wanna start small and we wanna have the right goals. Impactful goals are measurable. You have to be measuring these things. Your goal is to scale and that means that you're gonna need to talk to a lot of people about what's happening and what you're doing. And you want empirical evidence that shows how fast things are happening, how much you're achieving. Our goals have to be demonstrable. We have to be able to build something that we can demonstrate and show. It might be, hey, we had an idea on Monday. We got it in the user's hands on Friday. That's a measurable, demonstrative thing. And that's really, really important. And you'd be surprised how many customers overlook this. And then lastly, we need this thing to be useful. It should impact your business. Don't pick some pet project that nobody's ever gonna see or use because it's not gonna help you when you're making the case to actually scale your organizations. So start small, understand your goals and most importantly, control the culture. In a small organization, you get to set the culture and you should be able to create a little bit of an island around everybody working on those teams with the right culture. This talk isn't about what that culture should be but hopefully enough of you know what some of those things are. Creating a blameless culture, having transparency, having cross-functional teams. These are a lot easier to do when you start small and you have a well-defined goal that impacts your business. It's critical that you control your culture from the start. Hopefully everybody knows who Grace Hopper is but I love this quote from her. I think it's one of the most important quotes in computing, the most dangerous phrase in the language is we've always done things this way. Won't work. It won't work with Cloud Foundry and it won't work in Cloud Native. So control your culture. Then you can assemble the right team. This is pretty critical too, right? We can't take who's actually gonna be involved lightly. These are challenging things. So think back to that big mountain of information that comes up in the context or topics that come up in the context of Cloud Foundry. Things are gonna go wrong. We're gonna make bad decisions. We're gonna have to learn a lot. We need people that are empathetic. Empathy is probably the most critical thing that your initial team members can have. If they start pointing fingers at each other when things go wrong, they're gonna take the entire project down. You obviously know there's a lot to learn. It's a lot of new things and a lot of new features. We need people with aptitude. We need people that wanna learn. If they don't wanna learn, they shouldn't be on your team. I don't know everything in that mountain picture. I don't know if there's anybody in this room that would confidently raise their hand and say they do. We need to be able to learn and think and reason. And the last thing is try to create a diverse team. Teams that are made up of all the same people have one perspective. The chances of having one perspective and interpreting requirements correctly and building the right thing is very small. And actually diversity is really important even in small teams because we need those varied perspectives. We need to be able to challenge each other and build the right thing. If we don't build the right thing, it's not useful. If it's not useful, you're never gonna scale. So how many people were involved in Cloud Foundry before Pivotal was even formed when it was still in VMware? Anybody? Oh yeah. So two, think about the people at Pivotal Labs that took over Cloud Foundry from VMware when you start thinking about your team. They were given a project that they didn't write, that they didn't use, that they didn't know anything about. And they had to learn all about it and they had to build it and support it. And think about it in the context of those values. Those are the types of people that you need in your organization and on your team. So start small, understand the right goals, control your culture and assemble the right team. We good? Okay. Sorry, I have to keep walking over here because this doesn't seem to work. Education is actually important. My statements about that report initially are not that training's not important, but it's important in the context of everything else in the culture. We think back to the mountain and there's a lot to learn. And if you were gonna take your engineers and send them to a class for each thing on this list, you'd probably be in training full time for at least five years. And you'd come out of that training and you probably wouldn't know anything, right? Because you wouldn't remember, because keeping a mental model of this is really challenging. So we need to pick and choose what we're educating on and we need to maximize the effectiveness of that training. So how do we do that? The first thing is that concepts in context actually matter. Developers have to make decisions. You have to be able to reason over that mountain of things. And in order to do that, you have to understand things that are beyond the bounds of cloud foundry. If you just understand I can do CF push, you're not gonna write a very good app. I'll give you an example, kind of contrived example of the aviation industry. If I'm sitting in the cockpit of a commercial airliner and I grab the yoke and I turn it left, the plane goes left. Is that all I wanna teach my pilots? I hope not, right? They need to know about what the aircraft is doing and the mechanical systems and the flight surfaces. They need to know about physics. Why? Because it helps them make better decisions. If I know a little bit about how apps are staged and how apps are run in cloud foundry, I can make better decisions about my apps and I can build better apps. It's pretty simple. In order to do that, I need context so that I can reason and understand. When you're looking at training, the experiences that you have in the classroom matter. It's funny because some people actually in here have trained. So the experiences matter because we're creating a controlled environment. And we wanna train people in a way where they can learn without the risk of failure. How many people have gone to training classes where all of the exercises were cut and paste and you could literally cut and paste everything and do everything in the class? Is that useful? It's not useful. It's not useful because you don't actually learn anything. You need to be looking things up. You need to have things crafted appropriately and keeping with that aviation theme, that's the whole purpose of having flight simulators, right? You crash? Fine. We've removed the risk of failure, but we've created as realistic of a scenario as possible. And we've given them a safe environment to go through that in. So context matters and our experiences in the classroom matter. This one's overlooked a lot and I know this is gonna be a little controversial but who you learn from matters. Do you wanna learn from practitioners that know what they're doing or do you wanna learn from somebody that learned a script? Do you wanna learn from people that actually know, right? Because it's a lot of things to keep track of in your mind. So again, keeping with the aviation theme, if I'm gonna go learn to fly a fighter jet, do I wanna learn from Lieutenant Colonel Christine Mao, a highly decorated US Air Force officer, the first female to ever fly the F-35, or do I wanna learn from an actor? Think about that when you're figuring out who's actually training your people. Have you done it? Have you written code? Do you actually use Cloud Foundry? Have you used it in production? There's a lot of people and a lot of companies that do training that don't take this into account. I don't wanna go learn from Tom Cruise, I'm sorry. The last thing I'll say about training is don't train without real work. If you send a whole bunch of people to a class and you don't even have a pipeline of work for them to do, what are the chances that they're actually gonna remember what they learned? It's pretty small. They need real work. Training is just the beginning. The rest of the education comes from on the job. So they need a job to go do that relates to these things. You've educated them, you need to support them. I hope a lot of people in this room know who Adrian Kockroft is if you don't. He's over at AWS right now. But he was actually instrumental in starting and getting Netflix really going, right? And getting their online streaming service going. And he had a quote that I think sums this up perfectly. You can get many, many times more out of a good senior engineer by getting behind them and pushing instead of getting in front of them and getting in their way. And you think about culture changes and process changes, this is at the heart. So how do we do that? I highly encourage you to make it a priority to be involved in the community. When you're first getting started, who do you think your support structure is gonna be? It's gonna be the people sitting around you. It's gonna be the community. They're gonna be the experts and you're gonna have to go and ask them questions. It's really important to get involved in the community but also give back because then you actually start to actually learn more by teaching the next set of people. We've got a great community here. And it's important that you dedicate time for that. The other thing that's important is constant improvement. I've seen too many customers have a knee-jerk reaction to a bug going into production, to a bad decision being made on the interpretation of a requirement. And their response is always to start introducing a process. And process creep is a real thing. Constant improvement is about what happens when things go wrong. Constant improvement is critical to your team's success. So I'll tell you a little bit of a story here. Some of you know this story but when I started, I actually used to work for Pivotal. When I started at Pivotal, I spent the first two months in San Francisco working on Cloud Foundry. And I didn't know anything about Ruby at the time and what was going on with these projects. But they had a very early customer that had a bug, had a problem, couldn't figure out what was going on in financial services. And in most of my career, that would have resulted in a lot of meetings and a lot of finger-pointing. And that's counterproductive. What happened was a question, right? How many people might have worked on this? Who might know what was actually going on? We went around, figured out who those people were, all sat down in a room, looked at the problem, figured out what the problem was, wrote a test, implemented the solution, shipped it to the customer, took less than two hours. That's a culture of constant improvement, right? You gotta fight the urge to introduce process just because things go wrong. The other thing that you need to do is measure and report appropriately. And appropriately is a key word here. I've seen too many projects and too many customers where they do things like measure lines of code, number of commits and git, how many bugs the developer introduces. All of those things have negative impacts on the output of your developers, right? But the reality is you're trying to scale your organization. So you're gonna have to talk about these things. So you need to measure the right things. The things that show off what you're doing. Things like how long did it take when I came up with a new idea till I got it into a user's hands. How long did it take me to fix that bug? Was it two hours or were we too busy fighting? Those are good measurements. Those are real measurements that will help you as you make the case to scale your organizations. And you're gonna have to make that case. So you wanna take those measurements and you wanna publicize those achievements. But it's not just about the achievements and it's not about bragging. It's about being ready to start answering questions. Because if you have a small group that's being effective in your organization, the rest of the organization's gonna start looking around and noticing. And you wanna be able to empirically answer them. But you also have to talk about the culture and you have to talk about the challenges and how you overcame them. Nobody thinks this is gonna be perfect. It's not. It's impossible to run a project with zero issues. But how you respond to those challenges and how you respond to those issues is what matters. The good news is that people flock to cool projects and good culture. It's in their nature. If you're a developer, you wanna work on something that's impactful and work in a good environment where you can just impact the business and do something good. So if you're measuring these things and you're able to talk about these things, the good people in your organization are gonna start putting their hands up and saying, hey, I wanna do that too. Think about how many people actually apply to work at places like Google and Netflix and why that is and this is why. When it comes to hiring, whether you're hiring internally or externally, you need to be careful because hiring the wrong person is more damaging than not hiring. It'd be better to be late on a commitment than to have the wrong person. I think we've probably all heard the old adage that One Rotten Apple spoils the bunch. It's very true of cloud-native organizations. So I'm gonna divert a little bit here and just say one other thing about hiring. Whether you're hiring internally or externally, make sure you have inclusive job postings. These slides will be posted. Grab this link and read it. If you don't know what I'm talking about, you will after you read this. When I was at Pivotal and I was hiring people, I created one of these ridiculous job postings that we seem to do in technology, right? Where we say, oh, I gotta have 15 years of Cloud Foundry experience. They've done studies on that. You know what happens? Men apply because they go, I don't care. I'm just applying. Women don't. They've actually done studies on that and it's not that hard to rewrite your job postings to be more inclusive, to attract a more diverse team. And that works both internally and externally. The last thing that you're gonna need to do, hello, is actually defend this. You've created a utopia. You've created your own little world and it is your job to protect that world. I have seen customers do this really well with 15 people across three different teams. As soon as they added that one other team, everything started to fall apart. Culture creep is a real threat to your ability to scale. You cannot compromise on bad process changes. What I mean by bad process changes are, we're getting bigger. And so now we put this check in place. And that check has a negative impact on the rest of the organization. We're trying to create high-performing software organizations. I really like the way that Netflix talks about process. They say that good process allows people to be more productive. Bad process attempts to mitigate recoverable risk. And recoverable risk is the important factor. Somebody introduces a bug. It's more important how quickly they fix that bug than why that bug got there. Think about that when you start talking about the processes that are involved and what you're injecting into your organization. There's one other really hard part of this whole thing. Not everybody is cut out for this. Not everybody is a good fit. If you read any of the Netflix literature, you'll hear them talk about brilliant jerks. You might talk about underachievers, people that don't wanna learn. Inevitably in every group, there's somebody that thinks they know everything. Those are cancerous to your organization. And they have to be removed. Not everybody's cut out for this. I know that's not the politically correct answer, but if you wanna be a high-performing software organization, you need to prune them. You need to remove them so that they can't infect the rest of your team. Responsible people thrive on freedom and are worthy of freedom. Developers wanna do, for the most part, wanna do the right things. We've imposed process for our own vanity, and we need to stop that. And those of you that know who Adrian Cochroft is, I'm sure you've heard this quote, but I'll leave you with it. It's a little story of when he was working in Netflix, he was in a meeting of CTOs, and one of the CTOs raised his hand and said, we can't possibly do what Netflix does, because you guys have all these rockstar engineers, and we don't have any. And he stopped, and he looked around the room, and he looked at all the name tags, and he said, look, I hired him from you, and I got out of their way. That's what we're trying to do. That's what high-performing software organizations do. They enable people. They get behind their developers and they push. They don't get in front of their developers. If you do these five things, you can actually scale your organizations. You can find the right people within your organizations. You can give them the right education. You can give them the right support. All of that success and all of that culture is just gonna make more people get attracted to it. And as long as you defend that culture, you defend that process, you'll be successful. So thanks.