Back to resources

Helping Your Team Understand Its Scope

Ownership
Team Processes

27 April, 2021

Philippe Girolami
Philippe Girolami

VP of Engineer at Upflow

Phillipe Girolami, VP of Engineering for Data Engineering and Machine Learning at Dailymotion, explains how he rebalanced and clarified the scope of his teams by creating a detailed and parsable service catalog.

Problem

The scope my team manages is quite large because they have continually built new analytics & machine-learning products over the past few years. At some point, that entangled us in many ownership-related issues. I was wondering if people knew enough about the scope we handled, particularly since a number of new people recently joined the team. Also, I understood the importance of having a registry that would guide newcomers into the scope and provide sufficient information when a production issue arises on a component that hasn’t been updated in a long time.

Three main problems I identified that stemmed from the lack of well-defined scope were:

  • If people on the team were unable to grasp how all different pieces of software fit together and were overwhelmed by it, they couldn’t be empowered as ICs because they wouldn’t know how they could contribute to something.
  • If people were unaware of the scope, problems in production would inevitably emerge because it wouldn’t be clear who should be looking at what or who would know most about a particular something.
  • If managers didn’t understand where the scope was, they wouldn’t be able to understand where their blind spots were. It’s harder to coach and grow a team that would be competent across the domain when one doesn’t know where the boundaries of the scope are.

Actions taken

First and foremost, I acknowledged the problem, “Yes, the scope is large.”. That, to a significant extent, caused a lack of understanding of its boundaries within the team. Also, most people were unaware of the problems the lack of well-defined scope could cause. After I carefully studied the problem and its ramifications, I announced the plan to address it. My plan consisted of a number of actions.

I broke down our functional scope into smaller functional domains and created a draft Service Catalog to serve as a registry of all our software assets, be they a code repository, a pipeline running in production, a data set in our data warehouse, a messaging resource, a storage bucket, an API, a machine learning model, etc. The Service Catalog was built as a JSON file so that I could easily create multiple views of it. After reviewing this initial draft with my managers, I asked engineers to go through every single software asset we had --, and make sure they were part of the catalog along with important meta-data such as location, purpose, wiki page links, support level (on call or not). Software assets were grouped into “products” and “products” were grouped into functional “domains”. Finally, team ownership was made explicit.

Once the JSON file was complete, I noticed some imbalance and worked with managers to develop an action plan to rebalance the scope. That raised additional questions. There were some overlaps, and we had to reorganize the team and redefine responsibilities to clarify who would be responsible for which part of the scope.

Following this rebalancing, managers looked at each of the “products” officially owned by their team to identify people who had some knowledge of the service and what their self-assessment would be -- did they consider themselves experts, did they need some maintenance, etc.

When people started maintaining the Catalog, managers could use the competency matrix on the scope and add actions to each person’s objectives. Some people would develop knowledge of a specific service because there was a lack of sufficient expertise for that specific service. People would be given time and opportunity to learn about things they didn’t know much about, giving them a feeling of ownership.

Lessons learned

Don’t let it get away. Although you don’t need a detailed Service Catalog early on, a moment will arrive when it will be much needed. While many things you built wouldn’t require maintenance in terms of adding more features, you should be open to the possibility and start to document all those software assets.

  • Choose the right time to define the scope and categorize services. If you do it too early, people will be hesitant because they will not be aware of the problem’s severity. If you wait too long, the process will be more painful. We did it somewhat late, but people still find it very helpful.
  • Don’t create your Service Catalog in Excel. People would often think of it as a list of technical components to which they can add a column describing what service it is for. But that is not manageable. You will not be able to fairly and efficiently distribute the work across the team because you will not be able to extract and automate data from that spreadsheet easily. We did it in a JSON file, but there are other open-source tools that use parsable format. If you have a large scope, it will take a significant effort to list all technical components. It is important to spend enough time before you tell the team to start filling in all the fields and think thoroughly about the structure of data you are trying to capture. Think about what problem your effort will solve and what data you will need to solve it. Only then will you know (and be able to explain to other people) what should be filled up.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Motivate Your Engineers to Grow in Their Careers

13 June

Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.

Goal Setting
Different Skillsets
Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Motivation
Team Processes
Career Path
Performance
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight