How to Scale Up Quickly

  1. Posted on March 18, 2008 8:22:AM by Steve McConnell to 10x Software Development
  2. Technique, Management, software startups

The question of how to scale up quickly in a software startup company is a perennially tough issue. There are some good ways to get started -- starting with a core of really senior people is one time-honored approach. Starting with a core team of people who have worked together at another employer is another approach that often works. The question, though, is how do you scale up beyond that core, and how do you scale up quickly?

I think it's an especially tough issue for people who are process oriented. If an organization is already pretty good sized, then having well defined and efficient processes can be supportive of scaling up quickly. Telecordia added something like 1000 people to its technical staff in the year it was first assessed at CMM Level 5. But that's a very large organization to start with. If you're in startup mode I think it's hard to add staff quickly without your organization's software practices reverting to whatever the industry mean in your geographic area is -- the new staff just has too strong a dilution effect on the existing staff for it to work any other way.

Trying to startup quickly by outsourcing is a dead end as far as I'm concerned, especially to India where turnover is so high. Offshore captives can work, but minimum workable size seems to be about 100 people, and it probably takes 2-3 years of ramp up to get to financial break even. It's hard to find a time-to-market gain in this approach.

So I think the only strategy that has much chance of working is being very, very selective about hiring, co-locating everyone at one facility, and making sure everyone has lots and lots of opportunity to interact both formally and informally, i.e., in addition to meetings you sponsor lots of morale events -- Friday afternoon beer busts, pizza & movie nights at work, trips to football games, dinner at the boss's house, etc. You won't be able to guarantee that the new people will work in ways that are consistent with how the existing people are working, but at least they'll work in ways that are intelligent and they'll be cooperating well. After things slow down a little you can go back in and try to establish more work conventions. You hope!

What do you think? In your experience, what are the best ways for a startup to scale up quickly?

Lorenzo Vogelsang said:

March 18, 2008 12:50:PM

In general, adding people to a late software project makes it later. Ramping up rapidly has been a long standing problem everywhere I have ever worked.

That said, I have come to believe that the open-source software development model seems to provide an excellent way to quickly ramp up. ... What part of open-source development?

Karl Fogel, "Producing open source software", O'Reilly 2006 describes a set of common artifacts used in many open source projects that seems to work well. ... Exactly how does this help ramp up?

When a large number of software developers are already familiar with the process, or can be trained up to the culture using Fogel's text, then a a set of common working assumptions is in place. All hands march to that drummer.

Add to that, Joel Spolsky's "12 Steps to better code" and there exists a basic common culture that does work.

You, Steve McConnell have written some excellent texts on how to write good code. I've read more than a few of your books.

Just exactly how do you find, qualify, hire these practitioners is problematic. Given this nation's (USA) focus on driving costs down, software developers are still looked upon as worth less than a good manager, there appears to be a growing scarcity of "better" and "best" software developers. If you are trying to hire "good" developers, you won't find much worth having. The productivity of mid level developers is what US business is willing to pay for. This is actually competitive with offshoring costs. You get what you pay for. --- Upper end "better" and "best" software developers are scarce because (duh!) they are relatively few in number. Big companies look at a "best" software developer asking for $200,000 or more per year and say, "Why should I pay that when I can hire 3 or 4 'good' developers?" ... Most employers have not yet come to terms with the concept that a "best" software developer is 10 to 100 times more productive than a "good" software developer. They just don't want to pay the price.

In the end, in the face of low compensation in the software development industry, instead of Comp Sci school, many choose BS in business undergrad and MBA in finance for grad school. The money's better.

Good luck in your search.

David Seruyange said:

March 18, 2008 2:17:PM

I heard Philip Greenspun say something interesting on the topic with respect to the company he'd run just before the bubble burst - that prior to accepting venture capital they'd been deliberate about *not growing* because, and it's his words which is why it's probably as memorable but the phrase was "we can't transmit our culture that fast."

Perhaps your question is linked to that ability to "transmit culture?"  If so it seems there are some logistical limitations on how fast that can happen that should make it a strategic decision not to scale.

In a more concrete sense there's that notion of "process" but I guess the agile "people over process" mantra has infected my thinking to a point where I've come to believe people (and collectively, "culture") trumps process.

Erich von Hauske said:

March 18, 2008 7:35:PM

I am living exactly this situation, we started 3.5 years ago (we are in Mexico) and 2007 was the point of inflection where we tripled our sales and we are just having our financial break even. So we grew from 5 developers in middle 2006 to a team of 30 people (including the Help Desk and IT Ops and around 22 developers).

How did we get started? With a small group of experienced (4-7 year experience) programmers, and 3 of us had worked together at another employer. The results were successful if you measure software success based on economics, but required a lot of work and sacrifices, in many aspects including technical debt, including almost no documentation (as I said there were sacrifices, some very hard to make) and a lack of processes, guidelines and checklists, all of these you can attribute it to me and to the lack of venture capital in Mexico.

