Virtual Panel: Increasing Engineering Productivity, Develop Software Fast and in a Sustainable Way

Introduction

Companies need to balance between rapid feature development and long-term product sustainability. Engineers are taking on more left-shifted, cognitive load as their features intersect with user privacy, security, accessibility, and regulations.

In this panel, we’ll discuss approaches, philosophies, and techniques that companies and products successfully applied at very different points in their overall lifecycle to improve the effectiveness and efficiency of development.

The panelists:

• Jennifer Bevan – Senior Staff Software Engineer @Google
• Sergii Gorbachov – Staff Software Engineer @Slack
• Jenna Butler – Principal Applied Research Scientist @Microsoft

InfoQ: What are the challenges when it comes to balancing fast software development and long-term sustainability?

Jennifer Bevan: I believe that there are three primary challenges: a lack of visibility into the impact of short-term and long-term tradeoffs, a lack of institutional memory as to why these tradeoffs were made, and the unsubstantiated belief that “there will be time later” to get around to addressing the inevitable accumulation of tech debt.

It is inarguable that sometimes teams need to get products out the door quickly; the market pressures can be real. That said, we’ve got over 40 years of research into managing software evolution, and plenty of development velocity metrics, so I’m left with the belief that the underlying problem is not at all technical, but rather one of empowering the right leads to make fully informed prioritization decisions.

Sergii Gorbachov: Balancing fast software development with long-term sustainability is inherently challenging because it requires reconciling immediate delivery with future reliability. Rather than focusing solely on speed or sustainability, a more strategic approach is to prioritize delivering value that justifies the investment at the time of decision-making. This means each decision, such as accelerating a feature release or investing in extensive testing, should be evaluated through a return on investment (ROI) lens.

However, accurately measuring ROI in software development is a significant challenge, making it difficult to determine the appropriate level of testing coverage or decide whether to double down on a feature at any given time. In any case, a value-driven approach enables a pragmatic method that aligns development with team or company goals and ensures that each effort provides tangible returns.

Jenna Butler: I actually don’t think speed and sustainability have to be at odds – if you build the right engineering systems, they should reinforce each other. Think about it: if you have great tests, continuous deployment, and easy-to-use telemetry, you can move fast without creating a mess.

The real problem comes when speed means cutting corners – skipping tests, ignoring telemetry, rushing through code reviews. That might seem fine in the moment, but over time, it leads to tech debt and makes development slower, not faster. It’s kind of like skipping sleep to get more done. One late night? No problem. But if you do it every night, your productivity tanks. Same with software – if you never take time to clean up, everything gets harder to change. So yeah, sometimes you make trade-offs to hit a deadline. But if you never go back and fix them, you’re just setting yourself up for pain later.

The best teams build speed into their systems – not by cutting steps, but by making the right steps easy to follow.

InfoQ: What are the aspects that drive software engineering productivity and sustainability?

Jennifer Bevan: There’s some very basic development needs that have to be met, of course, like getting the time needed to get a new change into a testing environment so the developer can get rapid feedback as to whether or not they screwed up anything that’s obvious in retrospect. After that, the technical solutions start getting intermixed with human solutions, and that’s where it gets complicated.

Engineering Productivity efforts get prioritized when there are prior successes that can be expanded upon, so there’s a critical bootstrapping problem – so finding teams that have really terrible development experiences and making them better becomes a key driver and component to start building a repeatable and scalable solution.

And then there’s the metrics. In this day and age, there’s a real tension between the “show me the ROI” folks and the “trust the Tech Lead’s expertise” folks. In general, though, what I look for is a combination of successful pilot landings, innovative tools and infrastructure to get superlinear scaling of solutions, and then really driving home the message that without sustainable productivity, the business objectives of the company are directly at risk.

Sergii Gorbachov: Software engineering productivity and sustainability are influenced by many factors and can mean different things to different people. For me, the two primary drivers that stand out are code quality and efficient processes.

High-quality code is modular, readable, and well-documented, which simplifies maintenance, debugging, and scaling, while reducing the burden of technical debt. Efficient processes, such as CI/CD pipelines and automated testing, help reduce repetitive tasks and allow engineers to iterate quickly without sacrificing quality.

Together, code quality and efficient processes create a development environment that supports long-term productivity and sustainability.

Jenna Butler: I think personal satisfaction plays a huge role in productivity. Research shows that people who feel like they’re doing meaningful work tend to be more engaged and effective. Software engineering, in particular, attracts smart people who want to contribute – so if you can match engineers with work they find fulfilling, they’ll naturally be more productive.

