Mark McDonnell "Musings"

@Mark McDonnell  

 

The Word That Shaped IBM and Inspired a Culture 

 

Don’t Apologize for the Green Screen: Embrace it 

 

Special Edition: IBM i Adoption and the Quiet Influence of the Human Brain 

 

SMB Edition: IBM i Modernization: The Community Is More Diverse Than The Conversation 

 

SMB Edition: Why Some IBM i Modernization Narratives Don’t Always Resonate with SMB Organizations 

 

Know Your IBM i as You Know Yourself 

 

 

--------------------

 

Language, Precision, and Shared Understanding

 

#3 - Use an Accepted Style Guide to Help Call Objects and Actions Exactly What They are or What They Do. 

 

#20 - Demystifying Program Calls: Are You Unqualified or Qualified? 

 

#29 - When IBM i Experts and IBM i Novices Don’t Speak the Same Language  

 

 

History of Call Home Technology and Its Automation 

 

#14.5 - What you may not have known about the IBM i Electronic Service Agent Auto PTF function. 

 

#15 - The History of IBM Call Home Technology - Chapter 1: The Early Days – From Manual Processes to Automation 

 

#16 - The History of IBM Call Home Technology - Chapter 2: The "Magic" behind late 1990s and early 2000's Auto Problem Detection and Reporting: Service Director Explained 

 

#17 - The History of IBM Call Home Technology - Chapter 3: Operating System Integration 

 

#18 - The History of IBM Call Home Technology - Chapter 4: The Hidden Cost of “Call Home” Technology 

 

 

Stability, Automation, and Hidden Operational Debt 

#7 - Set it and forget it. Historical Performance Data Collections  

 

#36 - Why Stability Can Hide Operational Debt 

 

#41: When Stability Becomes a Constraint 

 

#42: Why “Don’t Touch It” Is Not a Strategy 

 

#43: Building Adaptive Stability on IBM i  

 

#44: Why Untouched Systems Are the Most Fragile 

 

 

Teaching, Mentorship, and Knowledge Transfer 

 

#31 - What Not to Do When Teaching IBM i 

 

#32 - What Good IBM i Mentors Actually Do 

 

#37: Teaching Judgment vs Teaching Commands 

 

#40: Why Teaching IBM i Is a Strategic Capability 

 

 

Familiarity, Expertise, and Human Risk   

 

#26 - How Familiarity Forms in New Technology and Why It Really Really Matters for IBM i  

 

#39: The Hidden Cost of “Just Let Me Do It” 

 

#45: Operational Confidence Is Built, Not Assumed 

 

#46: Why Familiarity Beats Heroics 

 

#47: The Quiet Risk of Silent Operators 

 

 

Knowledge Management and Documentation

  

#30 - The First 5 IBM i Knowledge-Base Articles Every Shop Should Have 

 

#33 - Why Knowledge Siloing Is an Operational Risk 

 

#34 - Why “We Don’t Have Time to Document” Is a Warning Sign 

 

 

Adoption, Modernization, and Strategic Perspective 

 

#19 - When Did IBM i and its Interfaces Become “Outdated”?  

 

#27 - Why IBM i Is Better Than Other Enterprise Hardware Ecosystems  

 

#28 - IBM i Adoption and the Power of Involvement  

 

#38: Why Modernization Fails Without Understanding 

 

The Questions That Built IBM i 

 

#50: The Questions IBM Engineers Asked: A Rochester, MN Architectural Series - Introduction 

 

#51: Did Rochester Expect These Systems to Run This Long? 

  

#52: Should Operating Systems Be Designed for Programmers or Operators? 

#53: Why Should Applications Care Where Data Physically Lives? 

#54: Why Rochester Hid the Machine Behind an Interface 

#55: Why Did Everything Become an Object 

#56: Why This Architecture Survived Generations of Hardware

#57: Why This Architecture Almost Didn’t Ship 

#58: When Architecture Works Too Well 

#59: The Questions That Built IBM i: Why Rochester Hid the Machine From Programmers 

Healthy Operations, Confidence, and Complacency

#48: Why Boring Operations Are a Sign of Health 

#49: When Confidence Turns Into Complacency 

#60: What Healthy IBM i Teams Look Like 

#61: The Cost of Avoided Decisions 

#62: Why Leadership Must Make Risk Visible 

#63: Turning Risk Into Operational Insight 

#64: Why Safety Enables Speed 

 

Improve Operational Understanding Through Small Actions

#65: Why Small Changes Outperform Big Plans

#66: From Insight to Action  

#67: Why Consistency Beats Intensity 

#68: Why Habits Outlast Initiatives 

#69: Designing Habits for IBM i Teams 

  

Gain Operational Strength Through Learning 

#70: Making Teaching Part of the Job 

#71: When Knowledge Transfer Becomes A Risk Control 

#72: Why Learning Must Be Public 

 

Measure What Matters

#73: The Cost of Measuring the Wrong Things

#74: Measuring What Actually Matters 

 

Operational Effectiveness and Decision Making

#75: The Difference Between Busy and Effective

#76: Why Judgment Can’t Be Centralized 

#77: Designing Decision Boundaries 

#78: When Control Gives Way to Trust 

#79: Why Technical Resilience Is a People Property 

#80: When Accountability Replaces Blame 

 

The Human Side of IBM i Architecture

#81: Why Expertise Creates Blind Spots