Malta — lean and software
We diagnose processes, then build the fix.
Sometimes the fix is a change to how the work runs, sometimes it's software, usually it's both. The method doesn't change: find where the work actually snags, then build the smallest thing that takes the snag out.
We work as lean process engineers and full-stack developers, which in practice is one job rather than two — most of the processes worth fixing end up needing something built, and most of the software worth building is downstream of a process nobody has looked at properly.
Three kinds of output
Same method, different stages.
- Client work Work Lean process consulting, AWS infrastructure, and full-stack builds for clients.
- Finished Builds The software we build for our own practice.
- In progress Experiments Prototypes, open questions, and what we learned from the ones we parked.
How we work
The problem gets stated before the fix gets built.
Most of what we're called in for is described as a software problem. Often it is one. Fairly often the software is fine and the process around it is doing something nobody intended, in which case writing more software just makes the wrong thing faster.
So we start by watching the actual work — not the diagram of the work — and writing down what's happening in plain language. That write-up is the thing we'd want to be judged on. If it's right, the fix is usually obvious and often small. If it's wrong, no amount of building rescues it.
Then we build. We do the infrastructure and the application code ourselves, which keeps the loop short: the diagnosis isn't handed to someone else in the hope it survives translation.