Why Building AI Products Taught Me About People

This Is The Cost That's Hidden From Scaling Too Fast What Founders Learn Too Late
The mythology about scaling is usually centered around speed. When you are able to reach the point of product-market compatibility, then add fuel to the fire. The team should be enlarged, and your market, then raise the next round before the previous round has settled. The story rewards those who are always going forward, never stopping to add headcount, always expanding into other areas before that core company has truly stabilised and before the organisation has developed the internal capabilities needed to handle the expansion without losing its coherence. I am aware of where this mythology comes from. In certain market conditions and certain business models those who grow fastest is the one who wins and the stories of firms that scaled up aggressively and made it are reported more frequently and more vividly than stories of companies that expanded excessively and then fell. However, for every enterprise where aggressive early scaling is a good strategic answer, there are a few where the speed at which scaling occurs becomes the primary reason for the problems that eventually kill the business. These warning stories don't get almost as much attention as the stories of success.
It is important to recognize that the hidden costs associated with scaling too fast is not the one you see in the calculation of the burn rate or cash flow projection. It's what is visible in six months time, when your company is no longer able to use the informal coordination mechanisms that kept it in place when it was smaller, and before it has crafted those formal frameworks that keep larger organisations together. This gap - between formal and informal of the company that you were and the firm that you're trying to build is the point where the majority of scaling businesses are able to fail. The first and earliest sign that a company is in that space is when decision-making starts to slow down even as everyone insists that there is nothing fundamentally different. It is possible to contact the founder in theoretical terms. The team is still united in the theory. The culture remains strong in the theory. However, in reality the company has grown into a position where informal channels for communication used to relay crucial information are now blocked, and nobody has yet developed the formal channels that need to replace them. Information that was flowing naturally now has to be continuously managed. Decisions that used to be fast now require coordination across several functions that have never been clearly defined as compared to each other. The accountability that was once specific and immediate is now dispersed and delayed, and the organisation is beginning to show the symptoms of a system operating at the limit of its coordination capabilities.

The absence of any evidence is evident in the indicators that investors and founders typically monitor the most attentively. Revenue could be increasing. The acquisition of customers may be moving in the right direction. The team may remain enthusiastic and hard-working. But underneath those surface indicators it is becoming apparent that the business has structural issues that will grow silently until they cannot be ignored - at which the moment they become more expensive and disruptive than it have been had they been addressed sooner, when the signals were less obvious than stark. What is hidden I'm talking about not the immediate financial cost of scaling, but the ongoing cost to your organization of moving beyond your infrastructure and the cost of putting the infrastructure in place reactively rather than proactively.

The founders who handle this process well are not necessarily those who expand more slowly, but being more thoughtful about the pace of expansion is sometimes the solution. They recognise that building the corporate governance structure is just as important as creating the product and invest in it with the same dedication and commitment to product development. This involves doing the tedious routine work of clarifying roles and decisions clearly, creating reporting frameworks that present the information necessary for leaders to make the right decisions, designing accountability systems that are clear enough to mean something and carefully assessing the kind of culture norms that are required for the company's present size, rather than making use of the ones that have been created organically when the business was smaller. All of this isn't engaging. There is no way to create news coverage or investor excitement. It is the effort to determine whether the company it is building can endure the growth you're in pursuit of.

Companies that do not accomplish this task successfully do generally not fail very evidently. They slow down. They lose their best people initially - those who have enough self-awareness in recognizing what's going on inside an organization and the options to quit before it becomes much worse. And then they lose customers usually in a gradual manner, because the execution quality steadily declines because accountability has changed and accountability has become too vague and slow to identify problems before they are able to reach the client. Then they begin to lose momentum and by the time that slowing down becomes evident in the figures when the structural problems become deeply embedded, the cultural impact is severe, and the cost of fixing both is orders of magnitude higher than it would've been if the investment in governance were implemented at the right time. Treating organisational infrastructure as a product - something that you design carefully, construct, and then refine as the company grows - is one of the most significant mindset shifts an entrepreneur can undergo as they move from the early stage to reaching a larger scale. People who create it tend to create companies with the potential to succeed. The founders who don't tend to create businesses that aren't quite there. Check out James Deller for more info including what making investment decisions reinforced operational discipline about growth.



