The following is lightly edited from the June 2014 version.
Once, a farmer interviewed a teenager for a job as a farm hand. One thing the teenager said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the teenager seemed competent and knowledgeable and so they were hired.
A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking them roughly awake, he demanded, “We have to bring in the animals!”
“They are already in.”
“We need to fasten the windows.”
“They are already fastened.”
“We need to tarp the hay.”
“It’s done.”
After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the teenager’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.
The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.
Applied to Software Development
Software development goes better when I work so I can “sleep when the wind blows”.
- I am more comfortable with myself and my work.
- My customers are more satisfied with the results they see.
- My teammates can trust me.
However, I find it impossible to achieve this level of performance on willpower alone. I need support, encouragement, and accountability. I need to be a member of a community to do my best. A key to performing well is accountability: making commitments, working in ways I am proud of, and rendering account of my activities clearly and directly.
When I first started talking about accountability, I met a lot of resistance from programmers who said they hated the idea of accountability. They told stories that sounded like this, “… and then he says, ‘I’m holding you accountable for this schedule slip.’” This not what I am talking about.
“Holding accountable” is code for blame, the attempt to avoid or deflect consequences. Blame is a weak premise from which to work. Blame requires that you spend time and energy protecting yourself. In an environment of blame it is not safe to say what you do and don’t know. Blame leaves everyone worried about who is out to get them. All the energy they spend hiding could be spent interacting and adding value to the project. Work gets done much less efficiently.
Accountability is a powerful premise from which to work. Working well and visibly builds strong relationships. Accepting responsibility sets the stage for satisfaction in a job well done. It’s a pity that the word “accountability” is misused, because the misuse obscures a useful concept.
Accountability can be offered, asked, even demanded, but it cannot be forced. “I hold you accountable,” doesn’t make sense. “I blame you,” or, “I hope you will accept the consequences,” are at least honest, even if they are a toxic basis for a working relationship. Managers can request or demand accountability. For example, a manager could ask that the software be ready to deploy at the end of every week so that the team’s progress is visible. From the other side, accountability can be offered even if it isn’t requested. “I can show you a log of how I spent my time last week,” is an offer of accountability.
I offer accountability to demonstrate my trustworthiness and encourage myself to behave my best. For example, when I am accountable to my spouse for finances, we discuss how to spend money. We agree on goals and principles for our finances. I render account to her of how I actually spend money. If I waste ten dollars buying something useless, I just say so and listen to her response. Having those preliminary discussions and knowing I am going to render account helps me spend money wisely and builds our relationship
Similarly, while programming I offer accountability as a way of demonstrating my trustworthiness and encouraging my own best behavior. Pair programming; test-first programming; continuous integration; visible daily, weekly, and quarterly cycles; slack; and estimation are some of the way I make public commitments and render account of my activities. Knowing I will be honest and accountable affects how I do my work, just as knowing that I am hiding and concealing negatively affects how I do my work. There is no hidden shame if everything I do is on the table.
When I program with a partner, I make my thinking visible to them and I listen to their thinking. If I am muddled, I say so. If I don’t like our design, I say so. We are free to ask for clarification or ideas from others. If we can come up with nothing better, we go ahead doing the best we can. There is nothing hidden about this process, no blame, no shame.
Test-first programming is a form of accountability, especially when practiced in its pure form where no application code is written without a failing test. The tests are an account of my thoughts as I program. They record the problems I considered. If a problem isn’t represented by a test, it is safe to assume that I didn’t consider that as I was programming.
Continuous integration renders account to the team every hour of what I have been doing to the system. Pausing in my work to make sure the tests all run adds to the accountability, ensuring that if I created a problem in the system I will fix it before proceeding (aligned authority & responsibility).
Visible planning cycles provide an opportunity to make public commitments and, at the end of the cycle, render account for those commitments. If I know I am going to render account at the end of the day or the week I:
- Waste less time
- Ask for needed help
- Move forward with shaky information.
“I spent three days not fixing defect 142 because I was too afraid to ask for help,” is embarrassing enough that I’d rather ask for help.
Making estimates is part of making commitments. Without estimates I don’t know how much to commit to doing. Without some slack in my schedule, however, I also know that I regularly won’t meet those commitments. Making and meeting commitments is an important part of building strong relationships during development, relationships that will sustain the team during difficult times.
Sometimes I am afraid of the consequences of offering accountability. “If they only knew how long fixing that defect took they’d think I was an idiot,” I say to myself. The more accountable I am, the better I work. If I really am an idiot we’re all better off acknowledging that fact and acting on it rather than trying to pretend it isn’t true. If I have done the best I can do, I don’t have anything to fear from the judgments of others. If I say with confidence that a job will take four months, then when someone tells me they would really like it in two months I can listen to what they are really saying. I can respect their position without necessarily agreeing with it. I can listen for needs, not just for words or tone. I can look for mutually beneficial ways of getting those needs met. If I am confident in my estimates and my work, then I can “sleep when the wind blows”.
When I look at the shifts in global IT employment I see a shift of jobs towards teams and organizations that offer accountability. CMMi level 5 has many pros and cons, but one thing it definitely offers is visibility. Teams at that level say what they are going to do and report what they really do. Then they reflect on that experience to improve.
Accountability isn’t simply a matter of reporting facts. If I know that I created 40 defects this week and accurately report that, I have been honest but not responsible. I have not completed my work in a way I can comfortably live with. I am not behaving in a way that builds relationships, relationships necessary for good software development. Extreme Programming is my way of working. Its principles and practices contribute to my ability to be accountable while developing. Accountability encourages me to do my best work. I resist the urge to take shortcuts or leave ugly code when I know others will see it and care.
Accountability is important at many different levels. Being accountable to myself, even if it is just making and reviewing daily to-do lists, helps me focus my efforts and take satisfaction from my accomplishments. Inside a team, accountability encourages trust to form, trust that frees energy to be used accomplishing shared goals instead of protecting individual turf. Teams offering accountability to their customers and their organization also build trust. When an accountable teams says “six months”, others can trust that information and act on it, confident that the team is acting in our mutual interest. Some development organizations have even gone so far as to make their internal quality metrics publicly accessible, offering accountability to the world at large to demonstrate their trustworthiness, communicate their belief in what they are doing, and encourage their own best efforts.
My experience is that the further my accountability goes, the more openly and directly I express my commitments and report my activities, the more empathically I listen to others, the better the results I see. The more accountable I am, the more creative I am, the more work I accomplish, the more value I create, the faster I learn, the more I can “sleep when the wind blows”.
[Commentary:
2021, here. I wouldn’t emphasize estimates and especially the word “commitment”, at least not without clarifying that I’m talking about impact & outcomes, not effort & output.
Another point is that consequences for accountability, positive & negative, are distorted by power differentials. In most of software development, a woman admitting a mistake will be treated differently than a man admitting that same mistake. My analysis above is skewed by my privilege. I think I’m directionally correct, accountability frees energy for progress, but not always and not always the same way.]
