The Value Statement

Several weeks ago, I received an forwarded newsletter from Mountain Goat Software that essentially stated that the higher you move up in any organization, the more difficult it is to distill your job responsibilities to a discrete checklist. The newsletter described this paradox by contrasting the examples of delivering newspapers to running an organization as the CEO. While delivering newspapers is discrete and well defined, running an organization entails responsibilities such as “making money” and “creating a great culture”.

When I was in school for my MBA, I was warned by several professors about checking your value statement in an organization. In other words, if you were at a dinner party and someone asked you “what you do”, would you be able to say something like “putting out fires” or would you struggle with something such as “cost accounting in excel”. In this manner, we were taught about making sure our roles in the organization aligned to the value of the overall organization.

In larger organizations, misalignment is easier to cultivate, and you could find yourself in the unfortunate position where you are performing a redundant job task. Or job tasks that provide incredibly little value.

The fundamental truth is that there is value in work. And there is more value in work that is purposeful and powerful in an organization. Stay away from terms such as “creating a great culture”, but instead provide discrete examples of how you might create that great culture.

When my organization first embraced Agile, there was an uncanny attraction to crafting user stories in the format of:

As a _____, I would like _____ so that _____.

At first this format was annoying. As a what? Every unit of work was required to be framed in the context of the benefit it added to the organization. And while it was somewhat frustrating, it required us to align our work. Who was the user story benefiting? At first the teams started specifying the pilot as the user, which was powerful in the event that the actual pilot was the recipient of this work. Later on, teams would specify other developers in the organization as the user when specifying user stories that required refactoring and/or technical debt. By framing our stories this way, we first encountered a cultural phenomenon where technical debt user stories were dubious, because the value was less obvious. In the end, the value of technical debt user stories was better realized.

Jeff Bezos has a famous Day 1 philosophy where he champions mantras such as:

  • Focus on results and not process.
  • Make decisions quickly.

which describe the cultural change that happens as organizations slowly shift to stasis, or more recently described as the “march to mediocrity”. While Amazon has come under fire for policies that try to incentive high performance, the reality is that there is no surprise that large companies become easily disrupted by new technologies.

As a manager and professional myself, I am dubious of job descriptions such as “create a great culture” or “make money”. Far too often I encounter employees whose value can be reduced to simply taking “meeting minutes” or “checking email”. Yes you could argue this is a part of creating culture, but the most powerful organizations adopt a day 1 philosophy where job duties are aligned and clearly pertinent to the overall goals of the organization.

Leave a Reply

Your email address will not be published. Required fields are marked *