A lot of it is in the handover

When I was in high school, I was a regular in the 4x100m relay team. My specialist distance was 400m. I did occasionally compete over 200, and even more occasionally over 100m. I wasn't quite fast enough to make the cut for the 100m individual event on a regular basis, but as a 400m runner, I had the bends down pat. And this is important in a relay team. You have to remember that your team is going to have to handle two very long bends. Sometimes the very best 100m runners are utterly useless in a bend. So a good coach will experiment with combinations until s/he finds one that works.

All well and good. Now we have four sprinters, including two who run a kick*ss bend. So we're sure to win, right?

Erm.... maybe.

There is the little problem of the baton. It's all about the baton.

The team starts with a baton and crosses the tape with that baton. That means (a) that the first runner is hampered by the need to hold the baton in one hand during the start and (b) there are three handovers during which things can go horribly wrong.

To make things even more complicated, sprinters tend to have egos the size of planets. Have you watched the Olympics? Have you seen them strut? It's an important item in their toolkit, and something they cultivate. But it does mean that working as a team is very difficult for them.

But the bottom line is: you can have the fastest team in the world, but if that baton doesn't make it over the finish line, your team doesn't win. End of.

I was once called in to address the learning and development needs around a new process. The problem was that the new process was being driven by the new systems that were to be implemented. And the systems were not really joined up. At no point had a proper business analyst been involved. Dangerously, I was the nearest thing to a business analyst to have come into contact with the project. Of course, in my line of work, there is some natural crossover into business analysis, but it wasn't enough by a long shot. Time after time, meeting after meeting, I tried to explain that there were gaps where things were going to get lost, but I obviously wasn't using the right language, because the stakeholder team simply could not see the problem. I was repeatedly told it would have to be addressed as a training issue, and began to gain a reputation for being obstructive.

I felt as if I were being asked to make a wedding dress for a girl who hadn't even been born yet. And like every L&D professional knows: when it fails, it's going to be our fault. It's going to be because the 'training' wasn't up to scratch.

Then came a Very Important Meeting. The development team was going to give a demo of the new procedure in action. Enough bits of the system had been completed to make this a viable possibility. The entire stakeholder team assembled in one room, including the biggest wigs. The team leader outlined the first stage and things got off to a great start. Then we started talking about phase two. This was my moment. I asked the team leader how a deliverable would move from stage one to stage two. His response brought the whole demo to a halt. That part had not been defined by the stakeholder team and was currently out of scope for the development teams.

Finally. The penny dropped. A few heads rolled. I felt like such a tattle-tale. But I also realised that it had been necessary. Without a workable process, the organisation wouldn't have a business.

You simply cannot go out there and get the best products in the business and expect things to work. The system(s) should support the process, not drive it. So it's very impressive to be able to say on your website that you use Blahblah technology version X.Y. In the final analysis, if the new bells and whistles whatever-it-is isn't going to help you make more widgets with a lower reject rate, then it's a waste of money. Surely? So you need to have the process defined first. You also need to know that the hand-offs between phases of the process and system applications have been... not just adequately addressed, but exhaustively researched and catered for.

Our relay team used to sit one behind the other along the aisle of the bus as we headed to competitions, passing that flipping baton forward over and over and over again. We used to get out on that track and practise that handover. Again. Again. Again. Each of us knew how to run. Like the wind, even. But that was no good whatsoever if the baton wasn't passed smoothly from hand to hand. And even with all that practice, we sometimes failed. We tripped, we dropped the baton, we missed the markers, we stepped out of our lane. We lost races. But we were just kids, and no-one's livelihood was at stake.

A relay race isn't a series of four runners putting in their best performance. It's a team of people getting a baton from the start line to the finish line. And much (most?) of that is about getting those handovers right.

Stephen Covey talks about starting 'with the end in mind'. Athletes repeat this mantra in various forms over and over again. And their entire training schedule, diet, everything is organised around that end.

So the process needs to be designed with the end-goal in mind. The systems need to support the process, so that the end goal is achieved. The people need to be supported so that they know (or can find out) what they're supposed to do at each stage, in order that the end goal can be reached.

And if the process is full of holes, or the system drops the baton... there's no point blaming the L&D team.

Just sayin'....