Skip to content
Lacambra Web Portal Services
← All writing
Decisions · 22 September 2026 · 7 min read

Nobody can decide

The most common reason I turn work down is not the budget. It is that when I ask who signs it off, the answer is a list of names.

A wire in-tray of blank printed forms, one pulled askew from the stack, with rubber date stamps and an open red ink pad beside it.

An organisation emails me with a real problem and a real budget. The system they run on was written by somebody who left in 2019 and nobody will touch it. Everyone agrees it has to go. Six weeks later the project has still not started, and mostly it never does, because four people each have to be consulted and not one of them can say yes on their own.

That is not a budget problem. I have turned down more work over this than over money.

It is the last question I ask, and it changes the answer

The fit check on this site asks seven things. Sector, what is breaking, how many people use it, when it has to work, what the budget is. The last one is who signs it off, and the options are: me on my own, me plus one other person, it needs board or committee approval, and I am not sure who would.

The fourth answer is the one that ends the conversation, and it is more common than the budget answers people expect me to care about. Somebody has been asked to look into options. Nobody has been given the authority to choose one.

An approval trail for one travel request: five stages each with a role, a status and a timestamp, one still pending at four days, and an exception route marked below it.
The approval trail for one travel request, from the demo system rather than a client. The organisation, the roles and every timestamp on it are invented. The shape is not: five stages in the official route, one of them sitting four days with Finance, and the branch underneath that people actually use when four days is too long.

A build is a sequence of decisions, not a sequence of tasks

A complete build is fourteen to sixteen weeks, and in most of those weeks there is something only the client can answer. Does a cancelled booking keep its reference number or release it. Who is allowed to see the salary field, and who is allowed to see that a salary field exists. What the system does when two people edit the same record within a minute of each other. None of these are technical questions. They are policy, and I am not entitled to invent the policy of somebody else's organisation.

If each of those takes three weeks to get answered, the build is not fourteen weeks. It is the better part of a year, and the delay is invisible from the client's side because nothing looks stuck. The invoice schedule is tied to working software, so a stalled decision does not bill. It just sits there, and my one build slot sits there with it.

What a stalled decision costsAs plannedBuild14 to 16 weeksWith each decisionwaiting three weeksthe better part of a yearBuild weeks. Identical in both rows.Waiting for an answer only the client can give.The build weeks are the same. Only the waiting is added.Nothing looks stuck from the outside, and a stalled decision does not bill.What a stalled decision costsAs plannedBuild14 to 16 weeksWith each decision waiting three weeksthe better part of a yearBuild weeks, identical in bothWaiting for an answerThe build weeks are the same.Only the waiting is added.Nothing looks stuck, and a stalleddecision does not bill.
Drawn, not photographed. The build weeks do not change. Three weeks of waiting at each decision is what turns fourteen weeks into most of a year, and none of it looks like a delay from the outside.

Board approval is fine. No decision maker is not.

These are different things and they get confused. A board or a committee ratifying a six-figure spend is normal, and for an NGO or a co-operative it is the correct way to run money. I write proposals so they can go straight into a board pack: fixed price, defined scope, a start date, the risks named. Tell me the meeting date and I will work backwards from it.

What does not work is when the board is the only decision maker. Boards meet monthly at best. A build needs answers weekly. Somewhere between the two there has to be one person who can say "yes, that is how we do it" without convening anybody, and who will not be overruled a fortnight later.

The organisations that need approval software are the ones where approval is hardest

I have spent a lot of my working life building exactly this. Travel authorisation that routes through a supervisor, then an executive, then an exception path when the trip has already been booked. Staff requests that go through HR and then Finance, in that order, with a record of who held them. Document routing across a regional labour office, where the point of the whole system was that when a citizen's paperwork stalls, somebody can say where it stopped and for how long.

So I am sympathetic. Diffuse authority is usually not dysfunction, it is an organisation that has grown careful for good reasons. But the same property that makes approval software worth building makes the project to build it hard to start, and pretending otherwise helps nobody.

What I do about it now

The written proposal names the decision maker before it names the price. Not a department, a person. If that line cannot be filled in, I say so on the call rather than sending a document that implies we are further along than we are.

It protects me, obviously. I take one build at a time, so a slot lost to a project that cannot answer its own questions is a slot I cannot sell twice. It protects the client more. The alternative is that they spend the deposit, we both spend three months discovering the problem, and they are further from a working system than when they started.

Enrique Lacambra III builds internal business systems from Pasig, Metro Manila.

Email me← All writing

Tell me what is broken and I will tell you if it is worth building. A 20-minute call, no charge, and I will say so if you do not need me.