Accountability and Sense of Ownership in Software Development

One of the most overlooked concepts in software development is accountability. Accountability means a team is totally responsible for successful implementation and execution of a piece of software or a service from the beginning to the end. From the time the software/service is envisioned and designed, to the time the software/service implemented and gets used by the end users, a single group of people is involved in the whole process and once it goes out of the door, that team is held accountable for the successes and failures for the end result.

This is the only way to make sure there’s a sense of ownership in a software project. Sense of ownership ensures that people in a project feel some kind of emotional attachment and responsibility towards the end result. Without a healthy dose of sense of ownership, it’s very easy for teams to develop an “ain’t my problem” kind of attitude and that’s not healthy to have in any project.

In big software companies, priorities often change and as a result, some teams are asked to stop working on a certain project, transition the project to some other team and start another new project. To upper level management, this is not a big deal, they’re just moving “resources” around from one project to another. But anyone who has done some kind of software development knows that this is much more than simply moving resources around.

By switching teams and projects around, accountability and sense of ownership in a software project are ruined. The team leaving the project will not care about the project or held accountable for it anymore because they will have a new project to work on. The team inheriting the project cannot be held accountable or feel ownership for the project either because they were not involved from the initial design. In the end, customers suffer due to poor quality. After a few project shuffles, people in the company gradually stops caring about accountability or sense of ownership because they expect that sooner or later their current project will be reshuffled and they are not going to be accountable for that nasty production performance bug.

To sum up, if someone asks you how to make sure a software project fails? Quite easy. Assign it to one team, then reassign it to another team in the middle. In the end, you’ll have an orphan piece of software that nobody feels responsible or accountable for and you planted the seeds of a non-caring unaccountable culture. Sure way of killing current and future software projects.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s