The main learning I took away from growing from 20 to 250ish employees, 1 product to multi-product and 1 geo to multi-country:

As a startup, your speed of execution is a function of your simplicity. It's about your only advantage over the big players.

Adding employees, adding products, and adding new markets increase your complexity non-linearly. ie. Going to 1 product to 2 products doesn't increase complexity by 2x, it increases it by 4x.

Avoid this complexity if you can: it makes you slow, makes you hire middle management, and makes what could/should be simple decisions, multi-dimensional.

So the lesson: stay as simple as you can for as long as you can. If you can't stay simple, don't underestimate the exponential drag of complexity.

Hope that's helpful

We could write a whole book on this. If you're VC backed and aiming to grow the usual 10x-20x per year, you'll end up changing everything drastically all the time. You end up with a different company every 6-18 months. I've had 5 direct manager switches on the last 3 years. The more complex your business, the more painful these reorgs will be.

Scaling isn't usually about making numbers grow. It's about complexity. Complexity goes up exponentially with verticals you're in. Every product has its own user channels. You sell the same thing in Phillipines and you need to use Viber. You go to Colombia and you need to cater to some specific Colombian law. One vertical across different countries is hard enough.

Once you start hiring people, you need to keep them. Ideally a person manages 5-7 people, after which they stop being a manager and become an observer. More people mean more managers. How are you tracking public holidays across countries? How are you handling internal comms? Tax? Legally mandated hiring laws? How are you scaling HR for this?

If you mix B2B and B2C, these are usually completely different engines. B2B may focus on sales and demand gen, B2C would be marketing and branding/positioning. You double the headcount but halve the leader's focus.

Companies like Google scale because they keep to a few verticals e.g. search and ads. WhatsApp and YouTube had massive enviable exits with few staff because they didn't really bother figuring out the business model, they just scaled it up incomplete and unstable.

If I had a tip, I'd say don't do it unless the gains are also exponential or necessary. You're either building towards economy of scale (lower unit price), economy of scope (lower marketing cost), or innovation (speed of product). An additional product should play into one of the above.

Sometimes it is necessary, e.g. if you're Google and you can't get acquired, you have to build ads.

IMHO the number 1 threath to look out for is premature 'maturation'. The strenght of a small business is in agility and getting things done. As you grow there will be people urging you to become 'more professional' and introduce more process, management and a formalized approach. After all, the big succesfull companies work this way, and you want to be big an successful no?

Wrong! Allthis will achieve is an explosion in overhead, deffered responsibility and learning, and as you get mired down into the spiral of ever more CYA instead of agile GTD your top delivery performers will leave as an MBA cadre and their process drones take over leaving you wondering where it all went wrong.

This is the famous 'wall' business hits typically around the 50 headcount. Meanwhile truly successful scalers postponed 'growing up' as long as possible and even then some, keeping the startup mentality even when they hit 1000+ people and many product lines.

The hardest part from my perspective is keeping focus on the fact that you need actual, live customers to keep everything going.

I don't know about others, but I find myself increasingly putting tech aside and riding the ass of the sales teams at smaller tech companies. It's really hard to keep going on a roadmap when you have nothing to validate it against.

As you grow a company, it is very easy to get drawn into the politics of org charts, teams and policies. You do need some of this, but if you are adding middle management layer at 12 employees you might be on a non-ideal path.

Everything always seemed to fall into place automatically when things were going well with the customer pipeline. Pressure from actual, paying customers is the magic trick for a healthy company. Without this, you will invent fake non-problems to solve. This is where virtually all of the drama and bad technology choices come from in my experience.

Don’t promote people who don’t understand building systems. Everything is a system above 100 people, focus on scaling the things that matter below 100.

HR and Finance? Route it all through 1 person and outsource anything that takes significant time.

Tech? Give equity and significant targets to the CTO who should also be CPO until about 80-100 people. Fire them if they aren’t planners.

I was working for a fintech company that experienced a large growth (in the number of employees). The leadership team was keen to "grow fast" and on the surface it looked good: investors where happy, the company had a not so high yet but steady income (subscription-based) and each team seemed to have a purpose.

But in reality there were many issues: - there was a culture of launching "project/initiative" to justify more hires and promotions, rather than improving on the key issues we had (that nobody wanted to tackle). - People were often switching team after a promotion, for example leading a new team, and leaving their problems behind. - On the technical-side it was extremely tedious to contribute, we started with a monolith, then moved a micro-service architecture (with k8s, kafka etc). There was a push to do things properly, but it translated in over-engineering parts (for the cool stuff) while the valuable not-so-cool stuff was left to rot. At the end we had to maintain multiple things and the engineering effort to do all these migrations was huge, and took us away from doing more valuable work.

