The Code We Want at CBH Engineering
Ideal code:
At CBH, our goal is to:
Any new project, starting from zero, should have 3 stages:
High Quality And Fast
Contrary to the common wisdom, maintaining a high-quality bar and moving fast are not mutually exclusive.
🗣️Frank Slootman put this eloquently :
When stepping up the pace, inevitably excuses are made about quality. We can’t possibly move this fast, and maintain quality? [sic] We would agree, because we are going to move faster and raise quality. It has a compound effect on productivity. It’s not defying gravity, it’s beating reams of slack out of the system. Until the pressure is on, we don’t even know how much better and faster we can be.
We recommend reading Frank’s original post in its entirety on LinkedIn. Slootman is always instructive.
Beyond the qualities of Curiosity, Initiative and Ownership we mentioned on the fast with high quality is our foundation, and it’s what we expect from every member of this team.
High Quality
Being owners means that we internalize that the buck stops with each of us -- nobody should have to chase us because we have a SMART plan, broadcast it, and adjust it (and broadcast it again). We each own the full scope of the success of what we’re working on. We prioritize the customer and the company, and we never say “that’s not my/our job”.
We recognize that writing is thinking and good writing scales well. The need to write is a feature of remote companies that we double down on because it forces us to think harder and think more clearly (see here for how we wield the Working Backwards Document). We also read a lot, and carefully, and fully and leave comments (both inline and broad comments) that help our teammates push further faster.
We default to clear written communication. When we work on our plans, we quickly identify what communications are required and we effectively educate internal and external stakeholders. Our writing is clear and concise. Our specs are easy to follow and we consistently work with our engineering partners to ensure they’re both coherent and complete.
In order to support the above, we need to do the reading (and hold others to that standard). That doesn’t mean we’re expected to read every WBD that the team produces, but if we’re attending a table read or if a teammate asks for our help, then we are expected to closely read.
Whether we’re investigating how a given Product process works or how another team within the company is structured, we’re expected to do the reading.
A lot of the work we do can be boiled down to repeatable, thoughtful and clear decision-making. A common failure mode for PMs is that we fall in love with our own ideas, or get defensive of our designs when challenged, or try to “explain away” issues others raise rather than treat comments and feedback as clues we run down without ego.
The standard that we hold ourselves to on this team is that we will skeptically evaluate our own thinking and remove the “who” that a given idea is associated with. One of the best levers for this is the WBD exercise -- we will write our pre-mortems and assess alternatives in good faith.
It’s not about your answer, but about the best answer we can think of as a group.
One of my favorite passages on this, from Larry Ellison on Bill Gates:
“It was the most interesting conversation I’ve ever had with Bill, and the most revealing. It was around eleven o’clock in the morning, and we were on the phone discussing some technical issue, I don’t remember what it was. Anyway, I didn’t agree with him on some point and I explained my reasoning. Bill says, ‘I’ll have to think about that, I’ll call you back.’ Then I get this call at four in the afternoon and it’s Bill continuing the conversation with ‘Yeah, I think you’re right about that, but what about A and B and C?’ I said ‘Bill, have you been thinking about this for the last five hours?’ He said, yes, he had, it was an important issue and he wanted to get it right. Now Bill wanted to continue the discussion and analyze the implications of it all. I was just stunned. He had taken the time and effort to think it all through and had decided I was right and he was wrong. Now, most people hate to admit they’re wrong, but it didn’t bother Bill one bit. All he cared about was what was right, not who was right. That’s what makes Bill very, very dangerous.”
There will be times when particular decisions can be supported by one or the other — but in our work, here, we are expected to stay in regular contact with customers and also stay on top of the metrics related to our initiative(s). On this team, we recognize that customer conversations in conjunction with relevant data are paramount.
When allocating resources, we think in probabilistic terms. We aren’t afraid to take big, high upside swings, but we also recognize and appreciate that small adjustments are important, as well. Like all portfolio managers, we must be extremely intellectually honest about the “expected value” of each item in our portfolio.
Fast
We are each accountable for surfacing customer problems to the team and ensuring we’re solving them with haste. Whether the problem is core to our ongoing initiative or it’s a customer that has reached out for help from a prior user research effort, we own the problem and treat it with urgency. We fully recognize that winning means doing this faster than anyone else.
We’re able to balance demands well and we’re expected to proactively raise our hands (as soon as you are aware) if we’re not able to deliver on a timeline or if being over capacity means we won’t be able to execute at the standard.
We expect and encourage debate on this team. Debate sharpens our thinking and, when wielded well, ensures we are holding ourselves accountable for solving our top customer problems as fast as possible.
If we’re not able to resolve the debate, that’s OK, but expect to be asked to disagree, and then commit. And “committing” doesn’t mean “following” the resolution. It means fully committing to an outcome. Our anti-consensus culture ensures that we make many decisions (small and large) much faster. That compounds over time and means we’re delivering on our promise of solving customer problems as fast as we can.
In order to get to the right answer the fastest, the standard is that we will be able to identify the hypotheses we hold that underpin our thinking and test them ahead of shipping our “fully baked” solution. Sometimes those initial hypotheses will hold, but sometimes they’ll be rejected – and that’s OK. What we expect is intellectual honesty in evaluating whether or not a) what we’re doing is working and b) it’s on the list of top customer problems we should be working on (great example being SuperNurse).
Whether it’s a new feature, an alteration to an existing flow or a decision on whether we should sunset an ongoing initiative, there should be customer conversations and/or data backing whether or not this is a change worth making.
💡An Aside on Speed
We talk about “speed” a lot here. The first explanation that comes to mind is “we’re a startup, speed is all we have, it’s existential.” That’s true. But in our context, speed is even more significant. For us, this cultural focus on speed will reinforce our advantage against rivals in the marketplace for filling shifts. As we’ve discussed before, every shift request is a race against other vendors and that’s why we will continue to push on faster enrollment, faster booking, faster pay and, most importantly, moving faster internally.
