At PagerDuty, taking the lead is a key value, and we are always looking for opportunities to cultivate leadership within our engineering group. One of the approaches that has worked really well is the project leadership model within teams.

As opposed to traditional team leads, the project leadership model is a more flexible approach. It relieves a single person from bearing the load of leading all projects by giving other engineers on the team the opportunity to lead on a per-project basis.

As an engineering manager, I originally set up the project leadership model on my team to solve a specific problem. However, over time, it has proven itself a great long-term model for our team and yielded many other benefits. In this post, I’d like to share that experience and some learnings we had in the hopes it may inspire others to consider this approach as well.

Origins of the Project Leadership Model

My team owned the notification scheduling system at PagerDuty. This is the system that determines in real time when and how to contact a responder during an incident, based on the user’s notification rules. In addition to scheduling notifications, the system must also reconcile real-time user response activities that affect ongoing notifications scheduled for delivery. As you might imagine, this is a complex and mission-critical service for PagerDuty, conforming to our highest service availability tier.

The existing service had been running in production for several years, but was beginning to show its age, causing availability issues for customers and considerable operational pain for engineers. The team had been firefighting the system for almost a year, culminating in a long major incident in the fall of 2017. Over that same period, the team had become under-staffed as multiple team members left the company, including the remaining engineers who originally built the system.

The latter was especially problematic because of the system’s criticality and complexity. The system had subtle business rules, and it was built on top of an over-engineered, home-grown queueing system that wasn’t well understood and extremely difficult to debug.

For these and other technical reasons, the decision was made to re-write the service. One of the important goals of the project was to increase the bus factor for the system. We added three additional senior engineers from other teams to solve the staffing issue, and with all the new members, we effectively became a new team. We had a lot of engineers being introduced to an essentially foreign codebase and a daunting project ahead of us. We were going to have to figure out how to work together quickly and make the project a success, all while keeping the lights on.

With the project underway, role confusion quickly became a problem. Some of the new engineers had been tech leads on other teams and were unclear on what exactly their role was on this new team. While we had a lot of leaders, there also was, paradoxically, a vacuum of leadership; everyone was trying to understand the existing system while avoiding stepping on each other’s toes. This led to problems with decision-making, excessive bike-shedding, and slow progress on the project.

We broke down the overall goal of replacing the system into a series of milestones. I wanted to see direct individual responsibility for aspects of the project, and one idea was to have someone lead each milestone. The typical project milestone was going to be around 6-8 weeks long—a project in itself. We discussed the idea at a team offsite in the winter of 2018, and after some discussion, everyone agreed to give it a try.

After the change, an interesting thing happened: decision-making quickly became much smoother. We had clear leadership for each phase of the project. It was as if a weight had been lifted and the other engineers had been given permission not to worry about the whole project and could just focus on getting things done. The other engineers also knew they would get opportunities to lead future milestones so there was no fear of missing out.

What Did a Milestone Project Lead Do?

So what did it mean to be a project lead? Early on, I put together a document for the team to understand the expectations for the project lead. It evolved over time, but the key points were:

• The project lead was ultimately responsible for successful delivery of the project
• It was not the lead’s responsibility to solve all problems; it’s was their responsibility to ensure that all problems got solved
• The project lead made sure the team was working on the most important thing at all times. This included making decisions about prioritization and re-prioritization when necessary
• The project lead was the final decision-maker on matters related to the execution of the project. They were the decider when the team could not reach a decision together so that forward progress could be made

One of the other really important aspects of being a project lead was thinking about execution trade-offs, such as tracking how we were doing against our goal and target completion date for a milestone, and avoiding bike-shedding and de-risking areas early.

The project lead worked closely with the product manager and myself to flesh out and clarify requirements, consult on prioritization, and checkpoint progress. I met with the lead on a weekly basis to discuss how things were going, if there were any roadblocks they anticipated, and whether I could provide any additional support.

The lead also communicated weekly goals and project status for the team in our weekly team meeting. I created an anonymous form that the team filled out at the end of each milestone to give the project lead feedback. Peer feedback created a good forcing function for self-improvement. Leads appreciated getting feedback from their peers, in addition to regular feedback and coaching from me.

Outcomes

The project presented plenty of challenges and setbacks, but we successfully shipped the new service in January 2019. The project was a great success—and having diverse project leadership was a critical factor to that success. Our team was in a situation where project leadership felt like a good approach under the circumstances, but we hadn’t anticipated the other benefits that resulted from implementing this model.

Reaping the Benefits

Besides driving accountability, project leadership was fantastic for professional growth and helped cultivate leadership capabilities within the team. Rotating project leadership also provided a nice balance for engineers in different growth areas. Engineers got a mix of engineering time and the opportunity to develop leadership and project management skills. This variety helped re-energize members of the team, especially some of the tenured engineers who were fire-fighting a lot in the previous year.

Project leadership presents a great opportunity for different people to lead, provide diverse perspectives, and help develop a more resilient team. Though several of the engineers who led project milestones later moved to other teams or larger roles within the company, we found our team was able to adapt well to these changes.

Finally, rotating leadership responsibilities helped build empathy within the team. The dynamic between the project lead and the team was generally very healthy—since many engineers led projects on the team over time, their experience helped build empathy toward whoever was in the role at any given time.

Other Learnings

The project lead model is not without its trade-offs. If you go all-in on this model, small things can fall through the cracks between projects; for instance, a bug ticket or feature request would sometimes languish in the backlog for too long. To help prevent that, it’s important to ensure you have clarity on who owns the backlog grooming process, whether it’s a product owner, eng manager, or someone else.

Consistent effort is also required by the engineering manager to select leads and coordinate across different projects. There is definitely a higher coordination effort than having a dedicated tech lead. However, one upside is that it’s a good forcing function to not work on too many projects! Our team had a tendency to limit our number of concurrent streams of project work to two. This worked quite well by ensuring a good balance of people focused on leading projects to people focused on doing project work.

Conclusion

As an industry, we spend a lot of time thinking about single points of failure in our systems, but not enough time thinking about it in our teams. Consider if you are over-taxing traditional tech leads in your organization and providing enough opportunities for others to lead, deepening your leadership bench, and building the future leaders your organization will need.

Because the project leadership model has been very successful for our team, we continued to use it after that first project, and it has continued to pay dividends. Many engineers on the team have successfully led other projects and had the opportunity to exercise and build their leadership skills. It has also been adopted by many other engineering teams at PagerDuty. Finally, it resonates with many of PagerDuty’s cultural values: Take the Lead, Ack + Own, Bring Yourself, and Run Together.

Tell us how you are spreading leadership opportunities around at your organization, we’d love to hear it. Or if you have used this model at your organization, we’d love to learn how it’s worked for you.