David Caulfield

Learning+dev Mastery: 5. Design the initiatives

This is a post from a larger series entitled A Path to Learning+dev Mastery.

The path to mastery looks something like:

Recap

In the last post, I discovered that design is a lot more than a short blog post. We explored how to design the backlog, so now we will explore how to design each initiative in the backlog.

Principles of good design

When it comes to good learning+dev design, we don't need to reinvent the wheel. The best learning+dev design principles should be based off product design principles. Our product is the learning+dev initiative and our customers are our employees. Inspired is a book I repeatedly return to for wisdom on good product.

Obsess over value to your clients

You must obsess over the value your programs bring to the company. Anyone can do your job as a learning practitioner and create courses that are of no value to anyone. If we don't obsess over value, we will water down our value with unecessary elements. For every extra detail you add, ask yourself "What value will this bring to my customer?". If it's unclear whether it provides value, it probably doesn't, so remove it. Your customers have enough to do without trying to bat away more waste.

Everything is an experiment in the beginning

This is key to progressing quickly through wasteful initiatives. No amount of planning or upfront research can tell you what the perfect initiative looks like. You must experiment with everything. So get your idea on paper and test it by trying it on a small group or talk to someone about it.

Everything is a minimal viable product (MVP)

When designing something, the first draft must be small. There should be no such thing as a 12 month program in the first draft - it's too long. There are a couple of reasons for this.

Firstly, you're too busy to build large-scale projects all the time. The needs of your colleagues change daily. What they needed last month they no longer need this month. So building things that get launched quickly is extremely important.

Secondly, people don't have the interest for long-term optional programs. If I want to learn more about leadership skills, I can probably keep that interest for a month at most. A 6 month program? I won't finish it. However, I might be interested in learning more about stakeholder management this month, public speaking next month and crafting presentations the month after. Even thought they're all leadership skills, by chunking it into manageable sections I'm able to retain interest and look forward to the next section.

Focus your initiative on one persona at a time

You can't please everyone with everything. So the key to good learning+dev design is to please a group of people now and another group of people in the future. For example, if you are rolling out a leadership program, you could roll out a program that tries to address the needs of all leaders. But this would make the program generic and watered down.

Instead, your leadership program should focus on a small cohort of people first (eg. new leaders), then expand it into another group such as team leads, then another group such as project managers. This allows you to create small initiatives consistently and ensure your participants keep receiving value.

State the goal and expectations

A tool to manage goals and expectations is the Object and Key Results (OKR) technique.

  • Objectives: What business results are you aiming for in the organisation?
  • Key results: What are the metrics you expect to change which would show your initiative is working?

Take each initiative in your backlog. Write out what the objective is for that initiative and the results you are looking for. As you write out each intiative, you may find you have many objectives - this is a sign you are too scattered. Each intiative should have 1-3 objectives. Any more than that and you need to reduce your priorities.

Kill it

The Sunk Cost Fallacy applies to Learning+development as much as any other discipline. Most projects don't work out. Most initiatives don't work out. Maybe they lack engagement. Maybe they didn't address the learning objectives appropriately. Maybe it was a great initiative but the wrong time. Maybe it was the right time but the wrong initiative.

Many things can cause a learning+development initiative to be deemed "unsuccessful". If the initiative is not outputting more value than the time that goes into it, you need to kill it. If the initiative has little to no engagement, you probably need to kill it. If it has simply run its course and does not provide any value anymore, you need to kill it.

Learning+development needs to constantly evolve and meet the business needs again and again. We cannot do that if we are bogged down by managing a long list of low-value initiatives. To quote Steve Jobs, focus is about saying no. To focus in the areas that provide most value, you must say no to the low-value items. Doing so will hurt feelings and egos (most of all your own). But focus is key to success, and learning+development is no different. So get used to killing your projects and ideas.

Cluster initiatives together

Similar to Learning Clusters, Program Clusters ensure I don't provide a single solution to a complex problem. The problem of "My team won't communicate properly to each other" will not be fixed with a single workshop. Complex problems require multi-faceted solutions.

For example, improving team communication could be improved with:

  • A team workshop exploring the problems they face + exercises to bring awareness to their actions.
  • A root cause analysis of the moments where communication is most critical but most lacking.
  • A list of templates containing best practices for the team to base their emails, reports and meetings on to ensure necessary info is captured.

For any complex problem, increase the likelihood of your program's success by adding multiple prongs to it.

The ingredients of effective learning+dev initiatives

After you have your goals and expectations written down, it's time to fill in the colour. A library could be written on this. Best pracitces in workshops, courses, performance enhancement and so forth. Each learning+dev tool has a body of research behind it all with best practices attached to it. So there's little point in me exploring anything too in-depth. Having said that, there are some axioms I consistently obey when designing any program or initiative. These axioms are there to focus on ensuring I deliver value and fail fast with whatever initiative I'm developing.

