Creating/Splitting New Engineering Teams at FloQast: An Engineer’s Perspective

In my short time in this round world, I’ve understood two truths in life.

1. The mitochondria is the powerhouse of the cell.
2. Phenomenons found in natural biology are used to describe product development teams.

At FloQast, I had the opportunity to participate in not one but two team splits. Here are some exciting challenges I found through this natural evolution to team building.

A Small Nuclei

In a previous article, I talked about our product, FloQast ReMind, and the learning curve that came with starting a new application on our small team. With time, relentless effort, and a healthy feedback loop, we created something that delighted our customers, and understandably, they wanted more!

Once we identified our product-market fit, we dove deeper into our customer feedback. We noticed recurring trends in user appetite:

"When will it be integrated with this feature?" – Customer A

"I want to do this with ReMind, when will this be available?" – Customer B

"This is a must-have before I decide to use this product." – Customer C

As you can imagine, this led to a considerable expansion of the product roadmap. We don’t want our customers to compete against each other for our development time. To mitigate this, we made enhancements to our small team.

New Teammates, Fresh Insights, and Different Challenges

Our team had a consistent output through each sprint (otherwise known as velocity), which gave us a general idea of when we could expect to deliver work. Each sprint came out to around 15 points of effort. Even though we operated at this steady, performant pace, it would take us months before we could tackle customer interests at the end of the roadmap.

When you’re a small team, bringing in more engineers feels like the cavalry has arrived. Last winter, when we brought in three more engineers, I expected that our delivery would accelerate dramatically. Interestingly, I found this was counterproductive in improving our team’s velocity.

Previously when we had two engineers, we would be able to ship code in a single day. With five engineers, our code reviews started to feel more like a Stack Overflow discussion, with everyone trying to provide their solutions. As it turns out, each engineer had their own ideas on how to do work. It would take several days to arrive at a consensus and finally get the code in production. Unfortunately, this did not solve our customer pain points any quicker.

The Maths

As the team grows, there is also a cognitive load to ensure that knowledge and perspectives are shared.

You can think of this as an algorithm. Any time you introduce a new person to a small team, you invoke the need to create a new line of communication for every existing team member. Now before you say, "Chris, that math doesn’t make sense," please let me explain through code:

let initialMembers = 0 
let projectedMembers = 5
let totalUniquePairs = 0

while(initialMembers < projectedMembers){
    totalUniquePairs+= initialMembers // establish new pairs with new team member
    initialMembers++ // team member is integrated
}

console.log("Unique pairs:", totalUniquePairs) // 10

And for my fellow visually inclined peers:

The team grew from 2 to 7 engineers. However, this did not enable us to ship more code. Instead, we had more meetings and async conversations to bridge knowledge gaps and get on the same page.

More team members on a single pod do not necessarily mean a more efficient team. Instead, there are more conversations about how we can be more efficient and productive. With more team members, the benefits of splitting grow even further.

Splitting and disambiguating

In retrospect, I strongly encourage using an Engineering Requirement Document (ERD) to facilitate team splits. An ERD will help cover key topics such as:

• Who owns these existing collections of data?
• Will there be new collections of data or APIs to facilitate our working agreement?
• What are the data contracts between these pods?

Different Pods, Same Team

Splitting a team does not happen overnight. Our pods are empowered with distinct missions and ownership of their business functions, but residual functionality still needs to be ironed out. Before the team split, we had a service that captures documents, but we identified that it is more effective for the new pod to own this API. It took time for the latter to rebuild and deploy that to production. We had to work collaboratively to ensure no outage for the customer.

The new teams have a weekly Technical Sync meeting to discuss progress and discoveries. Team members employ a google doc to organize a plan of discussion points and are encouraged to fill it out ahead of time. This practice helps keep us informed on the overall product development.

In my experience, we do not split a team for distinction or novelty. We split teams so that we can be agile in product execution and with the utmost priority of helping our customers. Today, the new teams can simultaneously solve different customer needs while contributing to the larger technology ecosystem.

I hope this has given you some referable insight into what team splits are like at FloQast. Soon, we will have an article that describes how we perform Team Mitosis in a practical setting.

Christopher Ngo

Chris is a Software Engineer. He tries his best to write informative and tasteful articles on his projects. English is his first language yet there is much to be desired.