Built by people who believe trying still matters.
Slash began through a series of problems, experiments and companies rather than a master plan.
What connected them was a growing belief that useful things should increase the capability of the people around them — and that worthwhile ideas need durable institutions if they are going to survive.
No hype verbs. No founder mythology. No urgency theatre.
Every belief here was learned by getting something wrong first.
The organisation was never the person running it.
Javier started in a student-led STEAM organisation called Launch, running workshops for other students, and eventually led it. The first version of that leadership was mostly about status — being the person responsible for something that mattered. What became obvious over time was that the organisation's value had almost nothing to do with whoever was in charge. It was the people, and what being given real responsibility did to them.
Autonomy without accountability amplifies whatever is already there.
After he left, he watched it erode — not through incompetence, but under leadership increasingly driven by status and being seen to be the best. The same freedom that had developed people was now magnifying something else, with nothing structural to check it. It is the reason this site pairs agency with accountability everywhere it appears, and why we do not believe in simply trusting people and standing back.
Conviction was not the missing piece.
The first version of Horizons came directly out of Launch: bring that experience of real responsibility to more people. It did not survive contact with its own economics. The problem was real, the intent was genuine, and neither of those is a business model. Rather than keep it alive on conviction, we paused it. The belief did not fail — the model did, and those are not the same thing. It is being rebuilt from that lesson, which is now step four of how we build.
Most technology problems are not technology problems.
SlashTech began as technical work and became something else. Years spent inside other organisations' operations made the pattern hard to miss: what presents as a software problem is usually an ownership problem, a process nobody holds, or a system somebody inherited and was never really given. Understanding how an organisation actually works became the first half of the job — and sometimes the answer is that no software should be written.
Different problems, sharing what should compound.
The conclusion was structural rather than strategic. A people-development problem and a technology-infrastructure problem should not compete for attention inside the same company — they need their own focus, leadership and customers, while sharing a philosophy, a standard, and everything already learned. That is the Group. It arrived from the lessons above, not from a portfolio plan, which is why the list of ventures is still unfinished.
Jayben worked as a mechanic before moving into technology. It is a small biographical detail and also the whole belief about people, arriving before we had worked out how to say it: what someone is doing now is a poor guide to what they are capable of.