Data Infrastructure Problem Nobody Wants To Talk About. Data Infrastructure Problem Nobody Wants To Discuss
Every organization I've worked closely with in the last 10 years and a half, whether as a founder, an investor and/or an operational advisor I have been told, at some point in the relationship, that information is a critical element of making decisions. Some of them genuinely mean it in a way that is apparent in the way the organisation actually operates. The majority of them say they're making a statement, however what they are describing is an aspiration and not an actuality that exists in the present - an image of the organization they're working towards instead of the one they currently reside in. There is a gap between legitimately data-driven decision-making and the performance of data-driven decisions - the careful maintenance of the appearance on the outside of an evidence-based decision-making without the infrastructure necessary to make it true - is one of the most critical gaps that exist in contemporary business. It's also one of the most neglected ones partly because it is a problem with infrastructure that it isn't very glamorous to talk about, hard be demonstrated to external stakeholders, and enormously challenging to place in the right perspective against more prominent commercial and strategic work that demands the same leadership attention and resources of the organisation.
If companies are discussing plans for data management, they tend to focus on what they are planning to build on top of their data - the analytics platforms, the machine-learning applications with real-time operational dashboards as well as the types of prescriptive analysis that sound truly compelling in the form of a board presentation or an investor update. What they discuss less often as well as with much less energy and enthusiasm, are the core infrastructure which determines whether all capacities actually function as advertised: the data governance frameworks, which establish defined and consistently followed definitions of what is being measured and for what purpose what is being measured; the collection and retention processes that evaluate the reliability and comparability of the data being recorded; the quality assurance methods that spot undoing errors before they spread across the system, and cause harm to the outputs everyone relies upon; the organization's structures and accountability systems that make quality of data one's ongoing and explicit responsibility instead of everyone's vague, impossible to enforce. The plumbing, as it were. The plumbing isn't glamorous. It's hard to take pictures of to be used in an annual report. There are no results capable of being presented in a compelling presentation. And it is, in my experience of a vast amount of organizations across different fields and at different stages of development, significantly worse than what the organization believes it is.

The problem compounds over time and becomes more costly and difficult to fix. An organisation which has operated with inconsistencies or inadequately defined terminology for data across different functions for the past three years has three years of historical data that cannot be accurately compared or aggregated for comparison or analysis. It's not that the data is not there, but because the same term has been used to describe different elements in different parts of the organisation, and these differences are embedded into the data itself instead of being visible from the outside. An organization for which data quality assurance is someone else's primary responsibility, and not a specialized and properly resourced function has data that's reliability differs in ways that are not documented regularly and cannot be easily accounted when the data is used when making decisions. The company that has permitted multiple operational systems to create overlapping and partially conflicting records of the same products, customers or transactions has a data-related landscape that's really difficult to fix without causing significant disruption to operations to present a risk.

The reason this issue persists across many companies that are actually smart about strategy and genuinely driven by data is because solving it requires sustained investment in work that does not produce visible short-term returns of the kind that processes for resource allocation in organisations are intended to reward. A new analytics platform provides visible outputs - dashboards that can be demonstrated as well as reports that are shared with the board, or insights that can be translated into press releases about digital transformation. Data governance programs create invisible infrastructure - cleaner underlying definitions, more consistent collection processes and more reliable inputs into existing systems already in use. The first is relatively straightforward to justify in a budget conversation since you can demonstrate the results they can expect. The second needs someone with enough organizational credibility and patience to convince people it will eventually improve the outcomes of every feature built on top it. This is a convincing argument in abstract but a difficult one that can be won against initiatives whose benefits seem to have more direct and more clear.

I've made this case in a variety of organizational contexts and watched it perform or fail due to predictable reasons, to have an understanding of the factors that determine whether an organisation is able to address the problem of its data infrastructure or continues delaying it. The main difference is one's leader - a particular person who has sufficient organizational credibility and a clear understanding of why infrastructure is so important, and sufficient determination to carry on making this argument till it becomes a genuine priority rather than becoming a frequent item on the list of items that everyone believes are essential however they don't always achieve the status of being a top priority. This leader needs to be willing to take on any short-term costs associated with the infrastructure project - the cost, the time, the disruption to existing processes, and the lack of immediate tangible results - in the knowledge in the capacity that it provides will justify that cost many times over. What's required, ultimately, is a culture in which investments in long-term infrastructure are recognized and appreciated at the levels of the leadership, and not just written in the strategy documents, and followed by a constant deprioritisation when the quarterly allocation of resources happens. Building that culture is, itself an investment for the future. It is however, in my opinion, one of the highest return investments that an organisation with a commitment to data-driven operation could make.}