Modernization Has a Memory Problem

I have spent a lot of my career around software teams.

Startups. Enterprise software. Delivery teams. Requirements. Architecture. Roadmaps. Jira boards that somehow contain 4,000 tickets and still leave everyone asking what are we actually building?

Over the years, I have seen a lot of modernization programs struggle.

And for a long time, I viewed many of those struggles through the software side of the equation.

Those are still important questions.

But lately I have been thinking much more about the person who has the job before most of that happens.

The person who gets handed a modernization initiative and is essentially told:

Figure this out.

Maybe they are a Program Manager.

Maybe a Business Analyst.

Maybe a Product Owner, Transformation Lead, Enterprise Architect or Director of something with the word "Modernization" in the title.

Whatever the title is, the job is enormous.

They need to understand why the initiative exists.

And, naturally, somewhere in the middle of all this somebody will say:

"While we're already doing this, could we also replace the CRM?"

Squirrel. 

"I know what you're thinking, why did I forward that invite..." 

Where does all of this actually live?

That's the question I have not been able to stop thinking about.

In most organizations, the answer is not one place.

It is everywhere.

Some of it is in PowerPoint.

Some of it is in Excel.

There is a SharePoint folder.

There are Teams conversations.

There are meeting recordings.

Somebody has notes.

Somebody else has a spreadsheet.

There are emails.

There are probably seventeen copies of the same document with names like:

Requirements_Final_v4

Requirements_Final_v4_UPDATED

and, eventually,

Requirements_Final_v4_UPDATED_REALFINAL

You laugh because you have seen it.

But there is a serious problem underneath the joke.

The information exists.

The truth does not.

There is rarely one place where someone can understand the complete story of the initiative.

That context gets fragmented across tools that were never really designed to preserve the story of a modernization initiative.

Now imagine the person leading the program leaves

This may be the part that bothers me the most.

Imagine you walk into work tomorrow and are told you are taking over a major modernization program.

The person who led it for the last eighteen months is gone.

Congratulations.

Here is a SharePoint folder.

Here is a PowerPoint deck from last quarter.

Here is an Excel workbook nobody seems willing to claim ownership of.

Here is the Jira board.

Here is the Teams channel.

And somebody thinks Steve may have kept notes from the stakeholder workshops.

Steve is on PTO.

Good luck.

Now you have to reconstruct eighteen months of organizational thinking.

If you cannot answer those questions, one of two things usually happens.

You spend an enormous amount of time performing what I can only describe as institutional archaeology.

Or you start making new decisions.

And that is how organizations unknowingly revisit questions they already answered, reverse decisions without understanding why they were made and slowly lose the original intent of the initiative.

Requirements are not the beginning of the work

This has also changed the way I think about requirements.

We tend to talk about "requirements gathering" like the primary task is producing a really good document.

It isn't.

A good requirement is the output of investigation.

Someone had to understand the business problem.

Someone had to talk to users.

Someone had to understand the current process.

Someone had to evaluate the existing systems.

Someone had to reconcile conflicting opinions.

Someone had to understand constraints.

Someone had to connect the requirement back to an outcome the business actually cares about.

The requirement is simply one artifact produced by all of that thinking.

Which is why I am increasingly skeptical of the idea that AI-generated requirements, by themselves, solve the requirements problem.

AI can generate a requirement very quickly.

It can summarize a document very quickly too.

That is useful.

But speed is not the same thing as understanding.

If AI is given one meeting transcript, it can tell you what happened in that meeting.

If it has access to the meeting, the existing systems, previous decisions, stakeholder feedback, current requirements, business goals and supporting evidence, it can start answering much more interesting questions.

That’s where AI starts getting interesting to me.

Not because it writes faster.

Because it can see across context that humans have historically had to hold together manually.

The missing system of record

We have built great systems for execution.

Jira helps teams manage work.

Azure DevOps helps engineering teams plan and deliver software.

ServiceNow manages workflows.

SharePoint stores documents.

Slack and Teams capture conversations.

Confluence stores knowledge.

They all solve real problems.

But I keep coming back to a different question:

Where does the modernization initiative itself live?

Not the project plan.

Not the backlog.

Not the folder containing the artifacts.

The actual initiative.

Its purpose.

Its evidence.

Its stakeholders.

Its systems.

Its decisions.

Its dependencies.

Its unresolved questions.

Its requirements.

Its history.

The reasoning that explains how the organization got from:

"We have a problem"

to:

"This is what we have decided to do about it."

I believe modernization needs its own system of record.

A place where that context remains connected instead of being scattered across every tool the organization happens to use.

Because accountability requires more than knowing what was decided.

It requires remembering why.

And that is the problem we are building STACKRYN to solve

And if I’m being fair, realizing this has changed the way I talk about our own product.

STACKRYN is not valuable because it can use AI to produce something faster.

It can.

But that is not the point.

The point is to give the person responsible for a modernization initiative one governed place to understand and manage the whole story.

The business intent.

The evidence.

The current systems.

The stakeholders.

The decisions.

The dependencies.

The requirements.

The questions that still need answers.

The history of how the initiative changed over time.

Then AI can sit across that context and help the team see things they may have missed.

That is a very different job than generating a half-baked requirements document after a few clicks.

It is about traceability.

Continuity.

Accountability.

Institutional memory.

And ultimately making better technology decisions before millions of dollars and hundreds of people's time get committed to executing them.

I started my career thinking a lot about how we build software better.

I still care deeply about that.

But after watching enough great software teams successfully build exactly what they were asked to build, only to discover that somewhere upstream the organization had not fully decided what it actually needed, I think there is another problem worth solving.

Modernization does not just have an execution problem.

It has a memory problem.

And maybe before we ask teams to move faster, we should make sure they can remember how they got there.