HoruSphere Group

How we operate

The group's operating model.

That sentence is the group's actual strategy, and it is the only reason a game studio and a developer-tooling company belong under one roof. This page sets out the argument, the four principles that follow from it, and the boundary the group keeps between its two companies.

The boundary

Standards travel between the companies. Roadmaps do not.

A group of two can go wrong in one of two ways. It can keep the companies so separate that nothing is learned twice, or it can merge them into a shared-services fog where no one owns a customer. The boundary below is drawn to avoid both, and it is drawn in exactly one place.

What crosses the boundary between the two operating companies HoruSphere Group sits above both companies and sends engineering, delivery and release standards down to HoruSphere Interactive and HoruSphere Systems. Between the two companies, product roadmaps and customer decisions do not cross: each company keeps its own. HoruSphere Group sets engineering, delivery and release standards Standards flow down Standards flow down HoruSphere Interactive owns its roadmap, its players and its titles HoruSphere Systems owns its roadmap, its customers and its modules Roadmaps and customer decisions do not cross product decisions stay local
Engineering discipline, delivery practice and release rigour are defined once by the group and applied in both companies. Product roadmaps, pricing and customer commitments belong to whichever company owns the customer, and the group does not reach across that line.

Operating model

Four principles, and what each one costs us.

A principle that costs nothing is a slogan. Each of these rules out something the group would otherwise be free to do, and the trade-off is stated alongside it.

  1. Build for our own operations first

    Tooling earns its place by being used on real production work before it is offered to anyone else. A Horu Platform module that has not carried a game build, a content branch or a release run is not a product yet, however good the idea is. The cost: it makes the platform slower to broaden. Features that would obviously help a customer we do not have wait until we have the problem ourselves.

  2. Keep the companies genuinely separate

    Distinct markets, audiences, products and execution paths. No forced synergy and no shared-services fog. A player buying a turn-based strategy game and an engineering lead evaluating a build system are not the same customer, are not reached the same way, and are not counted together. The cost: two brands, two sites, two audiences to earn. The group gives up the convenience of one funnel.

  3. Share standards, not roadmaps

    Common engineering discipline, delivery practice and release rigour move between the brands, because a build process good enough for a Steam release is good enough for a SaaS release. Product decisions stay with the company that owns the customer. The cost: the group cannot order a feature into either product to make a story tidier, including this one.

  4. Hold for the long term

    Depth over launch spikes, in both games and software. A simulation title and a developer tool are both compounding products: they improve over years of iteration and degrade when shipped to a date chosen for its optics. The cost: no announced release windows, which is less exciting than a countdown and the reason none appears anywhere on this site.