The key hypothesis of this paper is the relationship between releasing software and the Nadler-Tushman model.
Enterprise software is the automation of an organization's formal processes. Each time an organization releases software, it changes the “work” component of the organization in the Nadler-Tushman model. With each software release the people, culture, and org structure components must then be evaluated and possibly updated to keep congruence in the organization.
This means that the working software output of the agile software development model is a change in the work component of The Nadler-Tushman model. Under an Agile software development methodology, these changes are made frequently. During my time at Chatham Financial we released software every two weeks. In order to maintain congruence every two weeks we needed to evaluate the impact of the released software on the people, culture, and organizational structure components of our business. While this seems daunting it results in a series of small incremental changes and it is far easier to implement than the alternative of making large organizational changes every six months to a year.
When an organization adopts this mindset, the view of Agile software development changes from a process for creating software to a process for introducing organizational changes. Each software release requires managers to evaluate the congruence of their organization. If this task starts when product development is complete, managers lose their ability to adapt the product to meet their organization’s specific needs. The product may “check all of the boxes” on features but when a manager evaluates the output of their department, they may see no improvement or even a degradation of performance.
Taking an iterative approach to software development allows managers to continuously evaluate each component of the Nadler-Tushman model and shape both the software and the organization around it to maximize efficiency.
Release Management and the Hard Axis
The link between software and the hard axis of organizational structure and work is the most transparent of this framework. As business processes are automated and codified, new formal processes are created and the organization must find places to house the responsibility and accountability for production operations.
Effect on Uncoded Formal Processes
Not all work is automated. Not all work should be automated. Automation comes with development and maintenance costs. The more features are added to a system the more expensive maintenance of that system becomes. In the scrum software development process, each sprint the owner of the backlog prioritized a set of work and the team delivers. In the 14 years that I have used scrum, I have never seen a backlog become empty, there are always more features that could be developed. Development of an application typically ends when the value of new features is less than the development costs of those features.
Luckily this connection is typically done well in Agile organizations, and the business analyst role is well understood.
Effect on Org. Structure
When a manager evaluates the performance of their teams, responsibility and accountability must be clearly understood. In all but the smallest organizations some formal organizational structure is imperative for efficient operations and for teams to see how they contribute to the overall organizational strategy. As we change the “Work” component of Nadler-Tushman we will see a change in responsibility and accountability for that work. New work cannot be created without a place for that work to happen. Therefore, each release of a product must be evaluated against the organizational structure to ensure that the organization can deliver efficiently and without confusion.
User Experience and the Soft Axis
A modern trend in software development is the focus on User Experience (UX). A Business analyst asks the question “What do you want the software to do?”, while a UX designer asks “Why are you using the software?”. This distinction is a shift from focusing on the software itself and the work component of Nadler-Tushman to focusing on the people and culture components. By understanding these components early in the development process organizations can create enterprise software that more easily fits into their organizations, increasing adoption and efficiency gained.
The UX philosophy does not only apply to graphical applications. In fact, most of the code that I manage is “back end” code. This code still affects the “work” components of our organization and therefore it will have an effect on people and culture. When designing business processes, including those meant to be automated, organizations must ask these questions if they want to create truly effective software.
Effect on People
Very little enterprise software works without people. Great enterprise software is designed to leverage the talents of an organization’s employees and scale their skills, allowing them to focus on the more difficult or creative tasks that they need to do to accomplish the organization’s mission.
Effect on Culture/Informal Processes
Few managers have stopped to ask the questions “What effect does my software have on my organization’s culture?”, but when using the Nadler-Tushman framework the link between these becomes clear. Viewing culture as the informal processes of the organization and enterprise software as an automation of the formal processes, managers can begin to understand how to create software that allows the best parts of their organizations culture to thrive, and the worst parts to change.
Leave a Reply