The Mean Startup 2 –The Paradox of Speed

Jose L Ugia
8 min readNov 10, 2016

--

Startups, by definition, flourish in an ecosystem where there is no room for stillness. To the contrary, fast motion and transformation are reflected in undoubtedly relevant aspects such as time to market, prototyping, iterative development, emerging technologies, burn rate, growth, pivoting, and so on. Note the essence of time and quickness on each of them.

The Broken Speedometer

For eons, we have been assessing velocity of development in a very superficial way: linearly and visually. For example, if your job is to walk from point A to B, and these two points are 10 bamboos apart from each other, by the time you walk 5 bamboos you will be half way to finishing your job. This approach works great for activities that can be clearly described using a short list of tangible steps, like for example, gathering fruits, planting seeds, washing dishes, cooking, hunting, etc.

In startups (even the simplest ones), challenges tend to sit far away from such simplicity. Not only there is a bunch of independently moving parts that need to be put together to create some meaning, but also many of these parts require complex abilities such as creativity, resilience or curiosity. Take as an example the task of designing a consistent experience for two mobile clients and a web front-end. Concluding that the work is 33% done when there is a finished design for one of the mobile clients would be like determining that Beethoven was 55.5% done with symphonies after he wrote the fifth.

This same superficiality is seen in engineering, when progress is assessed by looking at the number of lines of code changed or commits authored in version control systems, hours sitting in a desk at an office or the ability to give up weekends in order to attenuate the effect of a pathologic inability in management to plan adequately or stick to a certain direction.

Companies looking at these indicators to assess progress are a gold mine for precisely the kind of engineers that you do not want to share your pull requests with. Since all that is needed in order to be successful in one of these companies is to write simple and bulky code, be the one who spends the longest amount of time in the office working on your own thing, or come in every other weekend to watch your favourite team play on a bigger screen.

As a result, objective indicators like fluency of communication, achievements based on informed estimations or productivity are completely disregarded. Does this sound familiar?

My Teacher Hates Me

Chances are your teacher did not hate you back then, nor your manager does today. Most likely, he or she likes you and wants the best for you; or at least, wants the best for the project you are working on.

Unproductive and sterile approaches such as the aforementioned are more likely to be a result of a religious belief in primitive models, lack of experience or empathy, or as discussed in the previous part of this series, a cocktail of factors like external pressure, fear, social limitations or emotional stillness.

What’s more important is that, if the way progress or speed is evaluated in your company is flawed, it is fairly likely that other fundamental managerial aspects could be greatly improved as well. Better yet, these other managerial imperfections will tend to negatively affect the overall speed and productivity of your people much more prominently than any positive impact produced as a result of encouraging everyone to work on holidays. That was a long sentence, here is an example:

Bernie was concerned about his next deadline, so he decided to work two extra daily hours for the rest of the month. Disregarding the fact that he could become a bit less productive, tired, irritable, lower the quality of his work and lose some motivation on the way; he estimated that he could accelerate progress by a respectable 8.5%. Good job!

Unfortunately for Bernie and his company, on the first week during that milestone, one of his managers recalled a feature that suddenly became unimaginably more important than anything else. Bernie had to help there. That slowed him down a 67% on that week. On the third week, a new customer reached out asking for a demo of the product, requesting a few minor changes. Bernie, who is a multi-use engineer, had to provide support there as well. That slowed him down another 78% on that week. At the end of the milestone, he was able to accelerate progress by 8.5% by spending more hours sitting in front of his computer, but these other poorly handled events on the planning and organisational side slowed him down an average of 36.25% overall. As a result, he was late to the planned deadline. To alleviate that, his colleagues in management brilliantly decided to ask Bernie to jump into a short period of crunch mode. They promised to buy him some pizza.

Need for Speed: The Race

But, can these behaviours really be so destructive? Aren’t most startups supposed to operate in such a reactive and disorganised fashion? Isn’t the term startup equivalent to working-until-your-brain-becomes-delirious?

To properly analyse the impact of practicing different ways of evaluating velocity of development, place yourself in the following scenario:

