Technical Coaching for IT Organizational Transformation
$12.00
Minimum price
$18.00
Suggested price

Technical Coaching for IT Organizational Transformation

About the Book

The technical side of organizational transformation often receives insufficient attention, leaving organizations with great market insight, innovative ideas, ambitious plans, clear priorities, a streamlined structure, efficient processes...and no way to execute.

After countless attempted transformations, process adoptions, and framework implementations, it seems as if little progress has been made. The world continues to suffer from poorly-designed, badly-behaved, costly, and hard-to-maintain applications and systems.

The ongoing problem is due in part to management consultants and client leadership underestimating the importance (and the difficulty) of technical improvement to support business goals, in part to the tendency to approach change mechanically, without proper consideration of the humanity of those involved, in part to ineffective coaching methods at the team level, and in part to the global shortage of well-qualified technical coaches.

This book offers suggested remedies for common anti-patterns in organizational transformation programs, clarifies the range of skills a qualified technical coach must cultivate (going well beyond technical skills), and describes a practical way to make gradual, step-by-step progress with improvement guided by appropriate metrics.

About the Author

David Nicolette
David Nicolette

Dave Nicolette is interested in software development, music, and science fiction.

Table of Contents

  •  
    • About the Author
    • Preface
      • Notes On the Second Edition
    • 0 | Introduction
      • 0.1 | What’s the Problem?
      • 0.2 | Who’s the Audience?
      • 0.3 | What’s the Scope?
      • 0.4 | Anything new here?
      • 0.5 | A Note on Agile
  • Part 1: Foundations
    • 1 | Is Transformation Possible?
      • 1.1 | A Longstanding Problem
      • 1.2 | If Organizations Changed Before, They Can Change Again
      • 1.3 | If We Can Find the Dots, We Can Connect Them
      • 1.4 | The Missing Element
    • 2 | Anti-Patterns of Organizational Transformation
      • 2.1 | Incomplete Solutions
      • 2.2 | Misalignment of Goals
      • 2.3 | Lack of Direction
      • 2.4 | Separation of Process-related and Technical Improvements
      • 2.5 | Misunderstanding the Nature of the Work
      • 2.6 | Conflating business agility with agile software development
      • 2.7 | Reintroduction of the Old
      • 2.8 | Inappropriate Organizational Structures
      • 2.9 | Big-bang Change Rather Than Incremental Change
      • 2.10 | Rigid Interpretation of Frameworks
      • 2.11 | Milestone-driven vs. Directional Approach
      • 2.12 | The Cult of Scrum
      • 2.13 | The Soft Stuff Is the Hard Stuff
    • 3 | Definitions
      • 3.1 | Capabilities
      • 3.2 | Leverage
  • Part 2: Strategy
    • 4 | Connecting Management and Technical Consulting
      • 4.1 | Half a Solution Isn’t Better Than None
      • 4.2 | A Proposed Solution
      • 4.3 | The Fulcrum Is the Natural Dividing Line
      • 4.4 | Connecting the Parts
    • 5 | Begin With the End in Mind
    • 6 | Target States: Where Do We Need To Be?
    • 7 | Leverage: Where’s the Fulcrum?
    • 8 | Getting Started
      • 8.1 | Impact: Structure, Process, Practices
      • 8.2 | Full-Stack Slices
      • 8.3 | Up-Front Analysis
      • 8.4 | Foundational Activities
      • 8.5 | Starting Iterative Improvement
    • 9 | The Cycle of Change
    • 10 | Monitoring Progress
      • 10.1. | Anti-Patterns In Monitoring Progress
      • 10.2 | When Should We Check Progress?
      • 10.3 | How Should We Check Progress?
      • 10.4 | Metrics and Managed Change
      • 10.5 | Cultivating Continuous Improvement
    • 11 | Metrics
      • 11.1 | Process-Agnostic Metrics
      • 11.2 | Directional Metrics
      • 11.3 | Measuring Capabilities
      • 11.6 | Measuring Stability of Production Operations
      • 11.7 | Measuring Software Quality
      • 11.8 | Measuring Code Health
      • 11.9 | What Not To Measure
    • 12 | Structures and Responsibilities
      • 12.1 | Structures Specific to the Transformation
      • 12.2 | Consultancy Responsibilities
      • 12.3 | Client Responsibilities
      • 12.4 | Joint Responsibilities
      • 12.5 | Consultant and Coach Responsibilities
      • 12.6 | Special Consideration for Technical Coaches
  • Part 3 | Humanity
    • 13 | A Chair Is a Resource
    • 14 | Holding Precious What It Is To Be Human
    • 15 | Safety
      • 15.1 | The Business Value of Safety
      • 15.2 | Putting People First
      • 15.3 | Importance of Safety in Times of Change
    • 16 | Responsibility Over Accountability
      • 16.1 | Accountability
      • 16.2 | Responsibility
    • 17 | Stress
      • 17.1 | Allow for Stress and Its Effects
      • 17.2 | Your Helpers Are Human, Too
      • 17.3 | Hold Course Despite Stress
    • 18 | Introversion and Collaboration
      • 18.1 | What is Introversion?
      • 18.2 | Can’t Introverts Just Get Over It?
      • 18.3 | Making It Work
      • 18.4 | Introversion and Coaching
    • 19 | Cognitive Biases
      • 19.1 | Categorizing Cognitive Biases
      • 19.2 | Confirmation Bias
      • 19.3 | Gambler’s Fallacy
      • 19.4 | Sunk Cost Fallacy
      • 19.5 | Negativity Bias
      • 19.6 | The Illusion of Explanatory Depth
    • 20 | Ego Development
    • 21 | View of Authority
    • 22 | Profiling
      • 22.1 | Pigeon-holing
      • 22.2 | Defamation
      • 22.3 | Excuses
      • 22.4 | Monoculture
      • 22.5 | The Slippery Slope to a Toxic Culture
      • 22.6 | Be a Grown-Up
      • 22.7 | People Can Grow (Resources Can’t)
    • 23 | Organizational Culture
      • 23.1 | What Is Organizational Culture?
      • 23.2 | How Is Organizational Culture Used?
      • 23.3 | A Systems View of Organizational Culture
      • 23.4 | Stop Worrying About Culture
    • 24 | Client-Consultant Relations
      • 24.1 | Factors Resulting in Sensitivity
      • 24.2 | Earning and Maintaining Trust
      • 24.3 | Who’s the Boss?
      • 24.4 | Ensure Common Understanding
  • Part 4: Change
    • 25 | Intentional Change
      • 25.1 | Current and Target Operating States
      • 25.2 | Missing Pieces
      • 25.3 | “How to Change” Doesn’t Mean “How to Implement”
      • 25.4 | Stepwise Improvement vs. Predefined End State
    • 26 | Initial Changes
      • 26.1 | Establish Collaborative Workspaces
      • 26.2 | Form Product-Aligned Teams
      • 26.3 | Take Baseline Measurements
      • 26.4 | Choose Initial Experiments
    • 27 | Workspaces for Collaboration
      • 27.1 | The Rise of Office Work
      • 27.2 | The Action Office
      • 27.3 | The Birth of the Cubicle Farm
      • 27.4 | The Open-Plan Office
      • 27.5 | Collaborative Team Work Spaces
      • 27.6 | Considerations for Remote Workers
      • 27.7 | 5S and Software Development
      • 27.8 | Gaining Cooperation from Client Leadership
    • 28 | Time Management
      • 28.1 | Outlook-Driven Development
      • 28.2 | Causes of Time Management Issues
      • 28.3 | Manager Time vs Maker Time
      • 28.4 | Managing the Calendar
      • 28.5 | Protecting Maker Time
    • 29 | Incrementally Collapsing Functional Silos
      • 29.1 | Initial Organizational Structure
      • 29.2 | Starting Point
      • 29.3 | Organizational Constraints on Silo-Busting
      • 29.4 | Temporary Scaffolding
      • 29.5 | First Steps in Silo-Busting
      • 29.5 | Special Considerations When Decentralizing Responsibility
      • 29.6 | Team Size
      • 29.7 | Security
      • 29.8 | Summary
    • 30 | Incrementally Improving Estimation
      • 30.1 | Who Needs to Estimate?
      • 30.2 | Factors Affecting Estimation
      • 30.3 | Incremental Improvement
    • 31 | Incrementally Improving Code Review
      • 31.1 | The Value of Code Review
      • 31.2 | From No Code Review to Formal Code Review
      • 31.3 | Use Checklists
      • 31.4 | Limit the Time of Formal Code Reviews
      • 31.5 | Refactor to Increase Review Effectiveness
      • 31.6 | From Formal Code Review to Pair/Mob Programming
      • 31.7 | Use Static Code Analysis
    • 32 | Incrementally Improving Branching Strategy
      • 32.1 | Types of Version Control Systems
      • 32.2 | One or Multiple Version Control Systems
      • 32.3 | One or Multiple Source Repositories
      • 32.4 | Branching Strategies
      • 32.5 | Challenges In Scaling
      • 32.6 | Typical Starting Points
      • 32.7 | Step By Step Improvement
      • 32.8 | Pitfalls and Anti-Patterns
    • 33 | Improving Infrastructure Support & Operations
      • 33.2 | Infrastructure Management Options
      • 33.2.1 | Stress
      • 33.3 | Leading Practices in Operations
      • 33.4 | Busting the Final Silos Within Each Technology Stack
      • 33.5 | Special Considerations for Mainframe Teams
  • Part 5: Coaching
    • 34 | Coaching Skills
      • 34.1 | Coaching Competencies
      • 34.2 | Self-Awareness and Empathy
      • 34.3 | Course of Least Resistance
      • 34.4 | Make Things Visible
      • 34.5 | Manipulation
      • 34.6 | Acting
      • 34.7 | Removing Organizational Constraints
      • 34.8 | Let the Team Stumble
      • 34.9 | Be the Rock
      • 34.10 | Conflict Resolution
      • 34.11 | Principles-Based Adaptation
      • 34.12 | Having Multiple Ways to Explain Things
      • 34.13 | Awareness of Context
      • 34.14 | Knowing When To Quit
    • 35 | Shortage of Technical Coaches
      • 35.1 | Availability of Technical Coaches
      • 35.2 | A Note on Agile Coaches
      • 35.3 | Tailored Approaches
    • 36 | Technical Coaching Approach
      • 36.1 | Problems With the Status Quo
      • 36.2 | Addressing the Problems
      • 36.3 | Team-Level Technical Coaching Model
      • 36.4 | Scaling the Coaching Model
      • 36.5 | Developing Internal Technical Coaches
      • 36.6 | Barriers to Adoption
    • 37 | Communication Models
      • 37.1 | Active Listening
      • 37.2 | Appreciative Inquiry
      • 37.3 | Clean Language
      • 37.4 | Crucial Conversations
      • 37.5 | Emotional Intelligence
      • 37.6 | Getting To Yes
      • 37.7 | Mindful Kindness
      • 37.8 | Powerful Questions
      • 37.9 | Radical Candor
    • 38 | Collaboration
      • 38.1 | Improving Collaboration Improves Flow
      • 38.2 | Team Cohesiveness
    • 39 | Internalities
      • 39.1 | Beginner’s Mind
      • 39.2 | Eye of the Hurricane
      • 39.3 | Non-Attachment
      • 39.4 | Nonviolent Communication
      • 39.5 | The Four Agreements
  • Part 6 | Summary
    • Appendix A | IBM Mainframe Considerations
      • A.1 | Mainframe UNIX Support
      • A.2 | Mainframe ASCII Support
      • A.3 | Mainframe as Cloud Host Environment
      • A.4 | Legacy Applications and IBM Z Cloud Features
      • A.5 | Test Automation and Test-Driven Development
    • Appendix B | Glossary
    • Appendix C | References
    • Appendix D | Picture Credits
      • Cover Art
      • Figures
    • Index

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

80% Royalties. Earn $16 on a $20 book.

We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub