Notes on Treating a Company Like Code

The Question

I do not think “company as code” is a finished model. At least not for me. Right now it is more useful as a lens.

When a team writes software, the surrounding habits are familiar: changes are proposed, reviewed, versioned, reverted, discussed, and tested. The artifacts are imperfect, but they leave a trail. Someone else can arrive later and ask: what changed, why did it change, and what else moved with it?

Most organizational work does not feel like that. Decisions drift through chats, calls, documents, dashboards, and memory. A lot of the context is real, but it is not easy to replay.

That gap is what interests me.

The Useful Part

The phrase becomes useful when it stops being a slogan and becomes a design prompt:

• What should be versioned?
• What should be reviewed before it changes?
• What context should stay attached to the change?
• What should be easy to compare later?
• What should remain human judgment, not automation?

Those questions are more practical than trying to force every activity into Git. Some things should be code. Some things should be structured notes. Some things should stay conversation, with only the decision recorded afterward.

A Working Shape

The pattern I keep noticing is not “automate everything.” It is more like this:

1. Describe the intended change before acting.
2. Keep the constraints near the work.
3. Make the review point explicit.
4. Record enough context for a future reader.
5. Accept that not every useful record needs to be perfect.

That shape can apply to infrastructure, documentation, access changes, internal policies, and small operational decisions. The implementation varies. The habit is the interesting part.

The Edge Cases

There are places where this lens gets awkward fast.

Some decisions are too sensitive to publish widely. Some work needs speed more than ceremony. Some records create noise instead of clarity. Some automation makes a system look controlled while hiding that nobody understands it anymore.

Those failures matter. A method that cannot admit them becomes theater.

So the test I like is simple: does the record help a future practitioner understand the change without needing to trust the original author completely?

If yes, it probably belongs close to the work.

Where I Am Leaving This

I am treating “company as code” as an open question, not a doctrine. The useful part is not the phrase itself. The useful part is the discipline of making important work easier to inspect, compare, and revise.

That is enough of a compass for now.