Stop disrupting your organizational memory

Organizations benefit from consistency. And yet, there is a cycle of disruption that many of us seem to be accustomed to because we see it happening over and over again, in many industries and in many countries, yet, we do not act upon it. This cycle seems to be almost culturally agnostic, at least when looking at the European playing field.

Let’s call this the Cycle of Organizational Memory Leakage.

The start of something new is always exciting…

When it comes to IT projects and building applications we, unfortunately, see it all too often. An organization defines an ambition and determines it to be special in a certain sense, which needs a customized supporting IT application/infrastructure.

Nothing wrong so far. When thought through and selected well, this is a valid approach.

Then comes the hard work, making this ambition a reality. Development teams are either hired or outsourced, designs are built and implemented, and the often years-long process of developing software starts. Implicit knowledge in the organization is gathered and turned into valuable organizational memory in the application to be and in the heads of those building it.

Then success comes! The first versions come out, and some tweaking is needed but, the application supports the business in growth and making a difference. Updates are made, additions requested, and finally, a stable version is available for the company to build its business upon.

With the building finished, the project comes to an end.

…but nobody likes the upkeep…

And maintenance is a very different animal. So the application is handed over to new custodians. Teams are scaled-down, and often pioneers of the application move on to new exciting challenges. 

Over time, however, it becomes apparent that the new setup is still expensive. There are quite a few internal developers still involved that could do other things too. The contract with the vendor might seem to have just a few too many hours, whereas this should be feasible with a lower support contract.

…and eyes are turned away from what once was new, to what will be new…

The balance shifts. Changes are made to reduce costs and in the end, only a shadow remains of those who were involved in the creation of the application that made all the difference. The custodian prepares the business cases and gets the approvals. And as these make sense, the downscaling happens incrementally over a few cycles. Often, it takes only months, not even a year, for the heroes of the project who made all the difference to be scattered to various organizations in the industry.

… until the cycle starts again, but with a hiccup.

This is often where one of two things always happens. (1) There is a new vision, a new ambition based on a changing market (approach) and this requires a whole new setup, or (2) things start to fall apart and need to be patched.

Sound familiar? So who do you call? 

The custodian of your software. The same person you have allowed to improve your position by removing ballast from the organization. Ballast with high costs and unclear benefits at that time. But this is the time that you realize that this ballast was also your organizational memory. Because ingrained in the people was the knowledge of how the business worked, how it was translated to this new supporting application and this is exactly what you need for the next cycle.

This cycle needs to end.

With the current state of the market, this is an approach and a cycle that companies cannot permit any longer. Innovations and disruptions in the industry are following each other at a rapidly increasing pace, and the people you need to stay at the forefront of what is happening in the market are getting to be very scarce.

It strikes us as odd that most organizations try to deal with this trend by looking outward: scouring the market. Whereas your first action should be to take a good hard look at the people you have and the projects you are running. Who will support your business in the years to come? Who are the current heroes of success? Who represents the organizational memory that you will want to keep in the years to come? 

Consistently successful companies can retain and nurture their organizational memory and make a repeatable difference. Enabling them to not only combat the disruptions thrown their way but to ride the waves of change and grab hold of the opportunities that these present. The question we have to answer is, how are these companies nurturing their organizational memory and how can we learn from it?

Four key behaviors to learn from

From our experience, we can elicit four (4) key behaviors that successful companies employ.

1. Keeping software engineers enrolled in changing company projects.
   Your IT Landscape is your asset. And you want people to be well-versed. They don’t have to be able to do everything at once, but over time you do want them to know how the various parts intertwine. Software engineers need to be allowed to build up their knowledge of the landscape and apply this experience across projects to build organizational memory.
2. Hire a core of senior developers/architects directly within the company (not only outsourcing).
   You have to ensure that core knowledge is kept within the organization. Business domain knowledge and the engineering culture are your competitive differentiator and intellectual property.
3. Proactively keep the primary and secondary working conditions up to par with the market.
   According to several surveys, a software engineer’s happiness at work is heavily affected by the quality of the codebase they work with. This is a good example showing why organizations need to invest in the quality of their applications, as well as, their people. This increases business value, attracts top talent, and improves staff retention. 
4. Treating software engineering as a mature field, measuring for success.
   In our line of work, we boast that software engineering is a very dynamic industry. However, we tend to neglect the fact that the industry needs standards, consistent processes, and meaningful KPIs that one can measure and track progress and success based on those. By doing so, organizations will realize that their assets/systems are not merely cost drivers but enablers of their business.

But above all, being clear in your intent gets you halfway there…

If software engineering is key to your organization and is a differentiating factor you should be aware of the above. Don’t forget, it starts with intent. You do not need to make radical changes within the week. Making the intent clear on what you want to achieve with the above behaviors is the first step in getting iterative change. And the great thing is: we are used to this. Years of Scrum and Agile working have prepared us with a skill set that we can apply even at the fringes of software engineering.

So first up: who will be your organizational memory for the years to be?