Process Design: Designing and Scaling a Process

Question

Your team owns an API (or framework) that many teams across the company make changes to. Design a process to ensure that all changes are reviewed by a member of your team.

Background

Designing good processes is another core TPM attribute. The purpose of this question is to probe the strong process design skills you’ll need as a TPM, and apply it to a technical domain to see if you are comfortable with combining technical skills with rigorous program management skills to manage change.

Similar to a previous question, we’ll use a role playing approach to simulate a real live interview.

Solution approach

We will use the following structured approach for this question:

• Clarify assumptions given its ambiguous nature.
• Outline the process workflow and the goals we want to accomplish at each step.
• Propose a process solution that will meet the stated goals.

Sample answer

Interviewee: I would like to start by clarifying some aspects of the question. First, how frequently should we expect changes to the API?

Interviewer: Let’s assume changes are quite frequent and tend to spike during certain time periods. There are at least several changes every week.

Interviewee: What’s the impact of changes? Why do we want to review every change?

Interviewer: This API is external facing, and many external clients depend on this API. We want to make sure the changes do not impact availability or introduce inconsistency in the API functions.

Interviewee: Are the changes fairly similar in nature or is each change unique?

Interviewer: Changes usually fall along similar themes such as introducing a new endpoint, modifying the contents of a return value, or deprecating an unused endpoint. However, we occasionally receive a fairly unique request that requires some scrutiny, such as changing the signature of a function or changing the name of an endpoint.

Interviewee: How long does a review take right now? What is encapsulated in a “review” today?

Interviewer: It does depend on the complexity of the change and how well prepared the team is in answering our questions. We’d like to have a fairly consistent review latency for common requests though which is why we would like a process.

Currently, reviews are done entirely adhoc and very unstructured. Somebody will ping someone on the team with a proposed change or just send out a code review and add folks from the team. We don’t have good visibility into every change either at the team level, or we often detect that changes have been made after the fact. This is leading to a lot of unnecessary churn and fire drills since these changes are often breaking. We’d like to make this more standardized and thorough so we can prevent these fire drills from happening.

Interviewee: Okay, I think I have a good enough understanding of the problem now. Let me start by outlining my understanding of the current workflow and how we can improve on it:

• A team inside the company identifies a change they would like to make in our API. The team analyzes the change and proceeds to development. Ideally, we want to be looped in at this stage so we can provide guidance and recommendations to prevent launch blocking changes at the last minute.
• Once a change has been identified, an engineer modifies the source code files with the proposed change. This is where our formal review process must kick in. We need to be able to detect these changes, provide feedback on the changes before they rollout, and verify our feedback has been addressed before the change is rolled out.
• The change is rolled out to external users. At this stage, we need a way to measure our process end-to-end to determine if our review process works.

Does that sound like the right direction?

Interviewer: Yes, that sounds good. Can you propose specific solutions to the process you outlined?

Interviewee: Great. Let’s talk specifics. There are four objectives we need to pursue here: