Startup Founders and teams often talk about how much fun it was during the early days, when everyone was on the same page and things moved quickly. Can the speed and simplicity of that early, perfect-startup moment be retained as companies grow?
Early days at Automattic
During those fun initial startup days, the team is usually around a dozen people in size. Most are at work on the first product, while a few generalists take care of early business needs tied to operations, systems, and customers.
When startups grow beyond that point, they encounter one or more of the following growing pains, which I’ve paired with solutions that can help mend flubbed operations and morale.
1. The myth of the flat organization.
Teams of around eight people are most efficient. Roles are clear, tasks are easy to track and communicate, and everyone feels in the loop and efficient. With good communication, teams can stretch to 14-16 people and still operate pretty well, though things start to get more frustrating. Tasks fall through the cracks. Everyone spends too much time keeping track of what everyone else is doing. There’s overlap in roles.
The breaking point usually occurs when the team reaches 20 people. Team members start to ask questions like, “So, are we going to have an org chart at some point?” Some team members want to stay flat and claim that things will suck and not be like a startup anymore if there are managers. Sometimes Founders even say this, which tends to prolong the misery.
First of all, it’s a myth that startups are flat or non-hierarchical. Someone is in charge – usually Founders, a CEO or a combo thereof. Everyone else is flat and getting frustrated about it. Failure to organize into smaller teams with team leads is an abdication of responsibility on the leader’s part.
The Solution: When you reach 12-14 product-focused team members, split into two product teams and continue splitting so that teams always trend toward the ideal size of eight. Invest in good team leadership, add one layer of management that is in charge of all the teams and makes sure they all work well together.
This makes everyone happy and efficient again and scales until you have upward of 30 teams, which is when you should think about the next layer of management. Another key is to avoid building silos and losing transparency when splitting into teams. Have as few meetings as possible and discuss as much as possible in open channels (Basecamp, Slack, etc.). Document all ideas and explain how and why priorities are chosen. Share financials and board slides. Argue over then agree upon KPIs, and track them openly.
2. The Founder/CEO conundrum.
The jobs of the Founder and CEO are two separate roles.
The job of the Founder is to be the product visionary. They articulate and constantly evangelize the vision and mission of their company, create and lead the product team, write specs, make tech and design decisions, and synthesize user feedback until product market fit is achieved.
The job of the CEO is to make the business run smoothly. They fundraise, find early customers and partners, set and communicate goals and strategy, track results, run business operations (HR, legal, finance), and coach and grow their leadership team.
Some entrepreneurs do both of these jobs in tandem very successfully during the early stages of a startup. Once a product is launched and the team exceeds 20 or so team members, it becomes more and more difficult to do it all. The Founder/CEO who tries exhausts themselves and frustrates their team. This is sometimes perceived as though the Founder has trouble letting go and trusting other people. Although, it runs deeper than that and happens to most first-time Founders.
The Solution: Realize that if your business is lucky enough to reach the point of employing a large team, every single part of your job will change. Your main role will increasingly be to find, coach and empower great people who can take over the various needs of your growing business. This will be your most important contribution. If done well, it will serve as a model for the entire organization.
3. The limitations of multiple-hat wearing.
During a startup’s first few years, most employees work on product development. The non-product roles are more self-contained and centralized, but they need to scale as well, and they do so in different ways. These are usually roles in systems, customer support, marketing, sales and operations.
For each, there is a breaking point where a single, more generalist person can no longer handle the task and it’s time to think about how to scale to multiple people. This is often painful because the generalist has grown to wear lots of hats, loves it and doesn’t want someone brought in “above” them. This could be a communications person whose role has grown to encompass marketing, advertising, PR and community management. Or, it could be a business person who is responsible for all partnerships, finance, HR and legal.
It’s really fun to handle that variety, but it gets to be too much at some point. That point is different for different roles. For example, somewhere between 30-50 employees, it’s time to have a dedicated HR person. Somewhere around $2-5 million in revenue, it’s time for a dedicated finance person, and so on.
The Solution: Anticipate these transition points, and manage them in a transparent way. Explain why it’s the right time to bring in specialists who are more senior and experienced at a particular job. The specialists, in turn, must recognize that they know less about the culture and inner workings of a particular startup than the early, many-hat-wearing employee and that they can learn a lot from each other. As mentioned above, these transitions are easier when the early Founders/leaders in a company have demonstrated how to navigate them for their own roles.
By recognizing the above challenges and managing through them at the right moment, a startup can get to hundreds and even thousands of employees while retaining the best parts of their early culture and the simplicity, transparency and agility that makes them so fun.
A version of this post was originally published on toni.org.