As we set out to build and optimize our team structure at Paradigm, we recognize that, as innovative as our company is, our journey is not entirely unique. We, therefore, first take stock of our combined experience and outside historical examples to leverage what our predecessors have already learned.

Please note, that this section is not meant to prescribe any particular organizational path, nor does it apply to every situation - we simply survey the common phases in team evolution. Additionally, we focus on early, quickly-growing startups or perhaps brand new teams within larger organizations - much of the consideration below may not otherwise apply, such as to teams of similar size that are not growing exponentially.

‍

‍

Early Days - No Structure

The first 5 to 10 members of a new team are likely to discover that everybody is generally expected to perform every function simply out of a dearth of options. 

Let’s say the first Data Scientist is hired, but there is no one available to set up the data pipeline infrastructure or business analytics frontend. Even if that’s where the majority of the effort is, the initial version of analytics is going to be delivered by just one person.

As the team forms, separating it into sub-groups is likely to be counterproductive due to heavy overlap of responsibilities. Project coordination, if at all needed, happens instantaneously and without structure, obviating the need for process or dedicated staff to uphold it (program and engineering managers).

‍

‍

Introducing Disciplines

As the team and, more importantly, technology and product complexity grows, the next logical step is to subdivide along technology ownership. E.g: “we need a mobile app - let’s spin up a Mobile Team.” By this point, some legacy code is likely to have been built up, but the teams are small enough to effectively balance their time internally between new feature development and paying back technical debt, where the latter is likely to be only considered in service of the former.

‍

‍

Improving Coordination

As the strength grows into double-digits, most modern teams start to resent the toll of coordinating feature delivery as investment into product/ program/engineering management resources seems to grow exponentially. Also, at this point, the product typically progresses beyond the initial MVP and customers demand an expanded feature set. 

This is a turning point for many engineering teams from the process perspective. Some choose to continue investing into management hierarchy and other coordination functions, while others take this time to reorganize based on functionality, rather than technology. While some disciplines, such as Cloud Infrastructure/DevOps, Test, and Design stay fully or mostly centralized, the feature teams are otherwise self-contained and are structured around solving a customer problem, rather than internal technology deliverables. This, at least initially, reduces coordination load as feature teams often use isolated infrastructure, services, and applications.

‍

‍

Multiple Dimensions

With the team hyper-focused on shipping new features, technical debt abounds. Code base priorities are unclear and often collide against feature projects and clear ownership is required.

At this juncture, many teams opt for a matrix structure, where maintenance and new functionality ownership is handled separately. Engineering Managers own frameworks, bug fixing, code reuse, security, and performance, while Program Managers lead features.

‍

‍

When Matrix Stops Scaling

The matrix starts to show signs of wear at a fairly large scale - well into triple digits. Tmain cause is the sharp rise in cardinality of the relationship between managers and feature teams (too many cooks in the kitchen and too many dishes for each cook to handle).

This is the time when, in an effort to rekindle the nimbleness of small isolated teams, companies reorganize into fully self-contained, very stable units, each with its own product goals and management structure.

‍

‍

Conclusion

The myriad of structures that have been successful in practice suggests that, in early stages (under 50 engineers), almost any organizational design, if thoughtfully applied, can be effective. A more interesting question is, how likely is it to change and how costly would it be to change it? 

This question may very well not feel pertinent when the company is still discovering its identity and product-market fit, which means that significant changes are expected one way or the other. However, the damage of a massive reorganization to morale and efficiency is often severe. It is therefore worth spending the time, as we have here, to understand common evolution paths and select one that is going to be most adaptable in the given team’s circumstance.

See the choices that Paradigm has made here.