This article is based on a two-part interview with Target CIO Mike McNamara originally published by The Enterprisers Project in early 2017. All quotes are attributed to McNamara.
From Brick-and-Mortar to a DevOps-Driven Retailer
Retail has historically been slow to adopt modern software delivery practices, but Target made a deliberate bet on DevOps as a competitive differentiator. When Mike McNamara joined Target as CIO in mid-2015, he discovered that the groundwork had already been laid by engineers inside the company. What followed was a structured effort to scale that momentum across the entire technology organization — and the results, by McNamara’s own account, exceeded expectations.
A Grassroots Movement Already in Motion
One of the most telling details from McNamara’s account is that DevOps adoption at Target did not begin with a top-down mandate. When he arrived, pockets of the engineering team were already practicing agile and DevOps — particularly in digital product teams and the enterprise architecture group.
This matters for any organization evaluating a DevOps transformation. A grassroots movement provides authentic proof points and internal advocates that no external consultant can replicate. Leadership’s role, in Target’s case, was to provide visibility, resources, and organizational cover — not to invent the culture from scratch.
“The grassroots movement was just looking for support, and the rest of the organization was looking for guidance – so it wasn’t a terribly difficult sell.”
— Mike McNamara, CIO, Target
The Dojo: Target’s Immersive Learning Environment
The most operationally significant innovation McNamara describes is an internal program called the Dojo. Rather than sending engineers to off-site training or relying on documentation, Target created an immersive, six-week coaching environment where teams continue doing their actual day-to-day work — but with agile coaches embedded alongside them.
How the Dojo Works
- Duration: Six weeks per cohort
- Format: Teams execute real work — not simulated exercises — while coaches provide continuous guidance
- Goal: Remove resistance to change without sacrificing productivity
- Ongoing use: After initial adoption, the Dojo continues to be used to refine and reinforce engineering capabilities
The Dojo model directly addresses one of the most common failure modes of DevOps training: classroom knowledge that never makes it into production workflows. By anchoring learning to real work, Target reduced the gap between theory and practice and kept teams productive during the transition.
“The Dojo has been fantastic in getting teams engaged with agile and DevOps, removing the natural resistance and fear of change, and then supporting the team through the changes while maintaining productivity.”
— Mike McNamara, CIO, Target
Handling Resistance: “My Area Can’t Be Agile Because…”
McNamara is candid about the resistance that exists in any large organization. The specific objection he highlights — “My area can’t be agile because…” — will be familiar to DevOps practitioners in regulated industries, mission-critical infrastructure, or legacy-heavy environments.
Target’s response was pragmatic rather than ideological: in areas where a full continuous deployment model was not yet appropriate, teams adopted agile development practices first, while still releasing in a more controlled, traditional manner. As confidence in CI/CD tooling grew, release frequency and automation naturally followed.
This staged approach — agile development first, then progressive automation of delivery — is a realistic model for organizations that cannot afford big-bang transitions in sensitive systems.
Assessing the Journey: Further Along Than Expected
By early 2017 — roughly 18 months after McNamara joined — Target had made enough progress that he described the organization as “further than I thought we’d be at this stage.” The company had received external recognition from publications including TechBeacon for its DevOps efforts.
However, McNamara is careful not to frame DevOps as a destination. He points to two reasons why the journey is continuous:
- Culture is never finished. Because DevOps is fundamentally a cultural practice, there is no end state — only ongoing improvement.
- Technology keeps evolving. McNamara specifically called out containerization as an example of a technology that was theoretical for years but had become a practical engineering requirement, forcing teams to learn new tooling and workflows.
Keeping Engineers Equipped: Quarterly Architecture Forums and Open Source
When asked how he ensures developers stay current with market demands, McNamara’s answer is notably decentralized: “They tell me.” Rather than a centralized procurement or evaluation process driven by leadership, Target empowers its engineers to identify and advocate for new tools.
The Architecture Forum
Target holds a company-wide architecture forum every quarter. Engineers present petitions for new products and technologies. Evaluation criteria include novelty and long-term staying power — an important filter that avoids chasing hype while still encouraging experimentation.
Open Source Engagement
Target engineers are active contributors to open source projects, not just consumers. McNamara frames this as a deliberate strategy: because many of the most significant DevOps tools have originated from open source communities, staying engaged at the contributor level keeps engineers aware of emerging tools before they reach mainstream adoption.
“The reality is a lot of the good DevOps tools of recent years have emerged from the open source community, so that’s where our engineers spend their time so they’re aware of everything that’s out there.”
— Mike McNamara, CIO, Target
Key Takeaways for DevOps Practitioners
- Build on grassroots momentum. If DevOps advocates already exist inside your organization, your first job is to amplify and support them, not replace them with consultants.
- Embed coaching in real work. Simulated training environments rarely survive contact with production realities. Programs like the Dojo, which anchor learning to actual team workflows, produce more durable change.
- Allow for staged adoption. Not every team can move to continuous deployment immediately. Agile development practices can be adopted before full delivery automation is in place.
- Decentralize tool selection. Engineers closest to the work are best positioned to evaluate new tooling. Structured forums — like a quarterly architecture review — provide a governance layer without creating bureaucratic bottlenecks.
- Invest in open source participation. Contributing to open source is both a talent retention strategy and an early-warning system for emerging tools and practices.
This article is based on part one of a two-part interview originally published by The Enterprisers Project. Quotes have been preserved as reported in the original source.