Transparent Process Case Study: A Training Delivery System

In any well-functioning organization, every function and process aligns with higher-level business goals.

Pixar, for example, has the vision statement: “Make great films with great people.” They operationalize this at every level (described in more depth here). On their first day, both a barista and a director attend the same orientation. They hear the message:

“Wherever you come from, whatever you used to do, you’re a filmmaker now. We need you to make our films better.”

Look closely at the closing credits of any Pixar film – you’ll see “Craft Service By Luxo Café” – the food service staff are credited in their films as part of the team. They are meticulous in their propagation of this high-level goal.

Similarly, in tech organizations, functional leaders must ensure their goals support overarching business objectives. However, this alignment is not usually the case. Imagine the power if it was? Every single function pushing in the same direction?

The Case Study: A Training Delivery System

Consider a former client-a large business delivering high-complexity solutions in high-consequence environments, including space and war zones. With 10,000 employees, including 5,000 engineers, they require top talent to execute complex projects in demanding conditions.

A key role in this organization is the Product Manager—the highest engineer responsible for project execution. To support the business goal of delivering high-complexity systems in high-consequence environments, the company established performance standards for this role and developed a training program to align with those standards.

However, a simple question from the company president to the Vice President of Engineering exposed a critical issue:

“How many Product Managers do we have, and how many have been trained?”

This question was flowed down to the next level of functional leadership, seven different Directors of Engineering, each responsible for reporting their training metrics. They found it very hard to answer this simple question. The answer was surprising:

• Total Product Managers: 247
• Trained Product Managers: 184 (78% coverage)
• Untrained Product Managers: 63
• Last training session: 9 months ago
• Next training session: 2 months away, with only 9 registered participants

The leadership team was stunned how seldom the class was being offered. And there was surprise at how uneven the training was within each department – especially the East Region which had trained only 11 of its 30 Product Managers (36%). They anticipated questions from the corporate president – some leaders argued that training wasn’t necessary for all Product Managers due to experience, while others pointed out that data was only a snapshot in time, and the lack of a target was very clear.

It was clear to me there was an opportunity to make this systematic.

Establishing a Systematic Approach

All Product Managers should receive training within 90 days of attaining the role.

This was a large business, people move in and out of these roles all the time as new projects are stood up, others completed. By introducing a time dimension to the goal we could prevent overreacting to temporary fluctuations. We could also use this goal to design a business system around it – one that responds to the dynamics of the business itself.

Key Challenges Identified

1. Lack of Role Identification – The organization’s HR system included a job code for Product Managers, but not all were coded correctly. The original job code required a seniority level of 71, but the company had rapidly expanded, and many Product Managers were junior employees at level 64.
   • One directorate had 45 Product Managers, but only 11 were officially recognized in HR records. This meant the least experienced Product Managers were also the least trained.
2. Training Gaps & Stagnation – Training sessions were scheduled at the trainer’s discretion rather than being based on backlog demand.
3. Lack of Proactive Action – Despite identifying 63 untrained Product Managers, only one additional training session was scheduled and it was under-enrolled.
4. Subjective Training Requirements – Whether an employee needed the training was often debated. Since the course was four days long, some managers hesitated to send experienced employees, fearing it would take them away from important project work.

I helped them set the following goal: “All Product Managers should receive training within 90 days of attaining the role.” This system is dynamic, people move in and of these roles, new projects start, others stop. It was important to give a time dimension to ensure, if we need to take action, we are not overreacting to a snapshot in time. This allowed for natural fluctuations while maintaining a structured training expectation.

Solutions Implemented

We implemented several solutions to the issues above.

1. Clarifying Role Identification – The HR system opened it’s job code for Product Managers to include the experience range the role was being executed at. This involved the creation of “Junior Product Manager”, “Product Manager” and “Senior Product Manager”, each with a level 1, 2, 3. Now, we could put everybody in the role into the job code.
2. Make the training required – This removes the subjectivity of whether or not it’s worthwhile to send someone to a course.
3. Establish a clear metric – The timing of training is important. Train too early, people lack the experience to understand how to apply the concepts. Train too late, people are already overwhelmed and the project is off the rails. Furthermore, we needed to allow time for the system to work, so we established the following goal: “All Product Managers shall receive training within 90 days of attaining the role.”
4. Automatically assign the training when someone is in the code – As soon as someone in the HR Information System is coded in the Product Manager ladder, the Learning Management System will assign the training.
5. Use the LMS training backlog to schedule courses – Rather than letting the instructor determine when he should teach, the training schedule was built in order to get everyone in the backlog into a course before they hit 90 days.
6. Creating an Exam to Waive Training – To address the concern that experienced employees were being unnecessarily sent to training, we introduced a competency exam. Employees who passed the exam were officially credited as trained, rather than being marked as “untrained” in the Learning Management System.

The magic is the transparency

We created a transparent system. We can see at at glance:

• How many product managers we have?
• How many have been trained?
• How many courses should we offer in the next 60 days?
• Do we have enough people to teach this course?

This ties directly to the engineering function’s requirement to deliver top-of-field product managers on the promises the business makes to its customers. And now, when the corporate president asks, “How many product managers do we have and how many have been trained?” the client was answering this question directly from the system they use to manage the process.

Impact Across the Business

The improvements were tangible:

• Managers could assign training confidently, knowing it would be delivered reliably.
• New hires received timely training, ensuring they had the knowledge and skills required.
• Projects benefited from a more competent workforce, reducing execution risks.

Conclusion: The Power of Transparent Processes

This case study highlights a critical lesson: If training and process metrics are not built into the system, they will be created on an ad hoc basis—often too late to make an impact.

By embedding training metrics into the organization’s operational fabric, leadership can confidently track, manage, and deliver training to maintain execution excellence. The result? A transparent, systematic approach that ensures employees receive the right training at the right time—every time.

Evan Hickok

Evan Hickok has over twenty years of experience designing and managing high-complexity systems in high-consequence environments. As a Systems Engineer and Program Manager, he has guided projects through every phase of the product life cycle—from concept, detailed design, transition to production, production, installation & activation, and operational support. A dedicated researcher of team dynamics, Evan focuses on building high-performing teams capable of delivering exceptional results in the most challenging environments. He shares his insights and frameworks in the Lighthouse Leadership newsletter, published almost weekly at evanhickok.com.

See Full Bio