Next steps for Rubric: “Have a stake, have a say”

It’s hard to pick one key takeaway from such a lively conference, but the message “Have a stake, have a say”—which was woven through the event—definitely struck a chord.

We’re proud to be employee-owned, and the conference reinforced that it’s the right strategic model for our business.

Sharing the learning

The EOA conference provides a rare opportunity to discover how other employee-owned companies operate.

A standout example was “Behind the Boardroom Door”, an interactive simulation of an EOT trust board meeting. It was fascinating to see how other trusts handle decision-making, and to learn that we share many of the same challenges. For example, effective governance is key to avoiding “role creep”, where trustees take on day-to-day operational responsibilities that should be managed by company directors.

When it comes to technical risk, non-technical stakeholders often bring a perspective that seasoned engineers sometimes overlook. While they may not grasp the intricacies of system architecture, code vulnerabilities, or network configurations, they instinctively understand one critical truth: risk is about impact, not just likelihood.

The Day We Replaced a Library and Everything Got Faster (and Worse)

We thought we were making a simple upgrade: swap out an old library for a new, “faster” one. And at first, it was glorious. Pages loaded in half the time. Processes that took minutes were done in seconds. We celebrated our own cleverness.

Then reality hit. Edge cases we hadn’t tested started failing spectacularly. Subtle bugs popped up in production. Logs flooded with errors we didn’t even understand. What was supposed to be a smooth, invisible swap turned into a firefight.

In software design, backward compatibility often operates behind the scenes, quietly influencing architectural decisions. Maintaining compatibility with legacy systems ensures that new features don’t break existing functionality—a necessity for enterprise systems, APIs, and widely-used platforms.

2026-03-10 - testing article name change

Observability is often talked about in ways that make it sound complex and mysterious. At its core, it’s simple: it’s about understanding what’s happening inside your systems so you can spot problems early and fix them quickly.

Instead of focusing on fancy terms like “telemetry” or “event streams,” think about three practical things:

Configuration files are meant to simplify systems, but they often do the opposite. Over time, quick fixes, legacy options, and environment-specific overrides pile up, turning simple settings into fragile, opaque structures. The result is accidental complexity: behaviour that’s hard to predict, harder to debug, and risky to change. Taming it requires discipline—clear defaults, minimal options, and regular pruning—so configuration supports the system instead of quietly undermining it.

Your build pipeline says “green,” but that only means the happy path passed. It rarely reflects real-world conditions like flaky dependencies, production data quirks, security gaps, or performance under load. Cached builds, mocked services, and overly permissive configs can mask failures that users will definitely find. The result? False confidence, late-night rollbacks, and bugs that “shouldn’t be possible.” Trust the pipeline—but verify it with production-like tests, chaos, and observability. Green builds don’t ship value; resilient systems do.

Some of the most dangerous failures are the ones you can’t recreate on demand. They happen once, under just the wrong conditions, and leave behind little more than a vague error and a frustrated team.

Designing for these failures means assuming you’ll never see them again—at least not in a controlled way. That pushes you toward defensive patterns: comprehensive logging, correlation IDs, immutable audit trails, and metrics that tell a story even when the system is already “back to normal.”

We disabled IPv4 expecting a clean, modern IPv6-only setup. What we got instead was a masterclass in legacy reality.

Several third-party services silently assumed IPv4. Some APIs resolved to IPv4-only endpoints. A few SaaS tools hard-coded IP allowlists. Monitoring broke in odd ways. Even “IPv6-ready” systems occasionally failed during DNS fallback or dual-stack edge cases.

The biggest lesson? IPv6 support is often theoretical until you remove IPv4 and watch what panics.