Accountability is a fascinating topic. The textbook definition is “the quality or state of being accountable; especially: an obligation or willingness to accept responsibility or to account for one’s actions”. While a lot has been written about individuals, I’ve found in my experience, the actual mechanics of how to think about team accountability for product teams, pretty lacking. This post is an attempt to describe the framework that has been useful for me. A few of these tips are borrowed from the great executives I’ve had the pleasure to work with and a few are homegrown. Hopefully, this helps somebody who is just starting out or well into their manager/team leader journey.
Why? What is the point of this?
Delegation without monitoring is abdication – Andy grove
When you make that jump from an individual contributor to a manager to a functional group leader, you are always given the advice, hire great people, give them a goal and purpose and finally give them autonomy. That’s how you re going to scale. However, that is just one side of the equation. To be a great leader you have to understand how to drive accountability in your teams as well.
Right people + defining roles and responsibilities + operating rhythm = success
I define operating rhythm as the framework by which you drive accountability in your teams and finally in the entire organization.
Why is this required? What is missing in the general hire->motivate->autonomy cycle is the feedback loop. How does the team know that they are doing better? as a leader how do you navigate and understand the things that you need to focus on to make your organization better? As your team and company get bigger and bigger, this problem compounds – how do you know whats working, not working when you are far away from the actual work? This is where the operating rhythm comes in – you need to have a regular defined framework and process for you to create this feedback loop.
Operating rhythm for product teams
In any organization that has multiple product streams, dependency management and making sure the trains are running on time i.e delivery is predictable, becomes complex. A great operational practice is the “Review meeting”. The main players in this meeting are
- You, the functional owner responsible for the output of the group
- Product manager (defines the what)
- Engineering Manager (defines the how and when)
- Project manager (tracks the when)
Your organization may have one person who does all three or some other combination – but the main thing to focus is that these roles are represented in this meeting. The key this is that everybody who needs to make a decision for the particular product stream must be at the meeting.
The objective of this meeting is to ensure that the team (including you) gets the full view of what is happening on the ground. This is the forum to uncover and remove roadblocks, make tradeoffs and enable fast decision making.
The review meeting should be scheduled in advance and is ideally weekly. There should be a low documentation overhead. The team should not spend a ton of time preparing for this meeting. The actual documentation artifact is not important – discussing the content is more important. The document artifacts should be sent to all participants in advance. This meeting should be mandatory and should just become a part of the weekly routine. The document should cover
- What is in flight?
- What is the value of what we are delivering?
- What is the expected timeline? Are we on track (Yes/No)? If no – what are the roadblocks?
- What are the tasks that are expected to complete this week (examples: Product stories due to grooming on X date, design mockups for the first review on Y date)
- Did we finish the tasks we committed to last week? What’s next up?
The actual meeting should be short – no more than 30 minutes. Everybody should have pre-read the material. Do not regurgitate the material. The time should be spent on talking through items that are off-track and possible solutions. Detailed minutes and action items are circulated post meeting (within a day) and added to the tracker for the next meeting.
What do you get out of this?
This regularly scheduled meeting establishes the key operating rhythm of your team and is a mechanism to ensure that your team is sticking to the goals as well as a shared sense of accountability. This process is pretty lightweight and is extremely useful to keep the trains running on time. You also get to remove roadblocks in a timely fashion and pick up on signals that you can tradeoff really quickly.
Functional benefits
- Immediate feedback on whats working not working, immediate surfacing of roadblocks. You can now clear em!
- All decision makers in one room – really speedy decision making – no more punting.
- Immediate signaling when projects are getting off track – more time to correct course make scope/time tradeoffs
- Trains run on time – predictable delivery
Soft benefits
- The team feels empowered – there is fast decision making and they are making the decisions with full transparency
- The team has a sense of accountability since we are all looking at a shared commitment on a week to week basis
- The team is absolutely aligned with what is required to be done
- You get to understand whats going on a day to day basis
I follow this process for all my current teams and we’ve gotten into a good rhythm, each meeting lasts about 15-20 min every week, a total of an hour a week. Time well spent!