Scott Rutherford

Welcome to the AXIOM Insights Learning and Development Podcast. I’m Scott Rutherford.

This podcast series highlights the expertise of L&D leaders, all focused on driving performance through learning.

This episode is the second of three parts of my conversation with L&D leader and learning experience specialist Tom Decker, exploring his experience in the development and launch of a learning ecosystem within a Fortune 500 company serving a staff of 18-thousand people.

In the first part, we talked about the strategy behind the work: defining the objective, making the business case, identifying resources, and helping internal leaders see the value of the future state.

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 over time. He also offers practical advice on finding people inside the organization who may be able to contribute, including engineers or technical staff who may see 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 can actually connect.

Here is part two of my conversation with Tom Decker.

Tom Decker

If you have the team in place that can technically start developing a product. Or are you asking before that?

Scott Rutherford

Well, I'm saying before that. The question is even if you have a team of ready engineers, 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 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.

Tom Decker

Yeah. And I think regardless of.

Well, I guess let's say it this way. If you don't have the team in place, what are your options? And I think you mentioned it. 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 exploring within what are some of the options to get one of those technical resources that can start chipping away at something and then it's a matter of determining, well, what does your minimum viable product look like?

Scott Rutherford

Right.

Tom Decker

What does your MVP look like? What is something that we can build that will get value immediately. It doesn't have to be the whole shebang.

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. We're pitching 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 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 into the platform.

Scott Rutherford

Building the pieces of the whole incrementally.

Tom Decker

Exactly. Which never ends.

And in an agile engineering team, you're never really done.

And so we're constantly building and building and building more.

Scott Rutherford

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.

Tom Decker

Right. And I think one of your questions kind of goes into this too, where we prioritized building via modules. 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. And so being able to just kind of connect them via these modules was important.

Scott Rutherford

How difficult was it for you and your team to navigate the protocols required for those integrations? I think there's again 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 everyone I think knows of SCORM and Tin Can XAPI, 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.

Tom Decker

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? And so if we're using RESTful APIs, we might want to avoid those vendors using SOAP. Not that we can't, but those are things that we have to really think through.

We would spend time, and this is something that I think we would probably prioritize a little bit more early on, 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 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 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 bringing that all together for sure.

Scott Rutherford

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.

Tom Decker

Right.

Yeah, slow down are the two words you don't want to hear in the corporate space nowadays.

You can't get too far with that.

Scott Rutherford

So based on the work you've done in building this ecosystem, is there one thing you would do differently that you've sort of learned the hard way?

Tom Decker

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 my business owners essentially, which was all the learning leaders across the company, truly comprehending what we were doing. 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 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.

Scott Rutherford

Because you've built a compromise, you've built an organizational wide compromise that's perhaps a little further afield from what they've built for their own interests, correct?

Tom Decker

Yeah. And I think this concept of being one as a company, as learning professionals, while we are decentralized, there's a lot of give and take there, as you mentioned. Compromise.

And so I think that was the challenge and helping. 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 tension points. It created some friction that quite frankly frustrated and caused us a little bit of stress. We moved through it, we moved forward.

I'm not sure if I lost advocacy or adoption from some of those groups, that was part of the challenge. And so I think early on what I would have done, and I don't know that I could have done this differently, to be honest with you, because the whole one enterprise solution was really not on the table at the time. I didn't think we would get there as fast as we did.

The product sold itself at that point and there was no stopping it. So I think I probably would have tried to figure out how to get to that final solution earlier.

Hindsight's 20/20. 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 up front 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 so we were learning that as well as some of these HR leaders too. And that was new for them. And so 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.

Scott Rutherford

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.

Tom Decker

Exactly. And 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 kind of.

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.

Scott Rutherford

And being able to work with each stakeholder to say, here's what you're gaining. You maybe feel, or maybe losing. You may 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.

Tom Decker

Agreed. Yes.

Scott Rutherford

Thanks again to Tom Decker for his insights here. This was the second of three parts.

The next episode is the final one in this three part series with Tom.

In part three, we turn to what happens at and after launch. Tom talks 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&D teams need stronger partnerships with engineering and technical talent, especially as organizations move toward build-and-buy approaches to learning technology.

You can find all of these episodes with transcripts and links to additional resources on the episode pages at axiomlearningsolutions.com/podcast.

Thanks for listening.

‍

‍