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.

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).

Source: 2020 State of DevOps Report

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.

Book on developers as kingmakers written by co-founder of RedMonk, Stephen O'Grady

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.


我写《互联》的初心是想通过写作帮自己更清晰的思考,也同时给读者提供一个和我一起思考的空间。我一直在思考的一个大主题,就是全球化的下一个阶段会是什么样的。在这个新阶段里,什么样的人、产品、模式和机会会是 “生来全球化”的 -- 从第一天起就超越国界,面向全球市场。

本篇探讨这个 “生来全球化” 主题的四部系列的第一篇。


我不认为 "全球化精灵" 会被放回瓶子里。然而,它将以不同的形式继续出现。如果说 “全球化1.0” 是被贸易推动的,那么“全球化2.0” 将是被科技推动的。





从某种意义上说,开发者与汽车厂的装配工人甚至中世纪的铁匠并没有什么不同。科技不过是 "让创造事物更容易的工具" 而已。但目前这批4000多万(而且还在不断增长)的使用数字科技的开发者的不同之处在于,无论他们出生在哪里,成为开发者一员时的年龄有多大,或是如何学会做开发的,他们往往都有全球的视角,从而也具有全球化的思维方式。




举个例子:为了打造一个实时数据分析系统,几个开发者可能会把 MySQL(瑞典)这样的事务性数据库与ClickHouse(俄罗斯,出自Yandex)这样的大数据分析数据库拼接在一起,由Talend(法国)这样的ETL解决方案连接,由Prometheus(德国,出自SoundCloud)这样的工具监控,由Apache ECharts(中国)把数据可视化。和许多技术一样,我选取的这五个工具都有开源版本,全球各地的开发者都可以任意使用。(关于开源,请看本系列的第三篇。)

这个例子的重点不是要点出这些技术的“母国”是哪里。恰恰相反。它们的“国籍”与能不能帮助开发者完成一项工作、解决问题或持续学习新技术的这些功利性需求完全无关。当一个开发者在谷歌上搜索一条error message或打入 "如何做 [随意填空]",查看票数最多的StackOverflow帖子,阅读GitHub上的文档,并最终自己下载一版来做测试的时候(这是个典型的开发者学习过程),整个世界的可用技术都在她的眼前。最能满足她需求的技术,就是她认可和采用的技术,无论技术的母国是哪里。




开发者也不是只会聊技术的机器人,他们也是有血有肉的人!  聊技术以外,他们会一起出去吃饭,喝酒,做瑜伽,甚至一起唱K。这是些真正的社区。






从投资或寻找机遇的角度来看,为什么了解开发者 "生来全球化"的特性很重要呢?


当然,这不是一件容易的事。这种巨大的机会也带来了许多独特的公司建设挑战,很多挑战还没有固定有效的玩法。但是,借用一句冰球大师 Wayne Gretzky的名言,就是要去球要去的方向发展,而不是球现在的地方。(请看本系列的第四篇,其中我分析了几家在这方面做的不错的上市公司。)

我之所以在本系列的第一篇探讨 "开发者",核心原因是他们的角色不仅仅是技术的建设者,也是选择技术的决策者。这种转变还是个比较新的现象。技术采用的决策过程曾经是自上而下的,也是次要的。(在有些行业里,仍然是这种情况。) 以前一家公司只用 Java,可能只是因为CTO或CIO就这么拍板决定了,也许与Oracle的其他业务关系有关,而具体做事情的开发者没有什么话语权。传统来讲,也没有人因为选择IBM而被解雇过。


Redmonk cofounder写的关于开发者的书




为了能更快的 "科技化",这些老牌公司对开发者有巨大的需求。它们也倾向于模仿作为科技公司出身的更年轻的同行。沃尔玛效仿亚马逊,Visa效仿Stripe,Charles Schwab效仿Robinhood,平安效仿蚂蚁,等等。




至于内部科技化,在最顶尖的科技公司里,新技术也无处不在。最标杆的例子可能就是特斯拉了。不仅其电动车是完全由特斯拉从头到尾打造的,公司本身的内部机关也是如此。在特斯拉2020年第三季度财报电话会议上,Elon Musk不遗余力地赞扬了他的内部应用开发团队,称他们是特斯拉公司的 "神经系统" 和 "操作系统"。成功的内部应用科技产品往往会成为新创业公司的启发。这些创意被其他公司的开发者采用,尤其是那些试图效仿某行业标杆企业的公司,从而掀起一波新技术应用的良性涟漪效应。最早在Facebook内部开发并催生了好几家创业公司的GraphQL就是个好例子。

很少有公司目前能达到特斯拉和Facebook的水平,但很多公司,不管是老公司还是新公司,都在努力效仿它们。在这个过程当中,有做决策能力和建设能力的人们就是这些 “生来全球化”的开发者。