The Importance of Celebration at Startups

About a year ago, when I was at my previous company where I held a bunch of roles from writing code, to selling, to customer success, & eventually leading the product organization (15 engineers & PMs),we got the engineering team to rate itself on multiple different categories.

On ownership & accountability, transparency, and effectiveness – the team gave itself between 8 & 9 points on a scale of 10. This was reassuring to me. Our lowest score was on celebration. The team rated itself a measly 4 out of 10 points.

At that time, I remember being confused why this was a bad thing. After all, this meant the team was aware that we have a mission ahead of us, and the job isn’t done, so why celebrate. The low score felt right in a strange way. I’d be pissed if the team felt we were celebrating a lot, because we had a lot to do, and accomplish.

But I was wrong, and I have since then thought more about this, and learnt some lessons which I now share.

Don “Wardaddy” Collier (played by Brad Pitt), & his team, take time to eat dinner in the middle of war, in Fury

Reality of a startup

There are some undeniable truths about startups. These aren’t laws of nature by any means, but they might as well be. That’s how prevalent they are.

You’re never growing fast enough

I have yet to meet someone who doesn’t subscribe to Paul Graham’s definition of a startup. It’s a business designed for growth (not sustenance), as defined by month over month revenue growth.

For an enterprise SaaS startup, at > $1MM ARR, you are expected to sustain a M/M growth rate of 10% (on the low side). The high side is defined by the likes of Slack & Zenefits which saw 30% M/M revenue growth for a year or more (after they hit $1M ARR). To put these numbers in context, at 10% M/M growth, you are tripling the business in a year, & at 30%, you are increasing revenue by 20x.

This level of growth is hard to sustain, if not statistically impossible. Yet, the DNA of an entrepreneurial team aspires to reach these numbers. You are always trying to find ways to grow faster.

We were sustaining mid teens in M/M growth from 7 figure base rates, but we were always trying to pull away. The next feature, the next speed improvement, the next performance improvement, the next widget we built would help us defy gravity.

We were shipping at a flattering pace, with multiple new product features (feature or performance related) going out in the product every week (sometimes every day) but it always felt like were too slow. There was no time to celebrate.

Something is always broken

Trying to sustain that level of growth automatically implies something is always broken. There were many nights where I was up with some of the team at 3 in the morning in New York, because our team in Australia was seeing slowness (FWIW, most common form of failure for growing companies). We fixed this fire, & at 6:30 or so, I’d go into work. We’d review the sales pipeline, & things were looking bleak because some deals evaporated. As I sat down to start work, I realized that there was a conflict about meeting rooms because they were overbooked. Open Zendesk, and there is a set of new issues, and often, we couldn’t afford to prioritize it. Open logentries & some error rate is spiking.

You get the idea. Something was always broken, and more importantly, we couldn’t fix most of it because it wasn’t important enough.Welcome to a startup. There was no time to celebrate when so much needs to be done, and so much is broken. Yes, the numbers went up but it rarely felt like it.

Every Startup has these problems

And before you think this is a problem for YOUR startup only, you’re wrong. Travis Kalanick of Uber has said that he is fearful that stress will kill him, Stewart Butterfield looks at his phone in the morning till he is physically sick of all the fires before he gets out of bed. I’ve since heard other leaders express this sentiment. The reality is that you are failing your way to success because you are pushing the boundaries, and this is independent of scale.

The Journey is never over (till its over)

When people say that startups are like a marathon, I disagree. A marathon ends but building a business is a never-ending race. All of SV aspires to be like Larry Page, or Zuck, or Elon Musk, and their companies are the work of their life. The reality is journey is never over. In fact, if you go into a startup thinking of exiting one day, you will likely never find enough courage to keep going.

So why celebrate? In an environment where everything is  broken all the time, and the journey is long, why celebrate? I think that is exactly why you need to celebrate,  because the journey is long & wins are hard to come by.

So why celebrate

Popular culture gives us mixed signals about celebration. The ethic of hard work & keeping your head down is the blue collar ethic. Celebration is considered opposite of this Celebration is perverse. e.g. athletes who celebrate excessively are flagged. And of course, we are told not to celebrate too early. And guess what, with startups, its always too early.

Importance of Celebration

Studies show (yes, based on my 30 minute Google Scholar lit survey) that celebration is important for human beings. Celebration gives us a sense of togetherness in a journey (e.g. birthdays, anniversaries). This creates creates favorable memories which we consume in times of hardship. With it, we build a sense of belonging, and a sense of orientation towards something we value. It gives us fulfillment, and in turn, gives us the courage to sustain the thing we celebrate & value.

In essence, it gives us the raw fuel to keep going in the face of adversity. And that’s what startups are all about. Overcoming adversity every single day, and celebration will not just make the journey easier, it will give you the courage to make the journey.