Where are we now? I’m the Director of Technology and Operations, and we have a LOT of projects with customers and internal project to improve our platform, hiring people to cope with workload (our projects are very small 3-10 weeks), and with significant degradation (and halt) in the architecture of our platform after 1.5 years of hiring talented (but not experienced) people. Oh, and a lack of test that would make you cry (as I am right now). On the other (brighter side) all the team is in the same room, communicates a lot, there’s a good understanding of our business and everyone in the team is very motivated to improve.

So, what do I intent to do:

    * Keep being very very selective when hiring, because of two reasons: 1) I still don’t have a decent budget (but who does?) and 2) Graduates from universities are very far from being SW Engineers and is very rare that they become SW Engineers later.

    * Dedicate resources to document guidelines and checklists and to document the basic architecture and create a list of possible improvements. These to have some introduction for the new guys.

    * Create an evaluation and compensation system similar to Construx’s Professional Ladder to further motivate everyone to improve (and specially to start reading books!!!). Especially I intend to include not only the SWE KA’s but also the Business “KA’s” required in our company.

    * Training, training, training. IT pros with knowledge in even some “simple” concepts as Refactoring and Unit Testing (or TDD whichever you prefer) are VERY hard to find here (or at least for me) so I think it’s going to be cheaper and easier to train them. As a side note I just sent the first one to a Construx Course in February :D.

    * If budget permits, buy some (basic) tools to help us implement the previous points.

Sorry for the long post, I’d find hard to explain it shorter, probably due to my constrained English. But I would love to hear more on this topic.

Paul Keeble said:

March 19, 2008 7:28:AM

The other way to go about scaling is when hiring people to put them working on different functionality/an entirely different application. The more sub teams you create and hence different applications the greater productivity of both the old and new teams because there is little to know about the existing system.

Companies like Amazon use this to build scalable systems as well as scaleable teams.

talmans said:

March 19, 2008 9:25:AM

I've seen this happen before. I led a new team brought in to quickly add new features to the product. Our small team stormed, normed and formed.

Later we were integrated with the larger engineering organization. This too needed to scale and doubled in size over the next two years, building new departments like testing.

There's plenty of turnover during this time too. Later I was part of another small team to build the next generation, more storming and norming.

My perspective is that hiring is important. Engineers who can handle some chaos and distractions are important.  

The goals of the company and engineering department are important. Is the goal too scale and improve quality or push product out faster and grab market share?  Is it to build a product that's low maintenance so the rest of the business doesn't have to scale 1 to 1 with the customer base.

I say this because defining best practices and other processes may be welcomed in some cases but not others. Scaling is not the same as process maturity although I think maturity makes it easier to scale.

With all that said we found engineering silos restricting scalability. Engineers couldn't transition and features and components couldn't be extended without 20 people in the room to assess the impact.

defining design and coding best practices and code reviews helpful.  This allows the engineers to see each others code, form a common understanding of good and not good code and begin to trust each other.

This alone will improve quality. Once this happens management will trust the feedback form their engineers more. This makes it more likely that the appropriate infrastructure projects and tool sets are built to allow the product and business to scale.


Steve McConnell said:

March 19, 2008 9:53:AM

David, I think it is about the ability to transmit culture, and culture includes attitudes as well as specific work practices and even processes.

Navision (a Danish company now owned by Microsoft) had an interesting program in which each new employee had to be coached by an existing employee for 3-6 months. Each existing employee could coach only 1 new employee, and an employee had to have been with Navision for 3 years before he/she could act as a coach. When I visited them in 2000 they had a hiring freeze in effect because they didn't have any available coaches.

So, some companies take preserving their culture as they grow very seriously.

Sudeep DSouza said:

March 24, 2008 2:38:AM

Offshore development should be viewed as a supplement to the existing team and not an answer to scale. Setting up a captive offshore unit has the same problems + more of setting up a unit where you are already located. So captive offshore units are never an answer for short term growth.

One way to scale using offshore development is to have a completely new requirement to be developed. But in order to make this work you need to have excellent processes and people to manage and control it in the initial phases. Do not expect to hand over and be delivered exactly what you want. Offshore development takes time and patience to nurture and build a team.

You can read more about my experiences in offshore development and my views on it on my blog

Post a Comment:


Steve McConnell

Steve McConnell is CEO and Chief Software Engineer at Construx Software where he consults to a broad range of industries, teaches seminars, and oversees Construx’s software development practices. In 1998, readers of Software Development magazine named Steve one of the three most influential people in the software industry along with Bill Gates and Linus Torvalds.

Steve is the author of Software Estimation: Demystifying the Black Art (2006), Code Complete (1993, 2004), Rapid Development (1996), Software Project Survival Guide (1998), and Professional Software Development (2004). His books twice won Software Development magazine's Jolt Excellence award for outstanding software development book of the year.

Steve has served as Editor in Chief of IEEE Software magazine, on the Panel of Experts of the SWEBOK project, and as Chair of the IEEE Computer Society’s Professional Practices Committee.

Steve received a Bachelor’s degree from Whitman College, graduating Magna Cum Laud, Phi Beta Kappa, and earned a Master’s degree in software engineering from Seattle University.
Contact Steve