So what is Slash Group, actually?

It's the question we get asked most, and the honest starting point is that from the outside it looks like a holding company slide: one name over the top of a technology company and a couple of things still being built. It isn't one.

The shortest true answer is that Slash Group is what one idea looks like when you try to act on it.

The idea is that you should see the world as it is, and build toward what it could be. Both halves are doing work. Seeing clearly on its own produces very well-informed cynics. Building toward what could be, without looking hard at what is, produces confident things that don't survive contact with reality. Slash Group is the structure we ended up with by trying to hold both at once.

A problem worth a company

Most problems get a feature, a service, or a line in a roadmap. That is usually the right call. A problem absorbed into a larger organisation gets a share of someone's attention, a slot in a quarter, and a champion with three other priorities, and for most problems that is proportionate.

Some problems aren't. They are big enough, and stay bad enough for long enough, that the only honest response is a company whose entire reason for existing is that one thing — with its own customers, its own leadership, and nobody to hand it off to.

Working out which kind you're looking at is most of the job. We use a short test, and it is deliberately hard to pass:

• Does it matter enough? Not interesting, not underserved on a market map — bad enough that we would still want to be working on it in five years.
• Can it stand alone? A real customer who would pay a company that did only this. If it can only survive as a line item inside something else, it isn't a company.
• Can we commit? Not "would we like to" — can we actually carry it, properly, for as long as it takes. This is the one that kills most ideas, and it should.

That third question is the one people are surprised by, because it isn't about the problem at all. It's about us. A problem can clear the first two bars and still be the wrong thing to start, simply because we don't currently have the capacity to do it justice. Starting it anyway isn't ambition. It's how you end up with several half-served customers and a story about growth.

Siblings, not departments

The alternative is putting every problem inside one organisation, and we think that quietly fails. Bolt enough of them together and you get a company that does software and also does training and also does a third thing, which is a company that does none of them properly.

So each one is built as its own company: separate teams, separate offers, separate customers, same standard. Siblings, not departments.

What they share is the part that should compound — the systems, the governance, the hard-won knowledge of how to actually do this — and not the part that shouldn't. A customer of a Slash company should be dealing with a company that is genuinely theirs, with its own name and its own reasons to exist, not with a division of something else.

It's also why we're not trying to make Slash Group a name people recognise for its own sake. It works best as the answer to "who's behind this?" — the thing that explains why companies in different industries operate the same way.

Where things actually stand

This is where the thinking has led so far. It is not a plan we set out to complete.

• SlashTech — operating, and currently the only one. Built around the belief that organisations should understand and own the technology their work depends on, and that systems should keep working long after the people who first built them have left. It works inside real operations to find what is actually holding them back, then builds the software, connected hardware and automation that leaves the organisation more capable than it was. The goal is not dependency on SlashTech; the goal is ownership. slashtech.com.au
• An operations venture — in build. Shaped by years of running client work ourselves, and by how much good work is lost to friction, waiting, and unclear ownership. Work should move, not wait.
• A people venture — coming soon. Built around the belief that capable people deserve clearer ways to develop, progress, and find where they can do their best work. Potential on its own changes nothing; it needs direction. Named when it's ready to be.
• Slash Labs — not a venture. It's the workshop: early experiments and internal tooling, including applied AI. Things get a name when they've earned one, and most of what's in there won't.

What comes after that isn't mapped. The next company may come from a completely different problem or industry than anything above, and that's the point — the group isn't a set of categories we're filling in. It belongs here only if it clears the same test.

The standard

All of it is held to the same bar, whatever the company happens to sell. The full version is on the site, but the two lines that cost us the most are these.

Leave capability behind. If a client can't run it without us, we've built a dependency and called it a solution. That is a comfortable business to be in and we don't want it. The measure of the work is what the other organisation can do after we've gone.

Prove what works. Activity is not progress. Reality gets the final vote, and reality is not especially interested in how good the plan was. We have been wrong about things we were confident about, which is the only reason that sentence is in there.

Optimising for whether a company can operate without us propping it up means moving slower, turning down more work, and having less to announce. We've written before about why that trade is worth making: the goal isn't to launch more, it's to build better. This is what it looks like structurally.

The thing that actually limits us

For a long time I assumed the constraint on doing more of this was ideas, or money. It isn't either. There are more problems worth a company than we will ever get to, and funding follows a company that works.

The constraint is capacity — how much responsibility we can carry at once without doing any of it badly. Which means the way to take on something bigger is not to start more things. It's to get better, and to get the things we've already started to the point where they can carry themselves.

That's the quiet mechanism underneath the group. Each company teaches us something, improves the systems, and eventually stops needing everything we have. What it hands back is the capacity to take responsibility for something else. How we build is that sequence written out.

So it compounds, but not in the way the word usually implies. Not more companies, faster. More capability to carry what actually matters.

Where you fit

Rough sorting, if you're trying to work out which door is yours:

• An operation running on spreadsheets, tribal knowledge, or a tool that stopped fitting a while ago → SlashTech.
• A team where development happens by accident rather than by design → the people venture, once it opens. Worth a conversation now if the timing matters.
• A problem that doesn't fit either, and that you think deserves a company → that's the conversation we're most interested in.

Either way it's a conversation before it's anything else — start one here.