Startups in Peru are struggling due to a lack of available investment, a lack of available software engineers, and a tech/business relationship that is inimical to the success of a software-based technology startup.

Introduction

To give you context for this discussion, my wife is Peruvian; I spent two years living in Chiclayo in northern Peru between 2010 and 2012 while my wife and I were dating. My family and I still spend a month or two a year visiting our family there. Last year, I realized that I would probably retire in Peru. While that retirement is, hopefully, far away, it’s better to be prepared than not prepared. I am a technologist, usually a technical co-founder of one startup or another. When I retire, I want to retire to a place where I won’t be bored, a place that has a good engineering culture where exciting things are happening. So I reached out to my network both in Peru and in the United States. What I found is disappointing. A set of conversations I had with several entrepreneurs when Startup Grind Lima interviewed me in September reinforced this disappointment.

The good news is that there is a lot of entrepreneurial spirit in Peru. There are a lot of people with great ideas who are not afraid to take risks. The bad news is that there is little to no technology culture to support them. That bad news gets compounded by the fact that, while their Peruvian entrepreneurs need technical co-founders, they don’t highly value those technical co-founders.

There are two sides to this problem. One is in the technical culture itself; the second is in the business culture and its relationship with technological culture.

Problems with Engineers

Universities and technical institutes train exclusively on non-open-source technologies. The fact that everyone who comes out of school only knows proprietary solutions seems to have set the expectation that those proprietary cultures are the right choice. Peruvian engineers have not yet made the cognitive switch to open source. Probably due to this fact, the engineers also do not train to advance themselves.

This background in proprietary solutions forces them to make proprietary technology choices that work in the short term but are self-limiting in the long term. For example, tech nical co-founders will choose the Oracle Database instead of Postgresql or Mysql. They choose Windows instead of Linux or BSD; they choose proprietary languages such as C# instead of open languages such as Scala, Ruby, Python, etc. The lack of knowledge of open-source solutions forces them into a narrow, expensive channel to gather information, get support, upgrade systems, and host software. These choices eventually kill the startup. I spoke with one startup in a Latin American country. The service this startup provides has a low daily hit count and a correspondingly small number of sales per day. Their current technology spend is in the range of $10,000–$12,000 per month. Based on their load, I would expect their technology spending to be in the realm of $500 to $1000 a month given their load. So, in my opinion, their technology spending is about 10 times what I would expect it to be. They can remain in business with this kind of spending because their infrastructure provider is currently giving them $10,000 a month worth of infrastructure for free—which runs out after 12 months. I expect this startup to die within two to three months of running out of the free period offered by their infrastructure provider. This startup is stillborn. Poor technical decisions that shut down the startup after a short period of success is a common problem for startups there.

Problems in the Relationship between Business and Technology

Problematic relationships between the business side of the house and the technology side of the house is a problem that is not unique to Peruvian startups. It is pervasive throughout technology companies around the world. The business part of the organization incorrectly orients itself with the technology part of the enterprise. In well-run startups, especially technology startups. The business side of the house and the technology side of the house work together to make the startup successful. Engineers are involved in setting deadlines and goals, informing the business what is possible and what is not. The business is responsible for setting a direction and setting expectations with customers. When there is a problem, the business and technology sides of the house typically work out a solution that allows for business continuity.

This mutually supportive and communicative relationship fails to appear in poorly run startups. When this failure happens, the business side of the house dictates to the technology portion of the house with little or no consideration on whether or not it is possible. Without a strong technology co-founder to push back, and the right culture to allow him or her to push back, one ends up in a situation where engineers are continuously working marathon days, direction changes constantly, and the project doesn’t make progress. If this continues long enough (and it usually does), the technology staff quickly burns out and starts leaving. The company quickly ends up on a treadmill where it is always hiring new engineers; those engineers last for a year or so (just long enough to get productive), then burn out and leave. This treadmill is also potentially company ending.

Brain Drain

The final problem, and perhaps the most insidious, is brain drain. There is massive demand for good engineering candidates all over the world. In Peru, if an engineer overcomes all of his obstacles to arrive at a point where the above problems no longer apply, he is immediately snapped up and hired into the United States or India. Staying in Peru has to be made attractive. In my experience, engineers enjoy working on difficult problems with peers they respect and admire and who admire them in return while making a decent income. Creating an environment where that possibility exists seems to be the best way to reduce brain drain

Solving the Problems

Solving these problems is difficult and will require a multipronged approach across many different sectors.

English is a Prerequisite

We live in an age where access to information and the ability to self-teach are at an unparalleled level. Anyone can teach themselves anything, which is particularly true for anything related to technology. Unfortunately, the vast majority of this content is in English. English is the lingua franca of the Internet and will continue to be for the foreseeable future.

The plethora of information available in English makes the ability to read and write English fluently a prerequisite to anything else you might do in this space. If you cannot access the information available to improve yourself, your career as an engineer is stillborn.

Step one is to include a strong English requirement into any technology program. Whether it is a degree-seeking program at a university, a certificate at a tech school, or a coding camp, begin with English.

Open Source, Open Source, Open Source

University programs should focus exclusively on open-source technologies. Focusing on open-source technologies is the only way to provide opportunities for engineers to bootstrap themselves.

Teach Technology Leadership

There needs to be some opportunity for engineers to learn about how to lead. That means leading other engineers but also driving the business to a certain extent. Engineers need to understand the value they bring to the table and be able to ensure that that value is brought to the organization.

Teach Business Leadership

Organizations in Peru, and probably most Latin American countries, are typically hierarchical. The CEO is king, his dictates are law, his vice presidents are the princes; their dictates are the law to everyone but the CEO and on down the chain. Top-down, hierarchical organizations with an “ask no questions” culture is not the way to build a successful technology company. No single person has all the information he or she needs to make a decision. One talks and argues and wrangles until reaching a consensus or realizing that a consensus is impossible to reach, and the discussion is no longer valid. Once reaching that point, the decision-maker must make a decision. Trying to reach consensus is not a lack of leadership. In this process, the leader (CEO, VP, etc.) must make a decision—and he or she does. However, that leader makes that decision in the context of the discussion and the tension of a group of invested partners.

Leading by consensus a difficult skill to learn for anyone and much harder to learn in a culture that tends to be hierarchically oriented. Therefore, it must be tough.

Start Early

Changing culture for a company is mind-bogglingly difficult. Changing culture for the industry in an entire country, much less a continent, is something I can’t even imagine. If I stretch my mind to try think about ways in which there is any chance of success, I arrive at the idea that you need to start early. University is too late; high school may even be too late. You have to start hammering on these topics early and continue hammering on them until the person leaves the education system. ⤧  Next post Correctly Orienting the Recruiting Org to the Business ⤧  Previous post Mocking is Evil