The Art and Science of Software Management
How management of software organizations can make the difference between stagnation or growth of a business
Introduction
Why are some companies growing while others stagnate? Why do certain companies employ double the amount of technical staff compared to their counterparts even though they offer identical services? Why do some companies drown in technical debt while others maintain high levels of productivity? Over the years we have worked with hundreds of tech companies across various industries. As companies grew from start-ups to established companies with hundreds or even thousands of employees, their technical backbones and the organizations that built them evolved as well. A codebase that enables the business and a high-performing software delivery organization are not a given. They are rather achieved through careful management and navigation through various, potentially conflicting, objectives. In this article, we give an overview of the challenges of strategic software management and how it can make the difference between stagnation or growth of a business.
Why software development is expensive
Sometimes we wonder why software is so complicated. Why does it take dozens of software developers to build and maintain a webshop? Why do large ERP projects fail? Why can’t we reuse standard software? Why does one company need 800 developers while their peers achieve the same value creation with 200 developers?
Unlike physical systems where components and their interactions are visible, much of what happens in software is hidden from view. This invisibility means that understanding requires building a mental model of the system, which can be difficult and unintuitive.
Software systems have components that interact in non-linear and sometimes unpredictable ways. This complexity can make it difficult for humans to anticipate the behavior of the system or to troubleshoot issues when they arise.
Even simple software systems can contain thousands of lines of code. The sheer amount of detail that accumulates can overwhelm human cognitive capacities.
Software behavior can change in response to user input, system states, or external factors. This dynamic nature adds to the difficulty of comprehending the full scope of the software’s functionality.
Software modules depend on other modules or external libraries. These dependencies create a complex web that can be challenging to fully understand, especially when changes in one area can have ripple effects throughout the system.
Software is rarely static; it evolves through updates and patches. Keeping track of changes and understanding their implications for the overall system adds another layer of complexity.
The human brain has limited cognitive capacity to handle software development complexity at scale. As the codebase grows, multiple developers need to cooperate to deliver features in a timely manner. A single team of up to 15 software developers can work efficiently on a codebase because each team member can acquire and maintain an overview of the entire codebase he and his teammates are working with. Beyond 15, that holistic overview is no longer maintainable, requiring multiple teams to work on isolated code areas and define interfaces for collaboration. At this state, no single person has a complete understanding of the full code base. This problem can be compared to a large building where each level is designed by another architect and none of the architects can read or fully understand the plans of the other architects.
Over time, the understanding further decreases as the first developer generation leaves the project and new developer generations are onboarded. While senior developers with historic context can maintain the most complex systems with moderate costs, junior or newly onboarded developers build new layers of complexity on top of existing modules, often lacking understanding of the underlying design principles. This accelerates the subtle degeneration of the codebase.
The lack of understanding causes more unforeseen dynamics, increasing the time spent on tasks not directly related to new feature development, e.g, bug fixing, technical debt clean up and refactoring. This increases development time and the cost per feature. It becomes evident when the software delivery organization is perceived as slow and the sentiment towards the tech organization turns negative as deadlines are not met. Attempts to improve the situation by staffing additional people often yield exactly the opposite.
As a result, the software can degenerate, feature development slows down, and, since external software libraries are not updated timely, security issues risk the business. Massive modernization efforts are required to keep the software operational. Eventually, software reaches an end of life state when it no longer can support the business. In this state, feature development slows down to a point that once the feature is released, its relevancy is not longer guaranteed. End of life software systems require a full rewrite. While a rewrite is a viable method for modernization for smaller codebases, it can require massive investments for larger codebases, introduce completion risks, and limit business growth and stability during the process.
Signs of age in software
The age of a codebase and its ability to support the business can be measured quantitatively and qualitatively. Measurements and KPIs are a great tool to assess the current status quo. However, numbers require careful interpretation and a holistic understanding of the situation before they can be utilized as guidance for decision making. Metrics like feature lead time, number of bugs and security issues, developer time spent, ENPS, DORA and developer attrition rate are easy to measure and already available in most organizations.
Feature lead time is defined as the delta between feature development start and its production deployment. Independent to feature complexity, if feature lead time increases the code base might be showing signs of age, as refactoring and technical clean-up is required before the actual functionality can be developed. While feature complexity is difficult to measure, consistently increasing lead times for most features can be an indication that software complexity and technical debt are reaching a critical level.
An increase of critical bugs and security issues over a defined period could be an indication that teams struggle to find timely fixes.
A high-level analysis of developer time spent — in particular, time spent on new features vs technical debt — can be conducted quantitatively and qualitatively. If developers spent more than 30% of their time on technical debt, the software shows signs of age and modernization initiatives might be needed.
Negative impact on team culture can be measured through a decrease in software delivery performance, e.g., DORA, employee satisfaction surveys such as employee NPS (ENPS), and attrition rate.
When innovation capability is important
Innovation capability is the ability to formulate and verify business hypotheses. A high innovation capability means that the organization is capable of formulating business hypotheses in high volume and validating them in high frequency. Software is a great tool to validate business hypotheses. Lightweight feature development allows companies to expose the functionality to customers early. Measuring the early adoption of features could give an indication that the hypothesis is valid, providing the necessary confidence to invest further in thorough development of the feature. The faster this cycle of build, measure, learn can be accomplished, the higher the innovation capability.
Innovation capability may vary depending on the growth journey of the business. The need for innovation capability increases when the scalability of a business value proposition becomes uncertain. For example, for start-ups, finding product market fit is essential. Being able to quickly validate hypotheses optimizes the use of resources and increases the chance of success. Similarly, for established companies in a competitive markets, innovation capability is essential to increase customer value and gain market share. On the other hand, for companies with an established business model that can be scaled globally, innovation capability might becausecome temporarily less important. Other capabilities such as stability and reliability become more relevant. From a software management point of view, this could be the time to build the foundation for the next innovation phase — even though need for innovation might decrease temporarily, it will become critical again once the market is saturated or competition increases.
High effort for new features should be a warning sign that technical leaders need to challenge the intended return on invest (ROI). Strategic modernization roadmaps are a great way to create transparency on needed transformations of the current software stack, create alignment across teams, and help to support priority decisions.
The Art of Software Management
Software management is the balancing act of steering a software development organisation towards a high output of business value and setting the foundation for continuous impactful delivery in the future. It is an art and a science at the same time. Software complexity itself and close entanglement with organisational structures render quantitative assessment of the current status quo difficult and future requirements difficult to anticipate.
While data, KPIs or qualitative assessments can provide a glimpse the current status quo of organization and technical infrastructure, it must be acknowledged that in practice data can never be complete and never 100% representative of the actual dynamics. Therefore, decisions need to be made based on experience, expertise, and intuition. Tech leaders need to develop leadership intuition or a sense to what works to continuously find a good balance between pragmatism, i.e., holding onto aging systems, modernization to enable future business and building culture capital.
Defining, implementing, timing and sizing appropriate guiding measures is inherently difficult as itrequires a forward looking perspective which is often difficult to maintain beyond a 6–12 month time horizon due to market dynamics. Changes in the market, M&A activities, or variations in company strategy can invalidate modernization hypotheses and impact projected ROI. Therefore,long running modernization initiatives beyond 24 months are risky, with a high chance that they will take longer than expected and cause additional cost or waste, as the originally intended goals are no longer relevant.
Incremental modernization approaches with clearly defined value propositions can help to increase chances for successful modernizations. Once a decision is made start a modernization initiative, tech leaders can increase chances of successful completion by rigorously allocating resources and ramping up team capacities quickly.
Although software environments are intricate and specific to the characteristics of the business, tech leaders frequently confront four typical scenarios: monolithic architectures, legacy technology stacks, lack of collaboration between tech and business and inorganic growth through M&A.
Monoliths
Monolithic architectures are often the fastest way to build software applications from scratch. Monoliths are simple to develop and operate and allow small teams of developers to work efficiently. However, as the size of the codebase increases, monoliths almost always become a bottleneck. This is due to limitations to scale, both from a technical and an organizational standpoint. Additionally, monoliths are difficult to integrate with other software systems, and incremental modernization often requires costly refactoring.
Most software delivery organizations face the challenge of deciding if, how and when to replace a monolithic architecture at least once in their evolution. Although technical best practices exist for transitioning from a monolithic to a decentralized system, less guidance is available regarding the timing and scope of executing such a transformation. To make these decisions, tech leaders need to consider feature pressure, need for innovation, and cultural needs of the development organization in alignment with short and long term business strategy. Too often, feature pressure is given highest priority as tech leaders lack the strategic vision and tactical plan to communicate the impact of modernization and cultural aspects on business value to the rest of the organization.
Replacement of a monolithic architecture is not always necessary. If the monolith serves the business well — meaning it scales with increasing numbers of users, operates robustly, and only incremental feature changes are expected in the foreseeable future — a modernization initiative to break up the monolith towards to decentralized architecture might be too early and risky. In these situations, it can be beneficial to delay modernization. If applicable, the tech organization can start to implement new and isolated features on a new and separate micro-service based technology stack. This gives the organization the chance to get acquainted with the new technologies while keeping the risks and opportunity costs low. Careful management is required to constrain development to features where additional costs related to the new technology is close to zero.
Legacy Technology
Technology innovation produces new methods of building software. New programming languages, software frameworks, and AI-assisted approaches emerge in fast innovation cycles and are adopted rapidly by the community. New technologies have the potential to make software development faster, more robust, more secure, and more enjoyable. However, unless technology reached an end of life state, migration to a new technology stack is costly and benefits are rarely measurable.
The developer community does not embrace all technologies equally, and as certain technologies lose popularity over time, the pool of skilled professionals proficient in those technologies may shrink. This can create challenges for organizations when it comes to hiring and retaining talent and therefore can complicate modernization scenarios.
Software developers have to constantly update their skillset to stay relevant in their career. Therefore, they seek opportunities to learn new technologies and adopt new approaches. Hence, it is less attractive for developers to work with the same potentially outdated technology over along period of time. A legacy technology stack can have an impact on employee retention,which can be critical as hiring for legacy technology is difficult.
Oversized Organizations
When the degeneration of codebases becomes visible to the rest of the origanization, it is perceived through slow down of feature deliveries, stability or security issues. In this situation tech leaders feel an urgency to address the issues and their response is often to increase the capacity of the organization by hiring additional staff.
While this can be a viable approach, it can also accelerate the degeneration of the codebases as described above. The figure above shows the relationship of FTEs working in the tech organization and revenue or in other words the number of people required to create value.
FTE counts of companies in the same market and industry can differ wildly. In relation to revenue some organizations seem to be needing more than three times the number of technical staff to develop and maintain their systems than comparable peers in the same industry. The reason is complexity of codebase, organisational structures and company culture.
Tech leaders need to consider and balance all of the three dimensions to steer the organization to optimal size. There is a tight relationship between the structure of software and the structure of the organization (team setup) that builds and maintains it. Software modules often are developed by teams and team responsibility creates modules and interfaces. To break these structures, one must first decouple the software first and then rebuild the teams. In other words build teams for the work at hand not the other way around.
Cultural aspects
When writing code, developers make hundreds of decisions every day. These decisions can create tremendous impact further down the line. They can make the difference on whether a planned add-on is straight forward to implement or requires extensive restructuring up front. A good developer is not only proficient with the use of technology but also a strong collaborator that actively seeks to understand the system as whole and enables their peers to do the same. A collaborative culture is absolutely mandatory to build high quality software.
Due to limited measurability, the cultural implications of a legacy architecture, outdated technology, and organizational structures are frequently overlooked. Perception of limited personal growth, no sense of accomplishment, slow decision making, e.g., due to high level inter-team dependencies, are demotivating factors for team members and are typical for aging software codebases. These factors can lead to an increase attrition rates, which further exacerbates the problem.
Investment into modern technology can help building cultural capital, which is the base for high performing teams. The key challenge here is to enable teams to chose fitting technologies while providing guidelines to keep the codebase as homogeneous as possible.
Change of seniority and tenure of developers over time also plays a critical role in team dynamics. Decreasing seniority through onboarding of a new developer generations or shiftingresponsibilities through outsourcing initiatives can negatively impact the level of ownership and understanding of the codebase, which increases the need for modernization.
Tech leaders need to navigate these influencing factors and include orientation in the strategic context for software development teams. Its is critical to identify the signs of an aging software stack. KPIs such as DORA, time spent on technical debt, or clean code are a good start, but a high level proximity is needed to sense and calibrate the qualitative indicators in both technical and cultural domains. A comprehensive and up to date strategic context and tight collaboration between technical, marketing, sales and legal teams is essential.
Leaders need to nurture this collaboration by providing appropriate organizational structures and incentive mechanisms that prioritize collaboration over individual performance. Seniority is key when handling aging software stacks. Attractive technical career paths, competitive salaries, and investment into personal growth help to retain key talent. Technical experts can scale their impact beyond individual contribution without being required to adopting management roles as long as they are strong collaborators. Managers need to sense this impact and award it properly through career progression and competitive salary upgrades.
Inorganic Growth or 1+1 ≠ 1
If companies grow inorganically, e.g., through an M&A process, the level of integration for multiple organizations, products and technologies needs to be decided. From a technical perspective the high-level merge scenarios are simple: both are kept and operated in isolation, one is chosen to continue and the other is decommissioned, a new platform is built either by choosing the best of both worlds or complete new development.
Investment risk and synergy potential are often anti proportional and determine feasibility of the integration approach. A technology landscape that grew inorganically over many years with a low level of integration is unlikely to leverage synergies. A merge of more than two platforms into one is seldom economically feasible. In these scenarios a complete re-write of the codebase is often the only viable option given a suitable ROI case can be formulated.
Despite the obvious cultural aspects of merging organizations, the technical impact on the organizations is important to consider. As an example, consider two companies, operating in the same market with a similar product offering. While providing the same functionality, the technical implementation of the product might differ substantially. As team are usually structured around functionality or software modules this could mean that you have overlapping functionality between teams which in turn requires substantial restructuring of the organization as result.
Integration projects are subject to completion risks often leaving the technology landscape even more fragmented. If integration projects are not finished timely, re-focusing may bring integration approaches to a halt leaving, the two original systems plus an unfinished third system (1+1=3) behind.
A crucial success factor for integration projects is their timely completion. Leaders must limit scope, allocate enough resources, and implement a strong governance to increase chances for success. Similarly, to re-platforming projects, integration projects should deliver their results with in 24 months. It that is not feasible a lighter scope or reconsideration of the integration approach altogether could be the better option.
Conclusion
Software is inherently expensive to develop and maintain. If not managed well, software codebases can degenerate and limit the ability of the business to grow and operate robustly.
Strategic software management can save millions and establish a solid base for a company’s competitive advantage. It balances the development of business enabling features and modernization efforts; therefore, it keeps the codebase continuously healthy and the tech organization performing at high throughput.
Software management is an art and a science. While you need to have essential metrics in place, status quo assessments are inherently incomplete and long term planning is not feasible in most industries, tech leaders must build collaboration platforms, enable fast learning, and provide strategic guidance to keep codebases healthy in the long run.
References
- Measuring the cognitive load of software developers: An extended Systematic Mapping Study, https://www.sciencedirect.com/science/article/abs/pii/S095058492100046X
- Neocortex size as a constraint on group size in primates, https://www.sciencedirect.com/science/article/abs/pii/004724849290081J?via%3Dihub
- Conveys Law, https://en.wikipedia.org/wiki/Conway%27s_law ↩︎
