I vividly remember the key moment: I was traveling, trying to enjoy the holidays, yet again I had to take an important conference call. Unavoidable. That call was indeed crucial.

At the Dutch Atlantic coast in a hotel room, I did not see much through the window. A heavy rain and strong winds were making my critical meeting more relaxed, since I had nowhere to go in such weather. Three key stakeholders from the customer on the other side of Atlantic, and me, a sole person, on this side of the meeting.

The inevitable question was very clear: "Will you do it? Will you embark on this flight?" It felt almost like a life or death decision. We were not (yet) ready. They were not (yet) ready.

The question concerned an innovative approach to the development of learning content. To me, and that was not so usual, the only decision possible was: "Yes." And I bravely responded: "Yes, let’s go together!" My positive answer was probably based on the reasoning that it was not "changing the course" entirely, it was more about "changing the altitude." I was aware of trends and the need to change: the digitalization of learning was on the horizon.

Already at that moment, I strongly believed in my decision. Sometimes you just have to take a chance.

Taking the chance

In this specific case, we were contemplating a significant change: We were switching from traditional sequential development of training content in PowerPoint and Word to Extensible Markup Language (XML)-based authoring in a new tool with a more agile methodology. We would be following the "develop once; use multiple times" approach (also called single-source authoring).

The problem was my team. What would be the best way to bring the news to them? To me, it was very good news, even though there was some uncertainty in it. But my team was not ready. I knew some members would resist the change. A former boss I had consulted also did not believe in making this change.

Yet I knew that this decision would strengthen our relationship with the customer, would bring our teams closer together, and would put us ahead of competition. Making this change—taking the chance—would simply bring us to a new level. We would "change the altitude," enabling us to fly smoother and faster in the years to come.

So, I carefully crafted my presentation and delivered it in front of the entire team. Was it a change of course? Not entirely. It was much more a change of altitude to catch the right wind. Quoting Bertrand Piccard, who, with Brian Jones in 1999 circumnavigated the globe in a hot air balloon: "If there is no wind or it is waning, the only way to continue in the same direction is to change the altitude."

With the right wind you might even accelerate, as happened to the explorers in their last leg across the Atlantic.

At the moment of our decision, there was almost no wind in our existing content development business. Making this change was inevitable and essential.

What does it mean to 'change the altitude'?

When you want to go upward, changing altitude means throwing some ballast or weight overboard and/or firing the burner to add some heat—hot air to propel you upward, if you are in a balloon. Normally for a long balloon flight, you look for higher altitudes since the flight is smoother there, with no thunderstorms, more predictable wind, etc. In a similar manner, at that moment, I decided to reach for higher altitudes.

Off-load ballast

There was a lot of (mental) ballast we had to throw overboard so that we could achieve higher altitudes. We’d also need to replace that ballast with new approaches.

Key ballast that we had to throw overboard included:

  • Getting rid of the old mentality. Some of the (especially older) team members had been creating content "their way" forever—using PowerPoint and Word. In promoting the new approach, I focused more on younger members who were familiar with key software concepts and with some terminology that was as close as possible to XML. These team members were more open to new approaches. Software components were an essential element of the new, more automated process.
  • Forget past (negative) experience. Most of us had negative experiences, as we had gone through a similar "re-usability" attempt long ago. It didn’t end well. This approach, though, was completely different, so the team had to let past experiences remain in the past.
  • Unlearn some skills. We had to make room for the new skills and let go of some old ways of working. In this specific case, we had to start using a different graphics editing process and add more video. We also needed to change our approach to project management. We had skills gaps; and worse, we did not have a dedicated team for such work. We would need to upskill the existing developers—our subject matter experts—and they would need to unlearn some past concepts and approaches.
  • Stop being impatient. Any new approach means you will face some setbacks and you might lose your belief in the possibility of success. As we started, we experienced our first setbacks—issues with platform responsiveness, templates, and more. Yet, through the years we had continually grown with the platform and with the customer. At the time the transition was completed, we had been working much more closely together than ever before.

Fire the burner

After unloading ballast, we needed to take these steps to fire the burner (and increase the flame) to reach for higher altitudes:

  • Create a new job position or even a new department. In our specific case, due to the complexity of our production processes, we decided to form a new department (here, my peer manager from another department was instrumental). This small, newly formed department became the core of all the development processes, especially with respect to content production and quality assurance. Somehow, it tied all the developers and other team members together. It became "one source of truth." This new organization instilled extra motivation in the team.
  • Hire new people and upskill (or reskill) team members. Our team had to do a lot of learning before we were able to demonstrate the first results. And we had to learn quickly. Fortunately, we were not heading in an absolutely new direction; rather, we were taking a higher altitude flight. We brought in people with video production skills, and we included people with software development skills on the development team. The automation of some processes, like practice items in the courses, required coding and scripting skills that our team hadn’t needed previously.
  • Embrace the new approach. As we developed more independent pieces of content we found that more parallelism became possible, which also enabled changes to our project management. It also meant (in some cases) that development was a bit faster and, in some cases, easier. For subject matter experts it was a relief, for example, to get rid of directional references in their reusable content. They simply were able to focus on the standalone piece of content they were working on. All these small benefits somehow compensated for the changes and issues we were facing during the transition.
  • Celebrate first (small) successes. We had to justify our brave decision to help the customer transition to a new altitude of learning content development. And that is why we spoke up when we succeeded in integrating our innovative ideas into their process. We went to dinners to celebrate the end of projects, for example. We suddenly felt that we were part of one big team, rather than "us" and "them." And this new team understood that we had to help each other through the transition.

Enjoy the flight

Though we experienced several turbulent patches, our "flight" slowly stabilized. It has never been smooth, but that is a common situation with constant innovation and the introduction of the new approaches that digitalization has brought into the learning business, especially to content development.

Fortunately, we have flown through most of the turbulence together with the customer, with both sides working on "stabilizing the flight."

What did this change mean for our business?

First of all, we stayed in business. We brought our business to a new level, unimaginable before. We basically transformed ourselves.

At the end, our bottom line was higher—for many consecutive years.

We improved our business practices. Things like working with the customer on adjusting their processes together became a natural part of our approach, enabling us to reach the highest level of customer relationship we could imagine.

Still, to me, the change had a much broader and more profound impact, beyond the content development department. First, the change improved the visibility of the department, and some other departments started asking for our services. With HR, we created some internal compliance training content—instead of using external resources. With the sales part of the company we helped some of our customers to create more digital content and reskill their people in an impressively short time. So, the change benefited our customers as well.

The decision we made at that crucial moment years ago had a strong contribution to the digital transformation of the company. The decision and its implementation was a clear demonstration how L&D leadership can not only respond to an organizational strategy, but also co-create one.

Connect with learning leadership peers

Learning leaders and aspiring leaders who are seeking the strategies and skills required to navigate the needs of today’s ever-changing workplace do not need to figure it all out on their own. Connect with a community of your peers to help you explore and resolve today’s biggest learning leadership challenges.

The Learning Leaders Alliance is a vendor-neutral global community for learning leaders who want to stay ahead of the curve and for aspiring leaders wanting to build their skillsets. The Learning Guild’s Alliance Membership package includes access to exclusive digital events and content curated for today’s modern learning leader, as well as opportunities to attend in-person learning leadership events held around the globe. See the details on our website.