At Oxide, our mission is ambitious, and we emphatically cannot achieve it alone: we need to partner with others to deliver on our mission. Determining with whom we partner and how is one of the most important classes of decisions we make; how do we make these important decisions?
Partners versus vendors
First, we must differentiate between a partner and a vendor. A vendor sells a product that we buy: the product itself is well-specified, mass-produced and broadly available. Vendor relationships are, by their nature, transactional; we are effectively anonymous to them — and perhaps they to us. When we engage in a selection process for a vendor, we are therefore judging them purely based on their products, price, and so on; our relationship with them is a non-factor. On the one hand, vendors are necessary for us — but on the other, no one vendor is essential; vendors are, by their nature, interchangeable at some level.
A partner, on the other hand, works with us to provide a part of our product. The relationship is commercial, but it is not merely transactional: a partner invests in and takes responsibility for our shared success. Partnership is more strategic and technical, though the technical specifics will run a gamut: some partners will deliver highly differentiated technical artifacts; some will take existing artifacts and combine them in novel ways; some will be operating on a much more tighter specification — and many partnerships will have elements across the spectrum.
Principles, values and partnership
Oxide’s principles and values underpin everything we do. We view our principles of honesty, integrity and decency to be constraints on operation; we expect everyone we interact with — including every partner and vendor — to share these most basic principles.
Values, on the other hand, are more nuanced: as expressions of relative importance, they are more uniquely ours, and we don’t expect them to be identical to those of other companies. That said, our values represent a potential lens by which we evaluate potential partners: we seek relationships with those who not only can work with us to build our product, but who also broadly share our values. Of course, values are not absolutes to be applied equally to all situations — and several of Oxide’s values are particularly germane to how we think of partnerships. We present this subset of our values more or less in priority order, but we expect a successful partnership to exhibit all of them.
Responsibility
We — Oxide — are responsible for the product that our customer runs. When the product fails to live up to our customer’s expectations, the responsibility for that failure must reside with us, regardless of where the technical origin of that failure may reside. Bluntly, we cannot outsource responsibility. To live up to our own sense of responsibility, we must find partners that share that sense: partners must see themselves as delivering together with us. If a partner views their relationship as purely transactional (that is, if they view themselves as a vendor rather than partner), we will not be able to get the level of engagement we need to deliver the quality of product that our customer demands.
Our sense of responsibility will lead us to take a deeper sense of ownership than our partners may be accustomed to. For example, we want to understand (if not ourselves deliver) all firmware that comprises our product: given our core strength in low-level software, our responsibility to our customer demands no less. That said, there are aspects of the machine clearly outside of our domain of expertise; in these especially, we will rely on a partner’s judgement, perspective and expertise — even though we must view ourselves as ultimately responsible for what is delivered.
There is one particular aspect of responsibility that merits a special mention: because we are building a product that is, by its architecture, secure, it is imperative that partners take any security responsibilities seriously; should security issues be discovered in putatively secure elements, components or processes, we expect timely (and unprompted) communication, over whatever embargo deemed necessary.
Our desire to have a partner that shares our value of responsibility will lead us to have fewer, deeper partnerships — and this is very much by design: just as we believe that responsibility cannot be oursourced, we similarly believe that it cannot be dual-sourced or otherwise sent out to bid.
Transparency
Transparency is a deeply held Oxide value, and it manifests itself in many of our technical decisions. We believe that a transparent product is a better product — and we believe that a transparent partnership is a more robust partnership. Our partners will find that we are very transparent with them: we don’t harbor hidden agendas, and are always happy to share what we know (within the bounds of our need to respect the confidence of others). Early in a relationship, transparency extends from mundane (but essential) details like documentation, errata, source code, etc. through more strategic conversations around future planning. Later in a relationship — and as the product of a partnership enters validation and ultimately the hands of customers — transparency becomes essential; when aspects of the system fail we need partners who (per their sense of responsibility!) are ready to engage with us to solve problems. Many a partnership has been tattered when defects were obfuscated rather than addressed!
Candor
We value candor in ourselves, and we value it in partners too: where a partner believes that we’re wrong, we want to hear it; we do not want a partner that agrees to something that they believe is foolhardy, impossible, or otherwise ill considered! Candor is important in all phases of a relationship, but its greatest test is under times of duress: where (when) the news is bad, it’s essential that we and our partners are forthright with one another.
Rigor
Details very much matter in a computing system, and we need partners who share our sense of rigor. The specifics will vary: because our partners often have domains of expertise disjoint from our own, their manifestation of rigor will differ from ours — but we expect to see shared rigor in things like communications. And when defects are found — be it a partner finding a defect in an Oxide deliverable or vice versa — we expect that the shared rigor of the partnership will result in immediate communication and a timely fix. In particular: we should not need to make the case of gravity — and that a component works under some other conditions or is otherwise widely deployed should not be used to excuse its malfunctioning.
Teamwork
One of our most deeply held technical beliefs is that software and hardware should be designed to work with one another. This isn’t easy: it necessitates collaboration among engineers from different domains. More concretely with respect to a partnership: we expect to be teaming our engineers directly with those of a partner. As a result, things like timezone are an important consideration for us. We are US Pacific-based; working with teams that are offset more than ~three hours greatly limits the tightness of collaboration — and working with teams that are offset more than ~eight hours limit our interactions to one per day (and assure that any calls are being held outside of working hours for one party).
Courage
We are a gutsy company, and we have a natural affinity for kindred spirits who, like us, are willing to challenge the status quo. We do not challege for its own sake, but if we believe we have a solution that will yield a superior product, we are unafraid to go our own route to build it. We are seeking partners who share well-placed courage rather than are terrified or perplexed by it.
Thriftiness
We appreciate value engineering, and we are always looking for ways to yield a system that delivers more bang for the buck. In our partners, we seek a similar ethos, and always welcome ways to find less expensive alternatives, greater manufacturability, lower total cost of ownership, etc.
Using values to evaluate partners
There is not a simple or prescriptive way to evaluate someone else’s values (be they a person or a partner). That said, over time, as one begins to know another, values will become apparent: they will either reveal themselves or be otherwise surmised. These values should therefore not be thought of as an a priori checklist or part of an RFP, but rather something to be mindful of as a relationship unfolds — and when there is something wrong (or right!) with a relationship that feels hard to put words to, it may be helpful to return to them explicitly. They can be used to reject a partnership before it forms (opting for another with clearer alignment with values), or to right a partnership that has started to list. In that regard: we have found that those who share our values are likely to appreciate that we are so explicit about ours — and in the very spirit of candor and transparency, it can be helpful to share this document with our partners early in a relationship.