TPM and Engineering Lead Execution Coordination

I was in a meeting with several of my peers today and someone was looking for feedback regarding gantt chart tools. They were frustrated that the current tooling they were using was fairly rigid and not easy to manipulate live during a working meeting. They wanted to be able to add and remove items, adjust timelines, and assess the impact in real time. They also wanted something that would be easy for Engineering to adopt, since Engineering would need to maintain task state and metadata information.

After the meeting, someone asked me what tools I use for my team in these scenarios. My response was “strong engineering leaders.” It was a bit of a flippant response, but it is true. I’m not saying it’s the ideal situation to always delegate the majority of the tactical execution. But, it’s where I’ve settled for now given my team’s maturity and where I think my focus should be during planning and execution to have the biggest impact. There are two main considerations that come to mind when determining how involved I get in the tactical planning for my teams:

  1. Are we aligned on overall strategy and confident that the project we are reviewing will get us closer to our goals?
  2. Are the Engineering leaders capable and willing to handle the project management of their team?

Mapping Outputs to Outcomes

When I looked at the person’s task hierarchy in the tool they were demonstrating, I noticed that they captured everything from their quarterly objectives, down to milestones for each objective, and then individual work items for each milestone. From their description of their pain points, it sounded like they often had discussions at the individual task level that required adding or removing tasks, adjusting due dates and tracking dependencies. They were also frustrated that it was hard to visualize everything in one place for their entire program since there was just an overwhelming number of tasks at the lowest level of their tree.

In my mind, the general hierarchy that is most directly under a team’s control is as follows:

  • Program Objectives
  • Program Key Results (or goals, target metrics, etc)
  • Project Milestones
  • Project Work Items (tasks could be organized by Epics)

These should all nest under a longer term vision and strategy for the team. These then support our higher organization’s goals and strategy and our company’s mission and vision.

The Objectives and Key Results define the outcomes we want to achieve as a group. The Milestones and Work Items reflect the outputs of your team’s efforts. They aren’t the same and I don’t think they need to be tracked directly together. It’s probably more useful to track them independently, in different forums, on different cadences, and likely with different audiences.

Our desired outcomes should drive decisions about which outputs we prioritize. As we execute, we monitor the impact of our outputs against our desired outcomes to determine if we are on track or need to make changes. We don’t want to continue executing our initial plan if we discover our work isn’t having the impact we thought it would. A project delivered on time that doesn’t impact our desired outcomes isn’t useful.

To Lead or Partner?

The other consideration when determining how far down the hierarchy to get involved is the the maturity level of the Engineering leader. I’ve found this image from one of Brandon Chu’s posts helpful when considering how I can best support an Engineering leader.

PM Skill vs Team Skill
PM Skill vs Team Skill

If the leader or their team is junior, then I may need to be more hands on with the tactical execution. I’ve helped teams define what needs to be included in a task ticket or bug report before it should be worked on by engineering. I’ve worked with individual engineers to think through a large project, develop a work breakdown structure, and identify risks and mitigations. I’ve helped teams set up their kanban boards and metrics dashboards and ran their agile ceremonies if needed. Sometimes these are the highest leverage activities and it makes sense to be this involved. But my goal is to create an environment where the team can increasingly operate without me so I can find the next highest point of leverage.

Since my current Engineering leads are all fairly senior, I mostly play a partner and support role. I primarily focus at the outcome level. I spend most of my efforts during the planning cycle to make sure our team leadership defines and is aligned on objectives and key results that progress us along our overall strategy. They handle the tactical execution and we collaborate at the outcome level, adjusting our plan to ensure we have the maximum impact.

I generally rely on the Engineering leaders to track their projects at the milestone and individual work item level. As part of our quarterly planning, each team presents their release schedule along with risks and dependencies and major milestones. I believe that providing them the autonomy to own their execution helps support a sense of responsibility, accountability, and drives their intrinsic motivation.

For initiatives that are more critical to our team’s success, I may dig into the more tactical work so that I can help with priority or scope decisions if we start to slip off schedule. I also help coordinate projects with large dependencies, especially if they involve working with external teams.

I’m not saying there isn’t value in gantt charts and detailed project management tools. Efficient execution is something we should always strive for and visualizing all the work in a gantt chart can help us improve our execution. My point is mainly that we need to ensure we are all aligned on the general direction we are heading and what success looks like first. It takes effort to maintain a strong product strategy, updating it as the product matures and we encounter new business problems to solve. It takes effort to distill the strategy into a small number of focus areas, defined as key results that are specific and measurable enough that we can get continual signal on them to chart our progress. Only once we are aligned on the outcomes does it then make sense to me to invest time in tracking the outputs.