At the organizational level, productivity isn’t just about individual happiness – it’s about alignment. If teams aren’t communicating or don’t understand the bigger picture, you get duplicated effort or, worse, people working at cross purposes. In research I did on OKRs in software engineering, many engineers weren’t even aware of what their colleagues were working on, even though they felt they ‘needed’ to know. That lack of visibility slows everything down. Strong leadership, clear goals, and a shared vision help teams move faster in the right direction.

Of course, culture alone isn’t enough – you also need the right technical foundations. Things like fast access to telemetry, easy-to-run tests, and continuous release pipelines all contribute to sustainable productivity. If you want to move fast safely, you need to be confident that your changes aren’t breaking things. That means robust testing to catch issues early and real-time data to validate behavior in production.

All of these factors tie into sustainability. If teams are misaligned, if code is rushed out with poor test coverage, or if planning doesn’t account for design and testing time, you end up in a cycle of constant firefighting. Long-term sustainability comes from building systems that support both speed and quality – so that engineers aren’t just productive today but can continue delivering value over time.

InfoQ: What have you done to improve the effectiveness and efficiency of software development in your company?

Jennifer Bevan: Well, now, I’ve been at Google for 18 years now, so, I’ve worked on a lot of things. In the early days, I built general-purpose test infrastructure (web and integration testing). In the middle bits, I did direct feature and product testing, gravitating primarily towards accessibility, privacy, and velocity focus areas. Somewhere around that time, I started developing my personal brand, which was nominally, that I didn’t care what the product was trying to do this time, but that I was determined to make the next time “suck less”.

I took that mindset and the general pattern of starting by cheerfully and aggressively partnering with the product teams, which led to both ongoing successes like our test accounts system, and long-lasting relationships with leads who know that I will find ways to land concrete improvements but not necessarily in the way they originally expected. I then moved closer to the governance and compliance space, because the incoming number of regulations was a scaling problem that wasn’t waiting to happen anymore. Am I happy with the progress? Yes, but I’m EngProd, so I’m also dissatisfied with it. We have so much room to continue to get better.

Sergii Gorbachov: In my role, I’ve focused on AI-driven code migrations and frontend test generation. Recently, I led a large code migration from Enzyme to React Testing Library, which initially required around 10,000 engineering hours. To optimize this effort, I developed a tool that accelerated the migration, saving time and reducing manual work.

Additionally, I created another tool leveraging large language models (LLMs) that allows generating React unit tests. I see significant value in using LLMs for code generation, error analysis, and data summarization, as they can help enhance productivity and optimize internal processes, and ultimately make software development more efficient and effective.

Jenna Butler: A few things! One of the biggest initiatives I led was a long-term diary study where engineers logged what went well and what challenges they faced every Monday, Wednesday, and Friday. Over time, we collected more than 14,000 responses – all read by real humans – which gave us deep insight into the day-to-day struggles of developers.

One of the biggest issues we uncovered? Engineers were stuck in back-to-back virtual meetings, with no time for even a quick break. So, we introduced the 5-minute rule: all 30-minute meetings were cut to 25 and started late instead of trying (and failing) to end early. This became an org-wide practice across thousands of engineers and is now built directly into Outlook and Teams.

I also led the adoption of the OKR framework after research showed that many engineers weren’t sure what the overarching company goals were or where to find them. By improving transparency, we helped teams better align their work with strategic objectives.

Most recently, I studied what causes engineers to have a ‘bad day.’ One major factor? Flakey tests slowing down development. As a result, we’ve been tackling those technical pain points to improve the developer experience. By continuously listening to engineers – whether through diary studies, research on bad days, or refining OKRs – we’ve made structural changes that improve both efficiency and developer happiness. And that, in turn, leads to better software.

InfoQ: What role does leadership play in sustainable software development?

Jennifer Bevan: They can make it or break it, especially at top-down companies. And it gets worse when there’s a revolving door of decision-making leads, because not only do the product priorities tend to get recategorized and shifted around, but every “horizontal” effort comes under scrutiny, and if you don’t have your metrics and narratives lined up, or enough allies within leadership to sponsor the efforts, then any of the more forward-looking productivity or sustainability investments are at risk.

Leadership has the unique ability to keep translating, at every layer up, why what we are doing is a critical part of delivering the company’s product offerings – and therefore we protect their revenue stream, even if we can’t prove the negatives of how many bugs, or outages, or incidents that we prevented.

Sergii Gorbachov: Leadership plays a crucial role in sustainable software development, as they set the strategic direction and determine how resources and time are allocated. Effective leaders understand the company’s priorities and resource constraints that enable them to guide teams toward high-impact projects that align with long-term goals.

