Some men are born to accountability...some have accountability thrust upon them

As a project manager, managing accountability is a cornerstone of my work. Because I am paid to assure that things get done there is an expectation that I will get things done. So, as the PM on projects, it becomes my responsibility to pass this expectation on to the developers, the people who actually get the work done.

In becoming an effective project manager of software development teams, I have learned that there are two sides to accountability. One side is empowering, the other is paralyzing. Knowing the difference between these two sides will help you effectively manage accountability and can ultimately affect the success or failure of your projects.

Tell me if you can see the difference in the following two statements regarding accountability:
- I will hold the development team accountable for getting thing done
- The development team takes accountability for getting things done

In each of the two statements above, where does the accountability originate? With the first, the accountibility is externally imposed on the team. With the second, it is internally imposed by the team on itself. Is this a significant difference? Let's look a little deeper into each.

Holding the Team Accountable
Often, holding a team accountable is not about assuring things get done but is about having someone to blame if things don't go well. This is the blame game and this is how it is often played out in project management:

1. Business envisions a project
   
2. Management estimates costs and dates for the project
   
3. Development team is given the project to complete without opportunity for input into the project estimates
   
4. Project scope creeps
   
5. Project delivery date slips
6. Management finds someone to blame, most likely the development team (they were the last ones doing anything on the project so they are fresh on people's minds)
   
7. Management puts the Big Bad Methodology in place on next project to hold people accountable
8. Management starts to measure project progress against the Big Bad Methodology
   
9. People start to focus their efforts only on their tasks in the methodology so they won't get blamed
10. The process becomes locally optimized and not globally optimized*
11. The delivery of projects gets worse
12. Good developers leave the company because they are being micro-managed
    
13. The remaining average and below average developers require micro-management
    
14. Management gets more serious about the Big Bad Methodology because it provides a way to get average and below average developers to accomplish something
    
15. Project delivery slows to a crawl (but nobody is getting blamed! They are all doing their part in the Big Bad Methodology.)
16. The organization cannot hire great developers to increase productivity because great developers don't want to be a part of a micro managed organization
    

*Here is an example of why local optimization is bad: in the Big Bad Methodology someone is responsible for gathering requirements. When they finish putting together their Big Bad Requirements document, they say "Whew! Thank goodness that is over with. I'm not gonna get blamed if this project is successfully!" as they throw the requirements document over the cubicle wall to the developers. But is the document sufficient to code against? Documents never are no matter how much time you spend on them. The requirements gatherers have finished their part of the methodology and are long gone to the next project and are not around to support the developers in getting working code into production. Therefore, the coding effort takes longer and is often missing the intent of the project vision because of poorly communicated/understood requirements. (See Theory of Constraints by Eli Goldratt or The Fifth Discipline by Peter Senge for discussions on Global Optimization.)

The Team Holds Itself Accountable
Being accountable should mean that you take responsibility for getting something done. You don't worry about blame but rather are committed to adding value to the organization. You are empowered and trusted to deliver.

So how to build a team that will take accountability? Here are some things to keep in mind as you build an accountability taking team:

• Hire great developers that are passionate about delivering value to an organization and not just passionate about writing cool algorithms
• Empower the team to self organize (see Artful Making: What Managers Need to Know About How Artists Work by Robert Austin)
• Empower the team to estimate projects (how can you possibly expect developers to commit to estimates if they had no part in deriving them)
• Make sure the team sees the vision of what is trying to be accomplished by the project
• Think globally, not locally, even within the development team's processes
• As a manager, be a Servant-Leader (see The Serving Leader: Five Powerful Actions the Will Transform Your Team, Your Business, and Your Community by Ken Jennings)
• Be adaptive - don't be rigid in establishing methodologies (see Agile Project Management: Creating Innovative Products by Jim Highsmith)
• Have a plan but be will to adapt as you learn