Getting Ahead of the Productivity Conversation

As a technology leader, how do you optimize for high performance in challenging and increasingly competitive markets? 

Given the macroeconomic outlook, you may deal with even more requests to justify budgets and find savings. Clarifying strategic alignment and the role your team plays is the first line of any budget defense. That said, equally important is to be fact-based with how the spend associated with your teams is translating to performance and what you are doing to further improve productivity.

Why should your CEO/CFO believe you’re running a tight ship? Why should they see your team as the one deserving investment at this point? And if push comes to shove, can you make smart trade-offs between spend and results?

In this article, we will discuss how you can get ahead of the productivity conversation. We’ll dive into three fundamental principles for improving overall digital product development productivity:

• measuring what matters
• organizing for speed, and
• cultivating a product mindset.

 The combination of these three elements will help you achieve higher performance and feature velocity while also increasing developer experience, which will assist in hiring and retaining top talent. 

Why Feature Velocity Is Key

Ultimately, releasing often by increasing deployment frequency and feature velocity will improve the quality of product management and the speed at which you can reach product-market fit. 

Understanding that your feature velocity is also the velocity at which you learn something new about your market is the first step in improving overall performance. 

You may have ideas, but neither you nor the customer can know how good they are before you put them to the test and get hard data. The company that learns the fastest wins the game.

Measure What Matters 

The first foundational principle relates to identifying and recognizing which metrics are important to measure. The heavily research-backed DORA framework puts forward four key metrics that, when improved, allow teams to drive productivity, improve developer experience, as well as lower deployment anxiety for the whole organization. The four key metrics are:

• Deployment frequency – how often you are able to launch new features.
• Lead time for changes – the time from when you finish building a new feature to when your customers can actually use it.
• Change failure rate –  how often launching a new feature causes a failure in production that needs to be addressed.
• Mean time to recover – if your production system fails, how fast can you fix it.

The DORA framework is discussed at length in Accelerate, a book by Nicole Forsgren, Jez Humble, and Gene Kim, where they found that creating high-performance software development teams, as measured by the DORA metrics, leads to higher business performance – such as profitability, productivity, operational efficiency, and market capitalization. The closer you get to the ‘elite level’, the higher your overall software development productivity and the higher the performance of the entire enterprise.

While DORA metrics are technological delivery metrics, what they are measuring is speed and quality. It’s not just assessing your tech detail but your product development capability. From our experience, teams that deliver software are very open to adopting these types of metrics since most dev teams want to release often and keep with industry best practices. But as usual, it’s important to make sure that metrics aren’t just enforced top-down but are adopted by empowering the teams themselves to seek ways to improve performance – we live through this day in, day out, using these metrics to drive improvements in our organization.

Getting Started with DORA

At Reaktor, we’ve seen these metrics generate success for many of our clients. With one Fortune 500 company we worked with, we decreased deployment frequency from a three-month delivery cycle to several deployments per day. The results were outstanding, with immediate upticks in the growth of the business.

That said, although DORA metrics correlate with higher organizational and company performance, correlation doesn’t automatically equal causation. There might well be other challenges that are blocking your growth. But understanding how your teams perform against these measures is a good starting point in forming a picture of possible improvement opportunities. DORA helps you determine whether your teams are able to improve the product fast and with high quality – a foundational capability. The user value of the features launched should then also be tracked, e.g., by conversion rate optimizers and product managers observing the associated improvements in conversation, adoption, usage, churn, etc.

To get started with DORA, several software products ease your teams to adopt the framework, such as Swarmia or Sleuth – to name a few. Once DORA has become a part of your teams’ ways of working, you can start comparing your organization to industry benchmarks using the annually published State of DevOps report.

Organize for Speed

Once your teams are established with the right metrics, you want to make sure the focus is on the most valuable tasks at hand. Ideally, you don’t want them to be waiting around for anything.

Especially in large organizations, a lot of time is spent on synchronous meetings and communication. Teams responsible for delivering features that drive user or customer value shouldn’t have to rely too much on any other teams or systems that they do not control. The more dependencies there are, the more points of possible failure and delay exist – limiting the speed at which new ideas can flow through the organization into production.

Team Topologies

A book called Team Topologies, Organizing Business and Technology Teams for Fast Flow, written by Matthew Skelton and Manuel Pais, outlines an approach for creating organizational structures that enable teams to focus and work in fast flow without unnecessary bottlenecks caused by communication. We would argue that Team Topologies is possibly the best book about software architecture that is not actually about architecture.

The book categorizes work into four relevant team types: stream-aligned teams, enabling teams, complicated subsystem teams, platform teams, and three core interactions between them. Stream-aligned teams create features for the end users, and the remaining teams handle capability building, enablement, and complex shareable components. 

The core concept ideology is based on applying Conway’s law – an adage rooted in the idea that a system’s design follows organizational communication patterns. Meaning organizations that design systems tend to produce designs that are copies of the organization’s communication structure. “Beware that your team assignments may end up being the first draft of your architecture,” as Michael Nygard writes.

With foundational DevOps capabilities in place, the team topologies approach will help you to further improve your DORA metrics by reducing the communication and cognitive load of your teams by allowing the completion of features to lay within their own control rather than in external dependencies.

End-to-end Ownership and Minimal Dependencies

