Global by Nature (Part I): Developers

I write Interconnected as a place to help me think and a space for anyone to think with me. One of the big themes I’ve been thinking about is what will the next phase of globalization look like and what kind of people, products, paradigms, and opportunities that will be “global by nature” -- transcending borders and addressing a global market from day 1.

This is Part I of a four-part series to explore this “global by nature” theme.

• Part II: APIs
• Part III: Open Source
• Part IV: Public Companies to Watch (Agora, JFrog, MongoDB)

Nativism energy has been on the rise around the world for the last half decade. It is a natural reaction to the first wave of globalization -- fueled mostly by free trade -- that both created unprecedented wealth and unprecedented inequalities.

I do not think the “globalization genie” will ever be put back into the bottle. However, it will take on a different form. If Globalization 1.0 was all about trade, then Globalization 2.0 is all about technology.

In Globalization 2.0, the most important people (or persona) to understand is: developers -- the builders and kingmakers of technology. It is the single most important demographic that will shape Globalization 2.0.

Global Persona

It’s worth first defining what a developer is. My plain language working definition is: someone who uses digital technology to build things. This includes your classically trained software engineers, who formally studied at a computer science program and went on to work at a Google or Apple; your scrappy entrepreneurs who prototyped her idea from watching free videos on iOS development; your mid-career lawyers who changed profession by joining a coding bootcamp; and everything else in between.

Admittedly, it is a broad definition. But it’s one that most reflects where reality is now and where the future is heading, because as technology know-how’s become cheaper and more accessible than ever before, the act of building is also occurring more frequently and by more people in more places than ever before.

In one sense, developers are not that different from assembly workers in a car factory or even a blacksmith in the Middle Ages. Technology is but a fancier word for “tools that make building things easier.” What makes this current 40-million-or-so (and growing) cohort of digital technology developers different is, regardless of where they were born, how old they were when they became a developer, or how they learned to develop, they tend to have global exposure and thus a global mindset.

This global persona is fostered from two motivations: utilitarian and communal.

Utilitarian: whether you were a hacker as a teenanger or switched mid-career, becoming and staying competent as a developer is an ongoing learning process. Generally speaking, the field of engineering has one of shortest half-lives of knowledge -- some estimates suggest between 2.5 and 5 years. Putting this observation in context, it takes between 10 and 20 hours of study per week just to slow down the natural progression of engineering’s half-life.

With this predicament in mind, developers who want to stay developers are constantly learning new technologies, frameworks, computer languages, etc. It’s a utilitarian need. While the technology industry is dominated by the US with China closely nibbing at its heels, the creation of new technologies comes from many places around the world. That’s because practitioners of technology are increasingly distributed.

An example: to prototype a real-time data analysis system, a few developers may stitch together a transactional database like MySQL (Swedish), with a fast analytical database like ClickHouse (Russian, out of Yandex), connected by an ETL solution like Talend (French), monitored by a tool like Prometheus (German, out of SoundCloud), and visualized by Apache ECharts (China). Like many technologies, these five tools I picked out as examples all have open source versions, which make for easy access on a global scale. (More about open source in Part III.)

The point of this example isn’t to point out the national origin of these technologies as if that’s relevant. Quite the opposite. They are irrelevant to a developer’s utilitarian need to get a job done, solve a problem, or learn a new skill to stay sharp and productive. When a developer Googles an error message or “how to [fill in the blank]”, checks out the top StackOverflow thread, reads the documentation on GitHub, and eventually downloading a possible solution to test out -- a typical learning process -- the entire world’s available technology is at her disposal. And the technology that can best serve her needs also has a global market of developers to cater to.

Communal: many developers don’t just transactionally Google for solutions and be done with it. They end up forming communities and tribes over technologies, computer languages, tools, and frameworks. This formation is also global by nature.

Whether you show up at an intimate 15-person meetup in a co-working space or a massive 15,000-people conference in a convention hall, you will notice that even though the scene looks like a UN General Assembly gathering, what you hear are conversations centered around technologies and their practical uses, not bickerings about national interests or fault lines between cultures.

There is not much of: are you Chinese or Israeli or Canadian or Russian. But more of: do you use Rust or C++ for your low-level systems? Are you a MySQL or a PostgreSQL person? Are you into OpenStack or Kubernetes?

Developers don’t just talk about the technologies that brought them together; they are people too! They have dinners, happy hours, yoga sessions, and even go karaoke together. It’s a communal connection.

One fascinating thing I observed, having gone to my fair share of these meetups and conferences, is that while the default language of communication is English, it is spoken in a smorgasbord of beautiful accents. For most people, they learned English as they became developers. As someone who picked up English as a second language, I find these developer-focused gatherings some of the most welcoming and forgiving venues for people who do not speak English as their first language -- perhaps because English is secondary to the language of technology which they all speak.

