When pressed, more enlightened decision-makers say they regard technology as a business and innovation partner. But all too often, the technology division is seen as one dimensional; simply accountable to their business stakeholders for work done and change delivered within the parameters of a given budget.

It’s a simple enough equation: Output divided by input. And a successful solution delivers the greatest output for the least cost.

But it’s not just about the volume of change delivered — producing broken code in an unreliable timeframe is unlikely to win the authors many friends. No, it’s also about the quality of change, delivering working code through to production without breaking or destabilising the existing system. Another vital characteristic is predictability, delivering the agreed scope on time, every time.

All or nothing

Like football, it’s a team game; you win together and lose together. And, as in the beautiful game, recruiting a group of high-performing individuals doesn’t guarantee high-level output. Your team has to function as a unit, with senior developers mentoring less experienced colleagues. Consequently, you need to measure the output of the whole team rather than individual team members.

Most software delivery metrics focus on coding, but this is only one part of the process. Unclear or unstable requirements and poor testing can result in a drastic reduction in output, so look at the whole picture — the total delivery lifecycle.

Measuring the right output

While it’s relatively easy to measure output in isolation, it’s virtually impossible to measure whole systems or teams — the input needed to produce it will vary greatly between systems. Output will differ significantly according to whether you’re working on an old, undocumented monolithic application with no testing or a brand new unit-tested set of microservices.

Whichever metrics you use, at least you can compare them at specific times to get an idea how your teams are performing and whether the trend is positive.

Factors that affect the rate of change:
  • Age and complexity of system and codebase
  • Type and scope of the change
  • Documentational quality
  • Greenfield versus brownfield project
  • Architectural complexity and flexibility (e.g., monolithic versus microservices)
  • Tools and technologies used
  • Automation levels enabled
  • Software development lifecycle (SDLC) and release cycle
  • Test environment availability
  • Business requirement quality and stability


Software development’s greatest attribute is that everything is measurable. And as a delivery organization matures, an increasing number of items can be tracked via a dashboard, allowing the regular monitoring of trends. Items like:

  • Stories delivered — a guide to business value
  • Pull requests per sprint — incremental delivery of value into test environments
  • Size of the codebase — the magnitude of one system versus another
  • Coding style violations — how much of the code follows best practice for maintainability
  • Defects found in each phase of the lifecycle — how many bugs are finding their way through each stage of testing and into production
  • Capacity allocated to new functionality versus bug fixing — the effort spent retracing your footsteps
  • Actual versus estimated effort — understand and refine estimate accuracy, learning from experience
  • Average delivery cycle time — how long it takes for a feature or user story to go from requirements specification to production
Process maturity
  • Knowledge index — spread of expertise across the team and different components
  • Requirements stability index — reliability of incoming requirements
Production stability
  • SME callouts — out-of-hours, critical issue investigations
  • Average time to resolve production issues — how soon the system can be fixed
Team stability
  • Employee motivation index — signs that your team is happy at work
  • Attrition — level of employee turnover (or churn) in the organization
Interpret your measurements

Measuring teams is fine as far as it goes, but what do the measurements actually tell you? Correlation between metrics can strengthen the signals and flag-up when it’s time for action.

Potential risks you could diagnose:

What drives output creation?

The scale of software engineering output depends on a combination of many factors, including individual excellence, teamwork and the company environment.

Clearly, you need to hire the best engineers you can find. At Luxoft, we have a large presence in parts of the world that give us easy access to top talent.

As well as technical skills, you want individuals with the right project experience and domain knowledge — people who have worked in your industry before and understand the nuances of your particular project environments.

Once you have the raw material, it’s about the way you set up and operate your teams. As mentioned earlier, just having a group of smart developers is not enough. Success relies on getting them to function as a cohesive, high-performance unit. This involves delivery processes and tooling, as well as best practices such as ensuring efficient knowledge management to avoid key person dependency.

Then there’s the ex-factor — building a culture of excellent performance, with exemplary training and exceptional motivation. HR processes have a central role to play here, promoting diversity and inclusivity to create a stronger team ethic and a more eurythmic workforce. The whole is stronger than the sum of its parts, and engendering a sense of belonging and respect, alongside peer and corporate recognition is a tried and tested way of developing and retaining your best talent. After all, staff retention is a key factor in ensuring predictable delivery.

With all that in mind, we must counsel you against assessing your development organization on a cost-per-head basis. Team and company considerations can have a telling impact on overall performance.

To misquote John Donne, No manager is an island, and the technology division is not entire of itself. In other words, no tech team performs in isolation.

Healthy collaboration between both individual technology teams, and technology and the business is a central pillar of software development success. However, technology teams can only fully engage with the business if they have sufficient domain knowledge to do so (which, I’m pleased to report, Luxoft teams do).

As you can see, getting optimum value for money from development teams isn’t just about cutting costs — nowhere near. There are a great many collaborative ducks of all shapes and sizes to get in a row before all parties can say they’re truly aligned.

Get in touch

At Luxoft we’ve been building and operating high-performing software engineering teams for more than two decades. Whether you’re building a new team or want to measure and increase the performance of an existing team, our experienced delivery managers and consultants can help you arrive at the right blend of metrics.

Mark Reynolds
Mark has 14 years’ experience of Financial Services technology, enabling strategy and business growth in a variety of client-facing leadership and business development roles. He specializes in working with nearshore technology delivery organizations, having built and led teams across Central and Eastern Europe.
Balaji Venkatramani
Solution Lead, Engineering Processes
Balaji is a senior director with Luxoft India. He leads engineering process solutions, globally, across lines of business and is responsible for delivery strategy for the APAC region. During his 22 years in the IT industry, Balaji has driven large-scale technology solutions and transformation initiatives in Silicon Valley technology companies, as well as service partnerships with global financial clients. He has extensive experience in knowledge transitions, transformations, Agile, DevOps, big data and analytics, cloud and program management.