Structuring & Scaling a Client-Facing Engineering Team: Part III
Model 3: Common platform teams
In the platform team structure, engineers maintain a common framework, like an API or web application, incrementally adding features, addressing user feedback, and making general improvements. On Spotlight, this would mean that engineers spend 100 percent of their time developing a project execution platform, and let client projects be handled solely by non-engineering users.
Advantages
- Good alignment with engineering growth — Platform scope and complexity is a good proxy for scope and complexity of engineering work. Implementing new features, scoping out user-facing improvements, and rolling out new versions of the platform all track very well against engineering growth and maturity, making it easier to learn and demonstrate the skills needed to drive career progression.
- Managing engineers is much simpler — With only one stream of work, it becomes easier to allocate time; there is nothing other than occasional on-call duty to distract engineers’ attention away from development. Recently, we began experimenting with preallocating a few team members’ time to work 100 percent on platform work. We found that the tech lead managers had a much easier time tracking engineering progress and helping with problems that might be reducing an engineer’s productivity.
- Long-term investment is possible — With the platform taking pressure off of the engineering team to deliver client projects on a deadline, engineers can build complex, multi-quarter products that wouldn’t have been possible in a time-split environment.
Disadvantages
- Low responsiveness — Any issues on the client project that come up now need to be addressed by making changes that could possibly affect all users. There’s no longer any possibility of doing a one-off fix, since fixes are more or less global to all Spotlight projects. In the same way, feature development becomes slower, since rollout needs to be managed across multiple projects at once.
- Disconnect between engineering and problem domain — Previously, engineers could draw upon their personal experiences executing on client projects to gain insight about the problem being solved. In this platform-based model, engineering and product management need to be very careful to stay aligned with actual user needs.
Lessons learned
We’re still in the process of transitioning from initiative squad work onto platform work, but we already have a few learnings from work on some of the common tooling that we’re building.
One aspect of platform work that has been going well so far:
- Thinking globally about user needs — We’ve already found places where the Spotlight project process can be optimized across workflows; for example, certain QA workflows that were performed by different functional groups can be merged together in an automated way, saving all stakeholders time and effort.
One point that has been challenging:
- Making a compelling case for users to move to the new platform — Incremental improvements within the previous team model had the advantage of fitting neatly into the existing project execution process since they generally seek to optimize rather than fully replace processes. However, to convince users to get behind platform improvements, we need to:
- — Match or exceed the existing process in usability and ease of understanding
- — Match or exceed the existing functionality in terms of feature set and correctness
- — Make stakeholders comfortable with using the platform to take ownership of tasks previously done by engineers
These are difficult to get right both on the engineering side and on the product management side, especially with the long tail of complex use cases that we have on Spotlight.
As we continue to build out the common platform, we’ll learn more about the tradeoffs in this structure. It’s important to note that we don’t expect any single model to solve all of our problems.
What we’ve found is that the best solution is to choose a team structure that is aligned to the team’s current needs, and keep close tabs on the weaknesses of the structure so they can be mitigated if possible.
In the end, we’ve learned a lot from evolving our team structure as the Spotlight business has grown and changed, and we will take this knowledge with us as we continue to iterate in the future.
