Allow me to start with a fable.
It might be a bit of a reach, but think of the story of the Tower of Babel, an origin myth from the Book of Genesis. It could prove to be an interesting anchor-tale when we discuss complexity. The people set themselves an ambitious goal of building a tower to heaven, and perhaps God thought they might succeed, which is why I think their plan is worth analyzing. God destroyed the project by confusing them with different languages — messing up their culture.
Now why would a modern IT leader look for inspiration in a Bible story from thousands of years ago? My guess is that if it has survived for so long, there might elements worth looking at. And their ambitious project surely resembles some of the IT projects I witness.
The specific points that I refer to as Complexity, are part of the “C” in the Nucleon formula. They differ from the areas discussed in the blog on Organization (and from the “O” in the Nucleon formula) in a number of ways, including the fact that they are much harder and take significant time to change.
I’ve found four relevant cornerstones to the Babel story that correspond well with my own findings in today’s companies’ complex systems development:
- Language. Whether you call it language or culture, it is the obvious core element of the story. The whole world “had one language and a common speech” is how the story begins, and it was this element that God destroyed, confusing them with many languages. So much for the tower: they had to cancel the project and comply with God’s original intent of scattering them all over the world.
- Architecture. The second core element mentioned in scripture was a blueprint, which is similar to enterprise architecture. “Come, let us build ourselves a city, with a tower that reaches to the heavens” refers to a master plan that would have helped them to organize all their work wisely.
- Methodology. The third element was the reinvention of their methods for construction materials. ”They said to each other, ‘Come, let’s make bricks and bake them thoroughly.’ They used brick instead of stone, and bitumen for mortar.” In biblical times, people built larger constructs out of normal stone and mortar. Not having enough stone in that specific geography forced them to change their way of producing materials (methodology) to adapt to the new circumstances. They burned hard bricks and used tar as mortar in a whole new way (waterfall to agile?)
- Legacy. The fourth element is implicit in the story and requires a closer look. The legacy of the people who gathered in Babylon was a firm commandment from God to spread out all over the earth. By ignoring God’s commandment in favor of their own ambition “so that we may make a name for ourselves and not be scattered over the face of the whole earth,” they released an enormous amount of energy (to no good end, but that is a different matter). They no longer had an anchor of history to drag their performance.
IT is unique in that it has so many different layers of complexity. These areas include security, cybercrime, big data strategies, fraud detection, hardware and software contract negotiations, operational stability, backup/restore strategies, CMMI work in general, education and training needs in the organization, external and internal branding/marketing and technical communication/network strategies.
All are vital to the survival of your business, and there’s no doubt that ignoring them can result in your organization landing on the front page because of a security breach or an operational glitch. Despite their importance, they are not severely impacting your performance in the area of application development, and that’s the area that time after time has proven to be the most important to efficiently and productively being a differentiator for your business.
Top management can add value by providing the money, mental support and human capacity needed, but should not be distracted from their focus on improving the application development area.
There are four IT-related complexity areas that I believe need top management’s specific attention in every organization:
Culture, while often seemingly intangible, is an enormously important area for anyone striving to optimize development team performance. There are six basic reasons why people work, and they aren’t created equal. Play, purpose, and potential strengthen adaptive performance while emotional pressure, economic pressure and inertia weaken it.
Having a solid and positive culture means everything to any working team, as well as to an IT development department; it makes an enormous difference.
Sometimes big companies lose their appreciation or sense of urgency about maintaining a positive culture, but the simple truth is that if you have an unhealthy culture you will fail. You need the best IT people you can find, but those good people can’t survive or thrive in a bad culture.
In Nucleon, I look at six empirically proven cultural performance indicators:
- Play – the feeling of having fun doing your job
- Purpose – when your work contributes towards something meaningful to you
- Potential – when the job is an active asset towards achieving your goals
- Emotional Pressure – when emotions are forcing you to work
- Economic Pressure – when you work solely for financial reasons
- Inertia – when there is no good reason why you work at all
These six drivers not only describe core motivational factors, but also the underlying performance cycle. Altogether these cultural assets have been shown to account for 17% of performance.
In our research we have found that there are three main performance effects of different methodological approaches; agility, practical experience, and team consistency. Not being agile and not having the practical experience within the team can reduce your team performance by upwards of 51%.
Methodology is a rigid area of competence, and that’s probably because IT development is so difficult. It is tough to work with people who constantly change their minds about what they want, and it is equally difficult to design and develop a perfect application that is easy to maintain in the operational environment.
In the end, the IT organization is always the target of critique when the systems don’t reflect the solution that business had in mind. As a result, IT people are very conservative as to what the best development approach may be.
In general, the choice of methodology should be the same throughout your organization, but the most important thing is to have the same knowledge and choice of methodology within an individual team — teams must be harmonious. That said, today’s talent has been brought up with agile development methodologies, and even if it is not optimal for productivity purposes, you want to be flexible enough to be able to move your developers from one project to another. You can accomplish this more easily if your entire organization is working with the same modern methodology.
The Nucleon formula helps you measure the implementation of your methodology and what it’s doing for your performance. It does this by assessing every individual’s maturity in the new methods and then collectively looking at the compatibility of the complete team.
Legacy can significantly hamper development performance. In certain IT environments we have seen a performance drag of up to 18%. We measure the legacy score as the share of systems the individual is working with and interfacing to that are not state-of-the-art systems with strategic value for the IT infrastructure and future development of the business.
Generally speaking, existing systems are not altogether terrible. Businesses live and thrive using these systems, but they may be taking up far more resources than you realize.
Companies might have to live with bad decisions for many years and end up with much higher maintenance costs than originally anticipated. Some organizations allocate more than 80% of their staff to maintaining old systems and the implementation of new legislative requirements within those same systems.
As a manager you need to know what resources are allocated to the maintenance of obsolete systems versus your core current systems. Knowing this gives you an overview of what resources are available for the implementation of new systems that are more efficient.
Another major aspect of old legacy systems (other than the maintenance burden) is that they are difficult and expensive to integrate into new (build or buy) systems. If your business functionality or data are not easy to access it will drag performance out of an otherwise straightforward integration project.
Nucleon measures the legacy impact by asking individuals to evaluate how large a share of their current environment (interfaces, platforms, systems etc.) is coherent with the above definition. This is due not only to the fact that the legacy impact can be very different in different parts of the organization, but also because the factual and perceived legacy burden might be different. An individual might perceive a larger burden than there actually is, but their perspective is still relevant, as its the way they will experience it.
Most often the wisdom of the crowd will be a better estimate than a single individual from the Enterprise Architecture department deciding on a legacy level, and therefore it is important to involve the entire development organization and not just someone with more stars on his shoulder.
This legacy number tells you exactly how much development capacity you really have available to serve your strategic new development; it’s likely to be less than you think.
The architecture score of a team is a product of the quality of their APIs, the degree to which the architecture allows for reuse, and how well the teams are future-proofing their applications in development. The sample space of the architecture score falls between 0.74 and 1.
Architecture is the art and science of giving shape and form to buildings, spaces or physical structures. In IT, the architecture department supervises the overall picture, or the master plan. It governs the technology stacks and is responsible for durability, maintainability and interoperability. It should be an authoritative guide to development teams and business people.
Architecture is the most basic and important function of all the support staff areas in IT: if the architecture department doesn’t work well, all projects suffer.
Companies that have service-oriented architectures are much better positioned than those that have not prioritized this function. An obvious example of architecture’s benefits is seen in how much you can buy from cloud services; what was impossible to envision only five years ago is now easy to see as a practical and viable solution.
The chief ambition of the architecture function is to leave the IT department better than they found it. Architecture should be easy for developers to navigate, and so too should choosing approved technology stacks for projects. Requirements for interfaces should be simple to understand and the environment should encourage reuse of existing stubs and code. It should also discourage development of proprietary interfaces. A strong enterprise architecture will help you avoid redundancy and improve quality, availability and sharing of data. It will save significant expense.
Architecture can be measured in many ways. While many process-oriented measures of architecture seem to be great measures of effectivity, the view of architecture is often isolated to structure and management, and doesn’t take into account some of the more operational benefits.
Our measurement of architecture is based on the degree to which reuse is enabled, used and secured. This is done by looking at the level of state-of-the art APIs, the ability to use code from other projects or repositories, and enabling the future use of the current project.
This performance view does not isolate architecture to a measure of documentation or process rigidity, but instead looks at how well the architecture is enabling fast production and ensuring that all development carried out will have an accelerating effect on future work.
Complexity is the enemy of performance. If you use the Nucleon formula and find that you’ve scored well, you are well positioned to enable your high-performance teams to function optimally.
I encourage you to read chapter 5 of my book, Nucleon, for much more detail and insight on IT complexity.