Structuring & Scaling a Client-Facing Engineering Team: Part II

In Part I, we covered the inception of Spotlight engineering as a set of client project-focused engineers building tooling as they went along, along with some of the limitations of that model. In this part, we’ll talk about two subsequent team structures that we have been exploring as the team has scaled and share the results we’ve seen from each one so far.

Model 2: 50/50 split teams

To solve the coordination problems of project-specific teams and take on larger, more complex engineering projects, we made the following changes:

• Carved out a 50/50 time split between client work and infrastructure work.
• Divided engineers into “initiative squads,” managed by Tech Leads (TLs) and Tech Lead Managers (TLMs), each of which was responsible for using their 50 percent time on longer initiatives for a particular functional theme (i.e., engineering automation, cross-functional workflows, regulatory requirements, etc.).
• To support the changes above, we doubled the number of staffed engineers, aligning with Spotlight business stakeholders on the benefits of increased automation to reduce staffing pressure in the future.

Figure 1: Spotlight engineers only work on project teams, as detailed in Model 1

Figure 2: Model 2: Spotlight engineers split time between project teams and initiative squads

In this structure, Spotlight engineering squads are defined by the problems that they solve. Large problems like project automation could be broken down by each squad into sub-problems, like QA automation, delivery automation, setup and configuration automation, each of which could then be turned into JIRA epics and quarterly OKRs in order to organize engineering efforts.

Advantages

• Easier to staff large projects — The initiative squads make it possible to commit multiple engineers to solve more difficult problems that could take months or quarters to get done. These larger projects include initiatives like building a full user interface to select cohorts of interest for research datasets, or new processes for automated QA before creating client deliverables.
• Easier to attract new engineers — With the new squads, we could start using interesting initiative work as selling points to convince new engineers to join Spotlight. By recruiting engineers for specific squads, Spotlight engineering has grown from four engineers in 2018 to 14 at the beginning of this year.
• Better relationships with non-engineering teams — As this model requires cross-functional points of contact for longer-term improvements, non-engineering teams have made corresponding changes like setting up working groups and initiative squads of their own. For example, over the last few quarters, our Quantitative Sciences team has been working with us on multiple QA automation projects, forming a working group to help define requirements and manage the rollout of these new features.

Disadvantages

• 50/50 time splits are challenging — Time spent between tasks on the engineering side and the client project side can’t always be split cleanly; time pressure on one often interrupts work on the other. We’ve frequently heard in team retrospectives that engineers are frustrated by the decreased engineering velocity caused by the 50 percent time split, especially on larger initiatives where a lot of engineering work needs to be done at one time.
• Convincing stakeholders of the need for platform work — This model is heavily dependent on convincing stakeholders to accept increased engineering headcount to invest in infrastructure. The increase in investment takes time to yield results, so stakeholders need to be on board from the very beginning.
• Managing engineering time is more complicated — Now that engineering attention is split between two 50/50 workstreams, Spotlight engineering managers have to make sure engineers do the “right” amount of each type of work:
• — In a few cases, concerns were raised about engineering performance on client project work, but TLs and managers only have direct visibility into initiative squad work, so this feedback came late and was secondhand.
• — Initiative work is valuable for career growth because it is high-visibility, complex and provides opportunities for engineers to practice new skills on the engineering ladder. However, successful client project delivery and client satisfaction are the most critical metrics that Spotlight as an organization is graded on, and the existential success of Spotlight engineering is heavily tied to meeting goals for these metrics every quarter.

Lessons learned

This model has worked well for solving engineering challenges that span one or two quarters and can be worked on by multiple engineers at 50 percent capacity.

Strategies that were effective in this model:

• Moving onto an Agile-like planning system, setting quarterly Spotlight engineering OKRs and tracking incremental progress against them on biweekly sprints.
• Working with non-engineering initiative representatives to align on work at the organization level instead of the individual project level.
• Onboarding a PM to find workflow optimization opportunities that are common across Spotlight and building a pipeline of longer-term pain points to take on.

However, this model still has limitations:

• Teams in this model find the problems of automating singular workflows to be a good fit, but some problems that involve building products to holistically automate larger, multi-function or multi-workflow business processes remain too large to solve in this model.

The initiative squad model has served us well as a way to grow the business while making progress on tooling, but it wasn’t meant to be a long-term solution. Solving workflow problems one at a time during 50 percent time captures immediate value from low-hanging improvements, but the long-term ideal state is for engineers not to be involved in project execution at all. To accomplish this, we are currently working our way towards a third model: platform teams.

Read Part I and Part III in this series.