Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

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

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Transitioning From Tech to Product Management

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, talks from his experience on how to excel in a PM role when transitioning from tech roles.

Ownership
New PM
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

The Benefits of Stakeholder Communication

17 November

Piyush Dubey, Senior Software Engineer at Microsoft, shares how to understand the stakeholder communication process better and why it is essential.

Meetings
Internal Communication
Collaboration
Ownership
Stakeholders
Piyush Dubey

Piyush Dubey

Senior Software Engineer at Microsoft

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.