Understanding a growing organization and the effect on technology

The characteristics of a growing organization
During this year's QCon conference held in New York, I attended a full-day workshop on the scalability challenges a growing organization faces, hosted by Randy Shoup. Randy explained us how every start-up goes through several phases, each with a different focus, specifically search, execution and scaling. The most difficult part of that growth is to scale the organization, the process, the culture and the technology at the same time. Some organizations have proven to be very good at the organizational level, but lacked on the technology level. Others tried to cling on the original culture, but didn't understand that this is something that changes as well. Randy emphasized that properly scaled agile teams, a DevOps culture and modern architectural styles like micro services aren't a luxury anymore.

To illustrate his pleading, he explained how the Universal Scalability Law, originally coined by Neil Gunther, applies to both software as well as organizational scalability. This law states that throughput is limited by two things; contention and coherence. Contention is caused by any form of queuing on a shared resource, be it some technical element, be it a authoritive person, department or process. Coherence defines the amount of coordination and communication is needed between nodes, machines, processes and people.

A real-world analogy of that could be the process of moving people out of a room through a door. If the door is narrow, only one person can get through, which means it'll take a while to empty the room. Having a wider door or even two different doors are obvious solutions to the problem. But if you have two doors, you'll need to coordinate the group or agree on an algorithm to decide who will go through which door. In other words, you need to ensure coherence. Most growing organizations can apply this law both on the organization itself, but also on the architecture. You can see that for example when more developers are hired. Work needs to be distributed over the teams, the architect or product owner becomes a bottleneck, and more coordination is needed between the people.

The phases of a startup
But, as Randy explained, there is a time where you don't need to think about this and a time where this becomes a real problem. In short, you need the right tool for the right job at the right time. Even a prototype or a monolith have merits under the right circumstances. To illustrate that, Randy divided the growth process of a start-up into three phases: search, execution and scaling.

The search phase is all about finding the right business model, finding a product that fits the market and acquiring the first customers. In other words, the organization is discovering the market. In this phase it is imperative to try new things quickly, so prototyping is an essential part of it. Scalability is not a concern yet, might even slow you down and thereby jeopardize the chance you reach your market in time. Paul Graham, one of the founders of the popular start-up investor Y Combinator, even encourages start-ups to do stuff that doesn't scale. So it's fine to take a technology or platform that your organization can't or doesn't want to support, as long as it allows you to quickly try out products and solutions. In fact, it's even advisable to take a non-conforming technology, since it might prevent you from converting that prototype in the real deal. Which brings me to the execution phase.

In the execution phase, an organization is focusing on meeting the near-time requirements as cheaply as possible to meet the evolving customer needs. In a way it's entering the market. Just enough architecture is the way to go and scalability concerns are not an issue yet. The point is that the organization wants to learn and improve rapidly, thereby expanding the market as fast as possible. Consequently, it will use familiar technology that is simple and easy to use and guarantees high team productivity. Organizations in this phase typically build monolithic systems that employ a single database. Although we all know that this will ultimately result in a lot of coupling, performance and scalability bottlenecks, trying to build something very scalable in this phase might actually kill your business. However, identifying natural seams in the architecture and using internal componentization can prepare you for the next phase.

The last phase is all about owning the market and scaling the organization to meet global demands. More centralized teams and standardization becomes necessary. Choices are made on the preferred network protocols, common services such as document management, as well as on development tools and source control systems. Tools are introduced to facilitate the discovery and sharing of code through libraries, searchable code and code reviews. But also the monolith must finally make way for the next generation architecture that uses scalable persistency and supports concurrency and asynchronity. Many of the prior concerns are replaced by dedicated services for data analytics, searching, caching and queuing. However, Randy emphasizes that rebuilding a system from scratch is out of the question. In his opinion (and mine), that would be the worst thing you can do. There's just so much information and history in that existing monolith, it is naïve to think that you'll be able to remember all that while building a new system. Instead, he wants us to start re-architecting our systems. What that means and how to approach that will be the topic of my next post.

So what do you think? Do you recognize the phases that Randy uses? Love to hear your thoughts by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.