 So I'm Langdon White. I'm actually a faculty member at Boston University. I teach the very, very intro to data science. But we have our little introduction slides so I was gonna kind of walk you through who we are and then we'll walk through some various questions. I'm gonna kind of act as both the moderator as well as maybe answer some of the questions so that should be entertaining for all of you. We'll see how that goes. So Satish, do you wanna start off and tell us a little bit about who you are? Sure, Satish Paranum. I'm the technical leader at cloud, dealing with a lot of cloud-related things, experimenting primarily, and a lot of community engagement that part of my team also does. So that's me. All right, and then next up we have Becky. Hello, I'm Becky Riss and I'm a principal architect and responsible for dev tools and developer relations. And my team helps build different platforms and services that our developers at Ford use to accelerate their ability to deliver code for the company. Our screen keeps flashing on and off, which is kind of cool. All right, maybe it's not Fedora. Trust me. All right, so I did mention that I was a professor at BU, right? So I do this like multiple times a week. But yeah, so lastly about me, I'm Langdon White, as I mentioned, I teach at Boston University. I used to be at Red Hat. I was also a software consultant for about 15 years. But I also had up, I'm the technical director for our experiential learning component. And so we do, so I kind of teach both ends of the spectrum, like first semester freshman year and like second semester senior and graduate students and the gap between them is sometimes really difficult for my brain. As you can see, I have three kids, managed to get them all in one picture. So I think I deserve some congratulations for that because that's always a challenge. But now to kind of get into the actual panel, so what we're kind of here to talk about is that how do we kind of bring Kubernetes and kind of a cloud native development kind of component into a large organization that has been doing things a lot of different ways for many years. And my perspective, I don't have, I have students who don't have kind of prior knowledge but have in a lot of ways similar problems. And we're kind of also here representing Kubernetes by example or Q by example, which I always call by its wrong name. And I do a live stream show where I interview people about what's going on in Kubernetes about monthly. And then there's all these learning tasks on Q by example. And I think Ford's found some good success with it. So that's kind of what we're here to talk about. I'm gonna sit down now and hopefully stop turning towards the mic when I talk so that I don't change my volume as bad. So my first kind of lead question was, what brought your organization to Kubernetes in the first place? Like what was compelling about kind of the investment in making such a big change in your development organization? You wanna start with Satish? Sure. We've been on a multi-year Kubernetes. I'm like, I would say modernization cloud journey. I think it all started way back in 2016 with the four paths app. Everybody does an app. So we have to have an app. So we did an app, which we have been modernizing ever since. Alongside at the same time, we started with Cloud Foundry as a, and then Cloud Foundry was great. Work beautifully for microservices, 12 factor. But then there is always a state somewhere. Where do you put state? And that time we were juggling with interesting ways of doing state in the data centers. So Kubernetes was an interesting opportunity for us to actually, can we manage state for those things? I think we always used to call internally as table stake services. Cloud Foundry, 12 factor is great. But where do you run your data services? Redis, MySQL, Postgres, all over the world. So that's basically what started our Kubernetes journey. And primarily stateful with a lot of people finds surprising. Right, right, yeah. Yeah, I think it's one of the common challenges, right? When you start talking about cloud native applications, a lot of organizations, there's a lot of state there. And it's often really expensive to refactor everything, right? So you sometimes just want to tolerate it until you build that thing again. And then you can kind of do it without a state list. Did you want to add to? Yeah, so my team works closely with Satish and his team who kind of experiment and decide what technology we can do and how we can build it and use it at Ford. And my team takes that and kind of operationalizes it or builds the platforms that developers can use and adopt. So we're like frickin' frack, I said. We're good partners in helping to create those platforms so each of our developers don't have to solve the same problems and be able to utilize those platforms to deliver software. Yeah, so also to kind of talk about it from my perspective, kind of with students, our challenge is when a student is presented with development problems, right? They think very, very serially, right? They're said, okay, here's a piece of code, now make it do this other thing. And it's really hard for them to kind of start to wrap their head around something like Kubernetes because you're kind of describing the state you want to have happen, right? And you have to kind of think non-serially, right? You have to think about things all kind of happening at once. And I think that's one of the biggest struggles that I have with students is like how do you explain, well, first of all, I have to start off with why do we care about things like containers and then why do you need something like orchestration? Then once I get past that, I have to start to explain, okay, now one of the development models that we're seeing that's getting increasingly useful is this kind of describing a state you want to be in and that that's a much better way to run the computer because the computer then can be responsible for making sure we get there, right? than a human having to manually code every single step. So it's kind of like, as I said, we don't have as much legacy kind of information but I have a lot more baseline I've got to provide to even get to the point where they understand why orchestration is important and then some. So we wanted to also ask as basically we got kind of connected because of your usage of the QBuyExample site which is basically a site that tries to help with the baseline components about understanding Kubernetes and it's community based, it's open source, et cetera and so what was it that kind of drew you to it? Yeah. So my team has been responsible for kind of helping our developers learn and grow and up skill and for many years before that site was available to us we had to create that content, right? We had to deploy it, we had to educate, we had to consult and we found many great use cases to use that material now and it saves us time, right? We can point to the site, we can ask people to take advantage of those learning modules and those examples and then work with them instead on their specific use cases that might go the next step further and that's been really helpful to us. So we're actually being able to focus on those higher level tasks and help in the organization move past that. So it's a great resource to us. So if I could add, so one of the things that I would add is that QBuyExample is a great thing that can give you a wide sized thing. You don't have to read the entire Kubernetes.io docs to get started. It's very similar to getting an owner's manual, you go back buy a new TV or a car. You do get it, take a book, nowadays they give you an electronic book. The idea is that you know where the steering wheel is, where the brake pedals are, the accelerator is. It's the same thing with QBuyExample. Gives you a very high level introduction to all of those concepts. But then we take it the next level in eternally, is that how do we actually take that, turn it into a working, living example. So we took another inspiration from another CNCF project called Spark Info. So take that, that basically epitomizes all the best practices of how to use Kubernetes, how to do HA, how to do DR, how to you know, things like label certain things. And then we turn that into a working YAMLs. I know YAMLs is boring, we're talking about Kubernetes. That goal is that to give you a functional YAML that is decorated with relevant block posts. Here is the functional things that you could do. And then you could, the best part is instant gratification. You can take that code, paste it into the cluster, off you go. I'm like voila, I'm like light bulbs close up. Wow, it works. And it's also a great tool for collaboration, whether we're talking about our internal collaboration channels where hey, I don't know how it works, I can go to GitHub, copy those lines, here you go. So that also helps and streamlines some of those back and forth that happens. Right, yeah, I think it's hilarious that every time I've been talking to you, every analogy seems to involve a car. I haven't, yeah, which I think is kind of amusing. But what I wanna add kind of from my perspective is, I get students who come up and ask me questions about literally anything in technology, right? And so the more of a laundry list of kind of trusted places I can point people to go get connected that I can kind of retain in my head, it makes a big difference. And so that's why I tend to recommend like, you can use Stack Overflow, right? You can use Google, you can even use the docs as well. But it doesn't always kind of get you to that first start. We were talking earlier about this, is that I teach at a university, right? So I'm biased towards, I think you need some theory, right? Like to be able to do this stuff properly, you have to have a good idea of like the why as well as the ability to actually implement it. And what I like about this style of communication and it's not limited to Q by example, by any means, right? You could also do this internally for your own organizations, right? Where, but I kind of, you get a little bit of theory, then you get a big chunk of practice, right? Then you get a little bit of theory, then you get a big chunk of practice. And I think that really helps, as you were kind of saying earlier, like cement in your head, the theory, because now you just used it, right? And maybe that's not everyone's learning style, but it's certainly, I've had pretty good success with most of the people that I've pointed it out to is that that style works well. What is the call as reinforcement learning? I think that's the way I think about it. I think it's funny that, I've learned a whole new ecosystem of language. Like I don't think I've ever heard the word pedagogy in like industry, but now people use it around me like every day. It's super weird. But so what I did want to kind of get to, which is kind of the crux we want to talk about was like, what has the developer transformation been like? What does that journey like for going from where your developers were to where you want them to be? In one word, hard, difficult, but can be done. So as I said, we have been on this journey since 2016 and the idea is to introduce a few concepts slowly. Other things that have really worked for us is providing examples or a opinionated example of here. So we are pretty widely deployed now in GCP. So how do you get started in GCP? Right, so up until right now, a few months ago, we're having multiple different ways to get in. Now we have one way to get in. It'll give you a pipeline. We'll give you example code and we will get you going from there, but that doesn't mean that's where we have to stop, right? So you can, that's a starting point and that has been phenomenal success in terms of how well, how fast we can provision, reduce the number of ask for helps. I think the idea of using examples, not just for Kubernetes, but for everything, it works really, really well. Gotcha. And I'll say that we've been on this journey since 2016, as Satish has mentioned. And along with that, we really invested in also a cultural change aspect of that where we helped educate our workforce what we cared about the most and how they need to invest in themselves and in their skills. And we gave them time, we call it power up time four hours a week to do just that. We have many different learning paths for them. And really partnering with our developers so that they can prepare themselves to meet the needs that we have as we go forward. And that was key to our success. So along with the technology advancements and the investments that we have made, we've also invested in our people and we've kind of had this expectation that you're responsible for your career, you're responsible for your growth and here are many different ways that you can do that. And I think that's been one of the reasons why we've been able to move as fast as we have. And also one of the reasons why I think our developers are very demanding on what those next examples are and they continue to need harder and harder examples to solve, which just shows you we're raising their level of maturity. I think the other important thing to add to it is just the sheer diversity of the things that we have to deal with all at once. I think sometimes that in and of itself is a huge challenge to address, right? So the better we, whatever I'm trying to find a word would be is like, how do we actually abstract those abstractions? So there are too many things. So we need to actually trying to focus on people saying that these are the first few things. Get good at it, rest of the things will fall out automatically. Right, yeah, I was gonna, I mean, you're kind of alluding to it is that I think both for my students but then also kind of in my industry career, leading teams and stuff. There is some really strong positives to kind of giving someone an opinionated solution at first and letting them explore after that, right? So get somebody to success as fast as possible, right? Get somebody who's gotta actually feel like they accomplished something before they're starting to try to figure out how to really understand what they're doing. And I think, so, I think it's often referred to as like have little wins as you go along. And I think that makes a huge difference to be able to get an adoption. Because I think the problem with a lot of kind of people moving to like a Kubernetes is like, it's not just a technology, there is a pretty severe culture change when you think about development in terms of kind of the cloud native style of development. You think about adventure and architectures, we're starting in a serverless functions. That is a very different model of development than when you think about building a website, right? You know, you can build a website with serverless functions if you want to as well. But what you think of traditionally is building a website. And I think that's been hugely interesting. And then you actually brought up a really good point earlier about empowerment. When we were talking about it, is that a lot of people find the empowerment scary. And did you wanna maybe elaborate on that at all? Absolutely, I'm like, it's scary because now like the knowledge you previously was trying going back to the car analogy is like, you're sitting in a car that's completely blackened out windows and screens, right? You just don't know what's going on around you. There's no situational awareness. All we're asking people is to just crack the window a little bit. You would find that there is, you are in control. You do not have to file a ticket. You do not have to go ask somebody something. And that is frightening because now all of a sudden, you could do something that you never intended to do. Or people think that maybe I'm going to mess up my production. But what if you are allowed to do and you are encouraged to do in your lower environments? That is a big thing. If you can actually overcome that, there is a lot of folks, pretty much everyone among us are curious, how does this work? What happens if I were to toggle this button or not pass this variable? I think that was initially very difficult. Proving that it is, you can do it. You must do it. You should do it. Helps along the way of reinforcing that trust and all that stuff, right? Yeah, I mean, it is really huge because the challenge rate is like, you give out this empowerment, right? But does the employee who's just a cog in a big wheel, right? I'm going to start using car analogies too. Do they really feel like they're not going to get in trouble if they actually take the power, right? You go definitely on something to add, I think. Yeah, I think the important thing that we've seen a big success is having multiple ways that our developers can ask questions, treating them all with respect. And no question is a dumb question. We have this nice community now where we're kind of crowdsourcing answers and helping each other. And then we, of course, have deeper consulting ability to lean in when teams are having more difficult problems. And it's a whole community effort to come together and really experiment in a way that you can learn the technology and be successful with those small wins, but also know we got your back. We'll help you through the harder challenging things when you need it. One other thing that I would add to that in the culture wise, when we were talking about earlier, one of the things that I have found more years at Ford is like, there's nobody at Ford is going to stop you that you are not supposed to do this. This is not your job, right? You are encouraged to think outside. You are encouraged to say that, hey, there is a better way of doing X. And the debate is healthy. Yes, we will have strong opinions like we all should, because I think that's where the innovation comes from. And that is encouraged. And everything that we have done around Kubernetes has been a direct result of all of that, because we started Kubernetes way back in 2016. I'm like, Kubernetes was just announced around summer of 2015, if I'm correct. And we were in production in 2017. I'm like, that's an amazing rate of change if we are not willing to risk experiment. And innovate at the same time, we would not be here talking about it. Right, totally. Yeah, I did want to also comment on the comment you made, which is I think, particularly amongst software developers, the term community sometimes gets a lot of short shrift, but even at EU, so when I, one of the classes or types of classes we teach are these ones where they're actually doing projects for third parties, right? And so it tends to be a lot of local government and nonprofits, but they're doing real world projects, right? So the organization that supports that's called Spark, but we try to build a Spark community, because, you know, and it's funny, we have the worst turnover problem of any organization anywhere in known, right? Because every three months, I turn over my entire development staff, right? Which is really difficult. And so what we've been trying to build, right, is a really strong community. And I don't think people give it enough credence. It's like, it really makes a big, huge difference if you feel like there are people who care about how you're doing and are interested in your success, and it really does kind of reinforce that whole feeling where you can keep doing this, you can keep building, you can transform into what you're leading them towards, right? So I think that's also a really kind of big thing that it gets glossed over a lot. So I was wondering, do we have any questions from the crowd that we wanted to take? Nope, your mic might be off. Yeah, I'll repeat it. Do you have a reservation? Yeah. I'm just kidding. Talk a little bit about the process of educating the community that they don't have a place to go if it was like top down and then everybody or not, it was like bottom up, like how did you get people to actually put it aside as well as using the new materials and your alternative and then let's say spreading that. So to kind of repeat it, well first of all, it was really nice of you to bump his 150 reservation, but his real question was basically it's like, how do you spread that education through the community? And how does it percolate out maybe is a good way to put it? All right, so yeah, whichever. So Sidisha and I are technically in different teams, but you can tell we're kind of like I said, fricking frack. And both of our organizations have many different learning paths that we utilize. We use guilds at the company to help teach the kind of one hour lunch and learn type size things to give little teasers of where you can get information to learn more. That will lead you to a community of practice of people who are actually doing things. My team itself, we do deep enablement and consulting services. So our approach has been communicate, communicate, communicate, communicate. And then when people start to hear that, they start to learn, they start to pay attention and it grows from there. And they start to talk with other people and it grows from there. And they start to have success and it grows from there. I wanted to actually just quickly mention you brought up something earlier that's kind of relevant to this, which I thought was really, I don't know if I've ever heard anybody say it before, which was the part about when somebody asks one of your teammates a question. Can you tell us, what do you extract them to do? So a typical thing that happens and I think we're all a little guilty of it, someone asks you a very specific and direct question and you answer the specific and direct question. And one of the things I encourage my team to do instead is say tell me more and really try to get to the heart of what the problem is that they're trying to solve because it's quite possible, they're asking you the next question in their investigation journey and it actually might not help them solve the problem. So pause and ask, tell me more what problem are you trying to solve? And that generally leads to even a richer exchange and a richer communication back and forth to get them faster to the solution that they're really looking for. So don't just answer what's asked, right? Ask for more. I think one other thing that I would also add there is like when you were asking how we get started or pick the curiosity, right? We are all our curious. How about one of the things that parts of the team who are sitting in the back of the room and only they will do is that they will do weekly demos. It's like nothing planned. It's like most of the time it's impromptu and we'll just, hey look, this cool thing that we built, what you could do about it, right? That actually sparks an imagination saying that, hey, maybe we should actually turn it into a service. And one of the things that we did early on is like documentation. Communities has a great documentation, right? It uses a framework called Doxy if some of you are aware of it. We wanted to do the same thing. We did that two years ago and then now we are doing over and over again. I'm like, I was just speaking the curiosity saying that, hey, look, you can do docs as a code. Now you can build a pipeline around it. Now you have a community around it. Now everybody can contribute. So it was like an example that one of my peers did and then it just goes from there and it is repeated over and over again for several things. Not just like docs, but anything that we do. Here somebody do that. There is as Becky was mentioning, we had like this power up times where everybody is encouraged. Come up with an idea. You want to share with it. We will get behind you, right? So, and I think that has been instrumental in helping us get some of these things done. Yeah, so I would add kind of two things from my perspective. One on yours, software engineers and students share one major common thing. If there's free food, they will come. So, yeah, I found that to be very true. So we use the same technique of, you know, essentially, you know, one of the challenges, right? Especially like in a school like Boston University, their workload is high, right? And so getting them to do anything that's kind of not directly related to getting a good grade in a class is really, really challenging. Even if I could tell them, right, that if you go to these six workshops, that next class that you take will actually be much easier. But nobody believes you, right? So what we try to do is we do free food. We try to do marketing of it. We put it out. The other thing that's been also interesting is, you know, you gotta follow the different kinds of socials, right? So, you know, so our Instagram feed, for example, trying to reach those people is much better at reaching them than Twitter, for example. And so I think part of the also the thing that all of you should also keep in mind, right, is that your community within your organization probably uses different techniques to communicate with each other or different ways of kind of being aware of the world. Yeah, I keep talking about starting a TikTok channel just so I can feel like I'm cool enough. But the other thing I just, oh, I was saying that thing I was gonna add. Oh, the other thing I was gonna add is you brought the demos. We, when we do these projects for external parties, we usually have them follow a, you know, a scrum model, you know, and kind of go through some of the scrum ceremonies, but we don't do all of them because it would just take too much time. So we do some level of daily standup, except they're a little less often, et cetera. But one of the gaps we had, in my opinion, and that we're trying to change, I think we're gonna change it for next semester, is that we don't do demos. And I can't express enough how important like sprint demos are because I have the advantage of either class, right, that are all working on different projects. And so it's good for them to see each other's work so I can do that aspect. But even within, you know, within your own teams, sprint demos, particularly ones that show failure, are awesome because they really do bring the group, the team together, right? It helps support, it reinforces that community, et cetera. And I think that's really a gap. I don't know why I missed it until now, you know, but I really noticed it this semester that we really should bring in demos in our classes. We're pretty close on time, right? Okay, all right. Do we wanna try and take one more? How about all the way over there, but you might have to project, right? So let me try to repeat the question. Just to, you said builds, correct. That's what I thought at first and then I wasn't sure. All right, so basically the question was, you know, if you kind of have, let's just kind of call it transformational leadership positions of whatever sort, right? And so you're kind of saying, you know, you have these guilds, you bring them into a community of practice. You know, what do you do to incentivize them to kind of go theoretically above and beyond their job? Yeah, so part of I think our culture at Ford is that as you gain experience, one of the things that is the expected norm is that you share your knowledge with others, whether it's your teammate, your team, your department or the greater community. And we have many different ways to allow people to grow their skills and their confidence in doing that. And as you kind of move up in the company also, there's that expectation. And that's one of the behaviors that we look for to go from like an entry level person to someone who's more senior level. As we look for your investment in others and that is a criteria to kind of move up. So it's just part of our normal culture. It's part of our reward and recognition system. And we have many opportunities to have people practice and coach them to be successful in that. In fact, everyone from Ford here today, there's a lot of blue shirts in the room, they all have an obligation to take back something that they learn at this conference because Ford paid for their admission to the conference. And one of the things that they have to do is to give back to the community and take something back, whether it's in the form of a paper that they share or our learning session that they have and they run. And of course you guys can partner with each other. We don't need to have 27 different sessions for Cubicon. But that's part of what we do. So kind of from our perspective, like I said, we run all these projects with all these classes. We actually pay for project managers. So we have students who are interns essentially, who we pay to be project managers on the projects, primarily because logistics are so difficult. You, as you might imagine, right, all the students are taking all different classes. So they had like finding a free window plus with a client is ridiculously impossible. But then we also have recently started paying what we're referring to as tech engineers. We would probably call them technical advisors, but as you might guess, TA is a really well-used, well-known term in a university. So we've been calling them tech engineers, but basically they kind of act like what you would think of as like a technical lead on a project because that way we can kind of scale because otherwise we're a team of like six people trying to run this whole experiential learning component. I think we have about 600 students a semester. And so in order to scale, we need more people, right? And so that's what we do is we actually, we pay them and then we kind of pay them back as well with the experience, right? So now they've actually had some real project management experience. We have to provide a lot of coaching. And then, and the technical engineer that we've recently started, that those are really valuable skills and also we can kind of carve out time in their schedule by paying them, right? So we've thought about actually doing that almost as a class in and of itself, but you know, you know, maybe in the future, we're just, we're not quite to that level of effort that we could get to to run a whole class around that. Do you have anything else to add? As I said, I'm like, the big one I would add is like we are looking for talented engineers. Everything that we do is based on technology. We as a company has prospered and benefited from a lot of the work. Many of you have been doing in the community. I think we need more of those. We'd like to learn from you, at least talk. Come see us in our booth. We are in G2, but if you are interested, hey, we are looking for some real talent as well. Thank you. And if you're watching online, go to careers.ford.com. Yeah. We're recruiting. Nicely done, nicely done. Yeah, and also, you know, cube by example, please come join us, come join the community. You know, we're taking PRs as they always say, right? And we really appreciate the help and find us around if you have any more questions. But I think that's the time we have, right?