Our Team’s Journey

The Paradigm Engineering team has grown from 4 engineers in October 2020 to 36 at the time of writing, November 2021. We still have quite aggressive targets to hit in the upcoming months in terms of product goals as well as team strength. While we are extremely fortunate to be able to attract amazing talent with the support of our leadership, we are faced with quite a challenge of ensuring that our processes are optimized at any given time. We hold ourselves to extremely high standards as per our Organizational Principles and it is paramount that our organizational design promotes and facilitates exceptional delivery, not hampers it. When combined with the full understanding of How Growing Teams Organize, these principles, when applied to Engineering, are translated into the following salient areas of focus:

Adaptability

For a startup, the only constant is change, but the rate of change even at traditional Silicon Valley startups pales in comparison to the advancements in crypto trading. Without a doubt, the biggest challenge for us is to balance building engineering rigor with velocity of innovation required to stay ahead of the fastest-moving technology market.

Agency

The most optimal decisions are made by those closest to the problem at hand. Process, tooling, and knowledge sharing must empower engineers to the utmost degree to implement what is best for the customer. This means that all leaders need to do is to articulate a customer need, staff a top-notch dedicated team, and let talented individuals do what they do best - solve problems creatively and effectively.

Predictability

We can’t foresee all the challenges that each project will face, but we can minimize their impact on timelines by proactively identifying and mitigating risk. Team structure ideally encourages clean short iterations and accommodates quick adjustments when the unexpected threatens delivery.

‍

‍

Our organizational design mainly draws on a system that originated at Spotify in 2011. Often referred to as “the Spotify Model” (no official name), it has been applied successfully by many teams throughout growth and scale. However, its history has not been without criticism and controversy that mainly stem from the fact that it is not designed to be a categorical recipe suitable as-is for all circumstances. Our experience running it in prior companies reveals that team values and goals, once considered, determine exactly how the model should be optimized.

‍

‍

How We Adopt and Adapt the Spotify Model

Squads are self-contained, short-lived (2 weeks to 2 months), cross-functional teams tasked with delivering customer-facing features. Guilds, on the other hand, steward particular code bases, such as server backend or cloud infrastructure. 

Squads have sufficient representation from all guilds that proposed functionality affects and at minimum contain a squad lead, a product owner, a test owner. Squads are self-contained, but they are not on their own - they have all resources they need to complete the project, but they are also supported by the guilds in design reviews, code reviews, regression testing, deployments, etc. Squad’s work is not done until the functionality is in customer’s hands; therefore, every squad member is a part-owner in the success of the project.

Guilds take a longer-horizon view of the health of their codebases to ensure maintainability, reliability, scalability, and security. In addition to supporting squads, guild members propose and execute enhancements in production and test code as well as tooling and infrastructure. If resource commitment is non-trivial, we plan and prioritize occasional guild projects - as a fast-moving startup, we spend the majority of our time with customer-focused end goals, but some dedicated technical debt payment is unavoidable.

‍

‍

What’s Next?

Engineering Management is currently independent of the disciplines and is based on general personality and experience fit. In the future, with sufficient manager staff, it will be tied to the individuals’ guild assignments. Product and Program Management also will have a more robust structure as opposed to current  project-by-project allocation. 

As guilds grow, we will subdivide them into chapters. Also, as functionality and code bases grow, we will introduce organizations based on long-running concerns independent cutting across guilds and squads, such as security, trading strategies, performance optimization. 

Such changes would only represent relatively minor adjustments and the strong foundation we have laid down should support new heights of engineering excellence as our team continues to scale!