OKRs and Software Architecture — Why Organizations Fail to Change
In almost every organization nowadays, agility is a prerequisite for success. In tech companies who have a software product at the core of their business, agility starts with a proper and solid architecture that encourages team autonomy, continuous improvement and, ultimately, customer value.
Every product company starts small, lean, and most of the time agile. Their employees are often involved in various projects and initiatives, they experiment, fail and learn in a fast-paced environment. Modern startups recognize the value behind an evironment that fosters quick exchanges and collaboration, in order to deliver a fast response to market needs. The teams are still quite small and cross-functional, and while they might have a hard time hiring the right talent for their needs, their employees are flexible, autonomous and savvy enough to solve almost any problem they might face. In software companies, the architecture is often still monolithical in their first years of business and technical debt is not yet a concern. As companies mature and grow in size and technical legacy, they start looking at the way the infrastructure is represented and at what they can do to improve it. But sometimes, growing businesses have a hard time shifting from a monolithical infrastructure and, as time goes by, they lose more and more money, resources and great talent when they fail to adapt. The transition to a microservice-based infrastucrure becomes their most burning pain point, since any further product decisions that meet new customer needs will heavily rely on a sound, healthy technical architecture and on well-designed teams.
While this article will not try to give you a thorough understanding on what microservices are and what organizations need to do in order to adopt this type of infrastructure, it is worth pointing out that businesses that have adopted microservices have significantly reduced the dependencies between their software development teams and the time that it takes to bring changes and new functionalities to production. Microservices also support the organization of product development efforts around feature teams rather than component teams.
As illustrated in the screenshots below, a component team is a single component and cross-functional team that focuses on developing one or more components that can be used to develop only a part of an end-customer feature. It is a horizontal team that might specialize in data, front-end, back-end and so on. Its advantages are in architectural consistency and code ownership, but fails in delivering end-to-end results and is less customer-oriented. On the other hand, a feature team is a cross-component team that consumes end-to-end items from the product backlog, is user-oriented and significantly reduces the number of cross-team dependencies. Although feature teams might carry the disadvantage of code duplication and of being sometimes harder to staff than component teams, they also enable faster inspection, adaptation and system productivity.
In agile organizations, Scrum teams are formed and structured to maximize product value and deliver that value in an incremental and iterative manner. Without a proper staffing of the Scrum teams, they often struggle to deliver a shippable increment at the end of each sprint and thus fail to create that customer value. When organizations focus on creating feature teams that use Scrum to maximize the benefit on the customer side and to deliver end-to-end functionalities, they increase the chance of success and reduce the time to market. Because the focus of component teams is not to iterate on what clients need and desire, but rather to maintain an already working system that does not require complex exploratory work, a conflict at system design level appears and the value of Scrum is not maximized. Moreover, a monolithic infrastructure creates dependencies between component teams and slows down technical debt rework and technical innovation. Luckily there are ways to help such teams to improve their workflow and to reduce their dependencies by using agile practices from Lean Startup, Kanban and XP.
While an organization struggles to understand business and technical agility and how to transition from a monolithic architecture to microservices and feature teams, it is very important to be aware of the difficulties that might arise when adopting the OKR framework too early in the agile transformation. An agile transformation is not just about helping the teams embrace agile frameworks and the right tools that enable them to foster transparency at scale, but will often start with technical agility that forms the base of the transformation. Agility is also about mindset and about learning to prioritize the work that results in positive business success metrics and in alignment between teams and stakeholders.
The OKR framework is a tool designed to create that alignment and engagement around measurable goals throughout multiple departments and teams. It is a change management framwork that enhances agility and works hand-in-hand with agile practices and frameworks to live by the vision and mission of the organization. It is by no means a framework designed to micromanage teams and departments. Unfortunately companies often times fail to understand the values behind OKRs and misuse it to their own business disadvantage.
If I have to think of an example of mismatch between software architecture and the application of the OKR, it is one in which a slow technical transformation in the context of a shift at company vision and mission level collided with the ambition to transform the way teams aligned and collaborated in order to release valuable functionalities. Although the organization was happy to shift towards a data-driven product organization, it did not have the necessary technological base in place to allow such big change and it did not yet have the right mindset to allow such a transformation. Here are some of the points that I have pinned down from their transformational journey:
The technical department relied heavily on component teams. In the context of product shift and the growing need to change and experiment with new functionalities and designs, the company needed to create high-performing end-to-end teams that used Scrum to their best advantage. Instead, it struggled to break out stable component teams into task-forces that were supposed to function as feature teams, but only partially managed to; on top of that, the OKR framework, as understood and applied in this organization, brought with itself the need to cross-polinate and create new temporary teams to test out experiments and initiatives with a high degree of risk. In the face of so much change and struggle for resources, the teams went through a constant storming phase that created confusion, chaos and dissatisfaction at work.
Product failed to recognize and prioritize technical excellence and quality. With so much change happening at product vision level, the engineering teams struggled to point out the benefit of modernizing and improving their technological stack, while product visionaries pushed for new features and designs. Their transition from monolithic to microservice infrastructure faltered in the face of other priorities and the engineering teams continued to hotfix issues that might have been avoided once the new architecture would have been in place. On top of that, the pressure of the OKRs forced teams to deliver less value to the customer and paradoxically to focus more on putting out internal fires.
Continuous Improvement was second priority. Without a proper understanding of the OKR framework and with an unprioritized product backlog, teams did not manage to understand what to focus on. With their main systemic goal being to improve and fix existing applications, component teams were faced with the pressure to deliver output rather than outcome. That took away their focus on continuous improvement and practices such as Test Driven Development, Continuous Integration and Continuous Delivery remained a far away dream.
Recap and Conclusion
As organizations become aware of the benefits of componentizing their monolithic architecture into microservices, they also face the dilemma of restructuring their teams and departments. In order to switch from component teams to feature teams that are empowered by the microservice infrastructure, software engineers need to define the business capabilities together with product managers and stakeholders. Once there is a clearly defined design for the new microservice structure and there is a general understanding among tech and non-tech employees of the product strategy, the organization can focus on defining the roles required for each feature team and can consider bringing in a framework such as Objectives and Key Results to keep the organization aligned and focused on value metrics.
While microservices are supporting an organization invested in achieving customer value, it is worth noting that monolithic architectures are not the bad guy here, but rather a necessity at the beginning of a product’s life cycle. But, as companies grow and products mature, the need to adopt a microservice architecture becomes more and more a priority. If product companies want to redesign or bring changes to existing functionalities, they need to reconsider the system structures and how they can redesign these in order to enable faster learnings, less dependencies and, at the same time, architectural quality. Without a proper transition to feature teams, an organization that wants to survive market changes will face great hurdles in achieving a faster time to market or in creating more value for the customer, thus resulting in less talent acquisition, less revenue and increasing infrastructure costs.
While the OKR framework is an excellent tool that can be used in multiple ways to help organizations align and create great quality products, it is also worth considering if the organizations are ready for the change that the framework brings with its adoption. Is the technical and organizational infrastructure allowing cross-team work and are the teams and departments organized in such a way to allow the changes and alignments to happen with easiness while keeping autonomy and purpose alive? Are the teams self-organizing and is the communication with the stakeholders requiring little effort on each side? If companies are not there yet, they might consider a different way to help break communication silos and to create alignment. Starting small from a few teams and expanding in a sustainable pace may bring much more value than a large transformation that requires too many resources at once. Let’s build strong organizations by adopting the right architecture, by building autonomous and happy teams and by teaching them to build long-term alliances that ultimately benefit both the customer and the business itself.
