Internal tools as a form of power
What a team uses every day tells you more honestly about a company than its product does.
A company's product is its front facade. Polished, thought through, it tells the story the company wants told about itself. Internal tools live on the other side: admin panels, dashboards, access systems, the tooling for building and shipping. Nobody demos them at conferences or writes them up on the blog. And they usually show you more.
The tool reveals the structure
Want to understand how a company is built? The org chart will tell you little. Look at the internal tools. Who gets to press which button. What happens in one click, and what takes three approvals and a ticket. What gets written to a log, and what passes without a trace. A tool is a frozen decision about who is trusted here and which behaviour counts as normal. It is honest for a boring reason: nobody made it to impress anyone, so nobody bothered to smooth its edges.
Power built into the interface
Inside an internal tool, power stops being an abstraction. It is a field some people edit and others only see. A feature flag open to the growth team and closed to support. A log that records who changed a limit and says nothing about who looked at it.
A couple of years ago I ran our feature-flag platform, built on Unleash. In theory a flag is a temporary thing: turn on an experiment, collect metrics, turn it off. In practice we had a flag that stayed on for almost a year. It was created to roll one feature out to a narrow segment, the feature later went to everyone, and nobody remembered to remove the flag. It hung in production like an appendix, apparently doing nothing. Until one day a junior, working through someone else's code, flipped it back, and for a few hours part of our users lost a screen they had been using for a year. The postmortem was short. The junior was not at fault. The fault was a system where a live toggle looked exactly like a safe one, sat in the same list with it, and asked for neither a confirmation nor a line about why you were touching it at all.
Each of those decisions, not marking live flags, not asking for confirmation, not storing who created a flag and why, was made in passing, as a small technical detail. Added up, they were our real access policy.
The policy sat in Confluence, and the actual access rules lived in a list of flags that nobody treated as a document.
"But this is just bad tooling"
There is an easy objection here, and I make it to myself. Everything above sounds like ordinary engineering sloppiness. A flag went unmarked, a confirmation went unbuilt, so it is unfinished work. What does power or the constitution of an organisation have to do with it. Fix the backlog, add a permission model, and the pretty moralising falls off on its own.
Partly true. A lot of the ugliness in internal tools has a plain explanation: no time, never got to it. But the choice of what you get to and what you don't is itself telling. For half a year we polished a client app where every pixel went through review, and at the same time we tolerated an admin panel where a support operator changed the status of someone else's request without a single line in the history. There is a hierarchy behind it: whose mistakes the company treats as expensive, and whose as tolerable. Bad tooling asserts something too, only nobody says it out loud.
Here I stop being sure
I have built such tools and seen how quietly an admin panel's design sets the norms. Make a dangerous action require confirmation and people start doing it more carefully. Bury the export button in a submenu and people stop using it, even when they need it for real work. The interface teaches, and it does so silently.
And this is where my certainty runs out. The very power I am urging people to handle responsibly is also pleasant to hold. When you decide that data export now goes through an approval, you look like you are caring about security. And along the way you quietly arrange things so that a little less can be done without you (without your role, to be precise). In the moment I did not always tell the two apart. A couple of times I added a "confirm this dangerous action" where the honest reason was that I felt calmer if people asked me one more time first. It is convenient to call that care. It was not always care.
What an engineer should do
Take internal tools seriously, including politically. Ask whether the thing works. Then ask which behaviour it rewards and whom it gives power to. Design access and logs as statements about trust. Sometimes that means giving people more than you are comfortable with, and recording less about them than you technically could.
An internal tool is the place where an engineer stands closest to real power in a company. Usually he doesn't notice, because power here looks like an input form and a "write to log" checkbox. I am still not sure I handled it well. But I stopped pretending it wasn't there.