Helping Your Team Understand Its Scope

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.