Peter Bordes

From Startup to Scaling Up and the critical transition from Founder to CEO

An overlooked key to growth: How well you transition from Founder to CEO determines how your company scales

A critical aspect of a startup's growth that is often overlooked, or not set as a component of a roadmap, is how well you transition from Founder to CEO. Which determines how your company scales.

Seed-stage Founders do everything. You have to early on. But when your startup starts to grow you can’t, "and shouldn’t", keep doing it all yourself.

That transition from startup to starting up is the biggest failure point in becoming a scalable organization, and then an enterprise. It is mission-critical to prepare ahead to empower the organization by wearing fewer hats, implementing measurable objectives, and holding each team member accountable for hitting their MBO's.

This is a fantastic podcast and read from NFX Ventures that talks about all the things you don't learn in school, only in the trenches, and the systems Founder CEOs use to transition into a high-growth organization.

This essay is adapted from the NFX Podcast: The Strategies of Elite CEOs, with Avishai Abrahami. Listen to the full podcast.

The transition from Founder to CEO is a watershed moment in your company, and in your life. A great Founder creates something from nothing. A great CEO takes the next step, and builds mechanisms of success. They turn that vision into a well-functioning machine.

NFX General Partner Gigi Levy-Weiss reveals how to get there, with special guest Avishai Abrahami, the founder of Wix. Avishai built Wix into a company of about 5,000 people, with 1.4 billion in revenue.

An overlooked key to growth: How well you transition from Founder to CEO determines how your company scales.

Seed-stage Founders have a hand in everything: marketing, hiring, product, sales, everything. You have to early on.  But when your startup starts to grow you can’t – and shouldn’t – keep doing it all yourself. Once you reach 30-50 people, your goal should be to build a team and mechanisms that will do “everything” so that you, the CEO, can focus on leading and managing.

The deceptively simple secret: Elite CEOs build systems.

A few years ago I wrote an essay about what makes a strong startup CEO. Now, together with Avishai Abrahami, the founder and CEO of Wix, we deconstruct how strong CEOs also design strong systems — for hiring, product, speed, measurement, and even systems for failure.

Wix was founded in 2007 and has grown into a company with $1.4B in revenues and 5k+ employees. (Notably, Wix’s own project management tool was even spun out to become Monday.com).

This is how you set the stage for billion-dollar scale.

Hiring Systems

Before we dive into systems, let’s get this out of the way. Don’t worry about spending too much time on hiring. Take the time you need to surround yourself with the right people.

For example, Avishai hired 22 people before he settled on his CMO:

I cycled for 22 people before I found Omer Shai, my CMO. I hired and moved people to different things. I fired people. It was around 22 people that they hired within about a year and a half…When I got to Omer after a few weeks, it was obvious he was on a different level.

The takeaway: Avishai wasn’t afraid to try people out. He moved people around, he fired some people, he hired people in junior positions to see if they might grow into the role. And he took his time.

That said, eventually, it will become impossible to review each hire yourself. At that stage, you have to build a mechanism to look at candidates early:

1. Testing

You can’t tell who is going to be a “super talent” in an interview. That’s why Avishai tests every candidate before they join Wix. I’ve also done this at my companies: I like to give candidates “missions” to accomplish and present as part of the hiring process.

Here’s how Avishai “tests” incoming HR candidates, for example:

We test everyone in HR by letting them interview people who already work at Wix, who we know. That way, we see how well they evaluate somebody that we already know based on an interview. By doing that we’ve created a test that allows us to know how good somebody is.

Lots of Founders push back on this, or worry they will scare away good talent. Don’t worry. It says a lot about a person if they’re willing to demonstrate their skills.

2. Titles Don’t Matter

Wix lets employees set their own job titles. Job titles don’t change salary, roles or responsibilities. I don’t see many companies do this, but I’ve done it many times before and it works well.

This also allows Wix to hire people in junior roles and see if they might be a good fit for more senior positions. That allows you to wait, see who performs the best, and give them that role later on.

