Values and Virtues of The Ockam Team
“What we do is who we are.”
The first product that Ockam shipped, in the fall of 2017, was our Values. They have remained virtually unchanged since our founding. They were originally stated as: Simplicity, The Team, Products. Over the past two years I have expanded upon the values’ descriptions, and built internal guidebooks of best practices.
The presentation, description and explanation of our values became bloated and spread across multiple medias. These volumes violated our value of simplicity. I sought out a new framework to better communicate our intention in a more simple way.
I read Ben Horowitz’s new book “What you do is who you are” and it crystallized a very simple idea;
“Values are what you believe,
Virtues are what you do.”
I decided that this framework was the simplifying structure I was looking for; To connect Ockam’s Values with the best of proven management behaviors from iconic technology companies - including Intel & Google (OKRs), Amazon (Day One / Decisions), Salesforce (V2MOM), Gitlab & Hashicorp (Remote-First), Heroku (Builder Day) - and Ockam’s own innovations to build simple tools with a high performance team.
CEO at Ockam
PS. I also recommend the following books for a deeper understanding of the culture at Ockam; “The Score Takes Care of Itself” by Bill Walsh,” and “Measure What Matters” by John Doerr.
What we believe;
The creation of simple solutions out of complex problems is the basis for our namesake, Ockam. Every idea, product, and procedure at Ockam should be governed by the principles in Ockham’s Razor. Simplifying is a difficult and iterative journey.
The High Performance Team
We simply call it “The Team”. Ockam has the ethos of a high performance, world-class sports team.
The responsibility of The Team is to provide an environment where every individual is empowered to be world-class in their role and to enable individuals to achieve more than they could dream possible for themselves.
High Performance teams have the grit to do the hard things. We dream audacious goals, and continue to progress towards those goals regardless of obstacles or setbacks.
Our Team includes every Ockam customer, partner, employee, supplier, investor, advisor -- and, of course, open source developer.
Builders love their tools
Ockam is a tools company. Our tools are used to build, or are built directly into, others’ products.
Builders enable new technical ecosystems to exist. We believe that builders should have meticulously designed, simple, and useful tools with elegant user experiences.
What we do;
We start with Trust
Some teams use a model where trust is earned over time based upon past performance. The Ockam Team does not do this. When people join The Ockam Team they should assume that they are completely trusted by everyone on The Team to be their best-self from Day 1.
The Team believes in you.
The Team gives people responsibility, not ownership. I have never liked it when people use the word ‘Own’ inside a product driven company. Typically it is used in the context of “I own the relationship with the customer”, or “she owns the problem with her feature.” Describing individual ‘ownership’ inside our high performance team culture doesn’t make any sense.
We uses a RACI framework at Ockam. R-A-C-I it stands for
When we juxtapose Ockam’s high performing team to a professional sports team the RACI framework comes into focus. Consider the role of the goalie on a soccer team. She is world-class at her position, is responsible for defending the goal, seeks coaching, works with other players to turn a defensive play into an offensive one, and clearly communicates with the rest of the team.
Every Objective at Ockam has a role for who is responsible, what must be approved, who is consulted, and who needs to be informed throughout the lifecycle of a project.
We use another well known framework at Ockam. It comes from Amazon’s playbook: “There are one-way decisions, and two-way decisions.” One-way decisions are permanent, ‘there’s no going back’, decisions. Two-way decisions are reversible. If you are responsible for an Objective, you should consider who else on the team needs to be an approver, consulted, and informed of your Objective. You should also know whether decisions you make are one-way or two-way decisions.
Ockam has also adopted a culture of ‘Disagree and Commit’. Ockam moves fast, and relies on Trust. This means that we disagree and commit on decisions all the time. This also means that Ockam’s culture is not consensus driven culture. We have far too many decisions to make. This is why Responsibility for an Objective also comes with the trust and empowerment to make decisions.
We strive to understand ‘why?’
Before anything else is understood, it’s first important to know ‘why’. When a customer engages with our products, it’s important to know why. When a teammate posts a comment in our Slack channel, that you disagree with, it’s important to first ask them ‘why?’.
After we ask why, we ask why again. We use the mechanism of ‘5 whys’. Usually it takes asking ‘why’ five layers deep before we can really understand why.
Once we think we understand why, then we then move onto ‘for who’. Segmentation and personas are critically important in a product driven company. A proposal for a feature may be important to one user, but not to another. When we understand ‘for who’ we gain an even clearer understanding of why.
Time is important at Ockam; a cherished asset actually. ‘When?’ is the next level of understanding to consider. Knowing when an objective needs to be accomplished forces prioritization. For example, a feature may be important to a customer, but when do they need it? Can we ship a partially implemented feature version, if the customer is satisfied that it is in our roadmap? Understanding ‘when’ helps us better understand why.
We move onto understanding ‘what’. Defining what should be done helps us generate a common language with tangible goals across the team. We create specifications, documentation, and graphical diagrams as part of our prototyping process to align on what we are doing. We typically represent what we do as Key Results in our planning. Definitions matter; what helps us to further understand why.
Finally, we add process to our projects. We define ‘how?’. We assign roles with our RACI framework, and put tooling into place to manage progress. Assignment of how helps us better understand why.
Understanding ‘Why?’ aligns the entire team to prioritize, make fast decisions and to align all of our efforts into pulling in the same direction.
We win by doing
Ockam is a team of doers, builders, shippers, and finishers. We celebrate things that are complete. Ideas are the easy part. We win by turning ideas into action.
Like many mission driven product teams, we utilize the Objective-Key Result (OKR) framework. Drawing from the Salesforce V2MOM structure, we additionally layer Ockam’s Values and Vision on top of the classic OKR structure.
Actions result in artifacts. Ockam is tooled so that all of our artifacts can be represented by a hyperlink; a proposal memo, the notes from a customer call, a product feature specification, a sales deck, sketch of a new webpage, or a pull request. After we create hyperlinks we ship them to The Team via Slack. This means that our culture of ‘shipping’ extends to everyone on the team, and not just our coders.
Learning from losses is a virtue at Ockam because a team with a virtue of doing must also value losing. There will be errors, fumbles, and losses on our journey. We would rather record a loss through doing and shipping than through an omission that stems from paralysis by analysis. Through actionable trials-and-errors a log of hyperlinks is created. This makes it easy to append post-mortem analysis so the entire team can learn from the follies in our archives.
Ockam’s vision is audacious and it’s difficult to build what we are building. Our action-oriented culture is susceptible to ‘The Law of Triviality’ otherwise known as ‘Bike-shedding’. Bike-shedding occurs when a team spends the majority of its time on real, but relatively minor easy-to-grasp issues while neglecting far more important and far more difficult and complex tasks. The combination of doing plus bike-shedding is deadly, because it efficiently and effectively destroys our most valuable asset: time.
We preserve and cherish time
Time is the most valuable asset that we have. It’s the only thing that we can’t recreate once it has been spent. This is why we put so much effort into preserving every second of time available to us.
Ockam’s OKRs are generated for far-term and near-term units of time. Instead of thinking of time in years, quarters and months we define time in the following units:
The vision and mission at Ockam is well defined and we do not anticipate changes. We are aiming for a point that is 10 years into the future. We would consider a coarse adjustment to our Vision and Mission to be a major pivot.
We think of our vision and mission as an input to our planning, not the output. We start with our destination in mind before we break down time, objectives and results into manageable steps.
Horizons reach as far as we can reasonably see into the future; about 15-20 months. Because Ockam is a venture-backed, deep-tech company our horizons roughly align with funding cycles.
We break Horizon objectives down into 2 or 3 segments. We call these segments generations. During a Generation we aim to solve one major theme that changes the state of Ockam. When we close one Generation and move to the next it should feel like The Team is stepping up into a new level, and that individuals are moving onto newly defined roles.
Marathons are subsets of a Generation. We break generations down into more manageable objectives that the entire team is aligned to. This helps to focus The Team into a specific unifying effort, like acquiring a new type of customer, or shipping a major feature. We think of it as a race. It has a starting line and a finish line. The last miles are probably going to hurt a bit, but we know that the finish line is the end of the race, and that there will be an opportunity to catch our breath before the next race begins.
Just like a world class marathon runner, we break down our Marathons into well defined chunks to monitor our pace. Miles are 2 weeks long. Every other Tuesday we gather the team to show demos, raise major blockers, and to plan the next Mile.
Many teams call their two-week segments ‘Sprints’. We don’t like to pretend that we can maintain a cadence of never-ending sprints. Building great tools and products is a marathon not a sprint.
During our standups, everyone shares Updates, and Asks / Blockers / Concerns. We aim to make this call no more than 10 minutes long. Topical discussions are moved into side channels if needed.
We treat teammates’ time with extreme care. We utilize Google Calendar’s “Speedy Meetings” feature. Our meetings are either 25 mins or 50 minutes long. Buffer time at the end of each meeting allows for quick notes to be captured, and to mentally context shift so that we are present for our next engagement. Each meeting has a t-minus 2 minute notification so participants all arrive before the meeting starts.
Finally, but perhaps most importantly, we have ‘Maker Day’ every Thursday. This is a day of uninterrupted doing, completely free of meetings or interruptions of any kind. The entire Ockam Team, everybody, participates. This is one of the best practices out of the early days at Heroku, and we are carrying the torch on at Ockam.
Build a remote-first team
We are building a high-performance team with world-class individuals. Therefore it makes sense for the primary-key in selecting teammates be ‘people’, and not their ‘geography’.
Remote-first means something specific at Ockam. Culturally and operationally we assume that everyone on the team will be distributed, even if we have co-located teammates. By doing so we avoid the first-class / second-class structure that many remote-friendly companies create when they structure themselves around a local geography, but make an exception for remote members. New tools and fast connectivity help The Ockam Team innovate in the future of work.
As a remote-first team everyone can optimize their own work environment so they can be their best-self. Because everyone is free to create a work environment that best suits their style, the Ockam Team is more inclusive to a wider distribution of diverse teammates from unique backgrounds. Diversity and inclusion drive the culture of Ockam’s high performance team. When coupled with our use of RACI, and because we are not consensus driven, outlier opinions from unique world-class contributors keep The Team and our products highly innovative.
Empower builders through open-source
Builders need great tools to build great products. When builders win, so does the entire Ockam Team.
We started with the end in mind, that’s why we have built Ockam’s tools in the open source ecosystem from the beginning. Open source speeds product innovation, drives adoption, improves security, and enables integrations. Together these four elements put the very best tools into builders hands.
Because Ockam is open source, ideas and roadmaps are not limited to the financial, time, and creative constraints of Ockam employees. Anyone can contribute to Ockam’s codebase without friction. A junior developer could build their open source reputation by adding a test, documentation, or code example. An experienced hacker could refactor Ockam into another language. A corporate product team could create a complex feature.
Because open source makes code transparent, accessible, and free everyone is able to use the Ockam code base to innovate in new ways.
Open source software is highly available. Anyone can access Ockam’s code, anywhere, anytime. The Ockam open source becomes more durable and valuable the more it is used by the community. This makes the tools more innovative, which kicks off a virtuous cycle that ultimately democratizes access to complicated security protocols for millions of developers.
We believe security solutions can not be a black-box. The more engineers that look at a piece of code, and the more times it is deployed the more secure it becomes. Security teams can inspect and audit the Ockam codebase for their specific application. If vulnerabilities are discovered that team is empowered to make changes that benefit the entire community. Again, the virtuous cycle of open sourced security improvements give every builder better tools.
Connected devices have an n-squared problem that blocks interoperability. With billions of combinations of possible connection configurations it’s impossible to implement all of the possibilities. Product managers at chip makers, device OEMs, network and cloud service providers need to integrate with each other.
However when one of these product managers, or anyone else, builds an Ockam OSS interface, millions of developers could then put trust into that component, product or service. Moreover an Ockam open source integration is only a pull-request away, without need for business development or administrative friction.