On startup life, being flat and parallel processing
Flat startups! The heaven of organizational red tape relaxation, where the people are all do-ers, there’s no office politics, no fighting for hierarchy, no endless meetings to get to a decision, and any information and knowledge is shared throughout. Everybody at any point in time knows what’s going on.
After many years in corporations and after gaining a certain amount of expertise, specialists spread their wings and fly into new ventures, to grow new ideas without the corset of structure — because you know what needs to be done and you just want to get on with it!
And because of this..because at first a flat startup functions and grows on do-ers, all successful ones experience a growth spurt that is usually hard to manage and even harder to see coming. What is that point in time when democracy diverges from agility, when information becomes hard to permeate? And of course without being in full possession of the facts, how can one usefully contribute to a decision?
And so it becomes that layers and structure do become needed, to allow some people to do, while others help the do-ers by constantly being in full possession of the facts and connect the dots.
Seems straight forward right? A natural progression from one state to another. And yet it’s so difficult to put into practice. Because the startup incipient phase becomes that paradise lost, that grace of freedom that can never be recaptured. That place where everybody was equal and had equal say.
As groups start to form and experiment with new styles of work division and decision making, one can truly feel the growth pains. Also because by the time a team has reached a sort of method it will most likely have outgrown its size again making the method redundant. Metcalfe’s Law shows that the number of relationships within a team increases geometrically as the team grows.
In addition to the difficulty of quantifying the “value” of a network, the mathematical justification for Metcalfe’s law measures only the potential number of contacts. However the social utility of a network depends upon the number of nodes in contact. If for whatever reason, large parts of a network are not in contact with other parts then the effect may be smaller. In social network terms, if users that join later use the network less than early adopters, then the benefit of each additional user may lessen, making the overall network less efficient if costs per users are fixed. So in essence, each additional member increases the communication complexity and brings less additional added value than the previous ones.
Which begs the question — what is the format that works? Is there such a thing as the perfect combo?
How should a startup manage lots of small teams? How many reports to a manager and how many managers? Tom Tungusz measured at Google, the product manager to engineer ratios across different projects in the company. More generally, this metric is called the span of control. On average, the ratio was 1:7. But there was variance. Search engineering saw ratios of 1:20 or higher. Newer consumer products might have 2 to 4 engineers per PM.
This is due to what Peter Drucker coined as span of managerial responsibility which he defined as: “the extent to which teaching and assistance are needed.”
In other words, teams with very senior people don’t need much teaching and assistance most often because they have extensive experience — this is where flat structures thrive! These team can thrive at spans of control of 15+. More junior teams, teams new to a field or teams building a new kind of product will demand greater managerial responsibility, which means smaller teams. As companies grow and their needs diversify, it needs people to execute various tasks that do not require necessarily seniority.
This explains how flat works — the span of managerial responsibility doesn’t demand lots of assistance! The people are all senior and therefore can govern themselves.
As the company grows, it starts having more and more teams to deal, in parallel, with various tasks. So then issue becomes even more complex. Dealing not only with the team dynamics itself but also with the workflow between teams. They become interdependent.
I see here a great similarity between the growth pains of a flat structure and parallel computing. Essentially, there comes a point when the speed and the efficiency stagnates regardless of how many people work in parallel and independent of each other if at a point in time their efforts need to orchestrate towards a common goal that has dependencies. This is known as Amdahl’s Law .
Amdahl’s law is often used in parallel computing to predict the theoretical speedup when using multiple processors. For example, if a program needs 20 hours using a single processor core, and a particular part of the program which takes one hour to execute cannot be parallelized, while the remaining 19 hours (p = 0.95) of execution time can be parallelized, then regardless of how many processors are devoted to a parallelized execution of this program, the minimum execution time cannot be less than that critical one hour.
And it’s this limitation that people start to feel most painfully!
Can we use this information though and apply it to the organization structure so it eases the pain? In theory, according to this law the one component that causes the delay needs to be as efficient as possible. So whatever the serial part in the processing, this needs in turn to function as best as possible so as not to delay the execution. So it’s trying to get the most competent and skillful people to occupy those functions so that they can enable faster execution.
The key to going from flat to structure? Put the right people with the right skill sets in the right places! Execution time will never be as fast, but it will be as good as it can ever be.