3. Fix Mistakes Quickly

When you recruit someone and they’re just okay after a few months, there are two schools of thought: give them a few more months to improve or fix the situation now.

Avishai believes in fixing mistakes quickly, because every hire affects the DNA of the organization. He put it this way:

My philosophy on this is that A players hire A players A+ players hire A+ players. B players hire C players. C players hire D players and D players hire F players, right? And so if you are not on top of that, and you don’t make super talents the majority, especially the managers in the team, you’ll end up with a really bad organization.

4. The “Types” of Talent to Hire

As your company grows, you’ll need people with different types of expertise to work on certain projects. There’s no “one type” of person that will work in every context.

For example, Wix is expanding into building websites for enterprise customers. This type of project requires people with experience with enterprise thinking.

In areas like marketing and product Avishai says tends to skew toward talent over experience:

In marketing and product I prefer people with less experience and a lot of talent so we can teach them how we do things. They don’t have to unlearn anything about how they already work. We teach them how we work. For developers it might be different because it takes a lot of time to be a really good developer, and it’s relatively easy moving from one environment to another…

Talent over experience tends to work well in roles where you already have a solid, effective approach.

Measurement Systems

Most Founders are good at measuring core KPIs, and bad at measuring support tasks. Here’s how we suggest you approach measurement:

1. If you can’t measure it, it didn’t happen.

You are almost certainly not measuring enough. You can’t get an accurate picture of your business from just 5 or so core KPIs.

When I was building my companies, I used to review metrics for about 15-20 minutes each morning. Avishai says his metrics tend to span more than 20 pages.

His policy: “If you can’t measure it, it didn’t happen.”

We measure everything. You can’t take pride in something that is unmeasurable. If you do marketing and you can’t measure an improvement, then it’s worth nothing. It didn’t happen from our perspective. It’s fine if you do things and it didn’t have the effect you wanted.

It’s important to point out that it’s fine if things don’t work. Some failure is good (more on this later). Don’t let fear of failure keep you from getting the full picture.

Here are just a few of concepts behind the data points Wix measures every day:

• Conversion (on dollars, not percentage-based conversion)
• Where people come from (what countries, keywords, etc)
• Conversion on landing pages
• Ads that work
• Conversion from each one of those ads to the product
• What people tried to do on-site
• What they actually did
• What they used in order to do that task
• Correlation of success between what customers tried to do and what they actually did
• What templates they choose
• When did they churn
• Why did they buy
• What support questions do people ask
• How much people complete on each website during each interaction

Measuring everything allows you to see what works for your customer and how you can scale it.

2. Share Measurements Widely

If you’re going to measure all these things, make sure you share them. Widely.

As a company grows, there’s some temptation to try to hide the full picture, or make things seem better than they are. But that leads to problems, and will kill innovation before it starts.

Wix shares all their metrics, all the time. Here’s why:

If you’re starting to build a company and you’re making sure you bring in great talent, if you give that talent all the information they need, great things will happen. Even without you doing anything. My belief is: share information as much as you can. All the sales, all the KPIs, what users did, what they didn’t do, all the issues in support…I would send reports to the level that people would just always come back and tell me: this is too much, we need to reduce it. And I would say, just don’t read it. I don’t mind. But I want it to be available all the time.

3. Differentiate between Good Failure and Bad Failure

When you start sharing data widely, it creates a good problem: everyone sees where the failures are.

People are often afraid to see failure. But you can change this perspective by distinguishing between good failures and bad failures.

Good failures happen when an underlying assumption is wrong. Sometimes you execute something well and it just doesn’t work. That’s okay. Now you know not to repeat this experiment.

A key thing to remember as a CEO: you must own the good failures. Avishai points out that this helps create an environment where it’s safe to fail while pursuing new ideas. That’s a good thing.

