The Law of the Instrument

Jeff Geerling (CC BY-NC-SA 2.0)
It's been said that "if all you have is a hammer, everything looks like a nail." That's a cognitive bias called the 'Law of the Instrument,' and one that I've encountered in the workplace a number of times. It might sound familiar to you as well. 

The worst example I can give is of the time I worked in a division of a company that used Power Point for pretty much everything. All reporting took place through Power Point slides, which is fine for high level presentations but not great when you need to get into details. Not long into my employment I was told emphatically that I had to create a 'detailed project plan' in Power Point. On one occasion I joined a meeting to discover that the person running it had used a one slide Power Point deck for the agenda. It was as if no one could imagine there being a different way to work.

Honestly, I don't know how it gets this bad in an organization. That it becomes a hidebound tradition is obvious, so much a part of the culture that no one questions it, and if they do there's no serious intention behind it to make a change. Maybe it began early on in the life of the group, and it could be that someone of particularly high seniority demanded that so much be done using one tool that for safety's sake people began using it for everything. It probably varies in origin from company to company. However it started, it's detrimental.

The capabilities of one tool alone become confining for a business unit, hampering work and narrowing horizons. Using the example above, there's no way to create a truly 'detailed' project plan of the quality a project or program management professional could take pride in. Or consider the agenda list on a single, standalone slide. Wouldn't that be better in a shared document where agendas and notes for a project can be gathered into one place?

Many years ago I worked at a startup where, every time there was an organizational shakeup, we got a new issue tracking system. The first (and my favorite) was Jira, but there were three more after that in the roughly two years of my employment, before the company folded. While I preferred Jira, any one of the tracking systems was just fine for what it did. I would not have considered, however, using them for some unintended purpose, like taking meeting notes or creating presentations for meetings. There were many tool options for one purpose, which was tracking issues, and it was a matter of choosing one that worked best for us and using it.

While most organizations I've worked with that use Jira also use Confluence, as it's made by the same company, that's not always the case. Confluence is a useful wiki-style collaborative knowledge base that I've used for many years, and to great benefit. However, in one company Jira was being used, but instead of Confluence there was SharePoint. While that struck me as an odd combo, it was also perfectly fine. I could do what I needed to do with SharePoint just as well as Confluence. Again, it's about using the right kind of tool for the purpose. 

Once, in preparation to lead an Agile transformation at a company, I discovered that a key team's backlog was in a 50 page Word document that only a manager had a copy of on his computer. Word is useful for writing up documentation, but not as a team's work backlog. It took some time, but I copied-and-pasted the items from that document into separate stories in Jira. When the team, along with their manager, were able to see the work together they quickly began discussing it and assigning priorities. Some stories were deleted entirely, while the others got cleaned up and prepped for future sprint planning. This could have been possible with a long Word document, but it would have been immensely more difficult. 

And there's the harm in the Law of the Instrument. Overuse of one tool, particularly in situations where it is ill-suited to the task, actually hampers progress. It becomes a matter of forcing the tool to be something it's not, and attempting to work around its insufficiencies. It's up to program, product, and engineering leads to define together a toolbox for their organization, and take steps to ensure that everyone who needs to use them has the preparation—and empowerment—to do so.

Popular posts from this blog

The Journey to Agile Transformation: A Scrum-Based Approach

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

Transforming a Traditional Engineering Team into an Agile Powerhouse