Developer productivity has become the latest term for a consistent goal: helping developers do their jobs better. While various movements and methodologies have emerged, including DevOps, platform engineering, and AI-assisted development, the fundamental challenge remains: how can we help engineering teams work more effectively in an increasingly complex environment?
Tara Hernandez, VP of Developer Productivity at MongoDB, gave Dev Interrupted a refreshing perspective on this challenge. Drawing from her extensive experience, Hernandez identifies three critical pillars that form the foundation of actual developer productivity and explains why the human element remains central to any successful productivity initiative.
How reducing noise fundamentally improves developer productivity
At its core, developer productivity is about creating an environment where developers can focus on what truly matters. As Hernandez explains: "If I were to describe what the biggest value of anything around developer productivity or the developer environment is, it's to reduce the noise. It's to allow the developer to focus on what they need to do by removing the things they don't have to focus on."
This noise reduction approach contrasts with adding more tools or technologies to developers' workloads. Hernandez identifies three key pillars that must work in harmony to create a truly productive environment:
- Technology: The tools that developers use
- Process: The mechanics of how teams organize their work
- Communication: How teams talk to each other and maintain transparency around metrics and insights
Notably, only one of these three pillars is technological; the remaining two, process and communication, center on people. As Hernandez emphasizes, "People ultimately are the most important aspect of good developer productivity. It is always going to fall to people."
Context matters when quantifying developer experience
Measuring developer productivity presents unique challenges, particularly when different product types require different approaches. MongoDB's complexity is evident in its approach to measurement across its product portfolio.
"MongoDB has had an incredibly invested culture around testing. From the get-go. It was [early] to the point where we've implemented our own CI system purpose-built to build and test distributed document database."
This testing culture exemplifies MongoDB's commitment to quality but also creates its own measurement challenges. Rather than simply counting tests, Hernandez focuses on understanding which tests provide the most value and which might be unnecessary.
The diversity of MongoDB's product offerings further complicates measurement. As Hernandez explains, teams have different delivery models that naturally require different measurement approaches and expectations.
Automation without accountability is the hidden risk of AI-driven software development
As AI tools increasingly integrate into development workflows, Hernandez offers a critical distinction: "Automation does not equal autonomy. If you have automation that goes nuts, it probably is doing the reverse of what you would hope." This perspective is an essential counterbalance to the often uncritical enthusiasm about AI's role in development. Hernandez highlights several concerns about AI-generated code, including potential legal issues, increased debugging complexity, and questions about accountability.
She warns that overreliance on AI can create significant risks, especially when organizations reduce engineering staff under the assumption that AI can seamlessly replace human developers. In such cases, when the AI fails, no one may be left with the necessary context or responsibility to address the problem, leaving both teams and customers vulnerable. Despite these concerns, Hernandez isn't anti-AI. Rather, she advocates for thoughtful integration with appropriate guardrails that don't increase developers' cognitive load.
Make the safe path easy with automated guardrails
Creating an effective developer experience means making the right path the easiest path. As Hernandez puts it: "Our job is to make the golden path the easy path, and to make it so that you will naturally go the direction we want you to go, because that's the easiest way to do it." This "golden path" approach applies particularly well to AI usage policies.
Rather than expecting developers to memorize complex rules about when and how to use AI tools, Hernandez suggests creating automated guardrails that naturally guide developers toward safe practices. Implementing guardrails shouldn't add complexity to developers' work. As Hernandez emphasizes, "You cannot expect the developers to keep a thousand things at the forefront of their mind when they're doing their day-to-day work. It's just not going to work."
Adequate guardrails are automated and almost invisible, making the compliant path the easiest one to follow. This approach has parallels in other areas of technology. For instance, cloud security evolved from relying on perimeter firewalls to implementing more sophisticated, integrated security controls.
How MongoDB balances engineering and business priorities
Drawing inspiration from McKinsey's Three Horizons business model, Hernandez has adapted this framework for software development:
- Horizon 1: Core business/keeping the lights on (KTLO)
- Horizon 2: What immediate improvements will make money next
- Horizon 3: Future investments (5+ years out)
This model helps teams balance their investment across these different time horizons. Hernandez suggests that KTLO work should ideally consume only 11-15% of development teams' resources, allowing the majority of effort to go toward new features and future-focused work.
When teams spend too much time "keeping the lights on"—for instance, if 60% of engineering effort goes to answering support tickets—it signals a need to address technical debt, improve documentation, or enhance existing services.
Use data to empower productivity improvements
Finally, Hernandez emphasizes an essential distinction between productivity data and performance evaluation. "One of the things I worry about is the misuse of data. It is very easy to inadvertently weaponize." Productivity data should identify process bottlenecks and improve team productivity, not evaluate individual performance. Different engineering styles can produce similar outcomes through various pathways; metrics alone can't capture this nuance.
The goal of productivity measurement should always be improvement, not judgment. When leaders focus on outcomes and empower teams to determine how best to achieve them, they create an environment where productivity can flourish.
By balancing the three pillars of technology, process, and communication, reducing noise and making the golden path easy, engineering leaders can create environments where developers can do their best work, ultimately delivering better outcomes for their organizations and customers.
Listen to Tara’s full Dev Interrupted episode here:
