WEBVTT
1
00:00:06.000 --> 00:01:30.000
Welcome to the AXIOM Insights Learning and Development Podcast. I'm Scott Rutherford. This podcast series highlights the expertise of L and D leaders and focuses on driving performance through learning. This episode is the second of three parts of my conversation with L and D leader and learning experience specialist Tom Decker, exploring his experience in the development and launch of a learning ecosystem and within a Fortune 500 company for a staff of 18,000 people. In part one, we talked about the strategy behind the work. We defined the objective and how to make the business case and identify resources, and also how to help internal leaders see the value of what you're building. In this episode, we move into the build itself, how to approach the learner experience, how to think about the minimum viable product, and how to structure the work so the ecosystem can evolve with needs over time. Tom also offers some practical advice on how to find people within the organization who may be able to contribute to the project, including engineers or other technical staff who may be able to use the project as a valuable career development opportunity. We also get into the technical side of the ecosystem, modular design, vendor integrations, APIs, data standards, and the importance of making sure the pieces connect the way you want them to. So with that, here's part two of my conversation with Tom Decker.
2
00:01:30.000 --> 00:01:36.000
If you have the. If you have the team in place that can technically start developing a product. Or are you asking before that?
3
00:01:36.000 --> 00:02:12.000
Well, I'm saying before that, if you. I mean, the question is that even if you have a team of ready engineers, the question is they're already working on something for a reason, so you're going to be pulling them off of one project and assigning them a new assignment. So you're shifting resources you do have, which is sort of even the easier scenario. Or you're making a case to say, we need to hire, we need to contract, we need to outsource, depending on the flavor you're pursuing. But there's a change management and a resource allocation question, which has got to be. Moment one.
4
00:02:12.000 --> 00:02:59.000
Yeah, yeah. And I think so regardless of. Well, I guess let's say it this way. If you don't have the team in place, right. What are your options? And I think you mentioned it, right? You can contract out. There are a lot of companies, I think, that value employee development and stretch assignments. And so maybe there's engineers within the organization that might like an opportunity to work on something a little bit different. And maybe it's an opportunity to start digging into a different code base and things like that. So I think, you know, exploring within what are Some of the options to get one of those technical resources that can start chipping away at something. And then, and then it's a matter of determining, well, what does your minimal viable product look like?
5
00:02:59.000 --> 00:03:00.000
Right.
6
00:03:00.000 --> 00:05:25.000
What does your MVP look like? What is, what is something that we can build that will get value immediately. Right. It doesn't have to be the whole shebang. What is, what is, what can we build right away? And so I think for us, we prioritized the universal concept. We had a lot of vendor tools like Pluralsight and Udemy and O'Reilly, and we had access to all of these resources that we knew we wanted to centralize within that lxp. And so we prioritized the universal single point of entry across the entire enterprise. And so it wasn't just for the resources we were using in technology, it was for resources we were using beyond. And a couple at the enterprise level. That was number one. Our thought process there was, we don't want people to come in here and have this incomplete experience. This is what we're pitching, is a complete experience. And so we want it to truly be complete when we get to that MVP status. Now, we did the big ones. And so that was the other thing too, is maybe you do the big ones and not all of them. And so we launched at the beginning with a handful of those, those major vendors that were connected, and it gave you basic functionality, which was your search, so your ability to search through the entire catalog, and a homepage which gave you access to some of this content that you saved. We gave them the ability to save content, and we gave other learning teams the ability to prioritize specific content as if they were a channel on YouTube, essentially. And that was kind of a similar architecture blueprint that we had followed. And so we created this homepage kind of idea and the channel views and the basic search and filter functionality, and then we just expanded from there. So those were like the core pieces that we knew were going to add value right from the start. And then constant enhancement every single month, every few weeks, we're constantly iterating and building new features, new functionality, new capabilities
7
00:05:25.000 --> 00:05:29.000
into the platform, building the pieces of the whole incrementally.
8
00:05:29.000 --> 00:05:42.000
Exactly. Yep. Which never ends. Right. And in an agile engineering team, right, you're never really done. And so we're constantly building and building and building more.
9
00:05:42.000 --> 00:06:27.000
Yeah, so I'm referring a little bit, actually, and I'll share a version of this graphic. It's something that you had shared on LinkedIn a few weeks ago, which I copied for Myself, because I like the diagram. But it essentially is a visual representation of the LXP and the integrated learning experience as the core, as the hub around which all of these pieces circulate or tie into. So you're talking about a lot with just to drop the O'Reilly, for example, there, your content repositories that you're bringing in, that's one petal on the flower, if you will, to try to help folks visualize what I'm talking about. But you don't have to have all of them all at once.
10
00:06:27.000 --> 00:07:24.000
Right, right. You can, yeah. So, you know, and I think, I think one of your questions kind of goes into this too, right. Where we prioritized building via modules. Right. And then it's a plug and play concept. And so each of those petals, they can be off the flower and you can put them onto the flower whenever you want, you can remove them and replace it with another one. And so that was the idea of this ecosystem, was that it followed this very plug and play concept, which enabled us to maintain flexibility long term. So that wasn't just a short term solution because it was easier to just pop these in. That's long term thinking. We know that we're going to continually pull some of these pieces out and pull new ones in. Being able to just connect them via these modules was important.
11
00:07:24.000 --> 00:08:20.000
How difficult was it for you and your team to navigate the protocols required for those integrations? And I think there's another resource I'll share which I had found on the EdTech Insiders. I'm happy to give credit to folks who put out good content, but there's everyone, I think knows of Scorm and Tin Can X API, but there's a litany of other protocols that exist in the world. Part of what we're talking about here for you and your team then has to be understanding not just, okay, what are the pieces that we want to fit together to make this whole work and play well together, but what are the underlying protocols that we need to understand and integrate? And you need to start making decisions about how it's actually going to work on a very, very granular level.
12
00:08:20.000 --> 00:11:19.000
Yeah, yeah. I think there's two sides to this. And so for us, when we start and we just think about within our group what's important to us, we wanted to use more modern technology. We had been building some of our tech with some older, outdated technology that was still serving us well, but we knew that it wasn't going to take us too much further into the future. And so we needed to shift to something that was a little bit more modern and we had started building our front end on React and using Node js. So for anybody that's got a technical background, that was kind of the programming that we had built our tech stack on. We knew that that was going to give us some modern capabilities. And we knew that over time if we were partnering with modern software solutions that would be easy, it would be a no brainer. Now the second part of that was ultimately we know what modern stack we want to work with and so how do we partner with the right vendors that can easily connect with us? Right. And so if we're using RESTful APIs, we might want to avoid those vendors using SOAP. Not that we can't, but you know, those are things that we have to really think through. We would spend time and this is something that I think we would, we would probably prioritize a little bit more early on is partnering with our internal leaders who are going out and grabbing solutions and talking to contractors and maybe even getting a little bit further down that road and engaging in a contract without engaging with us first. And so, you know, it takes time to fully adopt to a new model into a modern ecosystem. We were no different and we still had gaps where people were moving a little bit faster and kind of perpetuating the multiple disparate technology problem that we had solved. And so what we needed to do was spend more time in some of those early conversations and, and bring our technical people together to understand how do these pieces come together. In some cases, some software solutions had to build completely brand new API connection points from scratch in order to accommodate connecting within our ecosystem. Now some may not do that and some may, but still that's extra time and effort that might not have been planned for when the contract was signed. And so having those conversations early is going to be important to ensure that the technologies can speak together in the way that you need them to. And so I think that's going to be an important piece of kind of bringing that all together for sure.
13
00:11:19.000 --> 00:12:03.000
I think what you alluded to there a little bit is one of the real people risks of putting a large project together, which is to say, and this is the sort of ever present tension within centralized versus federated models of management because you don't want to be the bottleneck or what people think are slowing them down. If they're going off and trying to move forward maybe faster than you're ready for or aware of. It is not a comfortable position. Often to say okay, slow down, wait for us and let's integrate this because you then become perhaps a roadblock or perceived that way.
14
00:12:03.000 --> 00:12:13.000
Right? Yeah. Slow down are the two words you don't want to hear in the corporate space nowadays. Right. You can't get too far with that.
15
00:12:13.000 --> 00:12:27.000
So based on the work you've done in building this ecosystem, what is there one thing you would do differently that, that, that you sort of learned the hard way?
16
00:12:27.000 --> 00:14:00.000
I'm going to, I'm going to say this and I'm not sure if I would do anything differently. And I think one of our challenges early on was getting everybody on the same page. I had a really difficult time helping some of the, my business owners essentially, which was all the learning leaders across the, across the company truly comprehending what we were doing. Right. They all had stake in it, they were all accountable for it and they were all excited about it. But the day to day and I think the need for speed and the competing priorities were a challenge. At a certain point we had certain business units that were all on board ready to go. We had solutions set up for them. And then later on down the road we're like, okay, we need to do this across the entire enterprise. And that changed how our solution looked, how it felt. It quite frankly changed the architecture of it a bit. I think it was better afterwards, to be honest with you. But it was really, really difficult to help business owners who had already been settled into a solution move to something that felt for them a little less personalized. So I think going back.
17
00:14:00.000 --> 00:14:09.000
Sorry. Because you've built a compromise, you've built an organizational wide compromise that's a little further afield from what they've built for their own interests.
18
00:14:09.000 --> 00:16:33.000
Correct? Yeah. And I think this, this concept of, you know, being one as a, as a company, as learning professionals, while we are decentralized, you know, there's, there's a lot of give and take there, as you mentioned. Compromise. Right. And so I think that was the challenge and helping. I, I gave something to certain folks that had exactly what they needed and then kind of stripped a little bit back and they lost a little bit. Now we worked through it together, but I think that that created some, some tension points. It created some friction that quite frankly, I, I think maybe frustrated and caused us a little bit of stress. We, we moved through it, we moved forward. I'm not sure if, if I lost advocacy or adoption from some of those groups, that was, that was part of the challenge. And so I think early on what I would, and, and I don't know that I could have done this different to be honest with you, because the, the whole one enterprise solution was really not on, on the table at the time. I didn't, I didn't think we would, we would get there as fast as we did. The product was, the product sold itself at that point and there was no stopping it. So I, I think I probably would have, would have tried to figure out how to get to that, that final solution earlier. Hindsight's 20 20, I, I, I don't know that I knew that this would happen but I think now, knowing what I know, try to get to that final solution quicker to avoid having to take stuff away from a subset of some of my business owners. So I think I would have done that a little differently. I probably would have spent a little bit more time upfront educating some of those business owners on the process itself. We were all new to agility and being an agile team. So I had the engineering team, we were an agile team and we started to adopt a more rigorous agile process. And, and so we were learning that as well as some of these HR leaders too. And that was new for them. And so, you know, we're trying to, in a lot of ways we were flying the plane as we were building it and that was difficult. I think I would have given our, I would have tried to find a way to build a little bit more Runway first.
19
00:16:33.000 --> 00:16:52.000
Right. And it's a change management initiative that you're taking. It's not just a technical build, it's a process change and it's changing the way people work and expect to work. And the human resistance to change is not something to trifle with.
20
00:16:52.000 --> 00:17:35.000
Exactly, exactly. I think that's the other thing too that we didn't have upfront was a dedicated change management team for this. I don't know that we knew it was going to be as big as it ended up being. To be honest with you. I think that was another thing that we're just, we didn't think it would blow up like it did. And I would have advocated for maybe some stronger, some dedicated change management resources because change management is, there's a lot of skill and knowledge in that function. And I think having somebody who knows what they're doing when it comes to change management would have been immensely beneficial for that as well.
21
00:17:35.000 --> 00:17:57.000
And being able to work with each stakeholder to say here's what you're gaining, you maybe feel or maybe losing, maybe actually be losing some things. You may feel like you're losing control of other things. But being able to have that transparency again. We've talked about transparency earlier as being so important. Keeping that line of communication open to folks is so important to keep them on board too.
22
00:17:57.000 --> 00:17:58.000
Agreed.
23
00:17:58.000 --> 00:19:29.000
Yes, thanks again to Tom Decker for his insights here. This was the second of our three part series. The next episode will be the final one with Tom. In part three, we'll turn to what happens at and after launch. Tom will talk about managing the live solution, keeping stakeholders informed, supporting user adoption, and designing an experience that feels familiar and expected for learners. We'll also discuss the larger question of whether L and D teams need stronger partnerships with engineering and technical talent within the organization, especially as companies move toward build and buy hybrid approaches to learning technology. And you'll find all of these episodes with transcripts and link to additional resources on the Episode pages@axiomlearningsolutions.com Podcast thanks for listening. This has been the AXIOM Insights Learning and Development Podcast. This podcast is a production of AXIOM Learning Solutions. AXIOM is a learning and development services firm with a network of learning professionals in the US and worldwide, supporting L and D teams with learning staff augmentation and project support for instructional design, content management, content creation and more, including training, delivery and facilitation, both in person and virtually. To learn more about how AXIOM can help you and your team achieve your learning goals, visit axiomlearningsolutions.com and thanks again for listening to the AXIOM Insights podcast.
1
00:00:06.000 --> 00:01:30.000
Welcome to the AXIOM Insights Learning and Development Podcast. I'm Scott Rutherford. This podcast series highlights the expertise of L and D leaders and focuses on driving performance through learning. This episode is the second of three parts of my conversation with L and D leader and learning experience specialist Tom Decker, exploring his experience in the development and launch of a learning ecosystem and within a Fortune 500 company for a staff of 18,000 people. In part one, we talked about the strategy behind the work. We defined the objective and how to make the business case and identify resources, and also how to help internal leaders see the value of what you're building. In this episode, we move into the build itself, how to approach the learner experience, how to think about the minimum viable product, and how to structure the work so the ecosystem can evolve with needs over time. Tom also offers some practical advice on how to find people within the organization who may be able to contribute to the project, including engineers or other technical staff who may be able to use the project as a valuable career development opportunity. We also get into the technical side of the ecosystem, modular design, vendor integrations, APIs, data standards, and the importance of making sure the pieces connect the way you want them to. So with that, here's part two of my conversation with Tom Decker.
2
00:01:30.000 --> 00:01:36.000
If you have the. If you have the team in place that can technically start developing a product. Or are you asking before that?
3
00:01:36.000 --> 00:02:12.000
Well, I'm saying before that, if you. I mean, the question is that even if you have a team of ready engineers, the question is they're already working on something for a reason, so you're going to be pulling them off of one project and assigning them a new assignment. So you're shifting resources you do have, which is sort of even the easier scenario. Or you're making a case to say, we need to hire, we need to contract, we need to outsource, depending on the flavor you're pursuing. But there's a change management and a resource allocation question, which has got to be. Moment one.
4
00:02:12.000 --> 00:02:59.000
Yeah, yeah. And I think so regardless of. Well, I guess let's say it this way. If you don't have the team in place, right. What are your options? And I think you mentioned it, right? You can contract out. There are a lot of companies, I think, that value employee development and stretch assignments. And so maybe there's engineers within the organization that might like an opportunity to work on something a little bit different. And maybe it's an opportunity to start digging into a different code base and things like that. So I think, you know, exploring within what are Some of the options to get one of those technical resources that can start chipping away at something. And then, and then it's a matter of determining, well, what does your minimal viable product look like?
5
00:02:59.000 --> 00:03:00.000
Right.
6
00:03:00.000 --> 00:05:25.000
What does your MVP look like? What is, what is something that we can build that will get value immediately. Right. It doesn't have to be the whole shebang. What is, what is, what can we build right away? And so I think for us, we prioritized the universal concept. We had a lot of vendor tools like Pluralsight and Udemy and O'Reilly, and we had access to all of these resources that we knew we wanted to centralize within that lxp. And so we prioritized the universal single point of entry across the entire enterprise. And so it wasn't just for the resources we were using in technology, it was for resources we were using beyond. And a couple at the enterprise level. That was number one. Our thought process there was, we don't want people to come in here and have this incomplete experience. This is what we're pitching, is a complete experience. And so we want it to truly be complete when we get to that MVP status. Now, we did the big ones. And so that was the other thing too, is maybe you do the big ones and not all of them. And so we launched at the beginning with a handful of those, those major vendors that were connected, and it gave you basic functionality, which was your search, so your ability to search through the entire catalog, and a homepage which gave you access to some of this content that you saved. We gave them the ability to save content, and we gave other learning teams the ability to prioritize specific content as if they were a channel on YouTube, essentially. And that was kind of a similar architecture blueprint that we had followed. And so we created this homepage kind of idea and the channel views and the basic search and filter functionality, and then we just expanded from there. So those were like the core pieces that we knew were going to add value right from the start. And then constant enhancement every single month, every few weeks, we're constantly iterating and building new features, new functionality, new capabilities
7
00:05:25.000 --> 00:05:29.000
into the platform, building the pieces of the whole incrementally.
8
00:05:29.000 --> 00:05:42.000
Exactly. Yep. Which never ends. Right. And in an agile engineering team, right, you're never really done. And so we're constantly building and building and building more.
9
00:05:42.000 --> 00:06:27.000
Yeah, so I'm referring a little bit, actually, and I'll share a version of this graphic. It's something that you had shared on LinkedIn a few weeks ago, which I copied for Myself, because I like the diagram. But it essentially is a visual representation of the LXP and the integrated learning experience as the core, as the hub around which all of these pieces circulate or tie into. So you're talking about a lot with just to drop the O'Reilly, for example, there, your content repositories that you're bringing in, that's one petal on the flower, if you will, to try to help folks visualize what I'm talking about. But you don't have to have all of them all at once.
10
00:06:27.000 --> 00:07:24.000
Right, right. You can, yeah. So, you know, and I think, I think one of your questions kind of goes into this too, right. Where we prioritized building via modules. Right. And then it's a plug and play concept. And so each of those petals, they can be off the flower and you can put them onto the flower whenever you want, you can remove them and replace it with another one. And so that was the idea of this ecosystem, was that it followed this very plug and play concept, which enabled us to maintain flexibility long term. So that wasn't just a short term solution because it was easier to just pop these in. That's long term thinking. We know that we're going to continually pull some of these pieces out and pull new ones in. Being able to just connect them via these modules was important.
11
00:07:24.000 --> 00:08:20.000
How difficult was it for you and your team to navigate the protocols required for those integrations? And I think there's another resource I'll share which I had found on the EdTech Insiders. I'm happy to give credit to folks who put out good content, but there's everyone, I think knows of Scorm and Tin Can X API, but there's a litany of other protocols that exist in the world. Part of what we're talking about here for you and your team then has to be understanding not just, okay, what are the pieces that we want to fit together to make this whole work and play well together, but what are the underlying protocols that we need to understand and integrate? And you need to start making decisions about how it's actually going to work on a very, very granular level.
12
00:08:20.000 --> 00:11:19.000
Yeah, yeah. I think there's two sides to this. And so for us, when we start and we just think about within our group what's important to us, we wanted to use more modern technology. We had been building some of our tech with some older, outdated technology that was still serving us well, but we knew that it wasn't going to take us too much further into the future. And so we needed to shift to something that was a little bit more modern and we had started building our front end on React and using Node js. So for anybody that's got a technical background, that was kind of the programming that we had built our tech stack on. We knew that that was going to give us some modern capabilities. And we knew that over time if we were partnering with modern software solutions that would be easy, it would be a no brainer. Now the second part of that was ultimately we know what modern stack we want to work with and so how do we partner with the right vendors that can easily connect with us? Right. And so if we're using RESTful APIs, we might want to avoid those vendors using SOAP. Not that we can't, but you know, those are things that we have to really think through. We would spend time and this is something that I think we would, we would probably prioritize a little bit more early on is partnering with our internal leaders who are going out and grabbing solutions and talking to contractors and maybe even getting a little bit further down that road and engaging in a contract without engaging with us first. And so, you know, it takes time to fully adopt to a new model into a modern ecosystem. We were no different and we still had gaps where people were moving a little bit faster and kind of perpetuating the multiple disparate technology problem that we had solved. And so what we needed to do was spend more time in some of those early conversations and, and bring our technical people together to understand how do these pieces come together. In some cases, some software solutions had to build completely brand new API connection points from scratch in order to accommodate connecting within our ecosystem. Now some may not do that and some may, but still that's extra time and effort that might not have been planned for when the contract was signed. And so having those conversations early is going to be important to ensure that the technologies can speak together in the way that you need them to. And so I think that's going to be an important piece of kind of bringing that all together for sure.
13
00:11:19.000 --> 00:12:03.000
I think what you alluded to there a little bit is one of the real people risks of putting a large project together, which is to say, and this is the sort of ever present tension within centralized versus federated models of management because you don't want to be the bottleneck or what people think are slowing them down. If they're going off and trying to move forward maybe faster than you're ready for or aware of. It is not a comfortable position. Often to say okay, slow down, wait for us and let's integrate this because you then become perhaps a roadblock or perceived that way.
14
00:12:03.000 --> 00:12:13.000
Right? Yeah. Slow down are the two words you don't want to hear in the corporate space nowadays. Right. You can't get too far with that.
15
00:12:13.000 --> 00:12:27.000
So based on the work you've done in building this ecosystem, what is there one thing you would do differently that, that, that you sort of learned the hard way?
16
00:12:27.000 --> 00:14:00.000
I'm going to, I'm going to say this and I'm not sure if I would do anything differently. And I think one of our challenges early on was getting everybody on the same page. I had a really difficult time helping some of the, my business owners essentially, which was all the learning leaders across the, across the company truly comprehending what we were doing. Right. They all had stake in it, they were all accountable for it and they were all excited about it. But the day to day and I think the need for speed and the competing priorities were a challenge. At a certain point we had certain business units that were all on board ready to go. We had solutions set up for them. And then later on down the road we're like, okay, we need to do this across the entire enterprise. And that changed how our solution looked, how it felt. It quite frankly changed the architecture of it a bit. I think it was better afterwards, to be honest with you. But it was really, really difficult to help business owners who had already been settled into a solution move to something that felt for them a little less personalized. So I think going back.
17
00:14:00.000 --> 00:14:09.000
Sorry. Because you've built a compromise, you've built an organizational wide compromise that's a little further afield from what they've built for their own interests.
18
00:14:09.000 --> 00:16:33.000
Correct? Yeah. And I think this, this concept of, you know, being one as a, as a company, as learning professionals, while we are decentralized, you know, there's, there's a lot of give and take there, as you mentioned. Compromise. Right. And so I think that was the challenge and helping. I, I gave something to certain folks that had exactly what they needed and then kind of stripped a little bit back and they lost a little bit. Now we worked through it together, but I think that that created some, some tension points. It created some friction that quite frankly, I, I think maybe frustrated and caused us a little bit of stress. We, we moved through it, we moved forward. I'm not sure if, if I lost advocacy or adoption from some of those groups, that was, that was part of the challenge. And so I think early on what I would, and, and I don't know that I could have done this different to be honest with you, because the, the whole one enterprise solution was really not on, on the table at the time. I didn't, I didn't think we would, we would get there as fast as we did. The product was, the product sold itself at that point and there was no stopping it. So I, I think I probably would have, would have tried to figure out how to get to that, that final solution earlier. Hindsight's 20 20, I, I, I don't know that I knew that this would happen but I think now, knowing what I know, try to get to that final solution quicker to avoid having to take stuff away from a subset of some of my business owners. So I think I would have done that a little differently. I probably would have spent a little bit more time upfront educating some of those business owners on the process itself. We were all new to agility and being an agile team. So I had the engineering team, we were an agile team and we started to adopt a more rigorous agile process. And, and so we were learning that as well as some of these HR leaders too. And that was new for them. And so, you know, we're trying to, in a lot of ways we were flying the plane as we were building it and that was difficult. I think I would have given our, I would have tried to find a way to build a little bit more Runway first.
19
00:16:33.000 --> 00:16:52.000
Right. And it's a change management initiative that you're taking. It's not just a technical build, it's a process change and it's changing the way people work and expect to work. And the human resistance to change is not something to trifle with.
20
00:16:52.000 --> 00:17:35.000
Exactly, exactly. I think that's the other thing too that we didn't have upfront was a dedicated change management team for this. I don't know that we knew it was going to be as big as it ended up being. To be honest with you. I think that was another thing that we're just, we didn't think it would blow up like it did. And I would have advocated for maybe some stronger, some dedicated change management resources because change management is, there's a lot of skill and knowledge in that function. And I think having somebody who knows what they're doing when it comes to change management would have been immensely beneficial for that as well.
21
00:17:35.000 --> 00:17:57.000
And being able to work with each stakeholder to say here's what you're gaining, you maybe feel or maybe losing, maybe actually be losing some things. You may feel like you're losing control of other things. But being able to have that transparency again. We've talked about transparency earlier as being so important. Keeping that line of communication open to folks is so important to keep them on board too.
22
00:17:57.000 --> 00:17:58.000
Agreed.
23
00:17:58.000 --> 00:19:29.000
Yes, thanks again to Tom Decker for his insights here. This was the second of our three part series. The next episode will be the final one with Tom. In part three, we'll turn to what happens at and after launch. Tom will talk about managing the live solution, keeping stakeholders informed, supporting user adoption, and designing an experience that feels familiar and expected for learners. We'll also discuss the larger question of whether L and D teams need stronger partnerships with engineering and technical talent within the organization, especially as companies move toward build and buy hybrid approaches to learning technology. And you'll find all of these episodes with transcripts and link to additional resources on the Episode pages@axiomlearningsolutions.com Podcast thanks for listening. This has been the AXIOM Insights Learning and Development Podcast. This podcast is a production of AXIOM Learning Solutions. AXIOM is a learning and development services firm with a network of learning professionals in the US and worldwide, supporting L and D teams with learning staff augmentation and project support for instructional design, content management, content creation and more, including training, delivery and facilitation, both in person and virtually. To learn more about how AXIOM can help you and your team achieve your learning goals, visit axiomlearningsolutions.com and thanks again for listening to the AXIOM Insights podcast.
