Everything is Your Fault

Last week was perhaps the most intense at DelightChat so far (I’m sure that I’ll revise this statement every few weeks).

We now have a working engine of bringing interested customers to our website. Those customers are signing-up on their own, and booking a time for a demo call.

I’ve done about ~35 demo calls in the past 20 days, and some of them have already setup and started using DelightChat.

In startups, priorities keep changing. For the past 3 weeks, it was about bringing people through the door, giving them a 1:1 demo, and getting them to setup the app if they decided to proceed.

Last week, that priority shifted to making sure that every brand that’s signed up is successful.

Here’s what happened in week 1 of attempting that.

Hidden complexities emerge with real users

Our app went down in production multiple times. We didn't manage to move fast and respond to customer inputs, or ship enough improvements to the app.

Every nook and corner of your product that you didn’t even think could break, will break when real users use them chaotically. Tiny edge cases and features that you hadn’t put in your roadmap will suddenly become important, sometimes urgent, in your product roadmap.

Everything that can go wrong, will go wrong. And they sure did last week at DelightChat.

If bugs emerge, or you identify missing functionality that’s actually super important to your users, you need the ability to move fast.

We tried moving fast last week, and everything broke.

Sometimes we caught it before a customer, and sometimes it was when they messaged us.

Trying to move fast can result in not moving at all

We shipped a sum total of 2 features last week. One was already in the works since the previous week, the other was a small update.

This was enough to tell Sankalp and I that something is broken.

Our existing processes and the way we worked was fine while we were building in isolation, i.e. before real world users came into the mix and Murphy’s Law went into full effect.

I think we have reached a stage in our company where how we have been working so far won't work for the next stage.

To reach the next stage, we must adapt and evolve.

To do that, we have to own all problems and systematically approach solving them one by one.

What does extreme ownership mean?

As a manager or founder, under the framework of extreme ownership, whenever anything breaks, whether it’s a feature or a process, it’s by default our fault.

This simple idea - everything is your fault - gives anyone the power to change what's broken and drive progress.

Should it always be our fault?

No. The entire team needs to step up and join in on this mission.

But how do we show them how to step up, to adopt extreme ownership?

Simple.

We have to lead by example.

So here’s us leading.

Everything is our fault.

This is not a blame. Extreme ownership means to understand we have full power over any situation to fix it.

To start fixing a situation, it’s necessary to identify the real reason for the problem to exist in the first place. Without identifying that, any fix you apply will work like a band aid. A temporary fix of the symptoms.

To solve the real reason for a problem, we have to analyse and identify its root cause.

Root cause analysis
Whenever anything happens, our focus is always on the outcome and the immediate things that happened before the outcome.

Root cause analysis requires you to zoom out far enough to catch the trail of actions, the inputs that resulted in the final outcome.

Example 1:

• Problem - We couldn’t ship new features that customers requested fast enough.
• Because the person was unable to understand what the existing code did.
• Because the previously written code wasn’t elegant (self-explanatory) or had comments (sometimes code is messy) explaining what was happening.
• Because we hadn’t set a strong standard for what high-quality code should look like.
• Because we didn’t review the code well enough before merging it, thereby allowing this to happen in the first place.
• Because we didn’t have a set of values/guidelines for the process of reviewing code, which would have caught such problems when it first happened.
• Solution - Update our pull request approval process. If a piece of code isn’t elegant or has comments, it won’t be merged to our app. This way, everyone who is a contributor has to buckle up and follow a quality standard.

Example 2:

• Problem - The app broke due to one missing ‘?’ that resulted in a null point exception, thereby breaking the app for a customer in production.
• Because the person who wrote the code wasn’t thorough with their written code.
• Because the person who reviewed the code missed a tiny case like this and also didn’t read every line before approving the pull request.
• Solution - The person pushing the code needs to go through a checklist before submitting a PR. This checklist will isolate out all common and silly mistakes. The person reviewing and merging the code needs to go through the same checklist and read every line of new code.

When you identify the root cause, usually the solution just presents itself.

The power of processes

It’s ample clear from the above examples that we are encountering problems due to broken processes. These processes were broken earlier too, but under the stress of real world users and trying to move fast, the cracks emerged.

Processes are created to ensure that any work is performed the way it ideally should be, or that the work meets a certain level of quality. Good processes when followed rigorously eliminate the root cause of a problem occurring in the first place.

And that’s what we are attempting next, to set up good processes. Not only for the cases explained above, but for everything else where we want to deliver predictable quality.

It’s going to be difficult for everyone to always remember to do everything. By codifying how we work in clear checklists, process docs or words, we ensure that everyone (including ourselves) does things the right away.

How do you take extreme ownership?

Of course, things might still continue to break. It’s impossible to just isolate 5 things, fix them and say, “ha now we are perfect”.

When someone applies extreme ownership in their lives, their inherent approach whenever faced with an undesirable outcome will be:

• It’s my fault.
• What was the root cause due to which the problem occurred?
• How should I create/revise our processes to eliminate the root cause of the problem?

By writing this blog post and following these values while building DelightChat, I hope we can imbibe this quality into every tribe member.

Together, we will become better ✌️

--

Originally posted here