Some ways to celebrate

I’m definitely the wrong person for this type of advice but I’ve seen teams celebrate in some of the following ways

Celebrate (the right kind of) wins

We are surrounded by the drumbeat of media stories about all kinds of startups. Startups are getting hunt’d or crunch’d, and your startup is mostly never there. Even if you are, that’s not the right kind of win to celebrate IMO.

It is much more important to celebrate the unglamorous grunt work that goes into building the company. Celebrate outcomes that the external world will never talk about or see. Celebrate the hard fought wins in the trenches. This not only focusses the team on the right kind of wins, but it makes the team less vulnerable to externalities. It gives everyone a sense of agency.

Share Customer stories

All product teams know the list of things that are broken & requests is long. All product teams know that engagement & retention has room to grow. Surrounded by all of this, we sometimes forget that some people love the product. Share those stories with your team on a regular basis.

Bring customers to your office. Not only will they love meeting your team, they will give the team a shot of courage. This is especially important for engineers who rarely interact with customers.

Celebrate learning

Startups see a lot of failure. In fact, failure is a rite of passage for startups. If you wait for wins to celebrate, you likely won’t get many real chances.

Celebrate wins when you get them but more importantly, celebrate & share lessons. This will nourish your team when times are tough, and also create a culture where learning is considered to be valuable in its own right. Your team will be less traumatized by failure as well.

Create rituals

Rituals that teams share create a sense of normalcy in good times & bad times. Startups are a roller coaster, & you need to maintain a sense of normalcy even when the house is on fire. I encourage you to create rituals that your team shares every day. Eat lunch together every day, have a drink on Fridays, do a shot everytime you close a deal, send handwritten notes to your customers, create art collectively at the office once a month, design & wear T shirts & hoodies that reflect your culture. You get the point. Create rituals. Create a cult.

I wish I had learnt the importance of this a few years ago, & I think most startup leaders learn this too late. BUT, if you’re reading this, its never too late. Start celebrating because the journey is long. You will need to make time for it, but its worth it.

Design software to amplify working memory

Having just read Scarcity, I was reminded of how important working memory (or mental bandwidth) is for our productivity as professionals. I think this is an understated and, often differentiating, characteristic of great productivity software. In particular, software that requires us to make decisions benefits greatly from considering working memory as a design objective.

What is working memory?

Let me first define what I mean by working memory. According to wikipedia, working memory is the system that is responsible for the transient holding and processing of new and already stored information, an important process for reasoning, comprehension, learning and memory updating.

In easier to understand terms, working memory is the mental capacity we dedicate to a task we are working on, including processing the inputs, matching relevant patterns, reasoning about the task, making a decision, and acting on it.

Why is working memory important?

There are three reasons why I think working memory is, and will continue to be important for productivity software.

Decision making

For most of industrialized economy, our work was labor intensive. However, the characteristic trait of the information economy is ..well, information. This implies a lot of what we do is create artifacts based on decisions. Creation of artifacts is easy, thanks to software. As a result, most of our time is taken up in making decisions. Unlike labor intensive tasks, making decisions depends on how much working memory we have.

Influx of data

Data is pervasive. We are immersed in it. At surface, this makes decision making easier but that’s a trap. Almost always, the data that is most visible is the data that is easy to access, not the data that is most meaningful for decision making. It takes significant working memory to avoid getting distracted by easily available data, and doggedly pursue data that is meaningful.

Unintuitive phenomena

An intuitive decision is where you have a high degree of confidence in the outcomes of your action before you act. Where it isn’t obvious, instant feedback on actions helps form this intuition. That’s how we learn, and become good at things. However, there are many functions in an enterprise where this is simply not possible, especially when the feedback loop is long, and the most suitable agent is not making the decision (I call this decision distance elsewhere).

For example, hiring typically can take a few months from publishing a job spec to closing a candidate. The recruiter during this time, is making go & no-go decisions on hundreds of candidates, matching candidates to open positions, hiring managers are conducting dozens of interviews & grading candidates, before ultimately hiring a candidate. To make matters worse, the organization doesn’t know the final impact of their decisions till a year or more after the hire.

Similarly, closing a deal takes several weeks or months. It starts with the marketing team qualifying leads, sales reps talking to the prospect, doing demos, asking the right questions, talking to many people, furnishing collateral, etc. When a deal finally closes, hundreds of questions have been asked, many collaterals shared, and many small decisions made. The feedback loop is entirely absent. No, a sales playbook which relies on a human being (sales manager) for feature extraction, & is historic on arrival is not a meaningful enough feedback loop.

History of productivity software

