How software engineering can tackle performance challenges [Q&A]

Software engineering organizations often grapple with challenges that hinder their output -- including productivity blind spots, duplicate work, deadlines that don't stand a chance, burnout, and other hidden costs that eat up time and energy.

And while metrics can signal a problem, they don't always uncover the root cause or -- more importantly -- how to fix it. To explore this, we spoke to Joe Levy, CEO of Uplevel, an engineering optimization system helping developers independently measure the ROI of AI adoption.

Joe shares why pairing data with change enablement is critical for diagnosing inefficiencies and driving transformation. He also explains why Uplevel is bridging two historically separate disciplines -- engineering analytics and change consulting -- to help companies truly move the needle.

BN: What are some of the biggest challenges engineering teams face today in understanding and improving productivity?

JL: There's that saying that 'what gets measured gets managed,' but there's also a common misconception that measurement alone is enough to drive productivity. Real change is a human practice, and it requires navigating complex organizational structures and understanding how people think and act.

Change happens when both leaders and the working teams align on what to improve and how, and make the change a priority they track. This might sound easy, but even getting alignment on what to change can be a large hurdle, especially in big organizations. It requires understanding the business goals, what current productivity insights show, and, critically, the context from the teams.

BN: Why is it risky for engineering teams to rely solely on metrics to diagnose performance issues? Can you share examples of hidden costs or blind spots that numbers alone fail to uncover?

JL: Numbers might show that a team has complex work items that are generating tons of back-and-forth comments, taking a long time to complete, and resulting in a lot of meetings. Clearly, there is a challenge. But the challenge could still be many different factors such as poor coordination with product management, not enough time for technical discovery, a new team of people working on a fragile legacy product, and so on.

Proper diagnosis of the problem requires direct conversations with the teams for context and understanding. When you make changes based on metrics alone, you’re likely going to get pushback from engineers with boots on the ground (at best), or you'll make changes that take a lot of time and effort but don’t move the needle. Good management requires seeing the entire picture strategically before you take action.

BN: What is 'iterative change management' and what’s its role in driving change?

JL: Improving engineering productivity is not a one-time event. There are often multiple root causes for engineering delays and multiple changes that need to be made over time as systems and teams evolve. It requires continually suggesting the best change to make, helping the team make that change, and then reassessing the next best action.

That's why we've added Iterative Change Enablement as a core piece of the Uplevel system -- using data to surface the most valuable opportunities for improvement, and then giving teams the resources, tools and skills they need to act on them continuously.

BN: How does pairing data-driven insights with hands-on change management create a more complete solution/better way for engineering teams?

JL: Improvement comes from knowing what to do with the metrics that you see (and all the additional context that complements the metrics to tell the whole story). Insights alone lack context and rarely drive behavior change. They'll tell you what's wrong (mostly in lagging indicators) but not necessarily how to change it -- what new processes to adopt, how to involve your team in solutioning, how to gauge if changes are working, or what kinds of outcomes you should expect.

The truth is that you need both -- data and a process for change. Data needs to guide your change efforts and measure progress in the right direction, but organizational change is actually the harder part of the equation -- requiring skills that most engineering leaders simply haven’t been equipped with. If the entire point of measuring productivity is to improve it, we as an industry need to know how to close that gap.

BN: Do you see other sectors adopting a data analytics and change enablement model? How might this approach benefit industries outside of engineering?

JL: This approach has benefited other verticals for decades. In sales, a pipeline report might show low conversions at a particular sales stage. But until you talk to the teams and understand that, for example, they don't have good competitive intel to advance the deal to the next stage, you might not know the best solution to fix this bottleneck. Uplevel is bringing this same method to engineering.

BN: What advice would you give to engineering leaders looking to create lasting change within their organizations?

JL: Understand that engineering improvement has both technical and social components -- and that if the problem has both, the solution should too. Change cannot be only top-down. It requires context and buy-in from teams who are the ones actually changing. When teams understand the 'why' behind metrics and are involved in being part of the solution, they're more likely to embrace new ways of working.

Image credit: everythingposs/depositphotos.com