Why "Values" Feel Useless to Engineers

Many technical people (myself included) have rolled their eyes when presented with "Company Values". They feel like a way to cheer-lead good behavior akin to high school Spirit rallies.

I felt this way myself until I read Chip & Dan Heath's book Decisive. They helped clarify for me the real, primary purpose of personal and corporate values: prioritization decisions. A generic value like "We value helping others" feels trite, but when framed as, "We value helping someone out over getting my stuff done", now there is practical meaning. Helping others out is good, and so is accomplishing my work on time. If this is a value of mine, then when deciding whether to help someone who asks or tell them I'm too busy so I can finish my own work on time, I will prioritize the former. Corporate values frequently are trite, but well-written ones help people make trade-offs between good options.

In light of this, my work team (the SEU) at Turnitin put together our own set of values, which I’ve found extremely useful to review with new members joining us.

1) We value helping someone out over getting my stuff done.

2) We value consistent, unified solutions over engineer-specific solutions.

3) We value doing it the best way over doing it my way.

4) We value listening and discussing over asserting rank.

5) We value partnering over silos and lone-rangerism.

6) We value responding to change over sticking with what I worked on.

7) We value candor over excessive filtering of our words.

8) We value taking responsibility over making excuses.

9) We value showing grace and preventing mistakes over assigning blame.

10) We value proactively adding value to each other and other teams over waiting for them to ask.

11) We value long-term personal relationships over being hyper-efficient.

12) We value doing work our team can take pride in over merely satisfying requirements.

13) We value agile development over waiting for exhaustive requirements.

14) We value doing it right over doing it fast, where right means:

15) We value the functionality of old software (respecting and understanding it before we change it) over rushing to replace it.

16) We value cross-pollination and learning (through training, code review, and pairing) over saving time.

17) We value completing and owning projects for the long haul over moving to the next thing quickly.

18) We value exploration and experimentation over fanaticism or rigid rule-keeping.

The Agile Manifesto is a great example of values done right, and highlights another point, that values should not be interpreted mechanically. Think of it this way: an expressed value adds "weight" to one side that must still be weighed against other factors. Just because I value "individuals and interactions over processes and tools" does not mean we should prefer human interactions over use of a process in every case.

Values are easy to repeat or agree with. The real difficulty is making your culture actually live up to them. As I read our own list again I’m sure it drips with extra meaning for me because I get to see them played out in the day-to-day decisions of our team members. I’m proud to say that I work with a great group of people who, on the whole, live these values out. I hope you’re inspired by some of them, but be warned that instilling values, like any cultural change, is an arduous road. It’s also worth it.

You may look at your own company’s stated values and feel like they are unhelpfully generic (many are). As an employee you can do two things: 1) Appreciate that the leadership team chose these values for specific reasons, that those terms probably have meaning to them that is not obvious to you; 2) Ask about it.

Ask yourself: