Call it what you want, but topics related to “developer productivity” and “developer experience” are at the top of many engineering leaders’ minds. That doesn’t mean the industry has agreed on these terms: some might consider “developer experience” to be wholly encompassed by asking developers to fill out surveys, or that “developer productivity” is about the number of points delivered in a sprint.

These topics defy easy definitions, but we’ve realized at Swarmia that they all fall under a bigger umbrella of “engineering effectiveness.” They work best alongside a shared focus on business outcomes. These three pieces form what we call “the three pillars” of engineering effectiveness. You need to think about all three, and how they interact with each other, in order to truly improve the effectiveness of your engineering organization.

Why does it matter?

It’s a competitive advantage to incorporate all three concepts into your approach to effectiveness: you want work flowing through the development system smoothly (developer productivity), you want individual engineers spending their time only on the actually valuable parts of their work (developer experience), and you want to make sure all that work is aligned with the goals of the business (business outcomes).

Improvements in any one pillar often create positive ripple effects across the others. For example, investing in better development tools (experience) can increase productivity, allowing for faster delivery of business value. Similarly, ensuring that teams are familiar with business goals can improve developer experience by providing context and purpose.

However, neglecting any pillar can also have negative consequences. Overemphasis on short-term business outcomes might lead to technical debt, hamper future productivity, and worsen developer experience. Conversely, focusing solely on developer experience without regard for business outcomes could result in misaligned efforts and wasted resources.

Talking about an engineering organization in the language of these three pillars also benefits communication and transparency with non-technical stakeholders, helping them see bottlenecks and understand the value in solving them. The three pillars provide a framework for balancing short-term gains — the thing the product team needs done yesterday — and long-term sustainability, like driving down tech debt that’s making engineering work harder than it needs to be.

Exploring the three pillars

Now that we’ve introduced the concept of the three pillars of engineering effectiveness, let’s dive deeper into each one. Each pillar presents its own challenges and opportunities, but they are deeply interconnected. As we explore each in turn, consider how they might apply to your specific context and how improvements in one area could positively impact the others.

Business outcomes

Engineering effectiveness is intrinsically tied to business outcomes. While many organizations focus on outputs like features shipped or story points completed, truly effective engineering teams prioritize outcomes that create tangible value for customers and the business.

This pillar is about aligning engineering efforts with strategic business goals. It requires a shift in mindset among engineering teams from simply building what’s asked to understanding why something is being built and how it impacts the bottom line. This alignment ensures that engineering time and resources are invested in work that moves the needle for the company.

Prioritization becomes essential in this context. Engineering leaders must work closely with product teams and business stakeholders to identify and focus on initiatives that promise the highest return on investment. This often involves making tough decisions and saying no to projects that don’t sufficiently contribute to key business objectives.

Organizational structure plays a significant role in achieving business outcomes. The composition and organization of engineering teams can either facilitate or hinder their ability to deliver value efficiently. Cross-functional teams that combine diverse skills and perspectives often excel at solving complex problems and delivering comprehensive solutions. However, the ideal structure varies based on the company’s size, product complexity, and specific goals.

Modern product management measures success in terms of business outcomes, which means traditional engineering metrics aren’t enough. Effective organizations track metrics directly tied to business impact instead of focusing solely on velocity or bug counts. This might include customer retention rates, revenue generated from new features, or improvements in key performance indicators specific to the business.

Organizations can create a virtuous cycle by centering engineering efforts around business outcomes. Engineers who understand their work’s impact tend to be more engaged and motivated by the work, and they tend to deliver better results.

Focusing on business outcomes does not mean there’s no opportunity to focus on engineering-driven initiatives — rather, it focuses the conversation on why an initiative might be good for the business, such as reducing operational risk or eliminating a class of manual work.

Balancing your investments, particularly around “keeping the lights on” (KTLO) work, is central to an effective engineering organization: Focusing solely on new feature development is tempting, but not at the cost of neglected maintenance and technical debt. Healthy organizations are likely to invest some time in new feature development, some time in improving existing things about the product, some time on KTLO, and some time on addressing issues that are damaging the team’s productivity (such as a lack of automated testing). These sorts of improvements in other pillars should be tracked as an investment here.

Over time, ignoring these less-glamorous tasks will lead to further productivity losses. Effective organizations explicitly allocate time for each kind of work, recognizing that an investment in productivity will pay off in the future.

What to measure

• Investment balance: How are you spending your software engineering capacity?
• Initiative delivery: Is your team delivering on its objectives?

Developer productivity

Developer productivity focuses on optimizing workflows and eliminating bottlenecks that impede the smooth delivery of software. This pillar explicitly does not focus on individual output; it identifies where the team has opportunities to improve how they work.

