Organizational Design in a High Growth Environment

“During the past decade, as technological convergence has moved progressively forward, rapidly rising companies have astonished the global public with their ability to expand and scale at a pace that was previously unknown. From this phenomenon, the term “hypergrowth” was coined.”
— World Economic Forum

The World Economic Forum conducted a project with Ernst & Young to better understand hypergrowth, the challenges and best practices. The study defined hypergrowth as the time in which a company maintains a compound annual growth rate of above 40% in revenue.

Juniper Square has been, and continues to be, in hypergrowth mode.

In 2021, Juniper Square made the Inc. 5000 list of fastest-growing private companies, ranking within the top decile with 1,137% growth over the prior three years. Notwithstanding the pandemic, our trajectory is as strong as ever.

With growth, however, come some challenges.

In the same World Economic Forum study, talent was identified as the key growth challenge cited by the most companies.

In the last three years, Juniper Square has grown from roughly 50 employees to over 400 today.

While the team growth is exciting, we need to make sure we provide the optimal work environment and structure to truly empower everyone on the team to contribute to our mission.

Guiding Principles

Our guiding principles in our engineering organizational design stem from our company values.

One value, for example, “Think Like an Owner” promotes certain behaviors like taking initiative, focusing on the long-term, being transparent, and more.

We build on these ideas, and the rest of our company values, as we continually evolve our engineering organization.

We strive for decentralized decision making, allowing the most informed people to make decisions swiftly.

We strive for clarity around ownership and accountability, an important mechanism for a few reasons, including facilitating decisions being pushed down to the appropriate level as well as honing the team’s focus on long-term solutions.

While teams should have ownership, we need to continue to work together as an engineering team and broader company. We are not building silos. Inline with our value “Become better together”, teams should welcome contributions and feedback from other teams, always looking to collaborate. The long term owners should provide guidance as necessary.

We also look to provide support and context teams need to operate smoothly through our organizational structure. As in any environment, deep domain understanding is critical to be able to contribute and make adequate choices. Because we operate in a niche industry, it is critical that our teams are well positioned to truly understand our customers and their needs.

Ultimately, we are looking to empower teams to make their own decisions in alignment with our Juniper Square vision.

Evolving How We Work

Just a few years ago, Juniper Square was a much smaller start up. People wore multiple hats. Many core functions were not yet built out. Engineers were expected to ramp up on the whole platform and be able to dive into any issue in any subcomponent.

We knew this had to change over time.

As we scaled our engineering organization from a handful of people to tens of people, we established the concept of product development tracks and defined engineering squads.

Track is the term used to describe a collection of development teams composed of software engineering squads, product managers, design, and QA engineers.

Our original tracks were defined and segmented by our systems:

• Fundraising — inclusive of workflows for investment managers related to the CRM, offerings, data rooms, and subscriptions
• Administration — inclusive of workflows for investment managers related to transactions such as capital calls, contributions, distributions; investment performance; reporting; and more
• Network — inclusive of the investor portal, holistic experience, and the related network we are looking to build out

Each engineering squad belonged to one of the tracks.

This iterative improvement was an important milestone in our shift towards stable cross-functional teams.

There was, however, further opportunity to improve. For example, the projects a squad took on still spanned too broadly, and we found squads were still often working across various product managers, which led to unnecessary complications.

We recognized the need for clear alignment across product, design, engineering, and quality assurance, especially as we scaled to 50+ and looked to continue doubling the team in the years to come.

We conducted a series of exercises and discussions at the team-level to help each cross-functional team come up with their team charter.

A team’s charter is meant to 1) define the problem space the team is operating within, and 2) solidify the cross-functional team itself.

Rather than focusing purely on a system or subsystem, a problem space provides a much broader canvas for a team to work with. Rather than limit creativity to existing systems, a problem space empowers teams to come up with solutions.

Every team member, inclusive of the software engineering squad, product manager, designer, and QA engineer, contributed to this definition, a true bottom up effort. Once these conversations were wrapped up, each team published their team members and charter to their respective team page in our company-wide wiki.

This iteration led to major improvements at the team level. For example, these cross-functional teams took ownership over their own roadmap. Teams started focusing on the longer-term direction and desired outcomes, as opposed to only considering one project at a time.

Soon thereafter, we noticed an opportunity to improve our organization at the track level. Our initial plan to organize around system components had been causing some friction, similar to what we saw at the team level. With the latest changes, teams were able to understand the customer pain point at the team-level. The track-level did not provide similar context.

We shifted our product development tracks to align with our business objectives, i.e. company-wide problem spaces.

As of writing, we have four tracks:

• GP Software — This is the software solution we sell to investment managers, those that want to operate the software themselves.
• Services — This is the full service solution we sell to investment managers, wherein Juniper Square delivers outcomes by operating the software on their behalf.
• Network — This track is largely unchanged. The focus is around building out the ecosystem for investors, or LPs.
• Platform — Primarily an engineering track, this track includes devops, site reliability, shared services, data engineering, and other common platform needs.

While this change brings the business focus to the forefront by defining the track’s identity, teams still have ownership over underlying software components.

With this latest iteration, each engineering squad works with a single product manager and designer, making it easier to align on priorities and make decisions at the team level. Additionally, we’ve aligned our product development efforts with other functions across the company, including customer success, fund accounting, investor services, business development, account executives, and other departments.

Reflection & Closing

It is interesting to look back and see the changes we’ve gone through over the last few years. These changes are not easy to make — they occur while we continue to run at full speed.

Some of the outcomes were clear goals from the beginning. We knew we had to work towards clear engineering-product alignment, creating solid cross-functional teams.

Other decisions were more nuanced, such as organizing around systems or businesses. By organizing around systems, or software components, it would help highlight and better build the technical expertise in each area. By organizing around business domains, engineering teams might have to be more flexible and span more systems. On the other hand, focusing on the business objectives facilitates sharing of context. Teams are better able to understand our customer personas, what problems they have, and what value we are delivering.

Given the niche industry we operate in, we found product context to be a more difficult obstacle to overcome versus technical concerns, and ultimately, we evolved to the business-focused tracks.

While each approach has its own tradeoffs, we found this to be the better outcome for our company as a whole. Customer-facing departments know where to route requests and can stay up to date on the latest progress of the development teams. This improved communication ultimately helps build trust with our customers.

Maneuvering from the start up phase to a more sophisticated organization has been a rewarding journey. At the same time, we know this won’t be the last change. As we continue to scale as an engineering organization, we’ll continue to review and ensure we are well positioned to serve and empower our engineering teams.