“The purpose of organization is to reduce the amount of communication and coordination necessary.”

Frederick Brooks, The Mythical Man-Month

The word “reorg,” short for reorganization, has become a periodic source of frustration for most people working in a business environment of any non-trivial size. It is a significant change, one that is often disruptive to team composition, reporting lines and/or mandates. Counterintuitively, frequent reorganizations are often a sign that an organization is experiencing rapid growth. The structure that worked for a team of 50 does not and will not work for a team of 200 or 500. This stresses the importance of these changes and of ensuring that they achieve their intended goals. Special consideration should be given to the organization, or reorganization, of an engineering group given their bias toward building and delivering on long-term goals. There is no single right way to do this given the size of an organization, its business strategy, maturity, culture, etc. We must remember, as always, it depends.

Embracing change through focused principles and beliefs

As Fred Brooks points out in my introductory quote, organizations should reduce communication and coordination so that teams can execute more quickly and independently. The consequence of that put simply is to create scale. Scale in this context means creating the ability for each employee and new hire to get more work done than under the previous structures. Increasing capacity which reduces productivity, aka diminishing returns, is a clear anti-pattern to avoid. How do we best improve the chances of an organization to be as effective as possible? This requires adhering to a clear set of principles, and these are some of the most important ones we use at Addepar:

  • Understand the technical value of your work but more importantly understand the business value to the client.

  • This is a product company. A product team includes a product manager, engineers, designers, analysts, operators and testers — all equally important and all dependent on each other. Act without ego.

  • People, process and platform in that order. Platform and process is created for people. Both should fit people, not the other way around.

  • Measure early, measure often, measure everything. Metrics must drive decision making. If a metric is not used to drive decision making, then find a better way to measure.

  • Planning and long-term strategy are not mutually exclusive from incremental delivery. The former is the destination while the latter is how you steer to get there.

  • You can’t schedule innovation. Build and deliver client-centric software through experimentation, feedback, refinement, and iteration that are the basis of an innovation loop. No one ever transformed an industry or disrupted a market by perfecting flawed processes and broken platforms.

These principles bring to life a few key beliefs that are necessary for people to accept and embrace change:

  • Purpose

  • Delivery

  • Agency

  • Decision making

  • Balance

  • Innovation

An organization of any shape that embodies these beliefs will largely be successful. There are other considerations, but these principles and beliefs will motivate people to collaborate, take ownership, move faster, and remain client-focused. Implementing these and developing the leadership required to do so will be the basis of a future blog post. 

Employing horizontal and vertical team design aligned to priorities

Addepar has gone through several organizational structures in the past few years as it has experienced rapid growth. In 2020, the engineering organization was about 60 people and was roughly divided into a few teams across product engineering, data engineering and infrastructure. Today, Addepar engineering has grown to almost 400 global members and is organized into several verticals and horizontals with an increasing number of the aforementioned product teams. The use of the term vertical and horizontal is intentional, as they are roughly orthogonal given the dimension on which they optimize. Vertical teams typically focus on a specific product, segment, persona, geographic area or business line. Horizontal teams tend to focus on a system, service, capability or specific technology/skillset. Each team still considers the other dimension but has to choose a primary alignment. These teams can be combined in different ways and it’s important to understand the different benefits of each.

The structure of each individual team should include a product manager, engineers, a designer, QA, analysis, etc. The product manager is filling the role of product owner who is responsible for prioritization and trade-offs. Some teams may not have an explicit product manager, but as long as they have a product owner with specific domain or technical expertise, the team can operate effectively. As multiple teams form, the most basic structure first splits on technology. This is how an initial team typically forms with each person focusing on a different part of the stack. The teams grow from there based on their area of focus.

Most teams quickly outgrow the technology-split model as the natural cut point resulting from team growth creates more teams of the same type, e.g., multiple back-end teams, multiple front-end teams all with the same mandate. This requires increased communication and coordination which decreases productivity. The preferred model most companies adopt is a combination of vertical and horizontal teams which take a few different forms:

  • Horizontal

    • Platform: shared technology team that delivers capabilities to other teams, aka internal products

    • Subsystem: expert-level skills around a technology or domain requiring specialized experience

    • Embedded: shared skill set team that provides resources to other teams on a temporary or project basis

  • Vertical

    • Product feature/module: deliver on major feature enhancements centered around a module or capability

    • Client segment: cross-functional team focused on the needs of a client group

    • Business: cross-functional team focused on specific business functions or outcomes

The mix of these teams is dependent on the strategic initiatives of the company and the size of the organization. In general, the need for specific platform and embedded teams will arise as greater economies of scale are needed across products and/or internal enablement and productivity. Product module teams are the most common type of team and are the prototypical “product team” people think of in an engineering organization. Client segment and business teams are the most ideal shape for a team as they are nearly autonomous and completely cross-functional. The need to align priorities and dependencies across teams is obviated by the mandate that those teams have across the entire technology ecosystem. Please note, these teams will only be truly effective if the corresponding elements of the stack are loosely coupled, independently deployable/scalable, and encouraged by the organizational culture to cross boundaries and pierce the veil of a particular system.

Addepar Engineering in 2024

Addepar is on the same journey as other high-growth, high-performing SaaS companies. Four years ago, the engineering organization looked similar to a technology split team structure. Today, the organization is much larger and much more complex. It is a mix of every single type of team across the entire technology stack. This is the result of several reorganizations aimed at aligning mandates and creating independence between teams. As we’ve launched newer products, including Alts Data Management (ADM), Navigator and Trading, those teams have been created as separate business teams which are responsible for all facets of the respective product life cycle. There is currently one client segment team in engineering that focuses on the largest clients including enterprises and institutions. Addepar also has a number of platform teams, like the Data Lakehouse and API Platform, that provide an internal product to most other teams.

Looking ahead to next year and beyond, Addepar Engineering is looking to shift more teams to be as cross-functional as possible. This will require a gradual pivot of existing teams to take on business and/or client segment mandates. Not only does this reduce the number of dependencies, it more closely aligns with how the business, its clients and the broader industry operate. Having dedicated teams also creates a more transparent attribution of resources, costs and value. This in turn makes it easier to create business cases for additional investment and expansion of capacity as there is a direct link to client outcomes. 

Regardless of the organization structure put in place or how often it changes, it is critically important to remember that these teams are made up of real people. They can only handle so much change in a given period of time, so be judicious with reorgs, plan out the details, over communicate the strategy, measure results and admit when things aren’t working. Organization, like platform and process, is created for people. We want them to be engaged, productive and happy. That must be balanced against the most well-designed organizational structure and the outcomes to be created.

Anyone who has worked in and around engineering has likely encountered the phrase “Faster, better, cheaper — pick two.” The reality is you have to find a way to pick all three, and the choices you make to balance this equation will create significant value. Addepar engineering uses the principles and organizational structures described in this blog post to deliver industry-best products and services to its clients. We are continually enhancing and speeding up our delivery process while increasing efficiency by reducing dependencies and streamlining communication. This is achieved through strategic organizational design and establishing clear principles for success.