“What We Do Is Who We Are.”
Foreword: January 2020
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 (Maker Day) - and Ockam’s own innovations to build simple tools with a high performance team.
I also recommend the following books for a deeper understanding of our culture and frameworks that we use everyday at Ockam: “The Score Takes Care of Itself” by Bill Walsh, "Growth Mindset" by Carol Dweck, and “Measure What Matters” by John Doerr. Our entire reading library of recommended books, blogs and videos can be found here.
CEO at Ockam
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.
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.
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.
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.
As a team, and as individuals, we embrace a growth mindset. We are curious learners and strive to understand 'why?'. When a customer engages with our products, it’s important to know why. When we disagree with a teammate we stop to ask them ‘why?’, before we give our rebuttal.
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 start to 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 and planning '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 to all pull in the same direction.
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. As you will read in the next section, we break time into four intervals. We assign OKRs to each time interval across five categories;
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. This is a key indicator of our growth mindset. 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.
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 our mission as inputs 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 projected funding cycles.
We break Horizon objectives down into 2 or 3 segments. We call these segments Campaigns. During a Campaign we aim to solve one major theme that changes the state of Ockam as a business. When we close one Campaign 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 on The Team.
Races are subsets of a Campaign. We break Campaigns down into more manageable objectives. This helps to focus The Team into a specific unifying effort, like acquiring a new type of customer, or launching a major feature. All races have a starting line and a finish line. The last push in any race usually hurts a little bit as we 'do what it takes' to get to the finish. Because we define races and their finish lines we know 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 Races into well defined chunks to monitor our pace. We do Pace Checks every 2 weeks. Every other Tuesday we gather The Team to show demos, raise major blockers, and to plan the next two weeks of our Race.
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 beautiful products is a marathon not a sprint. Our Races are endurance events that require effective pacing across each Race.
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.
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, our growth mindset, and because we are not consensus driven, outlier opinions from unique world-class contributors keep The Team and our products highly innovative.
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 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. Ockam open source code 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.