Engineering org charts have familiar roles: software engineers, platform engineers, SREs, security engineers, staff engineers, managers, and architects.
These roles are optimized around building, operating, and scaling software.
Yet every mature engineering organization develops another problem: memory.
Almost nobody owns it.
A five-person startup can rely on conversation.
At twenty engineers, people start asking whether anyone remembers why something was built.
At fifty, diagrams fall behind reality.
At one hundred, institutional knowledge walks out the door every time someone changes jobs.
At several hundred, systems become owned by history rather than understanding.
Documentation tells people what exists.
Organizational memory explains why it exists, what assumptions justified it, what incidents shaped it, what alternatives were rejected, and when it should be reconsidered.
Those are different responsibilities.
An Organizational Memory Engineer would improve the organization's ability to retain and reuse engineering judgment.
Responsibilities might include:
None of this directly produces software. All of it increases the effectiveness of future software development.
Preserved reasoning used to look like overhead. In an AI-assisted organization, it becomes infrastructure.
Every preserved decision becomes reusable by humans and machines.
The next infrastructure layer may not be compute, storage, or networking. It may be organizational understanding itself.