How we find our own problems

There is no research function here. No survey, no market sizing, no slide that says the opportunity. Every single thing BE Teck has built came from the same place: somebody inside the group hit a wall for the tenth time and finally refused to walk around it.

That sounds casual. It is actually the most demanding sourcing method there is, because it means we can only work on problems we are ourselves standing in. We find our problems by living them.

There are three stages, and they are not equal.

Notice — name it out loud#

Noticing is the hard part, and it is hard for a reason that has nothing to do with intelligence. Any problem that survives longer than about a month stops being experienced as a problem. It gets absorbed into the description of the job. Ask somebody what is broken and they will tell you what broke this week; the thing that has been broken for three years does not come up, because it has stopped being an event and become the weather.

So the only reliable move is to say it out loud, in plain words, to another person: this step exists because of nothing. Naming it is what converts a tolerated condition back into a problem, and until that happens no amount of engineering will help, because nobody has agreed there is anything to fix.

The three rules then decide whether it is ours. Is it real, is it big enough to matter, and is it something worth doing regardless of whether it makes money. Most things fail the second rule and that is fine — small annoyances can wait.

Build — the smallest honest fix#

The word carrying the weight is honest, not small.

Small is easy and usually wrong: a shortcut, a button, a script somebody has to remember to run. That is another workaround, and workarounds are what we are here to remove, so shipping one is not a win.

Honest means the fix addresses the actual cause rather than the symptom somebody complained about. Sometimes the honest fix is one field on one screen. Sometimes it is an instrument. What is not allowed is a fix that looks finished while the gap is still there — a page that renders, a demo that completes, a pilot that quietly dies once the person who cared moves on.

The field test is the only test that counts. Not the demo, and not the happy path: a full working day, in the real place, on a bad connection, with the people who will actually use it and none of the people who built it standing nearby. If it cannot survive that, it is not finished, and it does not get called built.

Keep alive — we run what we build#

This is the stage almost everybody skips, and it is the one that makes the other two mean something.

We run what we build. The same people who closed a gap stay responsible for it being closed next month. Nothing gets handed to a maintenance team, declared done, and then slowly rots while the people who understood it move on to more interesting work.

Consequences of that rule, in order of how uncomfortable they are:

• Everything built is a permanent liability, so we build less. The question is never just can we? but are we willing to run this for years?
• Bad decisions come back to their authors. There is no distance between design and consequence, which is the cheapest quality mechanism ever invented.
• Total volume is capped by capacity to keep things alive. That cap is the point, not a limitation.

It also closes the loop, because running something is the single best way to notice the next gap. The people operating an instrument every day are the ones who see the thing it still cannot do. Stage three feeds stage one, which is why the method does not run out of material.

What this method cannot do#

It is worth being clear about the cost. Problems nobody in the group experiences are invisible to us. This method has excellent taste about problems we live with and no opinion at all about problems we do not, which is a genuine blind spot and not a modest one.

The only fix for it is other people describing their own walls. If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear — hello@be-teck.com.

Two of the method's rules have been written up on their own since: the machine proposes, a person decides, which decides what we are willing to let software do unattended, and what an audit trail is actually for, which decides what has to survive after it has done it.