Founder Mode (Part 1)

Paul Graham (the co-founder of Y-Combinator) recently published a piece called “Founder Mode”. It refers to a talk that Brian Chesky (the CEO and founder of Airbnb) gave at a recent Y-Combinator event and in which he reflects on what he has been told about running a larger company, how that advice has backfired on him and what he has chosen as his MO instead (there is no recording of the event but you can listen to this podcast in which Chesky talks about how he runs Airbnb).

According to the NYT, the talk of Chesky and the commentary of Graham have created quite a ruckus in Silicon Valley. The vibe reminds me a bit of the more positive reactions after Elon Musk took over Twitter and fired 80% of the staff. Regardless of that, their thoughts are relevant, so let me try to break the substance down for you.

Graham’s starting point is that there is a ”founder mode” and – in contrast – a “manager mode” to run a company and he is very outspoken against the latter.

The essence of manager mode is to “hire good people and give them room to do their jobs”. I’m sure you’ve heard this one before. According to Graham, the practical application of this concept is quite extreme though, with founders being commonly advised to only talk to their direct reports (no skip-level communication) and even in these interactions to not “get involved in the details of what …(the direct reports) do”. So very hands-off indeed.

The full shape of founder mode is still in development. Besides Chesky’s example, Steve Jobs’s way of running Apple is the main source of inspiration at this point. Even so, it seems clear that at its core it is the opposite of manager mode: founders remain very much involved in all aspects of operations, up to the point where, like Chesky, they “review everything”.

There is more to the way that Brian Chesky runs Airbnb and there are a couple of additional relevant aspects in Graham’s text and we’ll get to that. However, the degree of direct operational involvement is the key distinction between founder and manager mode. That said, I would like to change these labels. They draw the line between career stereotypes rather than between leadership principles and this muddies the clarity of the concepts behind them. So in the following, I will refer to manager mode as hands-off mode and founder mode as hands-on mode.

With that out of the way let’s dive into the genesis:

You grow your organization. On the way you pick up professionals, people who have already worked in positions of responsibility elsewhere (and who know that they will probably continue their career at another company later on), and you have created one or more layers of management between the individual contributors and yourself. So far, you’ve always been hands-on, being involved in all relevant aspects of operations and in direct exchange with the people in product and tech. Since this has worked up until here, you stick to it. But this puts your new management layers in a tough spot: What is their role? How can they be of importance? How can they exert control? How can they prove achievement? Not all of these are intelligent questions. But they are all human. Structure and hierarchy control the flow of information. Just by having a POSITION a manager can be on top of everything that happens. By sticking to your “old” behaviour you make things complicated. Your managers now need to chase information and they don’t always know why their people are doing stuff and whether it’s right (and approved) to do it. And it’s hard to find out because they cannot always come back running to you, for that would make them look weak and untrusting … and also it would annoy you (yes, it would!). They have to rely on the delivery of your message by members of their team in a game of telephone. What’s even worse: You’ve made it difficult for them to prove that they create value because when you work with the individual contributors directly there is very little room left for them to generate some. 

And so you experience pushback. Often aided by agile or product organization arguments, according to which the team is the entity that solves problems – meaning that you should not participate in the solution finding.

Sounds familiar?

 

I’ve been there.

In 2011 I became Co-CEO of idealo. I was hired by the founders and I worked with one of them as Co-CEO for more than 11 years. In late 2012 I took over the responsibility for the tech organisation. Back then we did not have product people – the MO was that the CEO spoke to one or two developers and got things into the world. There were a lot of private code gardens and we released twice a year. I realized that we needed a better structure. So I adopted agile as a framework and started to hire product managers. And inevitably, I started to experience micro-management-push-back. Some product managers told me to not talk to their teams anymore for I would push them too strongly and they were too afraid to discuss things with me. It was the sort of agile-thinking-ad-absurdum where people argue that the deep product experience of the founders was in the way of the team’s learning path and therefore of the success of the company.  We worked it out. But it took some time.

 

So what should you do? Should you give in to manager mode?

Certainly not because a framework dictates it or because it’s “the right way to do things”. That would mean confusing the means with the end. Organizations do not exist to become perfect models of working frameworks. They exist to produce products and services that are of value to their customers and, ultimately, to make money. A specific way of organizing the work is just a tool to get them there. There simply can be no a priori reason to become hands-off.

But – and this is a big but – this is true both ways. Hands-off is not better but it’s also not worse than hands-on out of principle. Not all of the pushback you may have received is without merit and “hiring good people and letting them do their work” is not wrong per se.

So, let’s dig a bit deeper. Graham claims that hands-on is more efficient. But I don’t think that is the case because it a better way to run a company, but because of how Chesky and Jobs have organised work around principles:

If you listen to the podcast, it becomes clear that Brian Chesky is a very focused guy (with a very good instinct for product).

-               He is totally committed to understanding and solving customer problems.

-               He made Airbnb have one roadmap for the whole company with very few things on it.

-               He has ensured a high degree of alignment and cohesion among the people who do the most important work.

-               He has everyone working towards joint deadlines.

-               He continuously pushes for a high sense of quality.

 

Steve Jobs was – from all we know – an incredibly focused guy (with a very good instinct for product).

-               He was totally committed to solving customer problems.

-               Apple by nature of its hardware/software business certainly had joint roadmaps for most of the company …

- and had to have everyone working towards (release) deadlines.

-               Jobs organized regular gatherings of the people who do the most important work to ensure alignment.

-               And he pushed for a high sense of quality.

 

It is these shared principles that create efficiency. Notably, none of these require hands-on mode. You can achieve them either way:

 In hands-on mode you do it by involving yourself in all important aspects of work and by being the ultimate quality control gateway for all that is being built.

In hands-off mode you do it by aligning deeply with your reports (and by requiring them to do the same with their reports), by having and enforcing strong processes for alignment and prioritization, by demonstrating and demanding a strong work ethic and by actively fostering a culture of quality and delivery.

 If you think that hands-off mode sounds difficult, you are right. It is. Maybe more difficult than hands-on mode. Finding the right people is hard and you are far from done when you’ve hired them. So is letting them do their jobs. Doing hands-off well requires that you continuously make sure that others are carrying out the work at least as well as you would. Deep alignment is the key to this. You and your reports must be on the same page, not only about the what but very much about the details of the how. And it must be clear when and under which circumstances you need to be informed or involved. Without such deep alignment hands-off is nothing more than a game of chance.

Personally, I believe it’s worth the effort. Because it creates a more robust and ultimately more capable system. Because it provides better grounds for people to grow. And because you can only do so much yourself without overextending and becoming a bottleneck. And so, while I don’t think you have to transition towards hands-off, I would recommend it. But transition is an important word here. This is not done by somehow switching to another “mode”. It’s a development in which you have to make sure that you are ready for every step and that the people you put in charge are ready for every step. And going about it step by step is fine. So is stopping, probing and reconsidering.

What you need to ensure during this journey at all times though, is that your company

-               is committed to serving the customer,

-               is very focused on delivering the big items,

-               has a high degree of alignment and cohesion,

-               and demands clear accountability for any activities it engages in.

The rest will follow. 

 

Another important aspect of “Founder Mode” is that both Jobs and Chesky have “meritocratic gatherings”. Though both go about it in different ways, this is a very interesting concept (if not without challenges) and it raises the question of whether you should organize your company as a meritocracy rather than a hierarchy. I’ll talk about this in Part 2 of this series.

Previous
Previous

Founder Mode (Part 2)

Next
Next

The value of Output vs Outcome when choosing KPIs