Nordstrom & Innovation-Driven Culture Change
Nordstrom is a real, 120-year-old department-store retailer, and this page sticks to what's publicly documented about its engineering culture: material from The DevOps Handbook (Gene Kim, Jez Humble, Patrick Debois, and John Willis, 2016) and the DevOps Enterprise Summit talks Nordstrom's own technology leaders — most visibly Courtney Kissler — have given about the transformation over the years. The mechanism worth studying closely isn't a tool or a metric; it's how a new practice actually spread inside Nordstrom's technology organization. Not by executive mandate — by short, repeated internal hackathons where an idea had to become a working prototype before anyone was asked to fund it at scale. That's a genuinely different transformation mechanism than Target's DevOps Transformation, covered elsewhere in this course: Target's dojo taught practices top-down, on a schedule leadership set. Nordstrom's hackathons let practices prove themselves bottom-up, team by team, before leadership had to make a bet.
Imagine two ways a school could teach every classroom a new study technique. Method one: the principal announces that starting Monday, every class spends its first four weeks with a visiting tutor who walks them through the new technique step by step, whether they asked for it or not. Method two: nobody announces anything company-wide. Instead, once in a while, any group of students who want to can stay after school for a weekend, try the new technique on a real assignment, and show the rest of the school what they built on Monday morning. If it actually worked, other classrooms start copying it on their own — no principal required. Nordstrom is method two. Target, covered elsewhere in this course, is closer to method one.
A department-store retailer under a very new kind of pressure
☺ Like you're 10: Nordstrom is a real, 120-year-old department store, and by the mid-2010s it was competing against companies whose entire business was built to move fast online — so its old, slow way of shipping software stopped being good enough.
Nordstrom was founded in Seattle in 1901 as a shoe store and grew, over more than a century, into a full-line department-store chain built on a reputation for customer service. By the 2010s its competitive landscape had shifted underneath it: e-commerce and digitally-native retailers were setting customer expectations for speed and personalization that a traditional, waterfall-paced software organization could not match release by release. Nordstrom's own technology leadership — publicly, Courtney Kissler, who led e-commerce and platform engineering during much of this period and became a recurring speaker at IT Revolution's DevOps Enterprise Summit — has described the starting condition in terms familiar from the rest of this course: releases that took weeks to move from a finished idea into production, handoffs between separate development and operations groups, and a technology organization built, retailer-style, around large annual initiatives rather than continuous delivery.
A value-stream-mapping exercise — literally walking a single change through every step and every wait between "idea" and "live in production" — is the diagnostic Kissler and other Nordstrom-affiliated speakers have described using to make the problem visible to people who hadn't lived through it themselves. It's the same technique covered in general terms on the DevOps lifecycle: you can't fix a bottleneck nobody has actually measured, and a value stream map turns "releases feel slow" into a specific, arguable number.
Two ways to spread a new practice
☺ Like you're 10: Once you know what's broken, the harder question is how you get dozens of teams who didn't ask for it to actually change how they work — and there are two very different real-world answers to that.
Diagnosing the problem is the easy part. The harder question every DevOps transformation eventually hits is: how do you get a new practice — trunk-based development, automated testing, self-service infrastructure — adopted by dozens of teams who didn't ask for it and don't report to whoever's pushing it? There are, broadly, two documented answers, and both show up in The DevOps Handbook using real companies as the evidence: teach it to people first, or let people prove it to themselves first. Target's dojo is the Handbook's clearest example of the first path. Nordstrom's hackathon culture is its clearest example of the second, and it's the one this page is about.
The hackathon as a proof-of-concept factory
☺ Like you're 10: Instead of asking for a budget to change how the whole company builds software, small teams just built the thing over a weekend and showed everyone — a working demo is much harder to argue with than a slide deck.
Rather than requesting budget and executive sponsorship for a company-wide DevOps initiative up front, Nordstrom's engineers have described using internal hackathons — short, fixed windows, commonly a day or two, in which a self-selected small team builds a working prototype of an idea and presents it at a demo — as the entry point for new delivery practices. The projects that came out of these events, in Nordstrom's own retelling, were rarely abstract: a piece of deployment automation, a self-service way for a team to provision an environment without filing a ticket to a separate operations group, a monitoring dashboard that didn't previously exist. The hackathon format itself wasn't the point. The point was that a working demo, built on real infrastructure over a weekend, is a far more persuasive artifact than a proposal asking someone to take a practice on faith.
A prototype outranks a proposal. Asking a VP to fund "a DevOps transformation" is an argument about culture, and culture arguments are slow and easy to table. Showing a VP a deployment that used to take a change ticket and a two-week wait now happening in nine minutes, because two engineers built it on their own time and it's already running, isn't an argument at all — it's a fact someone has to respond to.
Convert local discoveries into global improvements
☺ Like you're 10: A cool hackathon project that only one team ever uses isn't a culture change — it's a good weekend. The real trick is having a deliberate way to notice which projects other teams start wanting too.
The DevOps Handbook names this exact pattern as one of its core Third Way practices — converting local discoveries into global improvements — and Nordstrom's hackathon culture is one of the book's running examples of what that looks like in practice rather than in theory. A hackathon win that stays with the one team that built it isn't a transformation; it's a good weekend. What Nordstrom's account adds is the second half of the mechanism: internal demo days, guild-style communities of practice, and engineering leadership specifically watching for which hackathon projects other teams start asking to borrow. A prototype a second team wants, unprompted, is the signal that converts a local discovery into a candidate for real investment — engineering time, a formal owner, a line in the roadmap — instead of staying a hackathon curiosity that quietly stops being maintained once the adrenaline wears off. This is the same underlying instinct behind culture & collaboration's case for sharing crossing team boundaries by default rather than staying locked in one group's head — Nordstrom just built a specific, repeatable event around it.
Bottom-up vs. top-down, side by side
☺ Like you're 10: Put next to each other, Nordstrom and Target were solving the exact same problem from opposite directions — one proves it first and asks second, the other commits first and teaches second.
It's worth putting Nordstrom's mechanism directly next to Target's dojo model, covered elsewhere in this course, because the two are both real, both documented in The DevOps Handbook, and both aimed at the exact same problem — spreading new delivery practices past the one team that already gets it. They just start from opposite ends.
Target's dojo, covered in full on that page, opened dedicated physical space at its Minneapolis headquarters, staffed with embedded coaches, and rotated cross-functional teams through several weeks of paired, hands-on practice on real production work before sending them back to their home teams fluent in the practices leadership wanted spread. It's a real investment, committed deliberately, before most of the organization had asked for it. Nordstrom's hackathon model asks for that same kind of investment only after a team has already shown, in public, that the practice is worth having.
What each model trades off
☺ Like you're 10: Neither way is just "better" — one starts cheap and slow to spread everywhere, the other starts expensive but trains everyone evenly.
| Nordstrom's hackathon model | Target's dojo model | |
|---|---|---|
| Who has to say yes first | Nobody — any team can enter a hackathon | Leadership, before the first team ever rotates in |
| Upfront cost | Low — existing people, a weekend, existing hardware | High — dedicated space, paid coaches, teams pulled off other work for weeks |
| Speed to first success | Fast, but small — one team, one prototype | Slower to start, but consistent — every rotating team leaves trained |
| Risk if it stalls | Winning demos with no adoption path become "hackathon theater" | An empty, expensive dojo room is a visible failure leadership can't ignore |
| Where the practice ends up strongest | Wherever a motivated engineer had a good weekend | Uniformly, across every team that rotated through |
The failure mode specific to Nordstrom's model isn't a bad hackathon — it's a good one with nowhere to go. A demo-day win that gets applause, a photo, and then no owner, no follow-up funding, and no path back into the roadmap teaches engineers the opposite lesson leadership intended: that showing initiative is a nice weekend project, not a real way to change how the company works. The "convert local discoveries into global improvements" step from earlier on this page isn't optional polish — without it, this whole model quietly degrades into cynicism fuel. See DevOps anti-patterns & pitfalls for more failure modes shaped like this one: a good practice, run with no mechanism to make it stick.
What Nordstrom's account says actually changed
☺ Like you're 10: Nordstrom's own talks describe teams moving toward faster, safer releases one team at a time — but treat it as a good story leadership kept telling for years, not an audited report card.
Nordstrom's own public retellings — conference talks and The DevOps Handbook's summary of them — describe a technology organization that moved, team by team rather than all at once, toward continuous-delivery practices: shorter release cycles, more automated testing, and infrastructure a development team could provision without waiting on a separate operations queue. Treat this the way this course treats any company's self-reported transformation story: it's evidence the approach worked well enough for Nordstrom's leadership to keep investing in it and keep talking about it publicly for years afterward, not an independently audited before/after study with a fixed methodology. Worth noting: Kissler herself carried the same underlying philosophy — build small, prove it, then scale what proves itself — into her later roles leading engineering at Nike and, later, as CTO at REI, which is a small piece of evidence this wasn't a one-company fluke tied uniquely to Nordstrom's culture.
What to steal for your own team
☺ Like you're 10: You don't need Nordstrom's size to copy the habit — run a real demo day, build a way to notice good ideas, and watch for who asks to borrow them.
- Run a real hackathon with a real demo day — not a hypothetical one. A fixed time box (a day or two), self-selected teams, and a public demonstration at the end are what make the resulting artifact persuasive. A hackathon with no demo day at the end is just unpaid overtime.
- Build the "convert local to global" step deliberately — don't assume it happens on its own. Name the mechanism: a standing internal tech-talk series, an engineering guild, an explicit agenda item at a leadership review specifically for surfacing hackathon wins to people outside the room that built them.
- Watch for the actual adoption signal. A second team asking to borrow the prototype, unprompted, is the metric that matters — not attendance at the demo or applause in the room.
- Combine both mechanisms — they aren't mutually exclusive. A hackathon-sourced practice that proves itself can be exactly the thing a dojo-style embedded-coaching effort scales fast once leadership decides it's worth the investment. The two answer different questions — "does this work?" versus "how do we teach it to everyone at once?" — and can run in sequence, as Target's transformation shows for the second half of that pattern.
Pick one real, specific pain point your own team complains about (a slow deploy step, a manual environment setup, a dashboard that doesn't exist). Design a one-day hackathon around fixing just that: who's on the team, what "done" looks like by end of day, and — this is the part Nordstrom's model depends on — exactly what would have to be true at the demo for a second team to want to borrow it. If you can't answer that last part concretely, the idea probably isn't ready for a hackathon yet; it's ready for more thinking.
Honest caveats
☺ Like you're 10: Bottom-up doesn't mean leadership never gets involved — it just changes when they're asked, and it isn't automatically faster or easier than the top-down way.
- Bottom-up doesn't remove leadership from the equation — it just changes when they're asked to commit. Nordstrom's hackathon wins still needed a budget line, an owner, and real engineering time once they graduated from prototype to supported tool. Somebody with authority had to say yes eventually; the pitch was just made after the thing already worked, not before.
- It can be slower to reach full organization-wide adoption than a mandate. A dojo trains every rotating team on a schedule; a hackathon depends on the right idea meeting a motivated team on a given weekend, which is inherently less predictable.
- It requires genuine psychological safety. A team that fears looking bad in a public demo won't build the ambitious, real prototype that actually persuades anyone — a hackathon culture that quietly punishes visible failure produces safe, forgettable projects instead of the kind Nordstrom's story is built on.
- Retail's specific competitive pressure did real work here. Well-funded, digitally-native competitors gave Nordstrom's engineers an urgent, widely shared "why" that made a weekend's hackathon output feel worth building on. A lower-stakes environment may need to manufacture that sense of urgency deliberately rather than assume it's already felt.
- The public record is thinner here than a company's own engineering blog archive. This story is documented through conference talks retold in a book, not a running, dated engineering blog — treat names, roles, and the general shape of what happened as reliable, and specific project-level details as illustrative rather than verified against a primary source.
Foxy: So Nordstrom's engineers just... built the thing, over a weekend, and showed up with it working? No approval meeting first?
Benny the Beaver: That's the whole trick. Try convincing a VP to fund "a DevOps transformation" — that's an argument. Show up with a deployment that used to take two weeks now taking nine minutes, already running — that's a fact.
Timmy the Turtle: And it doesn't stop at the demo. If nobody's watching for which projects a second team wants to borrow, the whole thing's just a nice weekend that nobody remembers by Friday.
Gizmo the Gremlin: Booooring. Why earn it slowly? Just get the CTO to mandate it Monday morning, memo to all-staff, done by lunch!
Professor Owl: That's not wrong, Gizmo — it's just a different, real strategy. Target ran that exact play with its dojo. Both are documented, both worked. They just start from opposite ends of the org chart.
Foxy: Prove it, then ask. Or commit, then teach. Either way, someone still has to say yes eventually — Nordstrom just made them say it last instead of first.
Where this connects in the course
☺ Like you're 10: This one story touches several other lessons — read whichever matches the change you're trying to make next.
The direct contrast is Target's DevOps Transformation — read it right after this page while the two mechanisms are fresh, since they're answering the same question from opposite directions. The "same team owns the code and the pager" ownership model that made Nordstrom's self-service infrastructure prototypes worth building in the first place is the same idea behind Amazon & "You Build It, You Run It". The cultural mechanics underneath all of this — shared ownership, sharing crossing team boundaries by default — are covered in general terms on culture & collaboration, and the operating-model question of how much to mandate versus how much to let teams discover on their own is covered directly on best practices & the operating model. If your own team is weighing a hackathon against a more structured rollout, scaling CI/CD across teams covers the mechanics of the "scale it once it's proven" half of that decision.
1. What diagnostic technique did Nordstrom's leadership use to make its slow release process visible before proposing a fix, and what does it actually measure? 2. In your own words, what does "convert local discoveries into global improvements" mean, and what specific signal does this page say separates a real adoption from hackathon theater? 3. Name three concrete differences between Nordstrom's hackathon model and Target's dojo model from the comparison table. 4. Why does the page argue that bottom-up doesn't eliminate the need for leadership buy-in — it only changes when it's asked for? 5. Name one honest caveat to Nordstrom's model that a smaller, lower-stakes company should think carefully about before copying it.
Check your answers
- A value-stream-mapping exercise — walking a single change through every step and every wait between "idea" and "live in production." It measures where time is actually being lost in the release process, turning a vague complaint ("releases feel slow") into a specific, arguable number.
- It means a hackathon win that stays with the one team that built it isn't a transformation, just a good weekend — real adoption requires a deliberate mechanism (demo days, guilds, tech talks) for surfacing the win to other teams. The signal that separates real adoption from hackathon theater is a second team asking to borrow the prototype unprompted, not applause at the original demo.
- Any three of: who has to say yes first (nobody, up front, vs. leadership, up front); upfront cost (low vs. high); speed to first success (fast but small vs. slower but consistent); risk if it stalls (hackathon theater vs. an empty, visible dojo room); where the practice ends up strongest (wherever a motivated team had a good weekend vs. uniformly across every rotating team).
- Because a hackathon-sourced practice still needs a budget line, a formal owner, and real engineering time once it graduates past prototype stage — someone with authority still has to commit resources. Nordstrom's model just asks for that commitment after the practice has already proven itself, rather than before.
- Any of: it can be slower to reach full org-wide adoption than a mandate; it depends on genuine psychological safety so people will attempt ambitious, visible work; it depended on Nordstrom's specific competitive pressure to supply urgency, which a lower-stakes environment may need to manufacture deliberately; the public record here is thinner than a running engineering blog, so specific details are illustrative rather than independently verified.