Think about the prized "high agency worker." What makes them desirable is the willingness and ability to make well informed, unilateral decisions on matters that are likely not yet organizationally codified, or codified in a way that is "wrong" for the task at hand.
Also, the reason terraform works is because it is _operational_. As in, it's actual code that runs. If it was mere documentation, it would drift like nobody's business. In order to make "organizational code" operational, you would need enforcement (a compliance team?) manually keeping the documentation in sync with reality in all of the meat and thought spaces where real work happens.
The only place where this can plausibly be automated is in digital spaces. In fact, I'm surprised the article doesn't go there: "organizational code" starts feeling way more plausible as definition for AI agents than for real people, specifically because agents are operationalized in digital spaces, where enforcement can be automated.
The problem - and I do mean the problem, the only problem - is the threat this poses to power dynamics in the organization.
Compliance people do not benefit from their outputs being readily searchable and indexed like this, because it means there’s less need for them. Executives and leaders do not benefit from this, because they’re increasingly hired specifically because of their knowledge of various compliance frameworks. The people whose power derives from this knowledge and expertise are overwhelmingly the people in charge of the company and its operations, and they benefit more from blocking it outright than implementing it.
Don’t get me wrong, I love this idea. I love transparency in organizations, because it makes it infinitely easier to identify and remediate problems beyond silo walls. It’s peak cooperation, and I am all for it.
I also do not see it happening at scale while competition is considered the default operating mode of society at large. That said, I would love to work for an organization placing importance on this degree of internal cooperation. I suspect I’d thrive there.
And on the creation side, what prevents political fights over what goes into the "code policy" of exactly the same sort that lead to compromises or oddities in paper policies?
It's exactly the same paradigm the EU and countries around the world are avoiding - denying due process in things like freedom of press and expression, because they feel it allows them flexibility in suppressing and "managing" speech, people, and groups they deem problematic.
Having an explicit rule of law constrains the exercise of power. Those looking to wield power will never like that.
You don’t even need competition between people and orgs, just between solutions that work more-or-less equally but come with different second-order tradeoffs. Consider two approaches that solve a company’s problem equally but create different amounts of work for different people in the organization. Which solution to choose? Who gets to decide, based on what criteria? As soon as even a little scale creeps in this is inescapable.
I've been looking for such a org my entire career but recently resigned myself[1] to the fact it'll probably not happen unless I come into a situation when I can create it myself.
---
Or ASIN B01K2J06SY
Power dynamics have been extensively investigated by the "Johnstone school" of improv, because humans are (mostly preconsciously i.e. usually are not but can become conscious about it) interested in power dynamics -- especially in situations where power balance is switching -- so this is the key if you want improvise acts that feel realistic and capture the audience attention.
To really understand it, I would recommend taking some improv classes that are based on Johnstone's teachings. But the book will give you the idea.
And expertise, to be fair. Documentation as code is what we in the software industry call testing/type systems. The vast majority of developers cannot even write a good test for their code (if they are willing to even try at all), let alone their eyes completely glazing over if you ask them to write, like, an Rocq proof. And that's people who live and die by code, not business people who are layers removed from the activity.
In the early years, it was extremely, extremely open and comprehensive. I've definitely looked through it when I wasn't sure how to handle something at work.
Infrastructure as code is prescriptive. The code is the source of truth, and the world gets crested from it.
Company as code is descriptive. It is constantly catching up to meat-space, rather than creating it. Changes are gradual instead of instant roll-outs. Patterns change over time and only get documented later.
Making the company code prescriptive would require an insane amount of discipline that might be more stifling and restrictive than it is freeing.
- "Rule followers" think an org will be better off if everyone agreed on a set of rules to follow. At the boundaries, they will think about establishing new rules to clarify and codify new things. Charitably, I'd add that they might remove rules that are obsolete, but we all know this is not sufficiently true in practice: governments, for example, are much more likely to add new rules than to remove old ones.
- "Rule breakers" think that most rules are suggestions. At the boundaries, they will see rules other people are needlessly bound by, and translate those into strategic openings for whatever game they're playing. For better and for worse, start-up ecosystems are full of people like this.
Rule followers want to be told what's allowed, while rule breakers try to figure out what _should_ be allowed from first principles. At the extreme, they tug the world towards authoritarianism or towards anarchy.
This is obviously a spectrum, so everyone has both of these archetypes in them, albeit in different proportions (e.g. most people pay taxes, but almost no one drives the speed limit).
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
While the choice of implementation and performance were abysmal (Notes was a great/the only choice when the decision was made but 25 years later not so much), the actual idea was amazing and it worked extremely well.
What do you think are the reasons it worked so well? Any anecdotes of why it was so effective?
Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.
I see only 1.
Admin, access <> ownership.
If someone needs access to a secret, you would implement it in this DSL and commit that to the system. A side effect would run on that which would grant access to that secret. When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
> When you want to revoke access, you commit a change removing that permission and the side effect runs to revoke it.
For this to work, you’d need to also rotate the secret, or ideally issue one for each person (so that others don’t have to update their configs).
...but sometimes you can’t reliably automatically rotate the secret, because they could have used it for something in production.
Right down to the low code interface for changes.
In some big companies, for expenses or performance reviews you have a terrible stack of relationship info and logic involved.
We could even say somehow that the first big entreprise software were creating with that kind of purpose for the modern IT area.
The worst limitation to all of this is users being lazy to input all the info that might be required, or updating it. For example, how many of you never filled their "address" in their record in the big company internal directory portal because it looks useless and is not mandatory?