Heed the trap of local optimums in your organization.
I recently read a book titled Software Engineering at Google. It reminded me of a common phenomenon that I observed in human societies, especially in tech companies: the trap of local optimums.
As a clever species, we know the trick of divide-and-conquer since the dawn of human history. We organize ourselves into hierarchical groups that are way larger than primeval tribes. We study complex things in nature by analyzing their structures and inspecting each component separately. We divide long-term goals into granular milestones and decompose large tasks into simpler endeavors. This idea has significantly empowered ourselves and lowered the cost of problem-solving.
That is also how modern corporations work. Hierarchically structured organizations continuously deliver their business values in an iterative way. Each person works on one thing at a time, but over time they collectively created Apple, Microsoft, Google and Facebook.
However, not all tech companies are able to scale up their business smoothly and repeat the success of Google or Microsoft, even if they have a good vision to begin with. More often than not, you see a fast-moving startup gradually slow down its pace until its business hits a ceiling and morale starts to drain. I noticed there are two intertwined hindrances that might be common to many companies. For one thing, teams or individuals may overly commit themselves to local optimizations in their own interests. For another, they may also fall for interests in the short term, further hindering the sustainable development of an organization.
First, there could be inconsistencies between constituents of an organization. Each individual may have different pursuits, and so does each team. When teams are not well-structured, or when goals of teams are not decently aligned, efforts will be wasted and conflicts may even arise. To me, this is reminiscent of the tragedy of the commons and the prisoner’s dilemma, where a group traps into a Nash equilibrium that is not Pareto optimal. There doesn’t need to be any infightings to make an organization slow down. It happens as long as teams and individuals blindly pursue their own moving targets without good liaison. Think of a deep pipeline where owners of individual components have unaligned technical insights, making it extremely hard to pipe through a system-wide feature for immediate business needs. When this happens, the leadership should step in and optimize the whole system at a higher level, just as central banks would come into rescue when the market is bogged down in panic.
Second, even if teams are perfectly aligned, the direction they are moving towards may be inconsistent with their long-term vision. For example, engineers and product managers may be pushed for short-term deliveries, exacerbating feature creeps and technical debts. This might work fine in the beginning when everything is simple and a team runs at a brisk pace. But over time, the cost of maintaining pieces of smelly software gradually increases. At last, all low-hanging fruits are gone, team spirits fades, and technical progress gets stuck. Such a team is like a species trapped into the local optimum of evolution by ending up as a cockroach instead of developing a higher level of intelligence. This can be further exacerbated by high turnover rates due to overwork or drudgery, or by lack of ownership — for example, engineers might be moved around features or short-term projects but do not own durable components or products. People come and go, just like politicians who only care about their administrations without considering the well-being of the people in the long term.
So how does Google solve those kinds of issues? What I got from the book is this: always look at the big picture and minimize the amortized cost.
First, Google has tried its best to maintain an agreeable culture such that engineers trust each other and teams are willing to cooperate. It encourages knowledge sharing, cares about individual productivity, and internalizes organization-wide issues as impacts of designated teams. On the technical side, despite its striking scale, Google has managed to maintain a single codebase so that costs of large-scale changes are minimized and a local improvement is able to propagate globally to benefit all.
Second, Google does cost-benefit analyses in a longer horizon than ordinary tech companies. It tends to bear the engineering cost upfront and reap the benefit later. For example, code authors are enforced to follow language standards and optimize code for readability, since code is written only once but read more often subsequently. Meanwhile, engineers are encouraged to “shift left” development risks by making thorough designs and writing intensive tests. In the short term, there is a slight price to pay, but it will pay off in the long run.
In a word, Google puts sufficient efforts into global optimizations in terms of both scope and time, in contrast with the myopic views of many other firms. This might be why Google manages to circumvent the trap of local optimums that afflicted many others and has sustained its innovative vitality for over a decade.
