 My name is Ken. I'm the Enterprise Learning Architect at SimCorp, and in this I'm going to try to tell you a little bit about how we adapted and changed our learning and development organization to fit our new agile setup. This is supposed to be a speed talk, so I have 20 minutes, but I need to give you just some quick background on sort of the circumstances for all of this. Can everyone hear me? Sorry? I don't know. Can we turn up the volume a little? No, okay. I'll speak louder then. Okay. Just a quick show of hands. How many of you have ever heard about SimCorp? Couple of people. All right, that's sort of to be expected. So I just need to tell you really quick we are. Basically, we have one product. It's called SimCorp Dimension. It's a product that's targeted for the investment management and asset management industry. So basically if you're a professional working with an investment, that's that's what our product is all about. We developed on this product for more than 40 years. So it would be accurate to say that we are not exactly a startup anymore. We were founded in 1971. Annually, we plow sort of roughly 20% of our revenue back into R&D. We have 1600 employees worldwide. And of those 1600, around 650 are working on the actual product, developing the product. We have offices around the globe. Basically all the major financial centers were Scandinavia. We were started in Denmark. So we have offices in Sweden and Norway, Scandinavia, but other it's Paris, New York. Basically where you have big financial centers. We have more than 16,000 end users and we have around 180 clients worldwide. So those are seven sort of relatable numbers. And you can ask, well, OK, you've been in business for 40 years and you only have 180 clients. That's four and a half client per year. What are you doing? So let me give you just one big number to sort of round the introduction of assets under management by SIMCorp clients, so 20 trillion US dollars. So that's trillion with a T. That's basically what dimension is used for. It is used to manage stupendous amounts of money. This is a number that is so large that it's hard to sort of relate to it. So just to give you something, when Sweden today, the gross domestic product, so the value of all the goods and services produced in Sweden, a country of 10 million people, a very productive country, was half a trillion. That's 40 times less. The GDP for the entire world was 80 trillion. And since it is an astronomical number, the estimated number of stars in the visible universe is 100 trillion stars. So it is a very large number and that's what dimension is all about. It is managing this kind of money. There you go. So every path to agile is different. Our path was, we chose SAFE, the Scaled Agile Framework. Anyone heard of that? Familiar with it? A couple of people. Okay. It is basically a framework that allows you to scale agile from team level over portfolio to the entire enterprise. This is doing some strange things. We introduced this in 2016 and then we spent pretty much a year doing nothing else but train the organization in how to be, how to work in this new setup. So the entire organization, learning and development in particular, was completely focused on this. We did nothing else but run this training program. We had over 200 courses. We had eight full-time agile coaches working on this that was basically everything. We had no bandwidth for anything else. So that's one thing that led us to change our organization. The second was that in order for us to do this, we changed our organization. So we had a very nice, normal, very understandable line structure in the past. We had this falls under our CTO. So this is basically his area. I'm sure you're familiar with this kind of structure. Our learning, we had also a very conservative, traditional approach. We had three different academies that was targeted at this. Software engineering, product management, project management. Each of the academies had an executive sponsor. It had a principal, which was basically a program manager. And then there was a steering committee that ran everything else. Once we introduced SAFE, then all of this disappeared. So I didn't even have a structure anymore. These are the new roles that SAFE worked with. So they were rolled out. Everything was focused on rallying around the agile teams, because that's where the value is created. And now we have an organization that looks pretty much like this. So a little more complicated than a nice, normal line. The important thing to note here is that there is a complete separation between execution, that's what we have over here, and people development, which we have over here. The teams are self-managing, self-organizing. So a completely new structure. So since we had this kind of blank piece of paper, we might as well think how can we change the organizational set of around learning and development to actually fit what we're doing since we don't have anything else and since we've been on hold for basically a year doing nothing but agile. How should the new organization look if we had a blank piece of paper, which we were lucky we had. So we wanted to create something that was durable, something that was scalable, and something that was agile. The main principles were that we needed to create a strong, sustainable link between the business and learning so that there wasn't a gap between that learning was over here and the business was running over here. It had to be in sync. We want a complete transparency around everything that had to do with learning. People should know exactly what was going on. It didn't matter what kind, where you were in the organization. We wanted to create as much transparency also around budgets as possible. The key part here is we wanted to engage, involve, support, and empower the development managers. So this was a new role that was introduced by SAFE. The development managers sort of simplifying this a little, but their key job is to develop people, to make sure that the people we have grow in the roles that they have, that they become better for want of a better world. And then we needed to ensure that the business critical behaviors and skills that we had actually got the bandwidth that we needed. That was a challenge we had in the past. How, without adding headcounts to an L and D organization, how can we actually create enough bandwidth to support all the stuff that we're doing? And finally, obviously, we wanted to create a fit between the new ITL organization and everything else we were doing that had to do with learning and development performance management. So blank piece of paper. We had our new organization. We had the ITL teams. The teams were picked up by the art structure. That's a SAFE concept. Don't worry so much about that. We had a new leadership structure. And we had the development managers who were organized around the geographies that we were located and so mainly this part of the organization is in Denmark and it is in Kiev and the Ukraine. Then we have small satellites in Germany and UK as well. So a development manager works with the people in the country that they're in. We also had a strategy farm. The development managers, along with the enterprise leadership team, get together. They define a strategy, a business strategy, and that's basically the starting point for what we were doing. So we work with behavioral competencies and we work with something we call strategic skills. So basically something that's important enough to take to an enterprise level. And we wanted to ensure that that was business driven. So as soon as we have a business strategy, we look at that, we look at our behavioral competencies and we say, okay, what do we need in order for us to do, to execute on the strategy? These are just examples and the same, oh, sorry, and you can sort of sum that up into what we would define as our agile mindset. The same with strategic skills, coaching and facilitation, safe know-how, databases, architecture, C-sharp development. All of this is something that we could derive from our business strategy. Once we had that, we would create a learning strategy and say, okay, this is what we want to do. This is how we can support this as best as possible. And then the really big thing was that since we changed the organization, we now had an opportunity to centralize the budget. So instead of having learning and development budgets that basically rested within each of our organizational entities, be it a group, a unit, a division, we said we have one budget for learning and development. And we took a two-pronged approach to that. We have a discretionary budget. That discretionary budget is money that we allocate directly to the development managers because they have stuff that is not offered on a corporate level. And then we have the enterprise level and then we have the enterprise activities. So we have, for instance, a C-sharp course that everyone has to take. It makes sense that we have that over here, but there might be a specific conference, a specific training event that would be covered by the discretionary budget. Organizing all of this, we have the learning architect. It sort of sits in the middle of everything and tries to coordinate. And then we pulled the rest of the organization into this. So we pulled our development managers into this. We pulled our agile coaches into this. And we pulled product management into this because those are the three major stakeholders that we have in this. And then we looked at what we defined based on strategy over here and said, okay, it makes sense if you take charge of this, you become learning owners for this area that we call the agile mindset. And you might join up. So here we have a development manager working closely with an agile coach. So they take responsibility for that and they become learning owners for that area. And I'm sure you get the gist here. All of these are then sliced out and they're allocated a learning owner or team of learning owners who then run with it. The discretionary spending, as I said, that goes basically just into the development managers. They're free to use that for whatever they want to use it for the only thing that's important for us is that we sort of track it so that we can get inspiration if you send someone on a course. And it's a great course. It's important that the rest of the organization knows about it. But other than that, it is discretionary spending. It's also important and it sort of feeds into this centralized budget is at some point we would want to have the teams themselves have a budget for this. So that there wasn't a buffer in that you had a development manager who was actually allocating it. But the teams themselves would have the budget and they could spend it on whatever they wanted. All of this sort of feeds into a normal budget process would mean that you would sit down at, sorry, in Q4 usually. And then you would make a list of line items and saying this is what I would like to be doing for the next year. And you would try to guess, what am I gonna be doing in Q4 next year? It never works that way. But nevertheless, that's the budget process. So that's how we did it. But since we could now sort of change everything, that's what we did. We said, instead of having a fixed process, we say, okay, we have a reasonable guess as to how much money we're gonna need. Safe runs in program increments. In SimCorp, we run three-month program increments. Why not do the same with learning and say we're running learning increments? So every three months, we do a learning increment. And every three months, we decide what are we actually gonna spend money on. Now we can certainly say, okay, we already know that we're gonna need something in Q4. But other than that, we try to keep as much flexibility in our budget as possible. We don't commit to things that we just think we have. We make the decision based on what the actual need is. We have a support structure for all of this. We have learning management systems, all these kinds of things. And we have performance management processes that are being revamped to fit agile. But the key essence in this is that instead of trying to guess, which was what we had to do in the past, what are we gonna be doing a year out? We took just the natural consequences of that and said, no, we're gonna chop this up into three-month increments. That also meant that when our development organization hits into or starts a program increment, because we're timing this, they have a full picture of what kind of learning is gonna be available for that increment. And they can adjust their capacity based on knowing that we have this course running, we have that course activity. Okay, that means that our capacity is gonna be instead of 100%, it's gonna be 80%. And every basically ladder rinse repeat. The strategy process repeats itself every year and we start this process all over again. Yes, it's basically just a time duration. So it's a three-month period. So an increment is just, it comes from safe where you say you have a program increment of three months. So we say, okay, a program increment is how much we're gonna produce on the product. A learning increment is how much are we gonna produce in learning and we just slice that into a three-month period. It might make a little more sense because in order for us to manage all of this, we said, okay, we'll use just a traditional Kanban approach. So every three months, everyone who's involved in learning meet, we have the Kanban bought up and then we decide what are we gonna take from the backlog and move into doing and what are we gonna start executing on. So if you sort of put some, try to populate this, then there are five things that you can, that we start every learning increment by doing. The first thing is you look at the web limit and here we're not just looking at what is an individual team learning team able to do. Are they within their web limit? But we can also look at the entire enterprise and say, are we actually trying to roll out too much learning? That was a problem we had. Sometimes we would be offering courses and the business would come back to us and say, well, it doesn't work for us because we have this, that or the other happening in this particular increment. So you can't be running these courses right now. We need to sort of readjust that. Here we have complete visibility of everything we're doing, both in terms of what the teams are doing but also across the entire enterprise. So if we had two test related courses running, then the business could come back and say that's not really good for us because we have a lot of testing that needs to be done here. Can you move that back? Can you reschedule that to the next increment? The next one is we have Ideas Request New Knowledge as part of this particular Kanban board. This was a way to open up learning to the entire organization so that everyone could just pitch in with whatever ideas they had. This is something that we should be doing. So one thing was democratizing for one of a better word, the process around learning. But it's actually also a very interesting monitoring tool where we can see if we have emerging technology and we only have one thing in that, then a couple of red lights might go off and say, are we seriously not generating any new knowledge within this space? Is there nothing we want to share with the rest of the organization? The third is the budgets. I've already talked a little about that, but basically instead of trying to fund everything, we look at what's our backlog, what is important right now, and then we fund according to that. And it also means that we can look at, so just as an example, the agile mindset. If we have, this is full up and it's very, very expensive all of it, then I might need to have a conversation with the learning owners for that and say we can't spend our entire budget on this because money is a finite resource in all of this. And fourth is learning strategy. Instead of trying to know exactly what we're gonna be doing a year out, we basically revisit this every three months. Are we still on track? Are we still actually trying to do what the business needs for us? And the fifth is the done column where we instead of just having a done column, this, oh, sorry, to a large degree. So everything is the old traditional 70, 20, 10. I get back to it in one second. So basically done becomes the repository for all the different knowledge that we have. It's not just, as you say, it's not just courses, but it's everything we have. So we need to figure out how do we take the done column here and put that into the various different internet learning portals, everything we have. How do we then make sure that it's visible to everyone? Yeah, no, every quarter. No, I, yeah, yeah, the top line is fixed. The top line is fixed. Yeah, not necessarily that way, but so just as a round number, let's say I have a million euro to spend every year, that number is fixed. Finance is not gonna come and give me anything more than that, but how we distribute it across the different skills that can change every month. So we might go into a year saying we expect to be spending 25% of our budget on agile skills, but it turns out that we actually need to spend more on our technical skills. And those are decisions we make every corner. It also just, and the discretionary budget as well. So we start off by, we don't allocate everything, we do it in the increment way. So every increment we decide how much money is gonna be discretionary spending and how much is gonna be enterprise spending. And then just to add just the two new roles that we've introduced, we introduced the role of the learning architect. Basically the learning architect facilitates the strategy process, the facilitate the budgeting process, they own the learning budget and the learning strategy. They facilitate the decentral budget distribution and allocation process. They coordinate capacity and coverage with our senior leadership team. They drive the execution, mainly through the Kanban process. They coach and they advise learning owners. This is a very important thing because what we've basically done is we've taken a lot of people, we brought them into our learning setup. Not all of them have a background within learning. Most of them have, are good, can get stuff done. They can go out, they can contract with a vendor, they can do whatever, but they might not have a theoretical approach to learning. So coaching and advising is a big part of it. Coordinating with different parts of the rest of the company. So we have a group learning, that's actually why I belong. We have a group learning function. How do we coordinate with that? How do we talk to our leadership academies making sure that they get the right input from this part of the business? And then they align with different global processes. Could be performance management. And again, they align best practice approaches and they define what best practice is within, within research and development. So if you look at the words here, facilitate, facilitate, facilitate, there's only, this role has a tremendous amount of influence and very little real power. And it's been designed exactly to do that. The only lever that the learning architect has is the budget. But you have to work very closely with the rest of the team to make sure that this gets done. But other than that, the learning architect is not intended to be someone who just makes decisions and say, okay, this is the way we're gonna be going. Because we wanted to create the new role which is, so it says development manager, but think of these as learning owners. They own whatever budget they get allocated. So if they come and ask for 100,000 euro and we allocate that to them, they own that money. There's no approval process. They don't have to come and check. They have to spend within their limits, but other than that, they own whatever money they have. They define and evolve a 70, 20 cent based curriculum. That's something that we try to drive, as you said, not just courses, but everything else. They obviously need to identify and work with different stakeholders within the organization. They drive the development of the learning material and the key here is they drive. They're not supposed to sit down. They're welcome to do it if they want, but they're not supposed to sit down and create learning material. They are prime movers. They start the process. They prepare and they lead the area that they have once we get to the Kanban process. That's a hugely important thing in this because if you try to do everything in here, then you don't have it. You're not passionate about anything. And I wanted to have people who were passionate about their area. I wanted someone who would step up and slam their fist on the table and say, you know what? This is the single most important thing that we do. Maybe we disagree, but we wanted that kind of passion into the system. They're sparring partners for the rest of the organization. So if we have a learning owner for C-Shop, it makes sense that other development managers come and talk to that person and get their input on how best to develop people who are working with this particular skill. And they facilitate the creation and execution of effective communities of practice within their area if needed. So if we don't have a COP within something that we think is important, they might try to establish one, but still it's a COP. They're not trying to run it. They're just trying to facilitate the creation of it. So basically, we have been doing this for around a year. I think we are on the right track. Right now we're working with 14 strategic skills that have been identified. We have 21 learning owners who are assigned and who are on the job. And we have complete transparency and visibility to a number of dashboards that we've created where everyone can go in and see everything that's going on. So in 20 minutes or less, that was the very quick introduction to how we are doing this in Simcoe. I'm happy to take any questions sort of offline once we get there. Thank you.