Eventually the company couldn't sustain its workforce and we had multiple round of layoffs.

My key learnings are: - Unless you are looking for a promotion before leaving (pump and dump), hiring a lot of people in a short amount of time is bad. - Even in best scenarios, having more employees make things harder and slower. People are competing for projects, there is a need for more communication, more processes, more tools. Having a lean workforce as long as possible, focusing on what's really important is best. - It's okay if we can't do everything we want. Not so many "ideas" are valuable and employees cost - Before hiring for a new project, can't we move other resources? Is this project really important or just a distraction?

As a Chief Revenue Officer I've scaled two companies now - one from $3M and 5 FTE's to $6.5M and 12 FTEs, the other being from 70 FTEs and $70M in revenue to 1400 FTEs and $2B in revenue. Both were hard, but the hyperscale of the second example was insane. The effort was in scaling hiring and trying to get the best people possible and also not letting the processes and systems break that we built to handle that scaling. I tell people all the time, compressing your pipeline and expanding throughput of it at the same time is the where the things break and at highest risk. Intense doesn't really describe the effort accurately. During this timeline (12 months or so from 70 FTE to 1400 FTE) I didn't sleep much, worked 12-15 hour days, and strained my family and relationships. It was also super fun and a blast.

Now I'm doing my own thing, started a newsletter, and being calm and balanced for a while. https://www.aletterfor.com/ Scaling a personal project is very rewarding as well.

The bureaucracy must expand in order to support the expanding bureaucracy.

The biggest failure with scale I have seen in my own personal experience is fragmentation. The business knows they want to grow or diversify or whatever. They know what their desired end state is, and they kind of (at least they think they do) know what needs to happen to get there. This is wildly complicated with too many unknown unknowns so they backwards plan and short circuit until they reach their desired end state.

The end result is a bunch of teams each doing their own things in their own way and each with their own overhead. It is both expensive, high risk, and fragile. As developers we call this tech debt. If you think refactoring technology is hard then you are in for a real treat, because refactoring technology is child's play compared to refactoring people.

Of course the flip side to that is micro-management from the top. Yes, there is a centralized design, but nothing gets done because the micro-management gets stretched too thin to accommodate real world variability that comes with scaling in different directions.

I have never seen anybody solve for this in technology organizations as well as the Army. The Army has a vaguely new (15-20 years old) organizational philosophy called Mission Command. It is complicated, but the summary of it is execute to your leader's intent. The idea is that each subordinate leader knows what the boss wants and they own what constraints are imposed upon them. Just don't violate the constraints imposed upon you, but otherwise do whatever you think best to accomplish the boss's intent. The imposed constraints provide known limitations to prevent unintentional fragmentation but otherwise the subordinate leader is given maximum flexibility to move quickly and make decisions as operations dictate. Then once the initial boss's intentions are accomplished organizational refactoring occurs at lower cost.

From scaling a few companies, some with as little as 2, and ultimately hundreds...

Process changes and has to. Far too many people become entrenched with "but this is how we used to do it". Openness, and trust (but verify) is actually more important as you scale, as opposed to less. New people have new ideas, and at scale you can neither see, nor interact with the minutiae of every part of the business. Too many people stay too close to the ground, and lose sight of the big picture as a result.

I feel like I could write books about this.

Scaling a company, especially when adding a new product and growing the team, involves several challenges and priorities:

Maintaining Culture: As the team grows, it's vital to preserve the company culture and ensure new hires align with core values.

Team Communication: Scaling introduces complexity. Establishing clear communication channels and processes prevents silos and confusion.

Resource Allocation: Balancing resources between the existing product and the new one is critical. Avoid spreading the team too thin.

Hiring Strategically: Focus on hiring for key roles that complement existing strengths and address gaps. Avoid over-hiring prematurely.

Operational Scalability: Systems, workflows, and tools should handle growth. Invest in scalable infrastructure early.

Customer Focus: Ensure the existing product's users remain satisfied while diverting attention to the new product.

Challenges include managing growing pains, maintaining quality, and staying adaptable. In my experience, a clear roadmap, strong leadership, and a collaborative team make scaling smoother.

Like breaking up a monolithic app into microservices. The pain moves to communications. This cannot be solved by scaling HR. Avoid HR and recruitment people at all costs. Externally hire those if needed and drop them as soon as you can. These people too need to "set and achieve goals" which will grow more and more pointless each passing quarter.