Until quite recently, pooling common types of skills (e.g., by technology or platform) into separate teams was considered the smart org design move in most cases. However, in a world of modern DevOps practices, this has actually become an anti-pattern that you should avoid.

Instead, the winning organizing principle is to consolidate development work associated with building a new feature into the same team and backlog, even when you have to touch multiple technologies and systems.

Thus, consolidating user value-adding work into multi-competency (stream-aligned) teams is perhaps the most important idea of team topologies. It’s less about how the technology architecture is arranged and more about how to organize the work across it to minimize requisite communication and dependencies between the teams.

To demonstrate how inter-team dependencies can create issues and slow things down, let’s take the classic front/back-end team splits as an example.

A problematic org design that we frequently see splits work into different front-end web development and back-end services teams based on skills and competencies. This is often simply just matching people with the architectural components and assigning ownership and control of those components to the respective teams. As a result, the web team cannot work independently but has to collaborate constantly with multiple backend teams to finish tasks. In practice, the web team must – especially with new features – ask for some tasks to be added to the backend team’s backlog and wait for them to be finished before the two teams can coordinate a release. Add several other backend teams to this picture, and your productivity is decimated by an outbreak of complexity, constant communication, and waiting between the teams.

What you should do instead is assign engineers to teams responsible for delivering products or user features and give them end-to-end control over all the architectural components that may need to be changed, including the backend. This will also set you on the path to evolve your tech estate into a true user-centered architecture. In such a setup, all the elements are designed to add end-user value instead of being a compilation of mingled architectural components designed to serve each other, wholly unaware of the user’s actual needs.

As the system scales, it may make sense to form some separate shared enabling and platform teams. However, the raison d’etre of these teams should always be to support and reduce the cognitive and collaboration load of the user product/feature-focused stream-aligned teams. This can involve, e.g., automating reusable infrastructure services, APIs, or configuration tools that the stream-aligned teams can then use independently.

All that said, it is important to repeat here that adopting DORA and modern DevOps practices like trunk-based development, continuous testing, integration, etc., is a prerequisite to getting the most out of the key concepts of team topologies.

Cultivate a Product Mindset

The last foundational principle is around cultivating a product mindset. The mark of high performance is rooted in iterative development, experimentation, and continuous improvement.

A product mindset means that your organization is focused on solving the right problems with an eye on economics. Whether you are building an internal tool or something new and flashy for your customers, you need product-minded people who are passionate about deeply understanding the users, as well as building something that scales and is cost-efficient to maintain and extend.

Once the problems are thoroughly understood, you should let the product team experiment and innovate – fully engaging all the brains to find the best solution. ”Nothing is as valuable as an empowered engineer,” as the legendary Bill Cambell puts it in the  book Trillion Dollar Coach.

A Cross-functional Environment With Product at Its Core

At the beginning of this article, we outlined how DORA’s deployment frequency and feature velocity correlate with higher organizational performance. One of the reasons why this is possible has to do with product teams being able to release new features daily with confidence and quality. The product team, as a whole, can learn from the market instantly with high deployment frequencies, enabling them to achieve maximum product-market fit much faster than teams that have to wait months to see how their releases performed and whether the users liked the new improvements or not.

We would strongly advise doing away with the “we’re just an execution arm mindset”, where the tech team exists only to serve the needs of the business. Becoming just a feature factory should be avoided at all costs. Instead, begin instilling and cultivating a product mindset – where cross-functional product teams work daily with the organization at large and exist in unity to meet the needs of the business and its clients. In the book INSPIRED, Marty Cagan outlines the role of product management and product managers within the organizational structure. Cagan points out that you do not simply need outstanding product managers. You need a combination of outstanding engineers, designers, and product managers – all sharing the same product mindset and working on the same team.

Bridging the gap between business and technology all the way down to the team level is a crucial component. You, as the technology leader, are in a key role in making this shift happen. 

Defending Your Budget

So, how does this come back to defending your budget? Adopting the above methods is the first big leap on the road to true operational efficiency. It allows you to prove that you are running a tight ship with an ever-improving ability to do more with less. This makes a case for your teams to deserve more investment, not less. 

It’s clear how your performance compares, and once you reach the elite level, there is no waste in the system – any savings would cut straight into the muscle. Your work and tech estate are also organized in such a way that if push truly comes to shove, you can shift spending and dial investment up or down for individual features, each of which presumably has a revenue (or other financial) impact associated, allowing you to discuss the trade-offs in financial terms. You don’t have to resort to nonsensical ”cheese slicer” cost-cutting that would probably hurt more than help.

Ideally, your software development verifiably becomes so productive that you aren’t even asked to produce savings in the first place, which is really what everyone up to the board and shareholders should want. Because a great way to get ahead of the competition is to keep building when others stand still.

About the writers:

Mikael Kopteff works as a Chief Technology Officer at Reaktor. He is a passionate, forward-looking technology leader with a huge interest in cutting-edge technologies and the methodologies of creating exceptional digital products. Mikael specializes in technology organization design, technology strategy, business and digital strategy, technology innovation, software and enterprise architectures, modern process methodologies, modern leadership, self-organization, systems thinking, data, and AI.

Ali Paasimaa works as an Executive Chairman at Reaktor North America and has 20 years of experience leading high-performing technology and strategy development organizations. He specializes in technology governance and leadership, digital strategy and transformation, financial and business performance management, and software product development and management. 

Interested to learn more about optimizing for high performance? Get in touch.