At the heart of developer productivity is the concept of product development flow: productive organizations continuously deliver value in small increments, and that flow can be disrupted by dependencies, blockers, process, and more.

For example, imagine the work of adding a new field to a contact info form. The actual code is nearly trivial, but even such a simple change can require coordination across front- and back-end teams, if that’s how your organization is set up. Even with a full-stack team, a change like this can run into dependencies on legal review, localization, API review, documentation review, and more.

Work-in-progress (WIP) limits and batch size optimization are key strategies for improving productivity. By limiting the work in progress, teams can reduce context switching and improve focus. Similarly, working with smaller batch sizes allows for faster feedback loops and reduces the risk associated with large changes. These practices often lead to more frequent, smaller releases, which can improve overall system stability and reduce deployment risk.

Code review processes play a dual role in productivity. While they’re essential for maintaining code quality, inefficient review processes can become significant bottlenecks. Effective organizations strike a balance, using code reviews not just for quality control but as opportunities for knowledge sharing and mentorship. This approach helps spread expertise across the team, reducing dependencies on individual team members.

Measuring productivity goes beyond simple metrics like lines of code or commits. Instead, organizations should focus on metrics that indicate smooth, efficient delivery of value. This might include change lead time, deployment frequency, or time spent waiting for reviews or builds. These metrics can help identify bottlenecks and guide improvement efforts.

Ultimately, the goal of focusing on developer productivity is to create an environment where engineers can do their best work with minimal friction. This not only leads to better business outcomes but also contributes to improved developer satisfaction and retention. By continuously working to optimize workflows, manage interruptions, and balance different types of work, organizations can create a virtuous cycle of productivity and effectiveness.

What to measure

• Cycle time: How long does it take to finish what you start?
• Flow efficiency: How much “in progress” time is spent on active work?
• DORA metrics: How effectively is the team managing throughput and quality?
• Bug backlog: Are product issues piling up?

Developer experience

Developer experience is the third pillar of engineering effectiveness, focusing on the day-to-day environment and tools that engineers use to perform their work. This pillar recognizes that the quality of an engineer’s experience directly impacts their productivity, job satisfaction, and ultimately, the quality of the software they produce.

Cornerstones of positive developer experience is a robust CI/CD pipeline and comprehensive automated testing. These systems allow developers to work with confidence, knowing they can quickly validate their changes and safely deploy to production. When CI/CD processes are slow, unreliable, or cumbersome, they become a source of frustration and lost productivity.

Internal tool development and maintenance play a crucial role in shaping developer experience. Standardized development environments, for instance, can significantly reduce the “it works on my machine” problem and streamline onboarding processes. However, it’s important to strike a balance — over-standardization can stifle innovation, while under-standardization can lead to fragmentation and inefficiency.

Cross-team collaboration and communication are essential aspects of developer experience, particularly in larger organizations. Clear channels for sharing knowledge, seeking help, and coordinating work can dramatically improve an engineer’s ability to navigate complex systems and deliver value. This includes not just technical communication, but also visibility into broader business context and goals.

Effective onboarding and knowledge management systems are critical for both new hires and existing team members. A well-structured onboarding process can help new engineers become productive more quickly, while robust knowledge management systems ensure that critical information is accessible and up-to-date, reducing dependencies on specific individuals.

Learning and development opportunities are a key component of a positive developer experience. This includes not just formal training programs, but also opportunities to work on challenging projects, experiment with new technologies, and contribute to open source. Organizations that prioritize continuous learning tend to have more engaged and innovative engineering teams.

Recognition and reward systems, when implemented thoughtfully, can significantly enhance developer experience. This goes beyond monetary compensation to include acknowledgment of contributions, opportunities for career growth, and a culture that values and respects engineering expertise.

Measuring developer experience can be challenging, as it often involves subjective factors. However, metrics such as employee satisfaction surveys, retention rates, and adoption rates of internal tools can provide valuable insights. It’s also crucial to maintain open lines of communication with engineers, regularly soliciting feedback on their experience and acting on that feedback.

By focusing on developer experience, organizations can create an environment where engineers feel empowered, supported, and able to do their best work. This not only leads to better software outcomes but also helps attract and retain top talent in a competitive industry. A positive developer experience is a powerful differentiator for engineering organizations, contributing to both individual job satisfaction and overall business success.

What to measure

• Developer sentiment: What’s getting in the way of your engineers doing their best work?
• CI/CD pipeline reliability and speed: How much effort is required to get a change to production?
• Developer environment metrics: How much time do devs spend waiting on their tools?
• Adoption of internal tools: Are your investments in productivity tooling being used across the organization?

