For more than three decades, James L. Pulley has been at the center of conversations around software performance, scalability, and the cultural shifts necessary to make both a priority in organizations. His perspective, from Microsoft product support to being one of the first to use online forums to share expertise, has given him valuable insights on how software culture must evolve if businesses are to avoid the costly mistakes of leaving performance considerations until it is too late. Early in his career Pulley landed at Microsoft where he worked in product support for operating systems, databases, and SQL Server. “You’re talking to people who are incredibly frustrated, sitting in a phone queue for four or five hours for a new release. You have to calm them down, get to the information that matters, and find a solution quickly.”
That kind of work, he shares, trains your brain in ways few other jobs can manage. Around the same time he also experimented with early online communities. On CompuServe—an early subscription service that functioned much like today’s online forums or Slack channels—he served as one of Microsoft’s first voices of operating system support. It gave him another way to help people directly, extending support beyond the phone queue into a shared space where knowledge could circulate more widely. The impulse to give back deepened after 9/11. At the time his business had slowed, and like so many he felt a pull to reach out and help others. Out of that moment he turned more deliberately to online forums where practitioners traded lessons. He began answering questions about tools, techniques, and processes, “sometimes hundreds in a single year.” Over time he estimates those exchanges have reached between 15,000 and 18,000 people.
Why Performance Culture Matters
Software performance for Pulley is both a financial and cultural imperative. “Patterns are key,” he says. “Design patterns, development patterns, deployment patterns, if you don’t catch the poor ones early, you accumulate technical debt. And there comes a point where it is too expensive to unwind.” The timing of performance checks is central to this problem. Many organizations wait until the final weeks before launch to ask critical questions. “You have all this accumulated performance technical debt that’s so expensive to unwind. If you change your culture to ask earlier and often, you catch defects closer to introduction, where they are cheaper to fix,” Pulley says. As Pulley points out, loss of goodwill compounds revenue impact: “four out of five customers will not return to a site that frustrated them until all other options are exhausted.” This becomes most visible during peak shopping moments, such as Black Friday or Cyber Monday, when a slow or unresponsive site doesn’t just frustrate users, it translates immediately into lost sales.
Overcoming Human and Organizational Barriers
Still, the greatest challenge to embedding performance thinking as human resistance. “Almost everybody is wired to ask functionality questions,” he says. Developers and managers focus on whether a feature works, not whether it performs well. Adding performance, security, or accessibility requirements takes more time, and time pressures dominate. This creates tension in DevOps environments where speed of deployment is often rewarded over quality. “If your bonus is tied to how many times you promote to production, you’re not going to want to slow down,” Pulley says. To shift this mindset, organizations need strong internal champions who can advocate for performance culture against the natural pressures of deadlines and metrics.
Three Practical Strategies to Embed Performance Thinking
While culture change is complex, Pulley highlights three practices that can significantly reduce risk and cost:
- Ask if it is fast for one user. Most teams only test performance with multiple users. Pulley argues that catching slowdowns for a single user identifies about 80% of performance problems early, from poor page design to missing database indexes.
- Adopt clear performance requirements. Too many projects lack them entirely, turning performance tests into benchmarks rather than actionable evaluations. Pulley recommends adopting Google’s “RAIL” performance model to provide a shared baseline for architects, developers, and engineers.
- Leverage logs and real user monitoring in pre-production. These tools are often confined to production environments, but Pulley sees a missed opportunity in using them earlier. Passive data collection during testing phases can expose performance issues without changing tester behavior, providing a richer dataset for decision-making.
The Role of AI and the Shifting Value Chain
A frequent user of AI tools such as ChatGPT and Replit, Pulley is still cautious of the fact that they lack awareness of performance, security, and accessibility requirements across sessions. “They don’t normally build performant code,” he explains, noting that organizations are already hiring developers to fix the scalability and security issues in AI-generated applications. He describes a “value chain” in performance engineering that moves from raw data collection to actionable system changes. Production teams, with access to real-world data, are far ahead of quality assurance teams that struggle with test environments and inadequate training. This imbalance is shifting budgets toward production-focused reliability engineering tools such as Akamas, Dynatrace, and Splunk.
“A checkbox doesn’t have value, and it’s very expensive,” he says. “If performance testing doesn’t evolve beyond benchmarking, organizations will cut those divisions and move resources where they see higher value.” Organizations must make performance awareness part of their culture from the earliest stages of software development. The payoff is financial resilience, stronger customer trust, and fewer last-minute crises that drain budgets and goodwill.
Follow James L. Pulley on LinkedIn for more insights.
