One Million Man Startup

Published on:

Just over 3 years ago I joined a startup. The next 18 months went fast, they went really fast. We went from an idea, to having sold a product to some of the biggest brands in the world. We went from a tiny room in an incubator office in the North East to 3 offices in 2 continents and a staff count that was rapidly on the increase. We had a lot of fun.

Within this time I made (a lot of) tea, put together advertising stands and office furniture, evangelised our product at conferences, booked travel tickets, brainstormed product features, talked to potential clients, interviewed and hired new team members – and I developed a bunch of code. I was able to try new development techniques, new tools (some of which failed!), and push a bunch of code to live. Some deployments broke things and I panicked – those were fixed quickly! Did I mention we had a lot of fun?

“Nine woman can’t make a baby in one month”

Fred Brooks The Mythical Man Month

Fast forward another 6 months and our product had been in the market for over a year, we had an incredible client list, a rapidly expanding codebase and an even more rapidly expanding list of desired functionality. The company was no longer a startup and we needed to expand our capacity for both development and support.

So we needed to expand, but we needed to do it right. It’s widely accepted and understood that simply throwing people at software projects serves to slow development down. Attempting to attribute this to Brooks’s Law would be oversimplifying the scenario. However we needed to apply the same engineering oriented approach to scaling our team that we were applying to scaling areas of our codebase.

Along the way we had identified some specific challenges that we faced when bringing new members into the team. So the question was, how should we continue to expand both the team and the product, yet at the same time maintain all the aspects of the startup culture that enabled us to thrive so early on.

The Scaleable Startup

Why was that startup phase so fast and effective? why was it so fun?

At that point our product was small and we knew it all (inside out). We could brainstorm a problem in the morning, try out some ideas, and have them deployed before going home in the evening. We could do this because everyone was on the same page, was focusing on that same problem. Everyone felt the pain of that problem in the morning and the elation of the problem being removed in the evening. We were a small, multi disciplined team and within that team we had the source of the questions being asked, the answers to those same questions and the abilities to implement and test these solutions. We were a functionality machine!

And so that has to be the answer. Small, multi disciplined teams will always promote that same startup attitude. Our expanded ‘development team’ should instead be a well orchestrated development ecosystem. This ecosystem should harbour multiple ‘product teams’, each of which have complete ownership of a single product or a group of smaller related products. Each team should then be free to drive the direction and development (given functional requirements) of that product in whatever way they see fit – just as we did in those early days.

A small multi-disciplined team!

Each team should be looked at as a small development unit. They will need product direction, developers, testers and sysadmins. The requirement for the balance of these skill sets will be largely dependant on the type of product the team would be developing and so should be dealt with on a team by team basis.

The task then, is to create the ecosystem within which these ‘small startups’ can thrive. This ecosystem must support, nurture and provide each team with everything they need to be able to build and innovate within that ecosystem. For this ecosystem to work however, we must provide some basic building blocks.

Lessons Learned

Much value should be placed in domain specific lessons learned over time. These might take the form of tried and tested design patterns, tool configurations, UI constructs etc. There should be a ‘place’ to go to for these and it should be well used and well updated. Just look at Twitter’s University for an exemplary example.

Team discoveries should be actively percolated throughout the ecosystem. This can take the form of discipline specific mini summits or more regular meet ups. The overall concept here is to generate a passion within the disciplines that all teams can subsequently benefit from as well as supporting the distribution of learnings. Active emphasis should be placed on personal development within these disciplines.

Infastructure as a Service

Elements of infrastructure should be provided as easily consumable services to the product teams. Access to configuration servers and automated deployment through the use of manifests, cache clusters, load balanced app servers etc should all be simple and streamlined. Teams shouldn’t need to go through the awkward evaluation, analysis and deployment stages. Well defined interfaces should exist for each of these services, along with integration tool kits if required.

The aforementioned learning elements should make these infrastructure elements no brainers. They should be able to be utilised and rolled out quickly and as such will make valuable assets to each of the teams.

These infrastructure elements then are integral to the ecosystem building blocks being garnered. Development of them should be considered, active, and driven directly by the product teams themselves. Prioritisation should be given to elements that bring the most benefit to the ecosystem as a whole and these elements should be released to the product teams directly and frequently.

Team Interoperability

Team interoperability should be finely considered. When defining the product ecosystem the specific products being developed within this framework should be considered to be individual services. By adopting a service oriented approach to architecture, a natural boundary between products emerge. Product domain segregation becomes self enforcing and the sense of product ‘self identity’ is enhanced within the individual teams.

Taking a service oriented approach means teams within the company are able to manage interdependencies and service boundaries naturally. Teams should never be dependent on other teams for functional completeness and can instead take a more classic approach to engineering solutions by implementing against interfaces instead.


In reality, I’ve only really covered a high level overview of how the team, and loosely, system architecture should look. There are many other specific topics that could be expanded on in much more detail. I’ve also specifically not covered development methodologies as I believe they fit into this architecture. Again a topic for another post!

To summarise however, this approach favours the empowerment of small teams, each having complete creative ownership over specific products sitting within the larger, supporting ecosystem. This directly combats many of the perceived issues with larger scale, horizontally structured teams. It aims to distribute creative responsibility appropriately and enable a scenario within which multiple product specialists emerge within a wider, service oriented, architecture. Product boundaries remain defined, teams remain focused and at the same time motivated to enhance their ‘product’.

Given then an adequate imagination and ample requirement for functionality, this scenario enables the true One Million Man Startup.