Engineering Liquidity

Engineering Liquidity: Navigating Startup Team Dynamics

In the realm of startup engineering, understanding the balance of team sizes and their functions is critical. As highlighted in my previous post about the complexities of team scaling, maintaining a certain limit on engineering resources can be advantageous. Particularly in projects where speed trumps throughput, like in greenfield experiments, a lean team can be a key to swift progress.

When we shift our perspective to a broader view, the priorities change. In this context, throughput becomes critical and so as the company grows, so too will the engineering team.

There are decicions on how to organize an engineering department. An essential element in this context is the 'liquidity' of engineering talent, and the stored value of their work. For instance, in consumer startups with diverse platforms (such as web, mobile web, iOS, Android), skipping organizational steps can be fatal.

Functional Teams in Startups

As startups expand, they often (and should) form teams based on functional skill sets. We see the emergence of backend, frontend, Android, and iOS teams. These groups, comprising individuals with similar expertise, tackle diverse challenges. The methodologies they develop for tasks like testing and deployment not only shape their immediate workflow but also leave a lasting imprint on future team processes. These functional teams store value in their processes. It requires a certain liquidity of engineering talent with similar skills to unlock this value. Apple, thriving with its functional organization to this day, is a prime example.

Embracing the Matrix Organization

Matrix organizations are favored by founders and top executives for aligning with their vision and approach to product development. For early-stage engineering leaders, recognizing the right moment to transition to this structure is key. It hinges on the availability of engineering talent and the maturity of the processes created by the functional teams.

A premature shift to a matrix organization, especially in a consumer startup with multiple clients, can be detrimental. It might not falter immediately but can lead to long-term challenges. This structure, if implemented hastily, can inadvertently undermine the value of an entire engineering organization.

I recall a consultation with a CEO whose engineering department was in turmoil. Their team had dwindled from 80 to just 8 engineers, plagued by various issues like code quality, morale, and broken processes. My immediate diagnosis? They had grown rapidly, lacked technical leadership at the helm, and prematurely adopted a squad paradigm. They never solved the functional proceses that were required to build, test, ship, and scale. There was no team to address these issues. The fallout was, indeed, catastrophic.

Functional teams build foundations. They create processes that can be replicated and scaled. They are the building blocks of a matrix organization. Without them, the matrix organization is a house of cards.

The Value of Engineering Leaderhip

The allure of a matrix organization for product engineering is undeniable, particularly for management. It allows for teams to be organized around product features which occupies their view of the company. Each team is integrated with a dedicated product manager. This setup simplifies the workflow for product managers, who otherwise would have to coordinate with multiple functional teams for a single feature. In startups, where management often doubles as the product team, the appeal of this model is even more pronounced.

Great engineering leaders know when to say no, or at least, 'not yet'. Not until an engineering liquidity and functional value has been built out.