Senior Management – Karney Li

Thinking Distributed

The best analogy I can think of for how to think about scaling an organization to think distributed is the contrast between communism and capitalism methods of government. Objectively speaking, one is not necessarily better than the other, but in practice one scales better in our current world.

Communism is centralized command-and-control, it is a non-distributed organization. In theory, if you had perfect knowledge and ability to react in real-time, there would be minimal waste and demands would always be met with the right amount of supply. In practice, it hasn’t played out this way, probably because we don’t live in a world of perfect data and instantenous data processing abilities. Capitalism in contrast, relies on that invisible hand, it argues that in efficient markets, supply-and-demand will balance itself through price discovery. There might be some degree of loss in the beginning but it will come to an equilibrium fast and the overall oversupply or undersupply will be minimized.

In capitalism, when the government wants people to spend money, they lower interest rates. Instead of directing, they guide. They create incentives for the market to move in the desired direction but they don’t direct. In communism, there’s a required a feedback loop to central command so it can process the data and tell each type of producer the next steps. This often leads to either over-production or under-production because it’s easy to have incomplete information or data processing delay.

Leading a distributed organization is similar to working with monetary policy. We want to create the right incentives, we want the default thing to be the obvious thing. We want to build the necessary tools and safety-nets so that people can focus on their objectives and not worry about duplicating work. We want teams to operate independently, instead of relying on upper-management (central-command) for next steps.

Leadership cannot scale to have perfect knowledge of everything teams do, otherwise the leadership team ends up having massive reporting apparatus just to track work output and teams will end up idle waiting for the next instructions. Instead leadership needs to empower teams to want to act in their own best interests because those interests. Leadership can guide teams by helping them clearly define KPIs, but how they go about achieving those KPIs should be left in their hands, doing anything differently will only disempower.

Becoming a leader

Being a leader is a lot different than being a manager. A manager is an operator, they follow processes and are expected to produce the desired output.

A leader is not necessarily a manager. Individual contributors can be great leaders. Leaders are people who have strong values, exemplify those values, attract a following or inspire others to do the same. People work for a manager because they are expected to. People follow a leader because they want to.

Leaders are inspirational people, have a vision, the will and ability to make it happen. Of course, they can’t do it alone. In a casual conversation, Mike Katchen mentioned to his friend that I got a slew of people at the office to start doing HIIT workouts and intermittent fasting. His friend noted, “you’re like a cult-leader!” I chuckled and replied, “being a CTO is kind-of-like a cult-leader, but it’s also good for them”. Post, I realized there’s some truth to his statement, people follow because they want to, I didn’t have to force them to.

We live in an inter-subjective world. Values are what we as individuals deem to be valuable. As a leader, we create a narrative around why we value a way of doing things, why something is worth doing, and communicating potential benefits in the far-off distance. We don’t have all the solutions. As a leader, we want others to be inspired by our vision, follow us and come up with solutions that aid in achieving our vision.

As a technical leader, we live in a world where there’s endless chaos, no matter where we look there’s the opportunity for things to be better. The most important aspect of being a strong leader is to acknowledge this chaos, embrace it and provide a vision and plan for how to achieve the end-goal. I remember a quote from Bruce Lee, “A goal is not always meant to be reached, it often serves simply as something to aim at.”

Hiring a technical leader

One of the most challenging things for startups is hiring a really great technical leader.

Early-stage tech companies that don’t have a technical founder are often pressured by investors to land this crucial hire. Investors know that hiring this individual is like finding and capturing a proverbial unicorn; they’ve seen this play out across numerous companies.

A great tech leader will guide the team in terms of architecture, operations, engineering practices, employee growth, retention, etc. All these things allow for the product and company to grow and scale. This person is generally well-respected within the engineering community, this, in turn, attracts top talent to the company.

They are rare because there are several forces at play. In years past, technical leaders at startups typically spent a few years in software development or middle-management at large tech companies and decided to seek out the startup life. The last few years have been really good to large tech. Their middle-management and senior engineering talent have been rewarded handsomely, usually not enough to retire, but enough that they’ve grown complacent.

Someone who’s spent considerable time at Amazon, Google, Netflix, Facebook, etc have likely gotten used to their internal tools, the support infrastructure, their peculiar ways of doing things and that work-life balance. When one finds themselves outside that ecosystem, they can suddenly feel lost at sea. Some may even feel entitled and not willing to do things they feel are beneath them. What they don’t realize is how good they had it, many of the problems were already solved for them years ago at these companies. They are cogs in a machine. They are just expected to operate. Life is very different at startups.

Startups the past few years have also been doing quite well. Some are startups only in name (Uber, AirBnB, etc). These people aren’t likely going to leave a rocket ship or don’t really want to rough it out again, they’re waiting for their payday. The rate of new startups being created has actually slowed down in past years, of course, many have failed. Developers and engineering leaders find it a lot less risky (and lucrative enough) to join an established company. There are many engineering leaders that have failed, the really great ones that can execute and build engineering teams are an elite few. This makes for a very tight talent pool for experienced senior technical leadership.

Many teams make the mistake of not hiring this individual and they make lots of engineering mistakes, eventually, they fail to execute. You can’t expect a developer with 2-3 years experience to fill this role, without years of making mistakes and mentoring. Technology is a very expensive place to make mistakes. Many startups have mountains of technical debt, monolithic codebases and no rational plan or experience for managing it. Investors push founders to hire someone with pedigree (i.e. has a big name on their resume) because it’ll make other investors at ease that they have someone experienced at the helm, but often this person is not the right person for the all the aforementioned reasons.

Finding this talent is hard. When they do, startups should be prepared to pay for it in cash and equity. If you’re early stage and cash-strapped, perhaps tie create a year-end bonus correlated to company metrics.

In any case, good luck!