Learning to Lead: Accountability

In my previous post in the Learning to Lead series I talked about leaders needing to be motivators. In this post I'd like to talk about accountability.

Responsibility vs Accountability

As a leader you're often going to be the situation of being accountable while ultimately not responsible for a creating the solution. This is particularly true for managers where they're accountable for the delivery of a project or feature but not responsible for the implementation.

The danger of being accountable for something but not responsible is that you'll either end up micro-managing or under-managing those responsible for solving the problem. There's a really fine line between micro-management and under-management. One helpful phrase I've heard and used in my career is trust but verify. This means that you'll have to delegate to others and trust them relative to their experience and skill-set but verify that they're on the right track.

There are several helpful tools that can be used to practice trust but verify.

• Project burn-down reports
• Agile stories and tasks
• Architectural design documentation
• Daily scrum
• Demo day

Solving the correct problem

Being accountable means ensuring the team is solving the correct problem. This is easier in an agile environment as it's the product managers role in sprint planning to be the voice of the customer. But that doesn't ensure that during a sprint the team isn't randomized by outside work or out of band requests.

Accountability means being able to prioritize and make hard decisions on what the right thing to work on is. Often this means coordinating with both product, management, and other senior leadership to weigh the pro's and con's of new work that comes in.

One easy way to make accountability part of your teams culture is to practice it during your daily scrum. It's up to the engineering lead and other leaders to make sure that as people go through what they're working on today at stand-up that it's the most important work that needs to be completed. If someone says they're about to start something that's lower priority than some other work the team should be calling out the discrepancy and holding each other accountable to working on the correct stories/bugs.

Raising the red flag early

Another area of accountability that I'd like to call out is being willing to raise red flags early enough for them to be acted upon. In the technology industry we make a lot of decisions and set schedules based off of estimates. Once a project is set in motion it's often uncomfortable or unpopular to raise a red flag. As a leader though, you're accountable for the overall health of the project. If your estimates are incorrect or based on incomplete data it's important to raise the red flag as the project is ultimately unhealthy.

When raising this flag the accountable party should be able to explain why the flag is being raised, as well as what it would take to remove the red flag.