This report explores how Nextdoor integrated Agile principles into its software delivery and organizational culture—without ever calling it that. Through firsthand experiences, it highlights how tailored practices, cultural cues, and small, consistent actions created lasting agility in a complex, real-world environment.
1. INTRODUCTION
The heart of my approach to Agile has always been a focus on meaningful action over abstract philosophy. Early on, I embraced the mantra “invade the system—no change takes place from outside,” a phrase I once saw scrawled on a bathroom wall at San Francisco’s Horseshoe Cafe. That mindset shaped my belief in working within existing structures to drive transformation.
At Nextdoor, this meant integrating Agile practices into roadmaps and OKRs without explicitly naming them, and steering clear of theoretical discussions about “Agile” or “Kanban” that often alienate teams. Instead, I employed situational authority—facilitating meetings, hosting planning sessions, and ensuring every contributor had a voice—over traditional positional power. By embedding these principles into the day-to-day activities within the existing meeting agenda, we evolved Agile practices that fit our culture, enabling both team success and individual growth.
I joined Nextdoor as the Organizational Agility Lead in April 2020, at the height of the pandemic and during a fully remote period. In fact, my interview took place in February 2020—the very first day the company began working remotely. That remote-first phase lasted over a year, eventually transitioning into today’s hybrid model: a couple of days per week in-office for those near a location, which currently includes about half the company.
2. BACKGROUND
When I joined Nextdoor, the engineering organization was already operating as a full DevOps shop—there were no separate QA or Operations roles; everything was owned by engineering. The broader Product Development organization followed a structure inspired by Spotify, but with a unique twist: engineering managers oversaw all engineers on a team, regardless of discipline, rather than specializing by function. Nextdoor’s engineering culture—whether the team recognized it or not—reflected strong Extreme
Programming (XP) practices, though the terminology was rarely used. Our DORA (DevOps Research and Assessment) metrics were elite: we deployed our monolith 10–20 times a day, practiced continuous integration and continuous delivery (CI/CD), ran blameless postmortems, and recovered from production failures in minutes with automated rollbacks.
That said, there was room to evolve how we delivered value. A new engineering leader had joined the summer before I arrived. An early Agile enthusiast, he brought both a respect for positional authority and a focus on improving team efficiency. He made two key hires: first, a single Quality Assurance leader to implement “catch and release” practices—a visible ops approach. Second, he hired me as Organizational Agility Lead, a combination of an Agile Coach and Technical Program Manager. For the first three years, I was Nextdoor’s only Technical Program Manager, before eventually becoming Head of Technical Program Management and Quality Assurance.
Keith Nottonson, keithn@gmail.com Copyright 2025 is held by the author.
3. THE CHANGE JOURNEY: KEY MOMENTS AND LEARNINGS
3.1 Initial Challenges and Cultural Friction
Introducing Agile practices at Nextdoor wasn’t about starting from scratch—it was about evolving the existing system to better align with our challenges and goals. My role focused on addressing bottlenecks in product definition, prioritization, and delivery by improving cross-team alignment, operational visibility, and pragmatic agility. Over time, these efforts helped shift us from functional silos to a more cohesive, value-driven organization.
Six weeks into my role—onboarding remotely during a global pandemic—the murder of George Floyd sparked nationwide protests and a broader racial justice movement. One of Nextdoor’s co-founders asked me to lead the Anti-Racism Taskforce. For our first retrospective, I introduced Cynefin’s sense-making framework to help the team categorize ideas: the simple (actions we could immediately take), the complicated (work already underway), the complex (emergent efforts), and the chaotic (the state we found ourselves in at the start).
This moment exemplified a pattern that worked well at Nextdoor: introduce just one idea at a time, and always apply it in a practical, real-world context. In this case, Cynefin wasn’t taught as a framework—it was used as a lens to make sense of our retrospective and guide action in the midst of crisis.
3.2 Building Trust Through Transparency
One of the biggest challenges at Nextdoor was driving change in an environment already burdened with operational overhead. Weekly reporting rolled up through layers of management, culminating in dense executive-level reviews. Planning documentation could stretch to 400 pages—exhaustive and often exhausting—while teams were simultaneously asked to participate in detailed headcount planning exercises, all while handling frequent leadership-driven scope changes. New work was injected weekly, interrupting in-progress efforts and creating significant delivery thrash. Many team members had prior experiences with Agile implementations that were labeled as “transformations” but felt more like compliance regimes. This led to a form of passive resistance—“we’ve seen this before and it didn’t work then either.”
Therefore I focused on creating clarity and alignment through Service Delivery and Operations Reviews, fostering transparency in how we measured and improved throughput and reliability. These reviews helped illuminate delivery patterns and bottlenecks across teams, but they also revealed a deeper cultural friction: skepticism, inertia, and a deep fatigue from previous process-heavy attempts at transformation.
At the same time, the organization’s desire for precise planning data created further tension. Leadership wanted metrics—lead time, velocity, utilization—but often from small sample sizes and at a level of granularity that couldn’t support strategic clarity. Agile, in theory, promised flexibility and adaptability. But in practice, teams felt constrained, reactive, and under pressure to make forecasts with false precision. To bridge this gap, we introduced RBIs—Roadmap Backlog Items. RBIs provided a pragmatic structure for planning that was transparent and easy to align on. By visualizing throughput and contextualizing capacity, they helped leadership shift from abstract debates about accuracy to conversations about tradeoffs and delivery focus. RBIs created just enough structure for planning without overburdening teams. They also became a reliable instrument for identifying delivery anti-patterns and misaligned expectations. This was one of the key learnings: it’s not enough to “be Agile”—you have to create shared, comprehensible artifacts that build trust and clarify intent across functions. The tool didn’t matter as much as the transparency it enabled. Through this approach, we started to reduce resistance, lessen the thrash, and create more room for teams to shape their own direction.
3.3 Navigating Resistance and Adapting to the System
The real call to action wasn’t a single moment—it was a slow burn. A buildup of friction and dysfunction that gradually made the status quo untenable. Even with elite DevOps metrics, we were struggling to deliver value consistently. Teams were overwhelmed by complexity, constantly interrupted, and unsure where their work fit into the bigger picture. Planning cycles were exhaustive but often disconnected from execution. The real signal was in the thrash—the churn between planning and delivery, the cycle of rework, and the fatigue that came from navigating constant change without clarity.
At first, I didn’t push. I waited. I watched. I saved my social capital for the right moments—small acts of clarity that created curiosity rather than resistance.
Resistance came in many forms: skepticism from engineers who had seen Agile initiatives come and go, weariness from managers caught in reporting loops, and political hesitance from leaders wary of more “transformation.” To make progress, I learned not to name the thing I was doing. I avoided “Agile,” “Scrum,” even “Kanban”—because those words were triggers. Instead, I practiced what I think of as the Taboo
Method—like the board game, where you have to describe a concept without using the most obvious words. My job was to introduce patterns, ideas, and tools without relying on the familiar language that had, for some, lost all meaning.
For my understanding, though, I used a Kanban lens to make sense of the system. I didn’t try to implement Kanban as a capital-M Method. I simply used it as a diagnostic framework—quietly mapping cadences, flow, and feedback loops. I started by examining existing meetings: what was actually happening, what decisions were being made, and what was missing. That’s when I realized we lacked key operational feedback loops—no formal service reviews, no true operations reviews, no risk reviews. Our executive “pillar” meetings were a catchall for everything: strategy, replenishment, delivery, and firefighting. The absence of clear cadences was revealing our blind spots
To start shifting things, I didn’t run workshops or bring in consultants. I didn’t pitch frameworks or roll out playbooks. I did the work. I facilitated planning sessions. I took notes. I summarized conversations. I followed up. I became a trusted advisor by being useful, not loud. That meant being in the room—not just metaphorically, but literally. I avoided standing 1:1 meetings but was always available when needed. My rule: don’t meet just to meet; reach out when something needs to be done.
This approach mirrored what I’d seen successful changemakers do: invade the system, don’t orbit it.
Inject ideas inside existing processes. Use operational tools—like RBIs—to create shared understanding.
And never forget that change is about humans, not theory.
The biggest lesson? Sometimes the best way to lead change is by not calling it change. It’s by doing the smallest thing that makes the next thing easier. Then repeating that, again and again, until one day the system is different.
3.4 Key Moments of Change: Small Wins and Pivots
Not everything landed perfectly, and not everything needed to. I focused on finding small wins that created momentum and opened the door for bigger shifts. Many of the successes came from letting go of rigidity—especially in planning—and embracing flexibility where it mattered most.
One example: headcount planning. We moved from an intense, months-long cycle—where hiring plans were drawn up in granular detail, reviewed by every executive, and almost always changed a few months into the year—to a lightweight weekly sync with Finance. The shift wasn’t just a process; it was a mindset. Rather than optimizing for an annual plan, we aimed for fluidity within a framework. The weekly cadence lets us adjust in real-time, balance overall budget targets with the realities of talent availability, and maximize our ability to fill open roles based on need, not old forecasts. Recruiting bandwidth often capped hiring anyway, so the change allowed for smarter prioritization, clearer calibrations, and far less wasted effort. We kept final offers as the single checkpoint on headcount, which gave Finance the control they needed without the heavy overhead.
Another key shift came after the roadmaps were established. Once teams could see their work and backlog clearly, I began gently introducing some of the concepts of Enterprise Service Planning—focusing on selection and sequencing over date-driven delivery. This helped us move away from artificial deadlines driven by low-confidence estimates, and even more importantly, from everything being a “P0.”
But some things didn’t work. One of the most persistent challenges was expectations around DevOps. There was an implicit belief that implementing DevOps practices—CI/CD, observability, incident response—would naturally reinforce agility. But DevOps alone doesn’t change how work is selected, prioritized, or launched. You can deploy daily and still build the wrong thing. What we needed was a shift in decision-making flow, not just delivery speed. DevOps improved our ability to ship safely, but not necessarily thoughtfully. Without a better upstream operating model, DevOps became infrastructure—not strategy.
Another challenge was the invisible resistance—the kind that lives in org charts, meeting calendars, and team habits. You don’t always hear “no.” More often, you hear “we already do that,” or “this is how we’ve always worked.” That’s why I leaned heavily into the idea of saving social capital for the right moments. My version of Rahm Emanuel’s “don’t let a good crisis go to waste.” You can’t push change into a stable system. You wait for the inflection point—a reorg, a strategy shift, a delivery miss—and then offer something better. The lesson wasn’t just about what worked—it was about how it worked. Change came not through sweeping mandates, but through carefully placed bets. You listen, you wait, and then you move—quietly, decisively, and with as little friction as possible.
4. WHAT WE LEARNED
Change happens when the system is ready and when you’re willing to prioritize results over pride, ego, or credit. At Nextdoor, I learned that influencing the system required being part of it—joining meetings, using existing tools, and helping improve things one step at a time. I avoided “agile” branding, instead framing decisions through the lenses of operational leverage, talent density, and customer value. It was Agile in spirit, but not in label.
Earlier, I believed in fast Agile transformations—thinking the right tools and frameworks could create change quickly. Now, I see that change is gradual, evolving over time, shaped by the system’s conditions, constraints, and culture. This report reflects that slower, organic approach.
We got a lot right: engineering practices rooted in XP and Continuous Deployment, thoughtful experimentation, lightweight roadmaps aligning effort with value, and a strong culture of transparency and trust. However, we spread ourselves too thin by supporting too many roadmaps without incomplete teams. I was part of this diffusion to enable autonomy but I should’ve set tighter priorities and kept leadership more aligned.
The hardest truth: there’s no guarantee of Product-Market Fit. All the practices—experimentation, discovery, user research—improve your odds. But they don’t promise success. Stronger leadership and better decision-making increase the chances, but only time will tell if we’ve found Product-Market Fit in our upcoming release.
The key takeaway: real change starts from within. You can’t transform a system from the outside; you have to embed yourself in the work, use existing tools, and align with the organization’s natural rhythms. Let go of “Agile” vocabulary and focus on meaningful outcomes. Start small, build momentum, and shape the conversation when possible.
The lesson I’ve learned at Nextdoor: you don’t drive change, you invite it. Help create the conditions for change to emerge, help it grow, and relinquish control for something better.
5. ACKNOWLEDGEMENTS
Thanks also to John Cutler, Janice Linden, and Dennis Stevens for your insightful work, which I absorbed and built upon. A special thanks to Bryan Power for helping me shape this story. And of course, this paper wouldn’t have come together without Siva Kumar. Thank you, Siva!