Curate with Learning Clusters

Learning Clusters are a selection of curated resources based on a topic or need. They solve the problem of providing the correct resource for each individual at the correct moment. By curating a list of resources in different mediums and different depths, I remove the need of having a conversation with the person who has requested the resource or topic. Whether they want to look at a quick cheatsheet or watch an in-depth course, I can provide everything to them in the one place and leave it up to them what they want to use.

Whenever I receive a request for training, workshops or problems in general, I always sprinkly my response with at least 1 learning cluster. The Learning Cluster adds extra strength to whatever initiative I'm designing. Even if only 1 person gets benefit from it, it was still worth the effort to create.

Scrum Intro Learning Cluster

Track participants progress with timelines

I've written before how everything should have a timeline. This goes for both project delivery as well as individual participation for Learning+dev initiatives.

Here is what my excel tracker looks like. Excel Program Tracker

Collaborate as much as possible

Depending on the type of initiative, collaborative exercises can work extremely well. Each program should have at least some level of collaboration with other individuals in the program. Particularly where the initiative is related to "soft Skills" such as leadership. Getting together with other people who are interested in learning from each other can be extremely beneficial to the participants.

Allow people to join who will make the initiative better

Not everyone wants to participate in your initiative. Maybe it doesn't speak to their needs. Maybe they are too busy to even consider what you're trying to teach them. Maybe they just don't care.

Each person in your initiative who does not participate will suck the energy from every other partipant. I have have many programs and courses of 10 or more people and 1 person has destroyed the whole feeling of the group. Try to avoid these people in the future, and if you can detect them before starting the initiative, leave them out. They will shut down conversation and sit in the background like a silent judge, making everyone else uncomfortable.

Homework is a good thing

The great thing about homework is that it's ascynchronous. Many learning programs focus on what the learner achieves in the workshop or class. However, most learning takes place outside the classroom in the flow of day-to-day work. Therefore, having homework which applies to the learner's day-to-day tasks bridges the gap between the theoretical, lab scenario and the real-world scenario.

Homework has the secondary effect of identfying who is taking the program seriously. An optional, low-value program will have increased dropout rate with homework. As a learning+dev practitioner, this is exactly what you want - to reduce the amount of other people's time you are wasting. If they don't find the program important, they shouldn't be doing it. And if nobody does the homework, it is a good sign that your program is misguided and needs to be cut.

For those who do the homework or exercises outside of the regular program meetups, it indicates they are both taking it seriously, find it useful and want to continue. A program where everyone is doing the homework regularly is a great display of its quality and importance to its participants.

For example, let's say you launch a leadership program to develop the internal leadership skills of the company. You get great initial participation. But week-on-week, fewer people show up. Of those who do show up, they have not completed the exercises and seem to just want to waste 30 minutes on a call. At this point, we need to identify if the leadership program is serving its purpose. Maybe it's the case that it's a poor program. Or maybe it's a great program and the participants aren't linking it to their development. Or maybe they're not bought in enough so that when things get challenging, they drop out in favour of easier things. While this result may look "bad", it's better than the alternative of having 20 people show up to a call where they don't bring anything to the table and just waste 30 minutes of their own time. One way or the other, the homework does its job of helping people develop in their own time or highlighting they are not interested enough to complete it and drop out.

An example of designing a learning program

I'll describe a recent initiative I developed to take the top performers in the organisation and increase the value they bring to the table. The program involved a group of 12 senior engineers who had spent their careers in the telecoms domain. The goal was to increase the number of senior engineers who could consult with customers about their complex telecoms problems.

The first step was to identify the main KPI.

  • Increase number of people who can speak with customers.

Next was to write down what I thought would make the program a success. I used some of the ingredients listed above for this.

  • Collaboration is key. Most engineers do not have the depth and breadth required to develop these solutions. As a team, we can do a lot more.
  • Everyone needed to see everyone else progressing so that they put onus on themselves to do the work. An excel progress tracker was used to visualise this.
  • Domain knowledge, not just technical knowledge, was key here. We employed the Harvard Case Method to deliver and facilitate specific cases around the domain problems we wanted to learn about.

The program we developed was excellent.

  • Highest attendance rate out of all programs in the company: >90% for 4 months.
  • Consistent participation with only 1 workshop delayed.
  • We analysed more than 7 cases around the domain.
  • 5 people were brought into customer-facing conversations within the 4 month period.

Next steps

After looking at these design principles and techniques, next we will move onto executing and managing the programs.


0 kudos