I would be the first guy to say: ‘it’s my project. I approved it, I wanted it.’ That has to be part of the language of the company. There’s no forum where we look at everything somebody did and say well you did this and it didn’t work. All those tests happen in the background for the organization as part of the day-to-day activity. So by doing that, I think we’ve created much more freedom for people to fail.

On the flipside, bad failure happens when a project is executed poorly. It’s bad because you can’t evaluate the underlying idea if the execution is lacking.

That kind of failure can reflect individual performance.

Speed Systems

In theory, as companies grow they get slower. Avishai identified two reasons that companies get slower.

The first is a lack of urgency. By that he means that an individual employee begins to feel like they have no effect on the company’s trajectory:

A lack of urgency means if you work at Microsoft, you don’t feel Microsoft will be affected by what you do. It might matter to you, to your career, or to your boss, but it’s not going to influence Microsoft’s bottom line.

You overcome this by connecting employees to customers. It’s a way to prove that what you do matters to someone. That’s key to maintaining motivation.

The second reason companies slow down is because of complex decision making. Avishai has put a few Systems in place to simplify the approval process:

1. Every project has a clear owner

Overly long chains of command kill speed. Avishai simplified the chain of command, even as Wix was growing, by creating a sub-company structure.

Each “sub-company” within Wix has a trusted chairman and CEO that can approve projects without sending them up the chain of command.

2. No waiting in line for resources

Having too many ideas and too few resources to execute is a good thing. But there are ways to make sure that those resources are well-distributed throughout teams.

Your team should not have to depend on someone else to get what they need.

For example: If you need UX, or if you need someone to write content and you’re waiting in line things slow down. Wix cut down on wait time by giving each team their own resources (UX, content, etc).

As Avishai put it: There’s no team at Wix that is waiting on someone else to give them resources.

3. Write scalable code or refactor when you need to

How you write code early makes a big difference.

As Avishai experienced with Wix: When you just have two or three services, you can just write them from scratch and that’s okay. But when you grow to a thousand services, you won’t be able to write each from scratch.

His advice: If you’re good technically, you should [write scalable code] from day 1. If not you’re going to have to do some refactoring.

4. Kill useless meetings

As your company grows so will the number of meetings on the calendar. This is toxic. People will wait to pitch ideas in meetings, or end up with meetings with no action items at the end of the day.

Avishai’s advice: Any meeting that doesn’t result in a list of action items is a waste of time. Your goal should be to have about one meeting per day (unless you’re in upper management, where you’re meeting with teams is part of your job description)

5. Redistribute responsibilities within projects to cut down on meetings.

Sometimes, shifting who is responsible for what aspect of a project will naturally decrease back-and-forth.

At Wix, Avishai shifted the responsibility for certain projects from product people to developers. He found that it hugely reduced the number of meetings on those teams:

In most project management, you have a product guy who writes the specs and another guy who will work with the technical team. We found it was way better to say that the owner of the project, the product part, is the developer. He can go to the product guy for clarification – not the other way around. That made a massive reduction in meetings, because the engineers aren’t depending on talking to anybody to do what they want. If they understand it, they’ll do it.

Leading as a CEO

There’s a common distinction made between leaders and managers. The idea is that great leaders (like Founders) tell you where you need to go, even if you don’t want to go there. Managers create operational systems to get you where you want to go.

Avishai has a different take on this common dichotomy. You can’t be a great leader unless you understand the details the way a manager does. Here’s his take:

You can’t inspire people by giving a talk. It only works in a movie. In reality, if you want to talk about project management, build a CRM, build a website –– it’s about the person who leads that product. You have to be excited about the details. They’re going to see that you’re excited about what they do, which is the details. I think you cannot be a leader without knowing a huge amount of the details of why you’re doing what and what it’s like working with the team.

You transition from Founder to CEO by understanding your business, and building Systems that will scale faster than you can as an individual.

You become a great leader by tapping back into what made you a great founder. Use those new Systems to drive your company toward your vision.

---

by Peter Bordes