The class of problems productivity software has solved involved reduction of effort & time. Ranging from accounting to writing documents to sending messages, software greatly reduced the effort & time required to carry out a task. Even today, software makers continue to optimize for productivity in the narrow sense of the word – the amount of time or effort taken to do X (e.g. marketing automation software).

However, as they reduced time,  software started providing instant feedback as well. Excel caught our errors in formulae, and Word pointed out our spelling errors. These features liberated our working memory. When writing a document, I didn’t need to worry about spelling errors because the application would catch them for me.

Software engineering took this a step further. One of the huge benefits of continuous integration environments is instantly learning the root cause of a regression or failure. This frees up working memory to fixing the problem, instead of finding the problem.

Designing for decision making

With the amount of data and the number of situations where decisions are not intuitive & the feedback long, we need to start designing software that maximizes available working memory, and in many cases, amplifies it. There are two specific tools that will continue to further this.

User experience

Product managers have a hard time justifying or measuring user experience. This is difficult to do because good user experience doesn’t necessarily “save time” or “allow me to do X things”. Good user experience maximizes working memory of the user. For enterprise software, this will become increasingly important. Far too much memory is wasted trying to get software to just “work”. Well designed software creates a state of zen for its users, and allows them to get on with their work. Software teams that consider design as a first class citizen will win, & teams that sleep on importance of designers will lose. Not only will teams without designers lose, the teams that value design will see its benefits and continue to pull away by doubling down on design. I’m convinced one of the primary reasons for Slack’s success is that it amplifies working memory of its users

Machine learning

Techniques of machine learning are very applicable to problems where feedback is not instant or intuitive. This includes nearly all business functions, but primarily sales, recruiting, & people management. Human beings are terrible at feature extraction in noisy situations as well as recall. Our brain isn’t designed to be good at this but machine learning helps. This results in poor decisions & frustration for the work force. Machine learning, when combined meaningfully with good user experience, machine learning will amplify human decision making exponentially.

In summary, I think product teams need to start thinking in terms of working memory as an objective because a significant amount of work we do involves making decisions, and decision making requires working memory.

Success as a collection of failures

tl;dr: Failure is bad but its also a rite of passage for building great products. We need to continue to frame it as such, and I discuss some ways to do this.

Wright flyer crash in 1908

Everybody wants to be successful. We want our products to succeed, we want them to be adopted, and we want them to improve people’s lives. However, the reality is that most of our initiatives will end in failure relative to our expectations, & even relative to some minimum threshold of external success.

For many of us who are wired for overachievement over years of schooling, university, and success in various past roles, there is some trepidation about failure. From quizzes, tests to performance reviews, we are reminded of our failures. Unsurprisingly, we are conditioned to see failure as inherently bad. In school or university, or in less uncertain circumstances, it was reasonable to frown upon failure. Failure at problems which were deductive in nature was a reflection of our competence.

Fast forward to a startup or a technology company, the framing of the problem is much different. No longer is the problem deductive, nor are the rules of the world in which we operate predictable. While there might be an answer waiting to be found, it will more likely be “discovered” after many attempts than arrived at in some deductive manner. This is why I think we need to constantly reframe failure by defining success as a collection of unique failures, where we learn something new from each failure.

Build to learn

As we solve problems in an unpredictable world, it becomes important to look at our initiatives as experiments that’ll teach us something new about the world. In the business sense, a successful experiment furthers our business goals. However, on the path to that success, a successful experiment teaches us something new about the world. These experiments can vary from very rigorous quantitative undertakings on one end to qualitative testing with users based on prototypes. Therefore, for every project or initiative, we must ask what we want to learn and what we learnt, in addition to whether we succeeded.

Encourage internal attribution of failure

Failure is generally stigmatized. As humans, we internalize it as a bad thing, and our external systems tend to penalize it as well (they definitely don’t reward it!). The unfortunate consequence of this is that we are reluctant to internally attribute failure. This is bad because studies have shown that this “ambiguity of responsibility” impairs our ability to learn.

Independent of whether our actions resulted in failure or whether external conditions were responsible, internal attribution results in better learning. Here again I think how we build our products (reviews, retrospectives) or our teams (1 on 1s, performance reviews) can go a long way in creating a safe environment for learning. Saying “My Bad” is more powerful than we think.

Derisk early

Inherent in an environment where most initiatives fail to achieve their desired goal, it becomes imperative to derisk early. The universal truth about derisking is that everything can be derisked as long as we are ready to reorganize how we work. In my experience, derisking also inspires creativity. This is why I think constraining resources or timelines becomes important, something that is admittedly difficult at a well funded businesses

So while I think failure is a bad thing but its also a rite of passage for building great products. As a technology company grows, this becomes vital for it to maintain its trajectory.