I ran a bootstrapped firm that was about 15FTE at its peak before it sold. So growth, but not mega growth.

The problems I ran into was:

- Hiring experience from outside often led to the old "inside" team being disgruntled at having someone come in over them (who doesn't know our ecosystem that well)

- At certain points, I had to choose between taking profit out and taking a chance on an expensive outside hire (who would not necessarily be increasing revenue directly)

- OEM/Strategic deals (%20-40 of revenue) often took a _long_ time... (like 1-3 years). There was no good way to incentivize a sales rep on a sales cycle that is so long. (One of our deals took seven years from initial presentation to first dollar... but there were a lot of dollars once they started!) I never figured out how to grow a sales team for OEM deals.

So there are a few of my bits.

Main learning is to transition form 0-1 manual, rapid iteration to one to many, repeatable processes.

When you are still figuring our your product market fit and gtm motion, you can go deep on experimentation, knowing that you aren't being the most efficient. Your challenge is to solve a problem, not operationalize it. But when you start scaling inefficiencies cost dearly.

I worked a good amount of years in enterprise, and then one of my former colleagues hired me to help scale a company from startup to enterprise. He is a brilliant IT operations manager and I've now seen him build some of the most talented and successful IT operations teams in multiple organisations. Software development isn't his area of expertise though, but in non-tech enterprise software development usually falls under IT anyway. Long story semi-short, it sort of became my expertise.

The primary thing I've learned is that YAGNI is the best approach. One of the major hurdles I've seen in several organisations is that they've abstracted way too many things before they needed to do so. I don't blame them, here in Denmark, our various CS and SWE educations teach a lot of OOP and all the stuff which comes with it, which can basically be defined as Clean Code. I would like to point out that I don't think you can take a single principle form Clean Code, SOLID, DRY and so on and call it out as bad. I do think the overall philosophy is extremely flawed though. The way I see it is that Uncle Bob is absolutely correct when he dismisses everyone who fails as having misunderstood his principles. Unlike Uncle Bob I blame the principles and not the people who get them wrong, because so many people get them wrong. Anyway, I've seen people get stuck in abstraction hell to the point they couldn't deliver anything for their business on any reasonable time scale in virtually every organisation that have applied these things. Now, I do work with non-SWE and as such I can't tell you if these things work in places where 600 people work with software development. I can tell you that I have never seen them work in companies with 10-50 people in IT out of which around half are usually involved with software development.

I also see things like scaling issues rather different than a lot of people in our industry. To me running into scaling issues is a good thing. It means you've made it. Now this is a number that I'm pulling out of thin air, but I would wager that 95% of all software build here in Denmark never run into any sort of scaling issues. I also think a good amount of that software will never really need to be changed much once it's build. I think that you could build them on any tech stack with the worst cowboy code ever and be fine perfectly fine. I don't recommend doing it, but I also don't think you should focus much on how you engineer it since that won't matter until you've made it. To me it's better to rush ahead and get something working with Django, R&R, Node or whatever technology gets things out the door. I personally favor Go right now, but I do think Python will be easier for a lot of places. Then you can always re-engineer parts of it once you run into scaling issues, which you only will if you can continue to deliver for your business so that you don't become the obstacle. This is by far the hardest part of what I do. Teaching developers who are used to building things for how they think they will need to be in the future goes against what so many of them see as natural. Once they get on board though, and see how it means that they can deliver faster and focus their engineering efforts on bottlenecks as they arrive, I don't think many of them are going back. I don't go in expecting to rewrite all their existing code to remove abstractions. We typically do over time, usually be replacing bad parts with new parts when it makes sense. Sometimes it's faster for them to write a complete replacement from scratch than to refactor or rewrite, sometimes things can live for their lifecycle. The important thing is to get their ability to deliver value for the business in check so that this becomes a priority over software engineering. If you're thinking this will cost them down the line you're correct, but the thing is that by then they have more engineers and more resources to fix it. In most cases these companies will stagnate horrible if they don't change their focus, this is why they want people like me to begin with.

Another big challenge is usually ReBAC and automation of access control. This is somewhat contrary to what I've said before an area where I struggle to see why people don't engineer it into their architecture from the beginning. Since this is an area where you can't legally go very far with various hacks. It's also something which is frankly easy to do here in Microsoft land where everyone uses AD and EntraID anyway.

Spawn another tribe. Make a similar size. Grant them power. Low down the unnecessary management cost. Just copy Elon Musk did for X.

I am planning to do one.