Challenges in balancing the pillars

Balancing the three pillars of engineering effectiveness is no walk in the park. Each pillar plays a key role in overall effectiveness, but they often butt heads, forcing leaders to make tough calls and trade-offs.

One of the biggest headaches is juggling conflicting priorities. Push too hard for business outcomes, and you might rush features at the expense of code quality or developer sanity. Lean too far into developer experience, and you could invest in nice-to-haves that don’t move the needle on business goals. It’s like a game of tug-of-war where pulling too hard in one direction throws everything else off-kilter.

Then, there’s the classic short-term versus long-term dilemma. Business folks often want quick wins and immediate results, but investments in developer productivity or experience usually take time to pay off. This tension shows up often when talking about technical debt: dealing with it is crucial for long-term health, but it can slow down feature delivery in the short term.

Another tricky beast is measuring the fuzzy benefits of investing in developer productivity and experience. Sure, you can count deployments or measure lead times, but how do you quantify the impact of happier developers or reduced burnout? Things like better retention or increased engagement matter a lot, but they don’t always translate neatly into numbers that impress the higher-ups.

Engineers can also get pretty attached to their tools and ways of doing things, even if they’re not great. Try introducing something new, no matter how awesome, and you’ll likely hit some pushback. Leadership can be just as stubborn. Some leaders are so used to traditional success metrics and top-down mandates that they struggle to see the value in focusing on developer experience or productivity improvements that don’t immediately appear on the bottom line. This can lead to underinvesting in areas that could really drive long-term success.

Navigating all this isn’t easy. It takes a lot of educating stakeholders about how these pillars are all tied together, showing how boosting one area can lift the others. Leaders need to get good at explaining the value of intangible benefits in ways that make sense to the business folks, and be ready to champion change even when it feels like pushing a boulder uphill.

The end goal? Create a positive feedback loop where improvements in each pillar reinforce the others. It’s a tricky balance to strike, but it’s key to keeping your engineering organization effective and successful in the long run.

Read our book

Build: Elements of Effective Software Organizations covers the three pillars in great depth.

Read it online

The role of engineering leadership

Engineering leaders are the key players in driving effectiveness across the organization. They’re not just managing teams; they’re shaping how the entire organization approaches productivity, experience, and business alignment.

Leaders have to make the tough calls on what gets done now, what can wait, and what needs to be kicked to the curb. This isn’t just about picking which features to build; it’s about balancing quick wins with long-term bets on developer experience and chipping away at technical debt. Good prioritization keeps teams focused and stops the constant context-switching that kills productivity.

Leaders need to paint a clear picture of what an effective engineering organization looks like and tie it directly to the business’s goals. This vision should cover all three pillars, showing how they fit together to create a high-performing engineering culture. Without this vision, teams can easily lose the plot and get bogged down in the weeds.

Bridging the gap between the tech folks and the business folks is a huge part of an engineering leader’s role. Leaders need to be translators, explaining technical challenges and needs in a way that resonates with business leaders, and vice versa. They’re the ones who can make a compelling case for why investing in developer tooling or tackling technical debt is crucial for long-term success. This translation work is key to getting buy-in and resources for stuff that might not have an immediate, visible payoff.

Fostering a culture of continuous improvement keeps the organization from getting stale. Leaders should be cheerleaders for experimentation, learning from screw-ups, and sharing what works. They need to walk the talk, showing it’s okay to try new things and course-correct based on feedback.

Empowering teams and individuals is about creating an environment where people feel they can make real decisions and contributions. Great leaders set clear goals and guardrails, then get out of the way and let their teams figure out how to get there — all while guarding the team’s time against costly interruptions and gratuitous priority changes. This empowerment encourages and enables **teams to own their success in the context of the business.

By nailing these areas, engineering leaders can create a creative space where all three pillars of effectiveness can thrive. They set the tone for the organization, influencing how teams approach their work, how they play nice with each other and the business, and ultimately, how well they can deliver value.

Tying it all together

Engineering effectiveness — encompassing business outcomes, developer productivity, and developer experience — provides a framework for modern engineering organizations to create a virtuous cycle that drives innovation, enhances productivity, and delivers tangible business value.

However, balancing these pillars is no small feat. It requires thoughtful leadership, clear communication, and a willingness to make tough trade-offs. When you embrace this holistic view of engineering effectiveness, you can position your organization for long-term success in an increasingly competitive landscape.

The journey toward engineering effectiveness is ongoing, requiring constant adaptation and refinement, but the rewards — business success, technical innovation, and engineer satisfaction — make it a worthy pursuit for any engineering organization.

Swarmia can help

Learn more about how Swarmia can help your organization across all three pillars.

Sign up for a demo