Project Buddy

I am a loyal reader of Will Larson’s writings, and this article titled Work the policy, not the exceptions is one of my favorites. Despite reading it multiple times and asking the author in person, I was always on the fence of understanding it. To begin with, I fumbled on the title itself. I seriously questioned my English education: isn’t the verb work intransitive? It took me an actual, iterative policy design, dubbed Project Buddy, to feel like I finally scratched the surface of its meaning.

Every project was concerning

For the first couple of months in my role as an engineering manager, there were 5 engineers on my team, and there were exactly 5 sizable projects going on. It is reserved for another post why I would not do that again. Assuming the team would continue to operate that way for a while, I had some more pressing concerns.

I was a new engineering manager who just transitioned from an engineer on the same team. Even if I had prior context on every single project, there was no way in which I could coach every team member on each of the 5 projects. I was ramping up in my new role and picking up new responsibilities, and whatever context I had was quickly getting stale by the day. I could probably prevent a total disaster if I had 120 productive working hours a week. However, let’s face it, there are at best 6 hours of productivity out of me on a given day. I just could not do it all.

I did not want to excuse myself for simply being short on time either. I still had serious concerns about the projects. Do not get me wrong. I support an amazing team of engineers. They were more than capable, and no one was afraid of taking initiatives. I would place the ball in their hands every single time. But I was still in anxiety mode every single day. Some were new to the organization and did not necessarily have all the tribal knowledge or connections. Others were new to the particular technical domain and needed to ramp up. A few projects were straight-out risky.

Many options could work, or none would

The default answer to any time-constrained problem is to prioritize. I theorized about prioritizing my concerns. Project X was a sure bet. Project Y seemed okay-ish. Project Z trended the most risky. Project W was kind of uncertain, but it was fine to slip. Once I started going down that mental path, it was tempting to put more attention into the project I personally deemed most risky. Why not set up a regular sync between the project owner and myself? Why not delegate that to the “most senior” person on the team? Why not pause some other projects and put more people on that project?

All of these ideas seemed reasonable, and they might actually work. Nevertheless, I was not thrilled. What if I picked the wrong project to focus on? What if all projects were risky? What if adding more people slowed down the project? What if any team member perceived even the tiniest bit of distrust?

It appeared that I was heading nowhere when I targeted this very specific problem.

Enter Project Buddy

Pondering my options unsatisfactorily, I recalled my conversation with Will over a breakfast table. It was on the topic of policy design, and so he explained:

When presented with a seemingly one-off problem, I try not to come up with a one-off solution. Instead, I expand it to a class of similar problems, and try to come up with a solution to the category. To iterate on the solution, I use the particular problem as a test case. I would run mental experiments to test the proposed solution against this specific case, as well as other similar ones I could think of. I would iterate on the solution in my head until it satisfies all my test cases. It is like test-driven development.

Following Will’s advice, I expanded my problem a bit. What if every project was risky? How would I design a solution which could solve that category of problems?

An idea emerged in my head. Every project could have a designated shadow person, which would be similar to how every pull request has a designated reviewer. That shadow person could increase the chances of identifying and mitigating risks. What is more, it would also be beneficial in a number of different ways:

• It would provide the team with vital backups. Otherwise, only a single person would have knowledge of any given project.
• It would offer team members much-wanted opportunities to mentor and to be mentored.
• It would build collective trust among team members. Trust could easily be eroded with inconsistent treatments across projects, however reasonable that inconsistency could be.
• It would scale to many more team members and projects, without anyone miraculously working more than 24 hours a day.

I was thrilled with the idea. I felt like holding on to something by targeting the class of problems. I called it Project Co-Lead. It was a mouthful, but at least I got something.

Rolling it out

The idea could be brilliant, or more likely I was too excited hence biased. It would be irresponsible for me to declare that we were going to implement it just because I ran some test cases in my brain.

I talked to my team individually in our weekly 1:1s. I shared my concerns. I explained the options that I did not like and why, especially the possibility of eroding trust. I described the idea of having a shadow person for each project. I expressed that I could very well be biased. And I invited each and every one of them to critique the idea.

To my surprising delight, they all found the idea intriguing. Many were concerned about the potential variance in carrying out the shadowing practice, but they also believed we could iterate to convergence. Despite the predictable uncertainty of having not done this before, everyone was open to try it out. One person really hated the name Project Co-Lead, and proposed Project Buddy instead. I fell in love with the name instantaneously.

Next came an experiment in the real world. Two volunteers on the team agreed to be the guinea pigs, with one serving as the project buddy to the other. They met to discuss the state of the project, and worked together to identify risks and to find the critical path towards shipping. I shadowed in one of their meetings, and happily said no more than a few words.

I felt comfortable, if not confident, after gathering non-partisan support in private and observing some early success of the experiment. I then wrote down what I thought the Project Buddy role would look like. Here is the current version with internal jargons edited out:

There will be a project buddy for every project. The goal is to help each other getting better at project scoping and execution, and eventually we are helping ourselves.

The project buddy:

• is outside of the squad, hence not actively working on the project (i.e. not contributing directly to the design or code).
• is not required to have more experience or knowledge.
• is required to carefully review the project brief and prepare questions with a critical eye.

The project lead:

• is responsible for scheduling meetings
• is encouraged to view questions from a neutral angle

For every project, the lead and the buddy will meet at least once per sprint to discuss:

• Is the project scoped appropriately?
• Are the milestones reasonable?
• Where is the project right now?
• Are we working on the right set of tasks that will move the project forward?
• How do we know we are making progress?

Note the non-requirement on experience or knowledge to enable equal participation among team members.

I proposed this policy in the next weekly sprint checkin meeting, and it passed unanimously. Team members buddied up by themselves, and they kicked the ball rolling without my unhelpful intervention. We would go on to iterate, reflect and iterate again in the weeks and months to come.

Closing thoughts

It has been more than a few months since Project Buddy was rolled out. There was generally positive feedback among team members. We did observe some pitfalls:

• For the project buddy to be more effective, there needs to be some variance from the project lead in their background, experience (within the company/organization and throughout their career), style of thinking, etc. We should consider these factors thoughtfully, and resist the urge to buddy up with someone just because they are available.
• There was a lack of authority in the project buddy. While this was to some extent by design, it certainly gave rise to some regrettable occasions where legit concerns were deprioritized or ignored by project leads.

In spite of these observed shortcomings, I felt more optimistic after reflecting on this incredible journey. I created a concrete policy to solve real-world problems involving great people and important business. In doing so, I moved up the stack to design a solution for a category, and moved down the stack to implement the solution. I was excited to apply test-driven-development skills in this surprising yet satisfying fashion. It is quite plausible that we might get rid of Project Buddy someday, but I am confident that the general scheme of policy design will continue to serve us well indefinitely.