Part II: A Proposal for an Intuition Building Machine

Part I explains why an organization focused on principles outperforms a rules-based one. Rules stifle judgment, while intuition enables better decision-making. Yet, that’s easier said than done! Creating rules is simple; designing a system that improves our intuition is far more challenging. Part II explores how to tackle this problem, written for the Wefunder team.

First, Yes, Some Rules are Required

I don’t want to overstate the case: rules are required, but we aim to keep them to a select few. Every rule we create sends a message—it implies we don’t trust someone’s judgment¹ or value their freedom to act. That’s a tall order.

Before creating a rule, ask these questions:

• How frequent and costly is the problem? Weight it against the trade-offs and unintended consequences. We don’t want to override the judgement of our team for a problem that happens rarely - unless it could bankrupt us.

• Will the rule work in practice? Here’s the paradox: you’re creating a rule because you don’t trust the team’s judgment. Yet, if that’s the case, you must also assume the stupidest person will be the one to apply the rule. Especially for subjective problems, it’s often better to directly fix why there is a lack of trust.

• Can we automate it in code? If the rule is objective, then automating it can reduce the cognitive load on team members. But be careful: the straightjacket may create a Kafkaesque experience for our team or customers.²

• Who has the authority to break the rule? Every rule can be broken if circumstances warrant: we never want our team to mindlessly apply rules that don’t make sense. If exceptions are frequent, rethink or discard the rule.

• Does the rule address the root cause? Most rules tackle symptoms rather than the underlying problem (i.e., the principle). Dig deeper. Go down the rabbit hole. If you’re addressing symptoms, you could justify countless rules. When rules are created to address symptoms, the rule is arbitrary - perhaps hundreds of equally important rules could have been created, but this was the issue that happened this week. Why is this one more necessary?

That last point—addressing the root cause—is key. Rules that don’t solve the core issue often create more problems than they fix.

So how do we tackle root causes? More context and better intuition.

A proposal for an intuition-building machine

Ok, so you’ve decided not to create a rule! But you were tempted! How can we best help the rest of the team handle this issue better in the future?

The easy answer would be to slot it in the next training session. Once a quarter we’ll all trudge into a room, we’ll all sit there, and you’ll tell everyone.

I don’t think that actually solves the problem.

Instead, we should design for our culture and the talent we aim to recruit. If we continue to hire right, our team will demand personal agency - they are self-directed learners, driven to succeed and grow, who want ownership of their own “curriculum”.

We should also have living system that can rapidly evolve and improve each week. We learn best from each other as we do the work.

Here is the system I propose. Because I’m a little strange and find such things ironic and amusing, I’ve created my own bureaucratic jargon.

• “Lesson” : Whenever you learn something important, write it up. Keep it as concise as possible; a paragraph can do.

• “Corpus” : Each role has a Corpus of all the relevant Lessons. It must be able to be read front-to-back in under an hour.

• “Principle” : Each Corpus is organized into a set of no more than 10 Principles, serving as chapters. The Principles should be easily memorized.

• “Knowledge Drop” : An announcement when proposing to add a Lesson to the Corpus, meant to spark a discussion.

• “Corpus-Master” : Only the Corpus-Master can add or delete a Lesson to the Corpus.

• “The Culling” : Every so often, the Corpus-Master calls for a Culling, to cut back Lessons or re-organize Principles to keep the Corpus sharp and focused on what is most important. The entire team discusses and contributes to the culling.
  

This puts the responsibility on each team member to contribute to their living storehouse of knowledge³. We all collaborate together, in real-time. We all own it.

Realistically, we expect the team to remember the principles, but not memorize all the lessons. These are stored in the subconscious and re-enforced through lived experience. The lessons are simply there to help accelerate that process.

A hypothetical example

One day, our compliance team learns something new about a company fundraising on Wefunder. Their page implies that they have a signed contract with a venue that will host their shop, but what they actually have is a letter of intent. Our compliance team believes the founder had no intention of misleading investors. They used imprecise language.

How do we stop this from happening again? We could opt to create a new rule, something like: “If company claims to have contract that is important to their raise, though shalt ask to see contract”.

This fails my test to create a rule: One, it requires a well trained team member with good judgement to interpret the rule - an inexperienced team member will apply it stupidly (as nothing was done to build up their intuition). Two, anyone actually committing fraud can easily create a fake contract. But most importantly: this is a symptom of a broader root cause: thousands of equally important rules could be created if the underlying problem isn’t addressed.

So, instead of creating a rule, Bob creates a Lesson and Knowledge Drops it in Slack. The team discusses whether to include it in the Corpus. During the debate, someone points out that this best fits inside a Principle in the Account Manager corpus: “Educate founders that everything they say has to be objectively true”.

After Bob rewrites the lesson to fit better in that Principle, Corpus-Master Jill agrees to add the Lesson in that section of the Corpus.

Everyone who participated in the debate refined their intuition in real-time. Future hires can read the Corpus and store that lesson somewhere in their subconscious, ready to spring forth the next time a founder uses language that isn’t precise enough to be objectively true.

But…. what about legal rules!

A perceptive reader with a legal background will quickly notice a major challenge: our well-meaning regulators have created thousands of pages of rules that we are legally bound to follow. These laws are mandatory and cannot be ignored.

As a result, we must operate in two modes—one aligned with our internal principles and another that takes into account the regulatory ocean we swim in.

There is a wide cultural chasm between how a top-performing startup operates and - sadly - how our government and lawmaking has evolved over the last 50 years.

In Part III, I’ll talk about why this gap exists and how we handle it.

1. Sometimes the lack of trust isn’t the fault of the team member, but a flaw in how the organization is structured. For instance, Wefunder has a rule that a team member can’t discount our fees below a certain level. For legal reasons, we can’t pay a sales commission: our team is motivated to win a deal without any incentive to make sure we have a viable business. Other rules target similar “tragedy of the commons” scenarios.

2. I learned this lesson the hard way: in 2017, I hard-coded dozens of process and operations “rules” in code. I intended to force our operations team to do things the way I wanted. What actually happened is that I froze in time a process that became outdated within months, reducing the team’s ability to be flexible as they learned how to do things better.

3. Over time, it could be very cool to use AI to best search all this content to best help us!