The friendliest developer always pays the price

At some point in your career, if you work in a small technical team embedded inside a larger organisation, someone is going to send you a Slack message that starts with the words “quick question”.

It won’t be a quick question. It never is. It will be a request for something that sounds trivial but isn’t, dressed up in the language of informality to make it easier to ask. And because you’re helpful, and because you know how to do the thing, and because saying no to a quick question feels disproportionate, you’ll answer it. You’ll spend forty-five minutes doing the thing. You’ll mark nothing in the backlog. You’ll tell no one. And three weeks later, when a stakeholder asks why the sprint didn’t deliver what was promised, you will have no good answer, because the forty-five minutes happened in the gaps between the visible work, and the gaps have been quietly eating your capacity for months.

This is how small technical teams get buried. Not in a single catastrophic failure. In a thousand small acts of helpfulness that were never accounted for, never sequenced, never weighed against anything else. The team that was supposed to be building the platform has spent half its time fielding informal requests from people who know that a friendly Slack message is faster than the official intake form. And they’re right. It is faster. That’s the problem.

The front door principle is simple to state and harder to hold: all requests - every single one, regardless of size, urgency, or who is asking - enter through a single visible intake process. There are no informal channels. There are no direct messages to individual team members that bypass the backlog. There are no quick favours that go undocumented.

When I’ve explained this to people, the first reaction is usually the same. “That sounds like bureaucracy.” It’s worth sitting with that reaction for a moment, because it’s telling you something true about how the person asking has experienced process in organisations. They’ve seen intake forms that exist to slow things down. Governance structures that exist to protect someone’s territory. Approval workflows that add three weeks and no value. They’ve learned, correctly, that formal process is often a performance of control rather than a genuine attempt to deliver well.

The front door is not that. Or it shouldn’t be.

The purpose of a single intake process isn’t to create friction for its own sake. It’s to give the team visibility over everything that’s being asked of it, so that it can make honest decisions about what to do in what order, and tell stakeholders the truth about when their thing will happen. Without that visibility, the team is flying blind. Delivering whatever got asked most recently, or most loudly, or by whoever had the direct line to the friendliest developer. That’s not agility. That’s just chaos with good intentions.

There’s a particular failure mode I’ve watched play out more than once, and it goes like this. A small team builds something good. People notice. Requests start coming in. At first through the proper channels, then increasingly through the side door, because the side door is quicker and the people asking have figured this out. The team, being capable and conscientious, says yes to most of it. They’re helpful. They get things done. They stay late.

Six months later, the team is exhausted. The roadmap is a fiction. Half the work in progress was never on any plan. The stakeholders who used the official process are frustrated because their requests are taking forever; the stakeholders who found the informal channels are delighted, and have told their colleagues. The team lead is spending every Monday morning trying to reconcile what the team is actually doing with what they’re supposed to be doing, and the answer is increasingly “not the same thing.”

The thing is, nobody did anything wrong. Nobody was malicious. The people making informal requests were just solving their problem in the most efficient way available to them. The developers answering those requests were just being helpful. The system failed because the system allowed it to.

The front door closes that gap. Not perfectly. Nothing is perfect. But structurally. If the only way to get work from this team is through the intake process, then the intake process becomes an accurate map of demand. The team knows what’s been asked of it. Leadership knows what’s in the queue. Stakeholders know where their request sits and can see, clearly, what it’s competing with. Honest conversations become possible because everyone is looking at the same information.

There’s a secondary effect that’s easy to miss, and it might be the most valuable one. A well-designed intake process filters out work that isn’t ready.

If you ask someone to tell you what the user is trying to accomplish, not what feature they want, but what job they’re trying to get done, a meaningful proportion of requests reveal themselves to be underspecified. The service area that was absolutely certain they needed a new application turns out to need a change to an existing one. The urgent request that needed to be built this sprint turns out not to have a named UAT stakeholder, which means it can’t be tested, which means it can’t be delivered, which means it wasn’t actually urgent in the way it presented.

Returning those requests to the requester, with clear guidance on what’s needed before they can be accepted into the backlog, is not gatekeeping. It’s quality control. It protects the team from spending time building the wrong thing, and it protects the requester from receiving something that doesn’t solve their actual problem. Everyone benefits, even if it doesn’t feel that way at the moment of rejection.

The intake form, in this sense, is a point of reflection. It asks the requester to articulate what they actually need clearly enough that someone else can build it. Many requests don’t survive that encounter. The ones that do are better for having gone through it.

The hardest part of the front door principle isn’t designing the intake process. It’s holding the line when someone senior decides the rules don’t apply to them.

Because they will. There will be a director, or a head of service, or someone who is nominally a peer but has been at the organisation for fifteen years and has opinions about how things work, who will send a message directly to a developer asking for something. And the developer, being human, will feel the pressure of that seniority and will want to be helpful and will think “it’s just a small thing” and will be tempted to just do it.

This is the moment the front door either holds or doesn’t. If the team lead backs the developer up - thanks the director for the request, explains the process, genuinely routes it through intake - then the principle survives. If the developer answers the message and the work gets done informally, then everyone in the organisation has learned that the process is optional for people with enough status. And it will never fully recover from that.

Holding this line requires a specific kind of organisational support. The person who owns the front door, whoever is responsible for intake, triage, and sequencing, needs to have the backing of someone senior enough to make the process stick. This isn’t about being obstructionist. It’s about being honest. The message to the director isn’t “no, go away.” It’s “yes, and here’s how we make sure it gets the right attention and doesn’t bump something equally important off the list.” A good intake process isn’t a wall. It’s a managed queue, visible to everyone, with defensible decisions about what comes next.

That’s the offer. Transparency for process. You tell us what you need through the front door, and we’ll tell you honestly where it sits, when we’ll get to it, and what it’s competing with. No black boxes. No mysterious delays. No wondering whether your request got lost or deprioritised or quietly forgotten.

Small teams protecting their capacity from the combined appetite of a much larger organisation is, when you strip it back, just self-defence. The front door is how you do it without becoming the team that says no to everything, without losing visibility, and without arriving at Monday morning wondering where the week went before it’s even started.

The Slack message that starts with “quick question” will still come. It always does. The difference is what you do with it.