However, one challenge can be the gap between leadership and the nuances of sustainability in software development. Without a deep understanding of sustainable practices, leaders may prioritize short-term gains over long-term resilience and efficiency.

Jenna Butler: Leadership sets the tone for how work gets done. A big part of sustainable software development is proper planning – not just for coding, but for everything else that makes software reliable. It’s easy to underestimate how long a feature takes. Beyond writing code, teams need time for planning, integrating telemetry, testing, and deployment. If leadership doesn’t account for these in project timelines, quality and sustainability suffer. This is something the book “Clean Coder” explains really well (and every developer should read this before their first corporate job!).

Leaders also have the unique ability to see the big picture – something individual engineers often can’t. They should track key metrics, like those in the SPACE framework, to ensure teams communicate effectively, maintain test coverage, and keep throughput healthy. After all, you can’t improve what you don’t measure.

But measurement alone isn’t enough – leaders also need to reinforce sustainable practices. If teams are pressured to cut corners or ship too fast, burnout and tech debt pile up. The best leaders create an environment where good engineering habits – like writing tests, maintaining clean code, and allowing time for quality work – are not just encouraged but expected and rewarded.

InfoQ: How can we remove friction and obstacles in software development, making it easier for software developers to do their work?

Jennifer Bevan: Well, I think the first step is to listen to them. I rarely support asking product teams what we should do for them. That’s a great way to get nothing but XY problems. Instead, I tend to focus on listening to what it is they are trying to do, and what they think is keeping them from doing it well.

The second step is a bit unconventional: if the developers are not complaining enough, it’s probably because they’ve become complacent with, or resigned to, the status quo. In those cases, we can adopt the “we’re all one team” mindset and actually help them deliver features for a while – on the very clear understanding that we will be taking notes about everything that causes friction and then going and fixing that. That’s an excellent way to get the ground truth about how development is really going: listening, and hands-on learning.

After that, it’s mostly just problem solving at scale, making the right things to do the easiest things to do, and meeting the developers where they are before stealthily making everything better under the hood and then sending out celebration emails with lots of good metrics.

Sergii Gorbachov: It might be achieved by replacing software engineers with AI agents, in that way we will remove human involvement and will have no friction or obstacles. Jokes aside, friction and obstacles are essential aspects of the software development process, including writing tests, reviewing code, analyzing errors, or debugging. These tasks are part of the role for both product developers, who create customer-facing code, and internal developers, who write code to support them. Rather than viewing these as barriers, we could consider them as fundamental responsibilities of software developers.

Another important consideration is whether all friction is inherently negative. For instance, if a developer writes code, fails an end-to-end test, and then investigates logs or seeks help to resolve the issue, this process not only promotes accountability and learning but may also lead to beneficial changes, such as decoupling functionalities to prevent unintentional impacts on other features. While current tools don’t fully automate such problem-solving, large language models (LLMs) could bring us closer to reducing this friction by effectively handling complex and varied information.

Jenna Butler: I think the answer is obvious, but hard – we need to be willing to fund it. Every team wants fewer bugs, better telemetry, and stronger documentation, but no one wants to slow down development to make it happen. The truth is, if you want a smoother development process, you have to invest in it.

Fixing rushed code, documenting as you go, and doing meaningful code reviews all take time – but they massively improve both the developer experience and the final product. And right now, we’re in a golden age for making this easier, thanks to GenAI tools like GitHub Copilot.

I recently ran a randomized controlled trial on GitHub Copilot, and we found that developers using Github Copilot reported spending less time on mundane, boilerplate work and got to do more “fun” work. Even if you only leverage it for documentation – though that barely scratches the surface – it can dramatically improve code quality and maintainability.

And if you don’t fully trust AI-generated code? That’s fine. There are plenty of ways to use it today. Let it handle documentation, help you learn new APIs, or generate test cases. Start with low-risk tasks, and free up your time for the deep, creative engineering work we all love to do.

Conclusions

In software development, achieving a balance between speed and sustainability requires informed decision-making, prioritization of strategic value, and building engineering systems that support both speed and sustainability. Driving productivity and sustainability involves improving code quality, streamlining processes, fostering team alignment, and matching engineers with meaningful work.

Enhancing efficiency comes through continuous feedback, workflow optimization, transparency, and leveraging automation tools. Leadership plays a key role by setting direction, ensuring adequate planning and resource allocation, and fostering a culture that values sustainable practices.

Finally, removing friction in development demands listening to developers, investing in the right tools, and using AI to automate repetitive tasks, enabling higher-quality work and smoother processes.