I’m not suggesting that developer communities are some post-racial, post-gender utopias. Awful things still happen, toxic cultures still form, and moderating human behaviors is a constant challenge for all developer communities. On the issue of gender balance alone, the 2020 State of DevOps Report reminds us just how far the ecosystem still has to go, with only 16% of self-identified females responding to its survey versus 82% of self-identified males (though it’s improving compared to previous years of the same survey).

Many institutions like the Linux Foundation are providing diversity scholarships to level the opportunity imbalances. More and more developer-focused companies, large and small, are doing the same. With more of these efforts taking shape in the next 10 years (I hope), they will unlock new developer potentials in any region with a reasonably fast Internet -- coalescing around technology languages, not human languages. What you end up with is a global developer network effect that will grow as demand for technology grows.

Builders to Kingmakers

Why does understanding the “global by nature” persona of developers matter from an investment or opportunity perspective?

Only the product that can address developers’ needs as both builders and human beings will earn their long term approval and adoption. And the companies that create such products will, quite literally, be world-changing, because they are addressing a world-wide demographic need. This global audience is addressable from day one. For an ad-driven business like Facebook, you’d first appeal to a younger audience in a particular country, then expand to cover the 18-49 year old demographic (traditionally the group that commands the highest ad rate) in that same country, before expanding to other places. For a developer-driven business, the world is immediately for the taking.

It’s no easy feat to accomplish. This vast opportunity also presents a vast array of unique company-building challenges, most of which do not have settled playbooks. But that’s where the puck is headed, to paraphrase the hockey GOAT Wayne Gretzky. (See a few public companies that I think are doing a good job in Part IV.)

The core reason why I focus on “developers” in Part I of this series is that they are no longer just builders, but also kingmakers, of technology. This rise in importance is a relatively recent phenomenon. The decision-making process of technology adoption used to be top-down and a secondary priority. (Depending on which industry you are in, that may still be the case.) A company used to be a “Java shop” simply because the CTO or CIO said so, possibly due to other business dealings with Oracle. And no one got fired for using IBM.

Only in the last 20 years or so did developers start to gain more power and independence in deciding which technologies they could use. The developer-focused analyst firm RedMonk, founded in 2002, has been on the forefront of this trend.

Even so, building a successful product, commercialization strategy, and durable company that is purely developer-focused has been challenging. Published in 2017, the post-mortem blog post by the founder of RethinkDB serves as a raw and thought-provoking reminder of those difficulties for many people in the industry.

Timing is everything, and it’s fair to ask whether the developer-focused market opportunity is still too early. I believe the right timing is now because of two factors.

One: every company must become a technology company to survive. For new startups, it’s obvious. For older companies, incorporating new technologies is the only way to remain relevant and thrive in Globalization 2.0. Otherwise, obsoletion will swallow you no matter how iconic the company once was (see Sears).

In order for these older companies to “technologize” themselves, they have an insatiable demand for developers. They also tend to emulate their tech-native startup peers: Walmart emulates Amazon, Visa emulates Stripe, Charles Schwab emulates Robinhood, PingAn emulates Ant, etc.

This emulation is the smart thing to do, because they are fighting to hire and retain the same, scarce pool of developers. Based on the survey and research shown in “Accelerate”, a great book with a rigorous framework for understanding technology delivery inside an organization, giving developers the freedom to choose and experiment with technology is a major determinant of their job satisfaction and productivity. The older companies may be used to doing other things top-down, but when it comes to technology adoption, the smart ones give their developers the rein if only because the companies’ survival depends on retaining them.

Two: the surface area of “technologizing” is larger than most people realize. What people tend to expect is existing products and services being delivered more digitally with software, e.g. Target or Costco adding e-commerce. That makes sense, because it is the easiest to see and foresee. However, developer-driven technology adoption permeates both software and hardware, and both external and internal to an organization.

For hardware, there is a new wave of developer-focused hardware design technologies, led by RISC-V, that is making prototyping and building semiconductors easier and cheaper than before, with an experience and speed akin to developing software. Even though the RISC-V developer ecosystem is still young, its laser focus on improving the developer experience is the right direction. (I’ve written numerous posts about RISC-V if you are interested in a deep dive.)

As for internal, the best tech companies have technologies permeating inside them as well. The marquee example is probably Tesla. Not only is its EVs built from scratch solely by Tesla, so is the internal organs of the company itself. During Tesla’s Q3 2020 earnings call, Elon Musk went out of his way to compliment his internal applications team, describing them as the “nervous system” and the “operating system” of Tesla. Successful internal applications often become ideas for new startups that will get adopted by developers in other companies, especially places that try to emulate a market leader or industry icon. This kicks off a virtuous ripple effect of new technology adoption. GraphQL, first developed inside Facebook and has spawned a few startups, is a good example.

Very few companies are at the level of Tesla and Facebook, but many companies, old and new, are working to emulate them. The kingmakers who will decide and the builders who will create are these “global by nature” developers.

ICYMI: please give the other three parts of the "Global by Nature" series a read: APIs, open source, public companies to watch.

If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn.