chris-matts-first-kill-all-the-thought-leaders

Transcript

[00:00:00] Uh, thank you for inviting me back. Um, I think the last time I did a talk at a conference was in 2018 at Flowcon.
[00:00:08] Um, the talk I did was about the things I'd learned up to that point, which was mainly about how do you scale agile? How do you get agile to work beyond the team?
[00:00:17] Um, since then, I say I've not done a talk and and this talk is really about what I've learned since. A lot of the ideas that I'm presenting are perhaps not common knowledge in the community. And so what I've done is in the schedule, there's a link to a page where you can find the breadcrumbs, you can find the things that I'm leaving behind me because, um, I haven't solved most of the problems I've been trying to solve and I'd really like you guys to be aware of them. So this is going to be a talk about problems rather than solutions.
[00:00:55] You'll see there's a Kanban system on the stage. for four chairs.
[00:01:03] When the last chair is full, that's when the talking ends. And the first chair on the stage is for the value stream. Yeah, that's for the people doing the work to build the software system. So, just checking the audience. So in the value stream, there's the developers, any developers? Any testers?
[00:01:26] Any business analysts?
[00:01:29] Um, architects, product people. Yeah. So, this first bit is really for you guys. Um, we have a problem in IT. And the way I'm going to explain it is using something called maturity mapping. So, who's familiar with Walley mapping? Yeah, so we got Walley mapping, you're familiar with that. So Walley mapping, what we do is we take the value stream, put the the value delivered to the customer at the top, and then we show all the steps in delivering that value, all the components in the system. And then across, we show the maturity of those components in terms of in the community, how reliable they are. Chris McD and Mark McGregor extended that to something called maturity mapping and they and Mark, I think, did a talk at Flowcon during COVID about this. Where what they did is they brought in social practice theory. And what social practice theory does is it looks at practices, but it looks at it from the perspective of the meaning of the practice or the value of the practice, but also, um, the material, the tools that you use. And they did the same, they they map the maturity of these practices. And so, what happens is a new practice, it starts with value to the practitioner. Yeah, so the person doing the work sees a problem and they think it would be really good to do that. So let's pick on refactoring. Yeah. So in the early days, people would say, right, we got a problem because we're writing code and no one else can understand it. So what we need to do is make the code so it's easy for other people to understand. So they, there was a value which we called refactoring. And the early, in the genesis of this idea, they were coming up with the practices and working out how to do it. Then when they'd worked out how to do it, they would actually then share that idea at places like this. And people like you in the audience would hear these ideas and you would implement the practice, but there weren't any tools for it at that time. And so what you would do is you would use the existing tools that you had to do that practice. So you'd use search and replace to do refactoring, to do renames. It wasn't great, but there was huge value at this point to the practitioner. Now, those practices were seen to be valuable. Yeah, people realized that refactoring was a good thing. And so what eventually what happened is we get a tool.
[00:03:53] Now, the thing about the tool is it's valuable to the organization, but it actually devalues the practices and practitioners in some ways.
[00:04:02] And what this step does is it moves those practices out of the practitioners and they put them in the tool, so people without the full set of skills can do these things. What's really interesting is, and and I don't know if any of you have been involved in these kind of things, but organizations tend to think if we implement the tool, we will get the practice. Yeah. So, if you've seen IntelliJ get implemented where everyone's really excited because everyone's saying, well, we can't do refactoring until we get the tool, then they introduce the tool. How many of you have seen the perfect representation of a waterfall project in Jira?
[00:04:44] We've seen these things. We have a problem because our AI has arrived. And it's arrived here.
[00:04:53] It's a tool. It's a tool without a problem to solve and it's a tool without a set of practices. And what people in this room need to understand is, you're the people who need to take us back to the start of that process and develop a set of practices, understand the value that can be unlocked. But we need to get the conversation back to over here so that the conversation isn't about the tool, the conversation is about the practice and the value that's going to be delivered by the tool. So that's that's the first part of the problem that we have.
[00:05:30] The second relates to Jeffrey Moore's Crossing the Chasm. So once again, how many of you are familiar with this? So this is a very common IT marketing model, where what we have is we have early adopters who are the first people to kind of do it and they're very enthusiastic and they're prepared to put up with imperfect products. Then when the product is perfected, we have the early majority who are the people who dive in because they can see the obvious value. Then there's a late majority, the people are only doing it because other people are doing it. And then we have the laggard, the people who really don't want to do it. They're the ones who get McKinsey to run their agile transformation.
[00:06:09] What's been known for a long while is that between the early adopters, the people who are really doing it for their own value and the early majority bringing in the tool, there's a chasm. Yeah, and this is where Jeffrey Moore's idea of crossing the chasm comes in and that's very much our focus. But what I've seen in the communities around Agile and Lean and Flow and so on is there are actually two communities. Yeah. There is this community of solutions that is focused on selling stuff, but there's also a community over here which is focused on solving problems. Yeah. The community of needs, I call it. These are the ones who are trying to satisfy the needs of the organizations that they work in. They're trying to solve the problems of the organizations that they work in. And then, and it's the people talking to each other about how do I get this done. As opposed to the community solutions where people are saying, here's a solution you can implement that will solve your problems.
[00:07:09] Now, these two communities are not
[00:07:13] kind of like distinct, they're very vague. Don't you love this slide?
[00:07:18] This is literally my favorite slide I've ever done.
[00:07:23] Um, and what I'm trying to show is that it's not that there's this very defined thing, but there these communities massively overlap, but it's really about what's the the focus of these communities and what's the behaviors that we see. And when we look at these, what we can see is in the community of needs and the solutions, in the community of needs, we have peer-to-peer conversations, we have people talking to each other, very much like the meet you was saying earlier. As opposed to in the community solutions, we have leaders. We have learning versus selling. We have keynotes that are new and raw with interesting ideas, or they're by a famous person that you've heard of and they're polished. Where does the conversation happen? Is the conversation happening in the corridor or is it happening in the classroom? In the community of needs, we have practitioners. We have people trying to solve problems in their company. In the community solutions, we have experts, the best in the world at doing this. But for me, probably the the biggest difference between these is that in the community solutions, the solution is absolute. Scrum will work everywhere, Kanban will work everywhere, Safe will work everywhere. But in our work, it's all about context. Yes, the team next you've managed to implement something, but there's probably a reason why you can't. And so context is really important, and context is very specific. It's not for a company, not for any department, not for a team, or even an individual.
[00:09:05] In the community of needs, we have trailblazers. These are the people who are using a map that is not complete. There are gaps on the map. You're trying to find your way. There isn't a perfect solution for solving something for your team in your company. As opposed to the community of, uh, solutions, we have thought leaders. These are people who are experts. You can generally spot them because they they do all most of their work is training or short-term consulting, but everything they do is very general and not specific.
[00:09:43] There's a third type of leader in these communities. So we've got the trailblazers, we've got the thought leaders, and we also have the servants of the community. These are the people who write the blog posts where the people can understand stuff, who organize meetups and who organize conferences like this. So, can we just have a round of applause at the very start for the people who organize the conf and the volunteers in the blue team?
[00:10:14] (Applause)
[00:10:19] Who are going to be available to talk with afterwards. So, not everyone who's organized. So, come and stand up, all the people who have been involved in organizing this. Oh, not everyone, just the organizers. Stand up, the organizers. Yeah, all stand up.
[00:10:39] (Applause)
[00:10:51] Here's the problem we face.
[00:10:55] Yeah. What we need to do with AI is we need to bring the practitioners together to discuss things, and we need to kill the thought leaders. We need to kill the people with a strong opinion but no experience in this very new thing. Because we haven't got the practices. Thought leaders are very good in a healthy community where you have gone from developing the practice, understanding the value, and then you sell the practices. But at the moment, we've got a lot of thought leaders in our community who are expressing opinion, but they're not necessarily doing it.
[00:11:29] At this point, I just want to call out Romeo, um, and inspired by his talk on toothpaste. this is a really great way of thinking about the difference between thought leaders and trailblazers. Um, Listerine is a very famous brand. for one particular reason. It was a product that no one used until they invented a problem for it. And so what you can see here is they invented bad breath. Yeah? And that's the danger we've got, what we're going to do if we're not careful is going to have thought leaders inventing bad breath, rather than focusing on the real problems that we need to solve. So, here's a question for you. Are you an AI practitioner? So, do you have an LLM in production? Is anyone got an LLM in production for their system? Yeah. Cool.
[00:12:22] Uh, do you have code written by an LLM in production?
[00:12:28] Have you got problems that need solving? Anyone?
[00:12:33] Do I have a two or three brave individuals who'd like to come up and occupy the first seat? There's a boring talk if you don't want to talk about the things that are happening to you. Go on, go on.
[00:12:48] (Applause) (Applause)
[00:12:51] Go on. Yes.
[00:12:53] (Applause)
[00:12:54] Thank you. Two more. Yeah, you gotta do something. You gotta be standing right over here. Thank you. No. Just one more. That's right.
[00:13:06] (Applause)
[00:13:08] Come on, you can just do anything. Come on. Come on, just sit. No, not yet, not yet.
[00:13:12] (Applause)
[00:13:15] So we have one seat. So these are the people in the value stream who've got problems.
[00:13:22] So, over the last probably 15 years, I've been working at that level above the team.
[00:13:29] And so, what I've discovered is that the second seat is often one that's not involved in that. Oh, no, sorry. You only get one seat. Oh, come on. Yeah. One seat. I'm sorry. You can have a seat over there. That's fine. quite you could just do any hurry. The not. So, how have one seat? So, these are the people in the value stream who've got problems. So, over the last probably 15 years, I've been working at that level above the team. And so what I've discovered is that the second seat is often one that's not involved in that conversation. Oh, no, sorry. You only get one seat. Come on. Probably you can see. Come on. What does this mean? The other seat is for leadership, management. Right? These are the people who have to create alignment in the organization. Make sure that we're working on the right thing. Spot bad behavior and stop it. Keep make sure that two groups are not doing the same thing, learning the same thing, all of those things. This is the area where we have the biggest problem with thought leaders. Because they come in and the great thing about leaders is they've got big budgets. So they attract the thought leaders. About a few years ago, I met the COO of an organization with about 10,000 developers. So he he was the CIO of the IT department. And I've been invited to come and speak to him about, you know, uh the performance of the IT department. And so I was there. I'd prepared a deck with work I'd done at previous companies where we had what we called a metrics hierarchy where we could show the value that we'd delivered. And I didn't get through the first slide when he stopped me and he said that's not the problem we have. He says, every year we are given 2 billion pounds. I, the CEO. The business gives us 2 billion pounds. And we need to demonstrate that we're doing a good job with that money. Yeah. It says, we need to be able to explain and show to the business that we are doing a good job. And this is a problem I've been working on for 10 years, and the solution I'd got to that point was pretty good, but completely incomparable, you know, no one could understand what I was talking about, but it was right. Sound familiar? Um, and it completely changed the way I think about this problem. Yeah, this problem we have to help the the senior IT management with is one of making it really easy for the business to understand that we're doing a good job. And the reason is, if we do not do that, we ask for some money to do an investment, you know, whether it's a DevOps tool chain, or an agile transformation, or a lean transformation, or anything like that. Unless we can show that things are better, halfway through, someone's going to go, I don't like that. Let's stop doing it. Let's stop paying for it. Yeah. And I'm sure you've all been in that situation. So one of the problems we're going to need to solve within AI is that problem, because it's going to be even worse with AI than it was with just a lean DevOps or um, an agile transformation. So, this is an exercise I've run with many senior leaders in business and IT. I have um at least 100 directors, executive directors, managing directors, both on the business side and on the IT side. And what we say is, right, we're we're going to measure the success of IT. Number one is the point where someone comes up with an idea and it goes into the organizational backlog. Number two is when we prioritize it. Number three is when the first team starts working on it. Number four is when the team finishes working on it. Number five is when it's in production. And number six is when we've delivered value. Yeah. When the customer is able to use it, whether that's an internal or an external customer. So I want you just to say hello to the person sitting next to you. Ideally someone you don't know, and I'm going to give you about 30 seconds to just go, um, what would be a good measure of success for the business? What should we be measuring? So, what number do we start at, what do we finish? So, I'm going to give you about 30 seconds, go. Say hello to the person next to you, ideally someone you don't know. Come up with a numbers. The number you start at, the number you end at.
[00:17:53] [Audience murmuring] [Audience murmuring, laughter]
[00:18:38] Okay. So, one brave volunteer, shout out the two numbers they came up with. Just don't put your hand up. What? For the leader in the room. Okay. So, who came up with one to six? Yeah. This this was my boss's favorite. This is called concept cash. And and if we look at the lean literature, that's often considered the gold standard, concept cache. Can anyone tell me what the problem with this is for measuring the productivity of IT?
[00:19:23] [Silence]
[00:19:28] You're not, don't look. Actually, the big problem we have is that from one to three, it's got nothing to do with productivity. It's actually more to do with your imagination, how many things you've got in the backlog. The easiest way to get one to six is to have a shadow backlog where you do not tell anyone what you want until the last minute. And that makes it a nightmare for leadership to actually plan capacity going forward. Yeah. So one to six is not great.
[00:19:57] [Audience laughter]
[00:20:02] Anyone recognize this? Possibly the most toxic metric when it comes to productivity ever developed. A lot of nervous laughs there. Um, yeah, we know Dora is, it's like, yeah, and you know what, it's really good at showing how good a team is. Yeah. Does the business care how good a team is? Because what happens is one team improves. But if the other teams, so team A is great, but team B or C isn't so good. From the business's perspective, there's no, it's no good at all. Yeah. And what happens is this draws attention and thought leaders, and we're not going to talk about McKinsey. go out to the market and say, everybody, you've got to use Dora. The problem is that people who really don't understand this stuff, they go, okay, so let's compare teams. Possibly the worst, most toxic behavior you can imagine. Yeah. Because all of a sudden teams are competing when they should be working together to deliver stuff.
[00:21:06] [Audience laughter]
[00:21:11] And this has got, we've got with a thought work, this is a fantastic metric. Don't get me wrong, right? As a metric for a team to understand whether they're improving, it is fantastic. And you've got all these people who are used to working at the team level whispering in the air of leadership saying we should use the Dora metric. It's great. I'm the exact whisper. They listened to me. We did this. I worked for a company, they spent a year implementing Dora. The thing about Dora is to do it properly, you have to standardize certain parts of the process. So there was massive disruption in the organization. developers were told to change the way they work in order for them to be able to gather the Dora metrics. The first time they had the Dora metrics and they presented them to the executives, what do you think they said?
[00:22:00] [Silence]
[00:22:03] What the hell does this mean? What are we going to do with it? Never show it to me again. Yeah. I'm not saying we've got a solution, there are better solutions. But we have to look at the problems we're trying to solve rather than take our solutions that work well in one place and force them into other places.
[00:22:22] [Silence]
[00:22:27] The the better the best solution that I've come up with so far is what I call investment duration, the time from investing money, to the business getting a return. And everyone goes, but wait a minute, wait a minute. What about the bit at the front? The one to three, because actually that's where most ideas spend in terms of time. Well, we have another metric for that. It's called cost of delay. What we do is we go to the business, look, this is how good we are, but you see this, we're losing this much money because it's having to wait because we've got limited capacity. If you want us to go faster through that queue of work, you need to give us more money. Yeah. But we're having a conversation with the business in a way that they can understand and is meaningful to them, rather than one that makes sense to IT, but not the people who are paying for it.
[00:23:11] [Silence]
[00:23:13] Okay, I'm going to talk to you about the other big problem we've got in leadership, which is culture, which is also really important for AI. Can anyone tell me the difference between these two comic books? By the way, just in case you haven't known, I'm really pumped to be here because this is where the movie is, and I'm a big comic book geek. So, what's the difference between these two comics? Can anyone tell me what they see?
[00:23:36] [Silence] [Audience mumbling] [Silence]
[00:23:45] So the the right one is a bit older, yeah? Yeah, you're dead right. As a result, the one on the left is worth 1.1 million dollars, and the one because it's a bit more battered, is worth $5,000. And that's what it's like to be in a culture that's got a leadership culture where people are held to account and behave as adults, versus being in a failurship as we call it, where people are things are not quite right. It's not a big difference, you can't tell a lot about them, but there are these very important things. Leadership needs to start learning about these things and addressing these. because once again, what AI does is it makes whatever problems you've got even bigger, and you can't just hide them. So, a leadership culture is risk managed. If there's a problem, people own the risk appropriately. And the people in the organization care about the organization. As opposed to in a failurship, people are risk averse. And what that means is they don't want the risk themselves. And so they push it where it shouldn't go. So instead of doing the development themselves, they perhaps hire a consultancy that they can blame when it fails. Those kind of things. In a failurship, people care more about themselves than they do about the organization. Which is possibly why you tend to find that more leadership in companies where they're at risk as an organization and people know that their job depends on the company surviving. Whereas in where companies are very stable and safe, you find these sometimes quite toxic cultures.
[00:25:20] [Silence]
[00:25:23] One of the most disheartening things about this kind of culture is what does success mean? So, in a leadership culture at the start of a quarter or the start of a sprint, people say, this is what we're going to do. A group of teams come together and say, this is the deliverable we're going to do. Team A, B and C come together and say, we're going to do this. And at the end, they assess whether they delivered against their goal or not. In a leadership culture, when they didn't deliver, they're challenged to think and reassess and think about how they're going to improve things going forward. In a failurship culture, no one cares whether you succeed or whether you fail, it's got nothing to do with anything because all that matters is your relationship with the senior leaders. Once again, AI is going to make this really bad. Yeah? If you're in a failurship culture, it's going to get worse. If you're in a leadership culture, it'll be better.
[00:26:23] [Silence]
[00:26:26] So, we've got another chair here. Do we have any leaders in the room? People who perhaps lead team more than 150 people? Yeah, there was a hand there. Was there a hand there?
[00:26:40] [Silence]
[00:26:42] Any leaders in the room? prove things going forward. In a failure ship culture, no one cares whether you succeed or whether you fail. It's got nothing to do with anything because all that matters is your relationship with the senior leaders. Once again, AI is going to make this really bad. Yeah? If you're in a failure ship culture, it's going to get worse. If you're in a leadership culture, it'll be better.
[00:26:25] So, we've got another chair here. Do we have any leaders in the room? People who perhaps lead teams more than 150 people.
[00:26:37] Yeah, there was a hand there. Was there a hand there? Did I see a hand?
[00:26:44] Any leaders in the room?
[00:26:47] Oh, you're moving chair.
[00:26:52] When we're bringing in such a major change as something like AI and we want to do it in the right way, we need to make sure we're talking to everybody. Yeah, we need the the leaders as well as just the developers and the testers, we need everyone in there to make sure it works for everyone. Because you might develop a really great system.
[00:27:09] But this whole leadership thing is going to be a massive constraint on your ability to implement AI properly within your organization. So you've got to have the lead. So, thank you for being here.
[00:27:25] Anyone else who considers themselves a leader in some way in this space where you're running a team or so on that perhaps would like to offer some support to your colleague. I I think you need more leaders. You need to hear their voice more. You need to invite them in, bring them in. They don't all bite. Some do, but not all of them. So that's our leaders, that's our second chair.
[00:27:49] So we come to the third chair.
[00:27:55] So we've got the value stream, we've got the leadership, creating alignment, making sure things are right. The third chair is how do we spread these ideas? Yeah? So we've got a chair for the people responsible for training and coaching the rest of the organization and other organizations. Um, this is kind of been where my career has been for the last 10, 15 years, either as a coach or as a transformation lead trying to get team of coaches to do stuff, mainly working with leadership.
[00:28:28] And and this is the model I've found to be most useful. I've spent the most time with. Uh, the unconscious competence model. So, we all start in a state of unconscious incompetence. We don't know about this thing. We then move to a state of conscious competence where we're heard of it, but we're not doing it, we can't do it. We then do our 20 hours of practice and we get to a state of conscious competence. Um, and then finally after we've been doing it for a couple of years, we're in unconscious competence.
[00:29:02] The most interesting one there is the conscious incompetence. It's where you're aware of something and you value it. Yeah, it's not just about being aware. There's many, many people are aware of lean and agile and things like that. But from their perspective, they don't care because it doesn't benefit them, it only benefits the organization.
[00:29:23] And this is where I've spent a lot of time. So the the way I describe this is unconscious competence. You think of driving. When you're a very small child, you get in the car and you're not even aware that the anyone's driving the car. It's simple driving, you don't know what it is.
[00:29:39] When you're about four or five, you are aware of driving, you're aware that mom, dad, big sister, big brother, aunt, uncle is driving the car. But you see no value in it because, you know what? Whenever you go anywhere, you want to go with them anyway. It's only when you get to 13, and for some reason, you want to kind of have some freedom that you value driving. And it's only because you value it that when you get to 17 in the UK, you then do your 20 hours of practice so that you can drive. You then become conscious competent. And what that means is, and do you remember that, whenever anyone passes their driving test, I'm not sure what it's like in France, but in England whenever someone passes their driving test, they take their friends out to drive, they get in the car and they go, "Everyone be quiet, I'm driving." But then after a couple of years, they get more relaxed, so they're driving along, they've got a cup of coffee, they're doing Sudoku, they're texting, they're on the phone, they're applying lipstick, and that's just the boys, right?
[00:30:47] The most important thing here is value. Right? Because if people don't value it, what happens is they don't do it properly. They don't want to do it properly. They don't care about doing it properly.
[00:31:00] And most organizational transformations, they take people from unconscious incompetence, they make them aware and try and get them to conscious competence. They don't understand the value bit. I don't understand the value bit, but this is where I've been kind of focusing for the last 10 years. There's some brilliant work out there. There's a guy called Paul Adams. In that link I sent to you in the schedule, watch his video. It's brilliant. This is like 2012. Paul is the product, was the product manager for ads at Facebook. And as he said in the tour, he has all of the data. And then he stopped and he goes, I have all of the data.
[00:31:45] He said, if you want to make people aware of your product or anything, get someone famous to promote it. And everyone will be aware of it.
[00:31:57] He says, if you want people to change their behavior and adopt your product, one of the four people that are closest to them have to be doing it. And this is where you start learning about Damon Centola's work, where actually how you shape your network is really important to get ideas propagating in terms of people wanting to work with them. Because value is socially constructed. You value something because your best friend values something, not because Bono has told you you have to do it. Does anyone in this audience remember Bono? Just checking.
[00:32:40] It's different with thought leaders.
[00:32:44] With thought leaders, what Centola found is it's not four people because what they're interested in is the market, so they only switch across to a new way of working when they can't sell the thing that or get as much value out of the previous thing. So they need much bigger proportion of people doing stuff before they'll come across. Yeah? So they actually act as a mechanism that prevents new ideas from entering the community. So, you know, if they're a world expert on refactoring or on TDD, it is very likely that they will oppose AI because or insist that AI has to do refactoring.
[00:33:31] or TDD or vibe coding. Yeah? Because what they're doing is they're looking at their market and their customers and that's how they decide. So we find that if we listen to our thought leaders in a situation like this, we're going to be much later in the game to understand this stuff.
[00:33:52] Not only that, but thought leaders protect their communities. They stop people looking at these things that they feel threatened by in as an individual. You know, so you'll hear about people going on about AI Slop. There is no AI Slop. People are learning new ways of working with a new tool. A lot of people are doing it badly. But that's to be expected. Yeah?
[00:34:21] But there's a real problem with this and that I know a few people who have done a lot of work with AI, I've got huge amount to share, but because of the abuse that they've received on social media, they are no longer sharing their journey. So we've got genuine trailblazers who are not sharing what they're doing because of this.
[00:34:44] This is a paper I found because I'm addicted to Notebook LM. And I'm going to read it to you. But I found these two papers and it's about um simulations run on kind of social network simulations and it says, This implies that even a comparatively infinitesimal small number of bots still has a sizeable impact on the consensus and hence represents an obstruction to the wisdom of crowds. Throughout the paper, we've used the term bot as a synonym for various entities operating in social learning network intending to spread fake news or manipulate opinions. This broad definition includes actual automated bots and human operated accounts or groups with specific ideological agendas.
[00:35:39] Otherwise known as thought leaders and communities of solutions. What this is saying is a group like this, if we left it on its own, would find the best way of using AI. But if there are bots in the network, if there are thought leaders who are holding on to an old way of working because of their status in that community, or communities that demand on the presence of that community to make revenue, they will prevent us from finding the best solutions.
[00:36:11] And we'll end up with the door matrix again. Yeah?
[00:36:19] So these communities like the Kanban community, the Scrum community, the safe community, the DevOps community, could actually mean that we failed to find the best solution for using AI. Yeah?
[00:36:37] So perhaps, you know, this lump here is caused by Scrum and this one's caused by Kanban. And the reality is the best solution is both Scrum and Kanban.
[00:36:50] So, so this is really a call out if there are any coaches or trainers or people like that who'd like to join us up on stage. Any coaches? So, so are you Do you help team share their LLM knowledge? Are you running a community of practice for LLM's? Are you trying to inspire people to use LLM's? What problems are you trying to solve?
[00:37:20] We've got anyone else?
[00:37:25] Thank you for joining us.
[00:37:31] This is AI Slop. The original photo is one chat.
[00:37:39] bring you guys a little bit closer. And that's how we kind of
[00:37:45] the four chairs we want to move into. Yeah.
[00:37:49] If anybody gives, do you know what? If you don't like it. The one thing Centola is saying that people are saying is, I'm not saying this, Centola is saying this. is that we're going to use AI and we're going to move forward.
[00:38:05] So in terms of that, we from our leadership, leaders, your people. Now, if anybody here says, you know what? No back to that. We have that problem, people joining. What we're going to do is have a little conversation.
[00:38:27] Do you remember this? My favorite slide. Do you know why? Because when you look at it and you go, "I don't know that." We're going to be engaging in some sense making. It says, when you look at that, you go, I got to read that paper from Centola. Yeah. You don't say, I'm not reading that. I'm not going to engage in sense making and say, I'm not going to look at something that I've known telling me it's right. Um, what we're doing is we're engaging in sense making. And if I redrew that slide to look like that, it would kind of tell you I'm an expert.
[00:39:06] And if I drew it like that, it would tell you I really don't know how to use AI.
[00:39:14] So, if we've got our two lights, they're all ready to try. Right. So we have a question.
[00:39:25] So, what problems do we need to solve on the larger the value. LLM. Anyone want to speak on this?
[00:39:37] Oh, look. We've got a leader. Someone wants to say something. Thank you.
[00:39:46] I'm not going to try and find the best solution. Okay. No, I mean it's fine.
[00:39:57] Okay, thank you for the biggest problem we're going to run into that is the thought leaders and communities of solutions.
[00:40:06] But there are three human beings on a model that that will be on it. The more that can solve for this problem. Okay.
[00:40:16] By the way, is talking to the chair.
[00:40:20] I really want to come from my own contribution. I think we have to summarize the problem with this and it is always the case. The only solution that I am able to think about right now. Something.
[00:39:52] Okay, I think the biggest problem that I see right now for us, which we might not always say, is, one of the last part.
[00:40:05] God bless and actually, uh, people that are doing, uh, like the AI stuff, and the software development, I think this is probably the most, uh, 17-year old. For us, uh, just to share some something more of it. Uh, I will begin from my side of things. Uh, is there anything that we are still not aware of? Uh, what about, uh, actually the way I am in charge for uh this year, uh, project development, Michelle, you know, Okay, I'm going to interrupt you. Sit, I'm, sit on the chair. You can't, you can't talk like that. Uh, I don't think you can do that. Right. Uh, the team I work with, wants to use uh and they use their own tools and stuff. They use, uh, in sort of a Shadow IT. And I can't really control it, a lot to be honest with that. But the business case for about the tools is required to do layout. Which are awesome because of the employee attraction and stuff. So I can't really make the business case for bringing a new tool in. So I give them the worst tool, which comes with the Microsoft 365 license. And they use it. Yeah, it's pretty bad. Uh, and then you use Slack and they play with each other for bringing Slack into our agency. It's really bad. But it's, I think it's just a tool to get to results, like you are building results when you use something like. Uh, yes.
[00:41:57] And I don't have the chat to my problem that I have ten percent problem, uh writing with chat AI tools. Um so the good AI, we can't use good AI tools for the company because the company and some of them we can use with other process. And if you have a child running, you can use that now anytime. So we don't usually use a lot of AI for our.
[00:42:37] And then we try to host in the resource.
[00:42:44] Uh, so we're thinking about it, but it's a big company, so it's not in our hands, uh, what is about the company Uh, saying that I have to adjust to what they can do. Uh, it's going to take a lot of time.
[00:43:03] Some people are secretly doing it, and that's the thing. But they somehow have to ask the or sort of relabel it to do it. And then once they come to it, they probably will be using it to some degree. I know we're trying to incorporate this into our culture.
[00:43:30] It's just not the stuff from corporate, like if you're a big enterprise, you're not going to get from Google that they basically every all of them are running off. So the real is that really comes to like an actual address. So it's something that we are using it for. Yeah.
[00:44:00] Uh, I was talking about the chatbot. And then maybe we should really, what you really need. Like when it's for the engineers, I think we should talk about the problem. Uh, so what is it that it's just still. All right. No, this is it. Just trying to stop with some thing.
[00:44:24] No, no, no, sit, sit in chair. Ah, you're coming with a problem. I think the problem we are trying to solve is to make the impossible possible because.
[00:44:37] Before, when we talk to a product or specify it's something, we just find a release with a tool. And if we don't have, I'll say no more. Let's stop and we will still choose that to you. And we had, uh, I think, and make it, uh, so maybe, the problem we are trying to solve is the maybe. I think when people are not doing that, that means that our customer is not able to do something. And because of that, it means. And I think it's very important.
[00:45:23] Uh, I was thinking to what you say, what you say. The fifth website which is most used right now, is Chat GPT. And it took only six months to reach the fifth position around the world. Which means that at home maybe we use chat or use an editor. But people at home are using it a lot. It's like a Google, what's up to. Like if you have to feel about what you want to do.
[00:45:59] Uh, and as you say, you have people using Happy Motion or people using that mark to you and to use and stuff.
[00:46:12] I'm super excited and very nervous because I see people which I don't try to cut my company. And then there's people which are exactly a lot of things. And it's going very, very fast. So I don't know how you feel it, uh, it's stronger than when the internet was, uh, when it started to use that computer. And uh, how will we work? I know the team has to be asked. They chose something. For me, I would like to do it. I think it's awesome. I'm working with engineers and I thought it's just about the product and I think so. I was exciting from to do it, you know. And also I have a bit of fear. And I don't know if for us, if anyone that is working in the software development, is there a place for us for you in five years? Because if you are just a developer and not a child, it's changing very fast. And, honestly, for us, as a leader, what I, what I keep telling my team and the software developers, you have to use. And not only you and the team, the team is, I usually speak with my managers and leader and actually use it so that they can see and see. What's the kind of thing you can do with that and so that they can still have it working actually in result. But basically, it's just me. I'm just telling you that.
[00:48:21] Oh, definitely not. The economy of software development is changing. And so we are really raising the abstraction level because I mean, our software is built on systems we've known for years. And, uh, one problem I realized is that I stopped looking at it. And that is maybe a problem for some way. Because I can build the system with the modules and I know the modules talk to each other, but I'm not a modular. because I know that the module I chose is actually pretty about but but I see a lot of times people for just like the and they lose the understanding of what it's doing.
[00:49:07] And that is one of the reasons that happens. So that people building something without understanding, that's that mentioned breaks, the code because they cannot change things that they don't understand.
[00:49:23] Uh, I just don't think one right now. I have a, I don't know how to do that. And uh, so it doesn't work. I can do, uh, as a software developer. I think, uh, being about to front and correctly explain what you want is much more important than like. And uh, I also think the good was created by. Yeah, it doesn't care why you should use tech tools grow up. It doesn't care. If you do, uh, an LM developing account, uh, that started to use because it's quite simple. For LM, it's a very good language because it covers. Uh, and I come from a background, so is a reader, it's. So I feel, I feel when it comes to this change. And uh, where I started is the specific front and us, we need to share much more and we need to explain much more and what we are doing before. And for him, it has changed a lot the past year. And I rediscovery writing in PHP, JavaScript and so on, talking in LM. And Linux also. Uh, so I think I will still have a job, hopefully, but I also think that it's going to be a fun and learn.
[00:51:00] Yeah, I guess you turn more into product builders versus code, less less about profession development.
[00:51:07] I guess. Thank you.
[00:51:12] Anyone have a question about AI from a company or who currently is the one who is the, you know, about that, for example, just want to share some stuff. So yeah. Can anyone.
[00:51:41] Can anyone know.
[00:51:46] Maybe you want to talk about that. Yeah.
[00:51:51] Yes, so the question was what's the role of junior developers in this new reality? And uh, I think it's really difficult. Because I think we need to change the education model of how we educate people. Because different skills become more important now. Critical thinking was always important, but just to hard skills are also important. But now critical thinking is becoming way, way, way higher in the hierarchy of skills. So that's what we have to teach young developers and young, young people, that they need to be pretty critical about what they get from all of these systems that they're getting right now. And they need to learn how to ask the right questions, because that's what. If the curiosity of what the right question is, that's what we need to teach people to be more critical. Yeah, we need to change a lot of things.
[00:52:46] And I agree with you about education. It's very, I spoke the other day from contractor company in France and he shared with me that before when they hire someone they just give them a training. They learn how to use the way they work in this company. And now this company told me that they will extend the training period with two more, so they are thinking to really rethink how they train people. And about for me, from what I'm seeing, the junior, the junior engineer. So there are AI agents, I agree that there are AI agents there, there will be a lot of for people that, uh, they will be constrained. And I think it has to be about for junior engineer, uh, think about. So, so I think there is, there is value in junior jobs. But I feel there is one thing that higher people that are fresh and and really help order people to do it. We are helping order people to from the sound what can they do with this tool.
[00:54:35] I want to emphasize that what you just said because I've been seeing the same thing. Uh, I consult a couple of tech firms, some of them are very AI-native companies that GitHub, uh, but also in shopping, and the pattern that you see in those companies. So they were very early adopters of AI and coding assistants, AI tools, of course, that GitHub came out. Uh, I know people who are still talking about the very interestingly that Copilot. Uh, so they have a very strong history of learning how to use them. And when you see in those companies, GitHub, uh, Shopify, Uber, you will learn. Is that the more experienced you are, the more they really value that people coming in and having their AI first, that's basically their AI. Um, and I don't want to to to bash older people, but it tends to be something where younger people are more competent when it comes to the edge of like that. So, uh, I don't know the best for for. So, I think developers in companies where organizations try to use it to save money. Try to not hire. We don't hire especially in this environment. But when they get to the point, what we see the more mature companies are, the AI mature companies are that I any team that will go back and recruit their junior skills.
[00:56:18] I just want to share two things. The first is really important what you said about. And connect with the chatbot. And maybe as we see in the software, the real act as the 40 years. So they are. Maybe you believe in that you have a new developers to to the company. And AI is not just something to save jobs or to also. So we should embrace and that. And like we always, you know. If you're a country year experience in software development, the chatbot that is there and then it's transcribed and from Java to JavaScript and you learn all the way how you can improve your skills and stay up to date. Just one new cycle of learning.
[00:57:27] You can have faith.
[00:57:33] I have a question about other don't take too much.
[00:57:45] I know, I know. It's good, stay there.
[00:57:50] The these people are actually doing AI at work, which is kind of actually quite rare at the moment. A lot of big companies are not letting people really go full tilt on this. And I think it was great that you're sharing these things because I think you'll agree with me, but we're really just starting the journey. We don't know what the practices are. We've got the tools. We don't know why we're using it. Apart from it seems to be making Elon Musk rich and, you know, um, destroying jobs, but we kind of haven't really found the value. We haven't found the practices yet. And I think that thank you, I'm very brave. I'm going to now open it out to questions. Uh, so just to remind you, this is why I'm saying we need we need to be listening to people actually doing this stuff, you know, the trail blazers we've got on the stage. Because they're doing it, they're seeing what the real problems are. When you talk to real practitioners, the issues they raise, like, this is a defense company. We're not even allowed to use AI. I'm very different to the ones that, you know, the thought leaders in this space are coming up with. Um, any questions? I've, I've asked them to stay up, just in case, but I think they're more interesting than me personally. So if anyone's got any questions, we've got a few minutes. where you can either ask me questions about the presentation or you can ask them about AI.
[00:59:14] So we've got a microphone that's kind of.
[00:59:21] Any questions? Early coffee by the look of it.
[00:59:29] Um, by the way, just I just want to say one thing and say thank you for my colleagues, building is one of the most mural for Europe and one of the good things as well is the boss is the strip. Um, and you can actually see the video. So, so, so you can look at the advertisement now climbing in the conversation.
[01:00:01] A bit cheesy, I know, sorry, but, you know, for you.
[01:00:07] Okay, are we good?
[01:00:12] I think we're good. I, I, I'm one of the naughty people. I'm leaving here at 4:00 PM. So, you can chat to me till 4:00 PM. After that, I hope you like trains.
[01:00:29] Thank you. And you have a 30 minutes break so you can have a coffee again. And uh, we can go back here or the rooms are upstairs.