Setting up and Scaling a Business Intelligence Team

A short guide on how to best structure your Business Intelligence organization along with various options.

Preparing for Scale

As HeyJobs was closing the Series B funding round, and the much-discussed hypergrowth was transitioning from a hype word to our new reality, we knew that things were changing. Very ambitious goals had been set to further develop our Product, expand to new markets, and grow the company headcount, as part of our mission to help every talent find a job and live a fulfilling life.

The Business Intelligence (BI) team in HeyJobs has always been a key support unit helping our colleagues with all their data needs, towards being empowered to make data-driven decisions strategically and operationally. Thus as the company started to rapidly expand along with all business and technical complexity, the BI team needed to grow accordingly in order to fulfill our core mission.

In the early startup phase, BI was for a long time a single cross-functional team of Analysts and Data Warehouse (DWH) Engineers, with the Analysts focusing on their respective domains (Marketing, Sales, Product, etc.), and the Engineers working in parallel across all domains. This rather simple structure served us more than fine based on the company’s and team’s scale in terms of managing delivery across functions and domains, while still keeping intact the team alignment, teamwork, and sense of togetherness.

However, as more team members joined and the team steadily grew, we expected to inevitably reach a certain critical team mass, after which it would not be realistically possible (or at least efficient) to remain a single team. The key symptoms slowly and steadily started showing their face:

• lack of team direction due to the enormous scope in terms of multiple key business domains as well as analytical and engineering functions,
• disjointed alignment and communication,
• key processes breaking down (e.g. stand-ups become purposeless)
• lack of individual team member identity and focus.

We knew then that we could not just be one single large team anymore, and it was time to split up!

How to decide?

Our team structure needed to evolve and we started planning to find a concrete concept of how to best structure the team given the expected level of scale. In order to set ourselves up for success, we decided to perform a short research and review possible team structures.

We defined criteria based on which these team structures would be evaluated:

• Alignment on core Objectives.
  - Engineers require close alignment since they collaboratively own the BI infrastructure and are together responsible for its operational excellence (e.g. pipelines finish successfully daily) as well as long-term scalability (e.g. architecture decisions, dev tools, QA processes).
  - Analysts are at their strongest when they work closely together because it helps understand dependencies, focus on the bigger picture, and optimize cross-domain business impact.
  - Alignment between Engineers and Analysts empowers them to develop high-quality Data Products together, instead of Engineers just building pipelines and Analysts just building dashboards. It helps improve understanding and establish transparency on common business goals, the impact of their work, as well as the technical solutions themselves.
• Strong efficient Collaboration leads to effective flexible teams. Analysts and Engineers in close communication can dynamically resolve blockers, manage dependencies, and answer each others’ business or technical questions. The unity of the team is key and can prevent having separate analytical or engineering or domain-specific “islands”.
• Clear team and individual Ownership and Engagement.
• Continuous learning within or across domains and functions. A team’s greatest strength is from Knowledge Sharing across all directions!
• Well-sized teams (5–8 people), where team processes perform optimally.

As a disclaimer, we would be remiss if we did not emphasize that there can be no shoe that fits all, and criteria might differ case by case. No single team structure can provide the answer for all companies and business models out there, but we would still hope that this can serve as inspiration.

Option #1 → Functional Setup

The 1st option follows the most traditional team setting possible, where the BI team is split by functions leading to distinct and separate Analytics and Engineering Teams.

Scale the BI team over time in this structure would require a further split for both Analyst and Engineering functions based on domain, as shown below.

When evaluating this structure, we expected it to fulfill perfectly all aforementioned criteria within the functions (Analytics or Engineering).

However, across functions we identified great drawbacks using the same criteria:

• Poor Alignment on clear objectives. Engineers have limited visibility of the business priorities and Analysts on details of technical development.
• Poor Collaboration with dependencies/blockers/questions across functions that become more troublesome to resolve. Distance between Analysts and Engineers increases and goes against being one large BI organization.
• Poor Ownership of new Data Products.
• Poor Knowledge Sharing.

Option #2 → Cross-Functional Setup within BI team

Cross-functional Teams are collections of team members with a diverse range of skills and knowledge, who bring together their specializations and varying points of view in order to achieve a clear common higher goal. They create real value and address the bigger picture, while as individuals, they become part of something bigger, which is a natural motivator. Everyone has a purpose and a clearly defined role in terms of understanding what they’re meant to contribute to the larger group and the skills they’re bringing to the table.

Here is how the setup could look after a certain level of scale:

