Part III — Cultivating Organizational Flow · Chapter 46 · 7 min read · First Public Draft

Interfaces

Opening the Front Door

Making a capability reachable by someone who does not know anybody, which is most people.

Christoffer Råsten

Reduces frictionCreates valueHandoff loss

You Have to Know a Guy ended with Maja, who is excellent, and who is also the reason a capability that looked available was only ever available to people who knew her name.

This is the most concrete cultivation in the paper, and also the least glamorous. Most of it is documentation. Documentation never feels urgent, never gets celebrated, and never stops paying — which is a poor combination for getting it funded and a very good reason to do it anyway.

What changes

You start treating how do I use this as part of the capability rather than as documentation about the capability. It is a small shift in wording with a large consequence: an interface nobody can find stops being a communication problem and becomes an unfinished piece of work.

Watch a newcomer try

The fastest way to find every missing interface in an organization costs one afternoon. Give a new starter a real task that crosses a boundary, ask them not to message anyone directly, and watch where they get stuck.

Every place they have to go and ask a human is a missing interface. They are completely invisible to everyone else, because everyone else already knows, and knowledge of this kind is impossible to un-know once you have it. This is why the newcomer is the only reliable instrument available — and why their value as one expires in about six weeks.

It is also a genuinely enjoyable exercise, as long as nobody treats the results as a report card on the teams involved. Nobody built those gaps deliberately. They are just what happens when helpful people keep answering.

Name a front door, then let it be boring

One route in, per capability, that a stranger can find and that does not require knowing a person’s name. If the honest answer to how do I request this is “you ask Maja”, then Maja is the interface, and Maja will eventually take a holiday, get promoted, or leave.

The reason to make it boring is that interesting interfaces attract maintenance. What matters far more is that it is the same one next quarter.

Which gives the order to work in, and it is worth being blunt about it because organizations reliably start at the wrong end.

Automate it, if it needs no human judgement at all. Most of what sits in a queue is a decision somebody already made once, being made again by hand. If the answer is a rule, the rule can be code, and the request stops existing rather than getting faster.

Failing that, make it self-service. Something the asker can call, query or grant themselves inside agreed limits — with the meaning of the thing written down next to it, because access without meaning is how a third version of the truth gets built.

Failing that, run a proper queue, with a name on it. Queues are not a failure. A well-run queue with a visible owner and an honest response time is far better than an interface nobody can find, and some things genuinely need a person.

And only then, a person you have to know. Which is where most organizations actually are, and which is not a strategy so much as what is left when nobody worked up the list.

The reason to start at the top is that each step removes work permanently rather than making it more pleasant. A faster queue still consumes somebody’s week every week. An automated answer consumes an afternoon, once.

Then run the one-second test from An Interface Nobody Can Find across the front doors you already have, and mark each one honestly. If it lands in somebody’s list, it is a queue.

Expect that exercise to be mildly deflating. Most organizations discover they have rather more queues than they thought and rather less of what they had been calling self-service. That is a good afternoon’s work: nothing has got worse, and you now know which waiting is real.

Then the useful question for each queue is whether the judgement in it is genuine. Some of them exist because a decision really does need a person. Others exist because nobody ever wrote down what the answer is, and a queue formed over the gap — the same shape as the meeting in A Meeting Grew Here, one layer down. The second kind can usually be converted; the first kind should be left alone and staffed properly.

Organizations tend to build the escalation path first, because escalation is what hurts and pain gets budget. Most escalation routes exist because the ordinary route was never specified.

Publish internally as though you were publishing externally

An Interface Nobody Can Find makes the observation: internal and external consumers have identical needs and only one of them can take their business elsewhere. The cultivation that follows is a single standard rather than two.

A catalogue where anything can be found. Not a portal project. Somewhere a stranger can discover that a capability exists at all, which is the step most organizations skip because everybody internal already knows.

Documentation written for someone who has never spoken to the team. This is the hard part, and the test is not whether it is accurate — it will be. The test is whether it makes sense to a person with none of the context the author cannot remember acquiring.

Worked examples, because an example is what people actually copy, and they will copy whatever they find whether or not you meant it as a pattern.

Somebody who treats the experience of using it as part of the thing, rather than as an afterthought once the capability works.

The word for that discipline is developer experience, and it is the wrong word, because it makes it sound like a courtesy extended to developers. It is a friction control, and it belongs in the same conversation as ownership and guardrails.

And if any part of your business depends on other organizations building on top of what you do — the API economy in its unglamorous, everyday sense — the same discipline has to extend outward, published and discoverable. A partner who has to ask how to use you will find somebody easier to use, and will not tell you why.

The half this does for value

Everything above is friction. Here is the other half, and it is the reason I would put this chapter above its apparent importance.

An interface is where somebody outside gets to use what you can do. If it is hard to find, the people who give up are invisible: a partner who could have built on you and went elsewhere, an internal team that wrote their own version rather than wait, a customer who tried once. None of them file a complaint. They just do not come back, and nobody in the organization ever learns it happened.

So a findable front door is not only a handover you removed. It is the difference between a capability the organization has and a capability anyone can actually get value from — and those two are much further apart than most organizations believe.

Anyone building on you will tell you exactly this, if you ask them directly and make it comfortable to answer. They will not volunteer it.

Where it drifts back

Interfaces decay quietly. The rota stops being maintained, someone helpful starts answering directly because it is faster, and within a year the front door is decorative and Maja is back — usually a different Maja, doing the same generous thing.

That is not a failure of discipline. It is what happens when being helpful is easier than being findable, which it always is. Which is why this one is cultivation rather than a fix: it needs somebody looking at it about twice a year, forever.

This cultivates: You Have to Know a Guy, An Interface Nobody Can Find and The Detective Work at the Front of Everything, in Part II.