Exercises — Chapter 40: Knowledge Transfer and Mentoring
Section 40.1 — The Knowledge Crisis
Exercise 40.1 — Knowledge Risk Assessment
Conduct a knowledge risk assessment for a mainframe team (use your own organization if applicable, or create a realistic scenario based on Federal Benefits Administration).
a) List each team member with their approximate years of experience, primary knowledge domains, and estimated years until retirement or departure. b) For each team member, identify knowledge that is unique to them (no one else has it). c) Calculate a "knowledge risk score" for each person: (criticality of unique knowledge) x (probability of departure within 3 years). Use a 1–5 scale for each factor. d) Rank the team by knowledge risk score and identify the top three knowledge transfer priorities. e) For each of the top three, recommend the primary transfer method (pair programming, documentation, shadowing, recorded session) and justify your choice.
Exercise 40.2 — The Cost of Knowledge Loss
Research or estimate the cost of knowledge loss in a mainframe environment. Consider:
a) Direct costs: consultant fees for expertise replacement, extended incident resolution time, regression testing after uninformed changes b) Indirect costs: slowed project delivery, increased risk, degraded vendor relationships, compliance exposure c) Opportunity costs: modernization initiatives delayed or abandoned due to insufficient institutional knowledge
Create a one-page cost analysis that could be presented to a CIO to justify investment in a knowledge transfer program. Use specific dollar estimates (research industry benchmarks or estimate based on reasonable assumptions).
Exercise 40.3 — Knowledge Inventory
Imagine you are a senior mainframe developer with 20 years of experience. Write your own version of Marcus's "Things I Know That Nobody Else Knows" list.
If you are relatively new to mainframe technology, write the list based on any domain where you have deep expertise (a different technology, a hobby, a sport). The exercise is about the process of identifying tacit knowledge, not the specific domain.
a) List at least 15 items across the categories: technical knowledge, business context, troubleshooting heuristics, relationship knowledge, and historical context. b) Categorize each as Critical, Important, or Useful. c) For each item, identify the best transfer method. d) Reflect: how many of these items would have appeared in your formal documentation? What does this tell you about the limits of documentation?
Exercise 40.4 — The Retirement Scenario
Federal Benefits has the following mainframe team:
| Name | Age | Experience | Primary Domain | Unique Knowledge |
|---|---|---|---|---|
| Marcus Whitfield | 62 | 38 years | Claims batch, DB2, architecture | System design history, vendor relationships |
| Sandra Chen | 44 | 22 years | CICS, modernization | API architecture, modernization strategy |
| Dev Patel | 59 | 30 years | JCL, batch scheduling | Entire batch schedule logic, disaster recovery |
| Maria Santos | 55 | 25 years | DB2 administration | DB2 configuration, performance tuning history |
| Kai Nakamura | 28 | 3 years | COBOL, modern tools | CI/CD pipeline, automated testing |
| Elena Rodriguez | 31 | 5 years | CICS, APIs | API gateway, cloud integration |
| James Kim | 35 | 2 years | COBOL (learning) | Modern development practices |
Marcus retires in 2 years. Dev retires in 3 years. Maria plans to retire in 5 years.
a) Create a knowledge transfer priority matrix for this team. b) Design a 24-month knowledge transfer plan that addresses the most critical risks. c) Identify the single biggest gap in this team's future capability and propose a solution.
Section 40.2 — Explicit vs. Tacit Knowledge
Exercise 40.5 — The Documentation Experiment
Choose a task you know how to do well (it can be technical or non-technical — cooking a recipe, playing a musical passage, debugging a specific type of error, navigating a complex commute).
a) Write step-by-step documentation for the task, as if for someone who has never done it. b) Have someone else attempt the task using only your documentation. c) Observe where they struggle. Document each point of difficulty. d) For each difficulty, identify whether the gap was in explicit knowledge (you forgot to document a step) or tacit knowledge (you could not articulate what you know). e) Write a reflection on what this experiment reveals about the limits of documentation.
Exercise 40.6 — Knowledge Spectrum Mapping
For one of the mainframe systems described in this textbook (CNB's payment processing, Federal Benefits' claims processing, Pinnacle Health's claims system, or SecureFirst's policy administration), create a knowledge spectrum map.
a) List 20 pieces of knowledge required to maintain and operate the system. b) Place each on the explicit-to-tacit spectrum. c) For each piece of knowledge, identify the current "holder" (the person or document where it resides). d) For each piece of tacit knowledge, describe how it could be partially made explicit through documentation, recording, or structured conversation.
Exercise 40.7 — The "Why" Audit
Select any five COBOL programs or JCL procedures from this textbook's examples. For each one, write two descriptions:
a) A "what" description: what the program/procedure does (functional description) b) A "why" description: why it does it this way (design rationale, historical context, business reasons, constraints that shaped the design)
Compare the two descriptions. Which is more useful for a new maintainer? Which is more commonly found in documentation? What does this tell you about documentation practices?
Section 40.3 — Knowledge Transfer Methods
Exercise 40.8 — Pair Programming Session Design
Design a pair programming session plan for transferring knowledge about a batch processing system. The senior developer has 25 years of experience; the junior developer has 2 years.
a) Define the session scope (what specific knowledge will be transferred) b) Plan the session structure (timing, role rotation, break points) c) Create a pre-session preparation checklist for both participants d) Define post-session documentation requirements e) Design a follow-up session that builds on the first
Exercise 40.9 — War Story Collection
Interview an experienced professional (in any domain — it does not have to be mainframe) about a significant crisis or incident they managed. Structure the interview using this framework:
a) What happened? (The incident) b) How was it detected? (Monitoring, user report, accident) c) What was the initial hypothesis? (First guess) d) How was it actually diagnosed? (The investigation) e) What was the resolution? (The fix) f) What was learned? (The lesson) g) What would they do differently? (The reflection)
Write up the war story in a format suitable for a knowledge repository. The write-up should be compelling enough that a new team member would want to read it.
Exercise 40.10 — Recorded Session Script
Write a script (outline with key points, not word-for-word) for a 60-minute recorded knowledge session on one of the following topics:
a) "How Our Batch Schedule Actually Works" — a system walkthrough explaining the overnight batch processing sequence, including dependencies, timing constraints, and historical reasons for the current structure b) "The Five Incidents That Shaped Our Architecture" — a war stories session covering five significant production incidents and how they influenced system design c) "Understanding Our Data Model" — a walkthrough of the database design, including normalization decisions, performance optimizations, and the business meaning of key tables
Your script should include: - An introduction that frames the session for the target audience - Key points to cover in each section - At least three "this is why we do it this way" explanations that capture tacit knowledge - Questions that a viewer might have (anticipate and address them)
Exercise 40.11 — Knowledge Transfer Method Selection
For each of the following types of knowledge, recommend the best transfer method (or combination of methods) and explain why:
a) How to diagnose a DB2 deadlock situation b) Why the claims processing system handles Alaska differently c) Which IBM support engineer to request for DB2 performance issues d) How to estimate the effort required for a COBOL program modification e) The history of the batch scheduling design and why jobs run in their current order f) How to "feel" whether a CICS region is healthy by looking at the console g) How to present a technical recommendation to the CIO h) The vendor negotiation history and current leverage points
Section 40.4 — Documentation That Actually Works
Exercise 40.12 — Write a Retroactive ADR
Choose a technical decision from earlier in this textbook that was presented as already made (e.g., a design choice in one of the case study organizations). Write a retroactive ADR as if you were the senior professional who made the decision and are now documenting it before retirement.
Include: - Context at the time of the decision (not today's context) - The options that were available at the time - The decision and its rationale - How the decision has held up (with the benefit of hindsight) - Recommendations for future decision-makers
Exercise 40.13 — Decision Log
Create a one-month decision log for a hypothetical mainframe operations team. Include at least 10 entries covering a mix of:
- Routine operational decisions (job schedule changes, configuration updates)
- Response decisions (incident responses, performance adjustments)
- Design decisions (code changes, architecture modifications)
Each entry should include the date, the decision, the rationale, and the decision-maker. The exercise is about developing the discipline of recording decisions as they are made.
Exercise 40.14 — Runbook Rewrite
The following is a typical inadequate runbook entry:
BATCH JOB RESTART PROCEDURE
1. Check job status in scheduler
2. Review JCL for errors
3. Restart job from step that failed
4. Verify output
Rewrite this runbook entry to make it actually useful for knowledge transfer. Include: a) Prerequisites and context b) Step-by-step procedure with expected output at each step c) A troubleshooting section with at least five common failure scenarios and their resolution d) Historical context notes explaining why the procedure exists in its current form e) Escalation procedures and contacts
Exercise 40.15 — Documentation Audit
Evaluate the documentation for a system you work with (or a system described in this textbook) against these criteria:
| Criterion | Rating (1-5) | Evidence |
|---|---|---|
| Accuracy (reflects current state) | ||
| Completeness (covers all critical areas) | ||
| "Why" coverage (explains design rationale) | ||
| Discoverability (easy to find) | ||
| Currency (recently updated) | ||
| Audience appropriateness | ||
| Troubleshooting coverage |
For each criterion rated 3 or below, propose a specific improvement action.
Section 40.5 — Mentoring
Exercise 40.16 — Mentoring Program Design
Design a formal mentoring program for a mainframe development team of 20 people, including 8 seniors (15+ years), 6 mid-level (5–15 years), and 6 juniors (under 5 years).
a) Define the program structure (matching criteria, meeting frequency, duration, goals) b) Create mentor-mentee matching recommendations (who should be paired with whom, and why) c) Define three sample mentoring goals appropriate for each experience level d) Design the progress tracking mechanism e) Identify potential obstacles and how you would address them f) Estimate the time investment per participant and justify it to management
Exercise 40.17 — Reverse Mentoring Session
Design a reverse mentoring session where a junior developer (2 years experience, strong in Git, CI/CD, and cloud technologies) mentors a senior developer (28 years experience, deep COBOL/CICS/DB2 expertise).
a) Choose a specific topic for the session b) Plan the session structure (45 minutes) c) Anticipate potential challenges (ego, patience, different learning styles) and plan how to address them d) Define what success looks like at the end of the session e) Design a follow-up activity that reinforces the learning
Exercise 40.18 — Cross-Generational Team Design
You are restructuring a 15-person mainframe team from two separate groups (the "legacy team" of 8 seniors and the "modern team" of 7 juniors) into three cross-generational teams.
a) Define the composition of each team (who goes where, and why) b) Assign shared system responsibilities to each team c) Define the knowledge transfer expectations for each team d) Anticipate resistance and plan how to address it (both from seniors who may resist change and from juniors who may feel slowed down) e) Define success metrics at 3, 6, and 12 months
Section 40.6 — Building a Learning Organization
Exercise 40.19 — Community of Practice Charter
Write a charter for a Community of Practice focused on mainframe knowledge preservation. Include:
a) Mission statement (one paragraph) b) Scope (what topics are in and out of scope) c) Membership (who is invited, how they join) d) Meeting structure (frequency, format, typical agenda) e) Roles (facilitator, note-taker, presenter rotation) f) Deliverables (what the CoP produces — knowledge articles, best practices, etc.) g) Success metrics (how you know the CoP is working)
Exercise 40.20 — Brown Bag Series Planning
Plan a 12-session brown bag series focused on knowledge transfer for a mainframe organization. For each session:
a) Title b) Presenter (type of person, not a specific name) c) Topic description (2–3 sentences) d) Target audience e) Expected knowledge transfer outcome
Ensure the series covers a mix of: technical deep dives, war stories, business context, vendor/tool knowledge, and career development.
Exercise 40.21 — Knowledge Repository Design
Design the structure of a knowledge repository for a mainframe development organization. Include:
a) Repository technology recommendation (with justification) b) Content taxonomy (how will content be organized?) c) Naming conventions d) Content types and templates for each type e) Governance model (who can add content, who reviews, how is quality maintained) f) Search and discovery features g) Retirement/archival process for outdated content
Section 40.7 — Marcus's Checklist
Exercise 40.22 — Your Knowledge Transfer Plan
Whether you are the senior professional approaching retirement or the junior professional receiving knowledge, create your own knowledge transfer plan.
If you are the knowledge holder: a) Complete the "Things I Know That Nobody Else Knows" list b) Categorize each item (Critical, Important, Useful) c) Create a phased transfer plan following Marcus's template d) Identify your knowledge recipients e) Estimate the time required and create a timeline
If you are the knowledge recipient: a) Identify three senior professionals whose knowledge you most need b) For each, list the specific knowledge you need to acquire c) Propose the best transfer method for each knowledge area d) Create a learning plan with milestones e) Identify how you will validate that the transfer was successful
Exercise 40.23 — Organizational Knowledge Transfer Strategy
You are the CIO of a mid-size insurance company with 30 mainframe professionals. Twelve of them are retiring within the next five years. You need to present a knowledge transfer strategy to the board of directors.
Write a 2-page executive brief that includes: a) The problem (in business terms, not technical terms) b) The risk (what happens if you do nothing) c) The proposed strategy (methods, timeline, resources) d) The investment required (dollar estimate with justification) e) The expected outcomes f) How you will measure success
Exercise 40.24 — The Anti-Pattern Analysis
Case Study 2 in this chapter describes a company that did NOT do knowledge transfer. Using that case study as a starting point:
a) Identify the five earliest warning signs that the organization should have acted on b) For each warning sign, describe what action should have been taken c) Calculate the approximate cost of the knowledge loss (direct + indirect) d) Design a "recovery plan" for the organization after the knowledge loss has occurred e) What preventive measures could have been implemented at low cost, early in the process?
Exercise 40.25 — The Emotional Dimension
Marcus's knowledge transfer plan has an emotional dimension that is often overlooked in technical organizations. Write a 500-word reflection on one of the following:
a) What does it mean to have your life's work encoded in a system that will outlive your career? How should organizations honor that contribution? b) How does knowledge transfer change the retiring professional's relationship with their work? Is it liberating, threatening, or something more complex? c) How can organizations create a culture where knowledge sharing is rewarded rather than hoarded? What organizational incentives work against knowledge transfer, and how can they be changed? d) Describe a time when you lost access to someone's expertise (through departure, promotion, or organizational change). What was the impact? What would you do differently?