When evaluating the setup, it should not come as a surprise that everything is reversed in comparison to the previous Functional option. We expected it to fulfill perfectly all aforementioned criteria across Analysts and Engineers within domains (Product, Marketing, etc.).

However, across domains we identified similar drawbacks:

• Poor Alignment between Analysts, due to low visibility in cross-domain topics for generating business impact, and between Engineers on infrastructure performance and scalability.
• Poor Communication between Analysts on cross-domain business topics, and among Engineers with Infrastructure topics becoming more problematic to resolve. Further processes and touchpoints are needed to mitigate risk.
• Poor Ownership e.g. what happens when the core pipeline step breaks? Do all engineers own all pipelines? Is every engineer responsible only for specific parts? Is a separate team needed?
• Poor Knowledge Sharing.

Option #3 → Cross-Functional Setup within Product team

In this option, the Analysts and Engineers are part of a larger Product team consisting of people from multiple functions such as Backend/Frontend/QA Engineers, Designers, etc, and fully follow the internal processes of the Product team itself. This kind of structure requires the presence of a small core BI team that is responsible for running and scaling the core BI Product concerning the DWH and Reporting Infrastructure i.e. for ensuring pipeline stability and scalability. This team structure scaling is rather straightforward since the team members are not attached to any core BI team, but instead, every individual Product team is responsible for hiring according to their needs.

Within this team setup, we notice unique benefits in terms of strong performance across all criteria within the Product team itself.

However, Analysts and Engineers are very far from each other, and this setup ends up having all possible drawbacks from the previous two Options across BI domains or functions.

Proposed Hybrid Setup

Overview

We realized that none of the traditional setups could help us with our scaling challenge ahead. So we endeavored to establish our own custom setup by combining the best features that the Functional (Option #1) and Cross-Functional (Option #2) team structures have to offer, into a new Hybrid setup, while aiming to avoid their core pitfalls.

We split the BI Organisation into two dimensions:

• Team: Split by function, one can only be part of the Engineering or Analytics Teams.
• Squad: Split by domain e.g. Product, Marketing, Sales.

Into the details

What does this mean exactly?

• Each Team (Analytics, Engineering) has its separate daily stand-ups that take place in parallel. On top, there are additional weekly Squad-level stand-ups with the clear objective of syncing, answering questions, resolving blockers, giving domain-level updates, and overall maintaining a solid personal and work relationship among Engineers and Analysts.
• Every Squad has its own domain roadmaps, created and managed by the domain Lead Analyst along with the BI Product Manager.
• As the team scales, a separate team Squad would be needed to manage internal infrastructure and scalability topics, separately from the external Data Platform team.
• The Domain Lead Analysts have the role of Product Owners for each Squad on their respective domain (e.g. Marketing Analytics).
• Each Analyst can always be part of a single Squad due to domain-specific complexity and the need to have a clear business focus, while an Engineer can be at any point part of up to two squads.
  Engineers rotate domains every quarter in order to ensure that they are knowledgeable on different components of our infrastructure, thus eliminating potential bottlenecks and ideally promoting engineers’ overall engagement.
• Finally, there are regular settings where the whole BI Organisation comes together to discuss Design and Architecture topics, have knowledge exchange in our Intelligence Briefings, celebrate major releases, attend Engineering and Analytics Guilds, as well as review processes, discuss challenges, etc.

Scaling

As the team grows, the hybrid approach can be scaled, by creating in parallel multiple teams of DWH Engineers and Analysts as well as multiple domain-level squads, as shown in the figure below.

Evaluation

When evaluating the setup, we notice all the key benefits from the Functional and Cross-Functional setups are present across both domains and functions.

Some drawbacks do appear and need to be carefully managed:

• Individual complexity of being part of both a Team and a Squad.
• More meetings for all team members.

Wrapping up

You may have noticed that there was conveniently no real mention of line management so far. Our learnings show that on early levels of scale, some flexibility is required, while long-term a more rigid approach is needed. On the analytical side, we see clearly that domain and people leadership need to be eventually aligned under individual teams, whereas on the engineering side, more traditional structures remain efficient.

Realistically, success in the end is getting that first high-level team structure right. While the Hybrid setup has worked for us so far, it’s always good to keep in mind that continuous iterations of reviewing, learning, and improving are needed to ensure that the structure reflects the team’s scale at any given point in time, towards hopefully getting it right!

Interested in joining our team? Browse our open positions or check out what we do at HeyJobs.