Ownership

One of my favorite Twitter accounts in the software industry is Esther Derby’s. I’m constantly nodding along. This one got me thinking about the concept of “ownership” on software teams.

It’s a common refrain from software project managers that they want developers to take ownership of the features they build, as in, accept accountability for what they’ve built and its quality—to care about it.

As someone whose career responsibilities have occasionally involved diving into another team’s codebase to figure out what went wrong, I’m guilty of thinking to myself, “How could these devs have shipped this crap? Don’t they care about the quality of their work?”

Later on, I get a glimpse into the management of the team, and witness how the developers are pressured constantly to deliver more features, forget the bugs, and “commit” to delivering requirements they had no hand in writing and no say in the timetable for delivery.

It is damn near impossible to get developers to really take ownership of their code when all the circumstances of the project are implying: “Shit it and ship it!”

Development teams must have veto power over scope and estimates, which I’m sure scares a large contingent of managers out there, but without that there is no hope for “ownership.”