The Golden rule of platforms (™ Steve Yegge) is simple and well known – Eat your own dogfood. 

In the context of building technical platforms, it means that the first user of your platform is you. While this seems a fairly simple thing, certainly too simple to be THE golden rule, this guideline has very deep repercussions around why a platform is built, how it is built, and the impact it has on an organization.

The Golden Rule plays the essential counterfoil to the other cardinal rule of building platforms – a platform must be externally programmable. External programmability ensures that anyone can build cool new things on top of a platform without having to buy into your business opinions. “Eat your own dogfood” turns external programmability inwards by dictating that even internal teams, even the platform owner itself, must use the platform just as if it was provided by an external party. No backdoors. No special access. No admins. Nothing that you wouldn’t allow a complete stranger to do.

External programmability is the knife that separates platforms from products. The Golden Rule is this knife applied to the platform owner’s business.

Here are some ramifications of building a technical platform based on dogfooding.

A Good Platform is a Great Product

I have written before about why an organization should adopt platform architecture and strategy. 

Eating your own dogfood means that the reasons for building a platform are also the reasons for using said platform. A platform is typically sold as a set of tools that take care of “solved problems” and allows the buyer to focus on solving new problems. For a team to grow and solve business problems at a deeper and deeper level, it is imperative that they not be repeating themselves. Explicitly adopting platform architecture forces us to think about solved problems and unsolved problems separately.

A good platform lays down the building blocks and clear rules around using them. As a follower of those same rules, the platform owner gets a first hand understanding of the good, the bad, and the ugly. Dogfooding tells us about the “maker experience” first hand.

Externalizable from day one

If we are to eat our own dogfood, then ALL the rules and mechanisms for using the platform must be in place just as they would have to be if we were to let others (other teams in the company, people outside the company) use the platform. This means that in practice, a platform done right is externalizable and ready for consumption by anyone from its first day. 

A good effect of this is that the organization’s boundary starts becoming fuzzy from a technical perspective, switching from access control mode to cooperation mode. Anyone who wants to co-create alongside internal teams on this platform is now free to do so. We may never expose the platform externally, but it forces the business and other technical teams to think in a way that does not presuppose exclusive control and encourage co-creation of value with other partners (via close knit technology integrations). I can assure you that given such capabilities, business folks can get very creative very fast!

Layered Organization Structure

Eating our own dogfood means that we have to think about making dog food separately from eating it. Every business problem contains two parts. One is the part which is shared by all problems of that domain regardless of the organization (what I call Domain Context). The other part represents the organization’s specific ways of solving the problem – the Organization Context. 

Eating your own dogfood forces the split between these two in the organization’s technical architecture. I outlined a case study of such a split in an earlier post on building a notification system. 

Hierarchical, loosely coupled layers are an emergent property of platform architecture.

And since an organization cannot help but ship its communication structures, we can leverage this phenomenon in reverse to let the technical architecture lead us to an organization structure which is best suited to exploit this loose coupling and agility. Platforms architecture facilitates fast, unmediated (by humans, all mediation is over well defined programmatic interfaces) cooperation between teams that focus on achieving their specific business goals using the various platforms surrounding them – including the one they made themselves.

You can visualize this as a set of value generating, opinionated business processes sitting on top of a set of platforms. As these processes grow larger and more complex, they themselves start splitting into higher order platforms and even higher order business solutions built on top of them.

---

This is a brief look at the impact of The Golden Rule of Platform on technical architecture organizational attitudes. It is worth it to consciously apply platform thinking and this rule to every business or technical problem your are solving to what kind of structures emerge as a result and how we can benefit from them.

Read Next – Using API Gateways to build hierarchical architecture