← Back to Portfolio Index

Case Study · People & Tool Adoption

People, Frameworks, and the Three Phases of Tool Adoption

Why pushing a tool fails, how solving broken operational handoffs builds initial momentum, and why environment design must precede software adoption.

The foundational lens: the limitation of isolated effort

Having worked across three very different organizations with diverse sets of people, one truth became apparent early on: isolated humans have inherently limited capabilities. The highest-impact, highest-leverage value humans produce happens when they work together collaboratively and comfortably.

As a program manager, my fundamental job is not policing task checklists or measuring resource loading. It is designing the psychological and operational environment where people can build together comfortably.

When we introduced Jira to the organization, the intent was never surveillance. It was never about tracking hours or micromanaging capacity. It was designed as a shared mirror: a platform where teams could see how individual decisions create domino and butterfly effects across the entire project, keeping everyone aligned with overarching goals.

Realizing that vision took three distinct phases of operational learning.

Phase 01 · The Tool-First Trap

Attempting to map habits to software

We began by studying the people side, understanding how individual team members executed their day-to-day tasks and trying to integrate Jira into their existing work life. We opened Jira in daily standups, sprint reviews, and planning ceremonies, actively nudging teams to log tasks. We even secured top-down endorsements from team managers and business leadership.

The breakdown: despite executive sponsorship, adoption hovered around 10–15%. Asking engineers to change their recording habits without fundamentally improving their working reality created friction rather than trust.

Phase 02 · The Operational Wedge

Streamlining broken cross-team handoffs

Recognizing that abstract tool promotion was ineffective, we pivoted. Instead of trying to get all general project tasks into Jira, we identified a high-friction, unoptimized cross-team process: purchase requests.

Previously, purchase requests were scattered across emails. Requests lacked critical data, subjects were inconsistent, and endless back-and-forth emails created delays. We rebuilt the process end-to-end on Jira:

  • Standardized mandatory intake fields so requisitions had complete data upfront.
  • Introduced automated review gates to eliminate manual routing delays.
  • Enforced a single rule: unlogged purchase activities would not be processed.

The breakthrough: for the first time, both sides saw immediate value. Purchasers got clean, actionable inputs; requesting teams got transparent, real-time tracking of item status. Utilization climbed because the tool solved a painful operational barrier.

Phase 03 · Environment First, Tooling Second

The collaborative synthesis and dependency visibility

Phase 2 proved that operational gates work, but full adoption required something deeper. We stopped putting Jira in the front window. Instead, we focused entirely on fostering a collaborative team environment, treating Jira as an invisible secondary scaffold.

To bridge diverse teams, spanning Gen Z to Gen X (age gaps of 20+ years), deep technical specialists and generalists, I made key operational shifts as a program manager:

  • Shielding from non-value work. I sat with teams and isolated non-value-adding administrative friction so engineers could focus strictly on problem solving.
  • Collaborative co-planning. Rather than demanding plans, we sat together to map projects. We uncovered neglected tasks that frequently slipped through the cracks, showing teams how capturing them upfront prevented fire drills.
  • Standardized automated templates. We identified baseline milestones common to every project and built automated templates, eliminating repetitive setup.
  • Eliminating the “silent waiting” problem. Teams frequently stalled because Engineer A was waiting on feedback while Engineer B didn’t even know they were blocking them. Making cross-team dependencies transparent in Jira resolved bottlenecks immediately.

The outcome: tracking climbed from a forced 10% to an organic 55%+, establishing a shared rhythm that continues to scale toward 100%.

The program manager’s takeaway

Never lead with the software. Fix broken handoffs to prove utility, remove non-value friction to build trust, and cultivate the collaborative environment first. The tool will follow naturally.