You found an imaginary company called “Bug-Free Labs” to develop a predictive service that aspires to take all the hard choices in life for you — which toy is the best, what sport to practice, which university to go to, best beer, Ruby or Scala, merge or rebase, etc. For imaginary reasons, it is important for you to penetrate the market quickly, so you decide to monitor the development of the product.

Three months into the business, this is how the first plot looks like:

Note that in addition to your actual progress, there is a projected value that represents the potential outcome had you not suffered from some of the flaws/errors mentioned in this article.

Your team is a couple of features behind the expectation. In one hand, you were a bit undecided about the specific direction of the product in the last three months, and together with the pressure coming from external agents, you did not have the chance to plan too much ahead. But hey!, you feel that you are getting close to the right track. Moreover, you are confident that you can fix the situation by asking your colleagues for an extra effort. This lack of direction generated certain demotivation within the team, but it doesn’t seem too important to you at this point.

Two months later, you evaluate progress again:

Damn it! Still behind.

Your people were able to squeeze a few extra hours in (note the thicker blue line), which provided for a slight increase in speed. However, they also turned their brains into more stupid and less productive machines, so the net improvement ended up being relatively low. More important than that, you were still dubious about two potential product directions, which originated a couple of minor adjustments to the product. This seemingly innocuous steering not only neutralised the impact brought by the extra effort in your team, but it made you lag behind a bit more than before.

At this point you start to feel slightly helpless. There is more pressure coming from the market and shareholders, and the discomfort and confusion within your team starts to form some grey clouds. Out of brilliant ideas, you decide to go for one last push and encourage your team to give the rest.

Three months later, you witness something that you find hard to believe:

After a few of months of late working hours without much clarity on which direction your product is going, your team starts to feel unachieved, guilty, underestimated and exhausted. Also, they start to question your ability to guide them towards a good end, and start to think that they may be wasting their time there. At some point a few of them decide to look for a better life, leaving you with a void in resources from which you are going to need help and time to recover.

Now, on top of your list of problems, you are short of resources and cannot even dream about a successfully finished product for a while.

Inception

Hold on for a second… how is it possible that moving faster made everything go slower?

Virtue vs Vice

Remember that you work with people. People have brains, and brains are sensitive pieces of flesh that are conditioned by their circumstances and surrounding environment. If you need a brain to operate effectively, saying it so is not going to be enough; just like it is not enough to sit in front of a bunch of ingredients, close your eyes and scream “Cake, build yourself!” (this folk doesn’t count).

We don’t know it all about the human brain, but we know enough to benefit from a few key features. We know that the human brain:

  • Does not operate well under sustained fatigue.
  • Is not able to handle multiple currents of information consciously at once.
  • Is constrained by the status of the limbic system, that is, it is modulated by emotion.
  • Provides chemical reward in presence of empathy.

In other words, healthy schedules, clear channels of information, simplification of complexity, personal appreciation, honesty, cohesiveness in the mission, operational freedom, silent spaces, among others, are simple, yet very powerful ways to impact productivity, development and quality.

If the previous paragraph sounded scary and you are now ready to enumerate your infamous list of companies that succeeded practicing privacy, military hierarchies, “tough love”, deception, capricious and elitist narcissism or micromanagement, remember that correlation does not imply causality. Companies may or may not be successful regardless of their internal organisation. What you can tangibly measure is how micromanagement alienates, honesty builds trust, privacy creates ignorance and autonomy fosters creative and confident leaders. That’s causality.

And now that you mention it, I also have my own infamous list of companies that succeed practicing virtuously reinforced cultures. My favourite excerpts are Valve’s Employee Handbook, Basecamp’s healthy work-style , Zappos’ Holacracy and weirdness, Treehouse’s 4-day weeks and Chad Fowler’s anti-crunch-mode philosophy.

Nowadays after all, your company is not anymore a means for your engineers to pay the bills. If your people is with you, that’s because they want to be with you; so help yourself, your team, your shareholders and your customers avoid pushing all of you into induced mediocrity.

At least not so obscenely.

--

--