Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are your experiences with scaling a company?
70 points by surrTurr 43 days ago | hide | past | favorite | 38 comments
Let's say your company has 20 employees (markets, products, dev) and one stable product they offer. The plan is to introduce another new product and maybe add new members to the team.

What challenges are there? What's important? Do you have any experiences to share?




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


This is how I feel, and why I'm stuck.

I have a pleasant little workflow maintaining a content-based website. I'd like to hire help, but offloading work to a first employee feels like more effort than just doing the work myself.

How do I transmit 7 years of tacit knowledge, principles and best practices to someone else so that they do good work? How do I teach a writer to use my elaborate static site generator setup that was never designed for other users?

Then comes the paperwork, and the inherent difficulty of working with other people instead of having full control over everything.

So far, I have just accepted that my work has a limited scope, and that as long as I'm satisfied with my income I don't need to change that.


> that as long as I'm satisfied with my income I don't need to change that.

That is the key thing. I was a 1 person consulting/contracting shop for years and it 100% put limits on my income. But they were limits I was happy to accept.

If you are interested in trying to grow, I'd think of 1-2 tasks you can cleave off and hire someone to do part time. Have them be:

- not critical path

- async

- checklist oriented

You'd be surprised at the number of folks that would be willing to help you out. And you'd learn something about whether you feel comfortable outsourcing such tasks.


Break it down into manageable chunks. Do you have things documented?

I felt this way at first when I was doing my lead generation. I documented the process and brought on someone from the Philippines. I then ran into a similar situation where there were a lot of questions that I couldn't spend my time on. So, I built a GPT to help answer questions and to build another me to help them. This was simple and saved a ton of time.

Reflect on the tasks you are doing and pass off the work that you don't want to do first. Start small and continue passing off more work. You can hire a virtual assistant for $5-8 an hour, and it's beneficial to have some basic support. I also helped motivate someone who needed work.

It doesn't take much effort, let me know if you have questions on the tools and documents you would need to support something like this. I can share what I used.


Why are your best practices better than whoever you'll hire's?

Just accept another person to be an adult, and help you in increasingly good ways and communicate well. Or fire them if they don't


You will be suprised how quickly people learn and delegation is a forcing function to make things simpler. If they are good they will help you figure out how to make things simpler.


Well, at some point in your personal and professional life, you need to learn to let go, hand over, or pass on your responsibilities to the next person so that you can take on bigger, more critical challenges. Yes, it will take time, and no, they won't be your copycats, but you never know—they will make things easier for you and even better for your business.


Thank you for this!

Do you think multi-country adds so much complexity that you shouldn't explore it too early?

E.g. What if you have an incredible opportunity in another geo? Should you put it on ice? How long for?


As with most things - it depends. Hard to give you a clear cut answer without knowing a lot more.

For us, multi-country added a lot of complexities because we expanded from the UK to Australia. So we needed to staff and integrate different teams (which is where most of the complexity was).

If you're a pure SaaS with no sales GTM, I think it would be a lot simpler if you can stay centrally operated.


100% this. I had almost the exact same experience and lessons learned.


100%


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.


> You're either building towards economy of scale (lower unit price), economy of scope (lower marketing cost), or innovation (speed of product).

Did you come up with this or did you read it somewhere?


Nearly everything there is in a book somewhere but verified with experience.

This bit was from Harvard Business Review. I believe it inspired the Business Model Canvas. I first got it from an entrepreneurship course in ~2014. I believe the source may be early 00s if not 90s. It's hard to find sources from that far back, do share if you can find the article.

Lean Canvas is more popular these days, but if you know how business models 'click', you can use the BMC more effectively. Massage them into these forms. It's less useful for startups finding a business model, more for startups making the transition to scale ups.


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.


> CTO who should also be CPO

This is just awful, awful, awful advice. Please do not do this. Your technical leaders should think deeply about how to build a product, but not the product that is to be built. Asking them to do the latter is asking for absolute carnage.


When you’re smaller, the CPO doesn’t matter as much. Your business has an idea, your CEO and CTO knows what it should look like. Polish it later.


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.


Check out TN DuPuy, the US military theoretical who imported the German Auftragstaktik doctrine into US military thinking.


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.


Sounds like an AI wrote this.

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

I honestly disagree. You should allow the culture to evolve, but make sure it doesnt evolve in a direction that is different than where your values are now.

As an analogy, if you have a child who is 3, their culture is "energy", "constant learning", and "being cute". When they are 13, they should evolve beyond #3. And, they probably should add "be social/fit in", and "do good work (on homework etc)"

If you try to keep the 13 year old on the "being cute" value, you'll miss out on a lot


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 will be super hesitant to build multiple products. Why couldn't there just be a single product?


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?


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.


> 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

Exactly. It's very tough knowing what is "you won't need this" and what is "it won't cost a lot to add this now, you'll need this and it will save you a lot of money and pain for later".


Totally agree on YAGNI. I call it premature abstraction. My rule of thumb is I need to see 3 repetitions before refactoring cos 2 is not a reliable indication of functional invariance.


I see there is a lot of mixup between scaling company and scaling tech.

You can go really far on a server in your basement if you focus on scaling sales and scaling company and solving correct problem for right customers.


Well yes. I work on tech in companies which are slowed down because their IT departments can’t keep up with the rest of the business.


>Teaching developers who are used to building things for how they think they will need to be in the future

I'm trying to convey this very thing to my [new] manager and [new] BA/QA. With them coming on and taking over we are now doing agile in name only ... they brought their process/documents/outputs(over outcomes) waterfall ways here. It's a bit hellish lately. (I get those things were needed for SOX compliance but that overhead isn't needed here. They know a hammer, we are a screw. They are now trying to hammer the screw to make things work. SMH)


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: