JSCD: Taking Ownership of Your Team's Product

This week, I took on a task to fix some buggy table headers on my company's highly trafficked website. The webpages in question had a table that, when scrolled vertically, stuck the table header to the page top, so you could still see the headings for the data you were viewing. The bugs were:

1. The sticky header wouldn't scroll horizontally along with the table underneath it.
2. On mobile, the sticky headers' columns and the table columns would misalign.

I figured out that the sticky header was generated by a jQuery library introduced into our codebase some 4 years ago. This library cloned the HTML header and dynamically set the column widths equal to the widths of the table's columns. However, on mobile screens, the cloned header seemed to stop "obeying" the jQuery function, and its column widths would shrink further than those of the table.

At our sprint retrospective, I spoke up about the challenges I experienced in resolving the bugs listed above. My colleague Doug then asked, "Who wrote the code for these sticky headers from hell?" We all looked over at Andrew, who threw his hands up and replied, "Hey, I saw a library; it seemed to do the job, so I threw it in there. I didn't code nothing - check the PR out, it's a large block of green for the library I dumped in."

I half-expected Doug to respond that since Andrew was to "blame" for the now-buggy original jQuery code, he should at least work with me to fix the issues. But that is not the turn our meeting took. Instead, we started discussing the possible reasons for the bugs We created a list of possible avenues I could investigate for a solution. We brainstormed other ways of presenting those tables without cloning the header row, and decided that further conversations about it should involve our Design teammates.

It was refreshing seeing how every teammate assumed the responsibility of figuring out how to fix the issues. Very little time was spent on "who did this? why did they do it? who approved what they did?" Much more time was spent on generating several approaches for dealing with the issues, as well as how to update our documentation to avoid similar issues from arising in the future. My team takes on dozens of tickets and issues every sprint, so none of us are lacking for work. However, thankfully, there is little territorialism among us; regardless of the person officially assigned to a ticket, it's EVERYBODY'S ticket. We constantly draw on each other's time and strengths, working as a unit to make collective progress during each sprint.

I learned this week that a blame-focused work environment does very little to promote confidence, transparency and growth. Rather, it places everyone involved on the defensive, defines people by their mistakes instead of their improvements, and breeds the compulsion to constantly cover one's butt. However, a focus on team ownership produces a breathable work environment, where errors are readily embraced as learning opportunities and any weak links are compassionately reinforced.