raganwald
Tuesday, August 08, 2006
  The Difference Between Values and Strategies
Put simply, a value is something you are willing to pay for. A strategy is something you hope will pay off for you.
A LISP programmer knows the value of everything, but the cost of nothing.
Alan Perlis

People mix these things up all the time, especially in business. Have you ever been to a corporate retreat where a select group of the annointed gathers to write a company's "Mission Statement"? Everything is couched in terms of values: "We shall strive for the highest standard of customer service..." "Employees are our greatest asset..." and so forth.

Sneak Peek

It's a lot of wind. But let's assume that everyone is sincere. Are these things values? You can tell by asking the CEO why you need a mission statement. Here is an answer you might receive:
Companies with Service-Oriented Mission Statements (SOMS) have a P/E ratio 14% higher than their peers as ranked by Booz, Alchie & Weide. Furthermore, customer service has proven to be a competitive advantage: a recent survey showed that 63% of our new accounts selected us because of our reputation for service.
That's a strategy. The CEO believes that she will make more money if they say these things. She may also believe that they will make more money if they actually try to do these things. But either way, it's about the money.

Salient question: if one day they woke up and discovered that they could make even more money by outsourcing their customer service to the third world and driving their customers crazy with frustration, would the 'de-hiring' be done by middle managers or by Bob and Bob?

I'm not saying this is right or wrong, mind you. I'm just saying that if you'd drop service to pursue money, money is your value and service is your strategy for making money. (It might help to think of values as ends and strategies as means).

Something isn't a value unless you... value it. That means you are willing to pay for it. You are willing to give something up to enjoy it. For example, if you absolutely flat-out refuse to work for tobacco companies and you make 20% less money working elsewhere, you have a value.

Or if you insist on top-notch customer service even though it means you have to price your product higher to pay for it, which means you have less market share, and you end up being a niche company in your market instead of vying to be come the next Wal-mart, customer service is actually one of your values.

Now quite frankly, I don't give a hoot about public companies, not even Apple Computer. So let's talk about building great software. What about this quality software thing?

Obviously, quality software can be a value as well as a strategy. We can pretty much take it as given that you can make more money selling oats that have already been through the horse than quality feed. So when you decide that you will make a personal commitment to write the very best software possible, you are acting on your values.

People often have trouble understanding each other when one of them is thinking about their values while the other is thinking about their strategies. Just look at all of the crap people have written about why Apple should license or should have licensed the Mac OS to clone makers.

Could it simply be a values issue? Maybe Apple values the whole user experience and doesn't care if licensing is a decent strategy for gaining market share. (I said if. Allegations that large herds of me-too clone buyers would prefer OS X to stolen copies of Windows are, as they say, unproven in court.)

And so it goes for personal productivity and expression, otherwise known to me as developing software. There are certain aspects of development that incite fractious debate: the people, the processes, and the tools (especially the languages and frameworks).

Honestly,we can have a debate, but let's make sure we're talking about the same thing: are you talking about the best strategies for achieving a certain value? Or are the people, process, and tools part of your values?

It may not work for you, but some people value working on certain kinds of teams. Some people value working in a certain kind of way, be it Agile or BDUF. It's part of their nature. And most especially, some people value expressing their ideas in a certain style, using certain idioms that closely match the way they think of the solution. It's a very deep value.

Constructive Debating

The crazy thing is, a lot of people are resistant to coming clean and saying "Hey, it's important to me personally to do it that way." Perhaps they fear being labelled some sort of difficult prima donna. Yet elsewhere in business, we value people that care about their work enough to set high standards for themselves.

But whether they confess or not, a lot of people have values in this area and choose to couch them in strategic terms. The result is a lot of confusion. The next time you see a flame war going on over REST-ful web service architecture, meta-programming, or whether/how to hire great programmers, step back and try to deduce which participants are defending their values and which are defending their strategies.

You know what? You can go a long, long way towards mutual respect and understanding if you come clean about your own values. Are you constantly defending Java against the Dynamic Typing Visigoths? Try this. Simply say (or write):
You know, this thing I'm using is good enough for my purposes. I enjoy using Eclipse. I like EJB 2.0/Hibernate/Spring. Working with the de-facto standard for Enterprise is one of my values. What you're saying is interesting, and I don't doubt it works for you, but nothing I've heard suggests switching to Rails would be aligned with my values. So it isn't for me.
That would shut me up, right quick. Because I value people actualizing their values.

Practices are values, too

What about practices? For example, are Agile practices values or a strategies?

People get into all sorts of debates as to whether pair programming or project spaces, for example, are more productive than giving programmers private offices. I'm not coming down on either side of the debate here, but I will point something out: there's an implicit assumption that pair programming is a strategy. And that productivity is the value.

That seems obvious. Isn't productivity the goal? Why value anything else?

Well, isn't it just possible that some software developers like the camaraderie of a project space? That some software developers enjoy real-time, high-bandwidth communciation with their customers?

I'll get personal. I get a thrill out of shipping software. Incremental development is one of my values. Even if you could prove it is slower than BDUF, I wouldn't switch. I love the feeling of delivering functionality over and over and over again.

For some people, Agile is a value. Luckily, there's a strong case that it's a good strategy. So a developer that values Agile can work with a customer that chooses an Agile strategy. Click.

Sometimes a value is also a good strategy.

Integrating Values and Strategies

Unless you are a philanthropist, you cannot pay for your values over and over and over again. You have to find strategies that pay for your values. Life is very, very good when you find a way to turn a value into a strategy.

For example. I like working on interesting problems. It's a value of mine. But a career (or a company) can only be built out of solving profitable problems. If I want to integrate my values with my strategies, I have to find interesting problems that are also profitable to solve. Obvious, no?

But before I close on this happy thought, a reminder: even though a value might be a good strategy today, times change and one day the value may no longer be a good strategy in its own right. That's when the real test of commitment will arise: will you have the courage to seek new strategies that still preserve your values, or will both value and strategy be cast aside? It's up to you, and quite honestly nobody knows how they will react until faced with the posibility of making a real sacrifice to preserve their values.

This has been said so many times, in so many different forms, it must be very, very true and simultaneously very, very elusive:

To be successful and happy, seek out opportunities where the strategies for success are tightly aligned with the things you personally value.

fin

Labels:

 

Comments on “The Difference Between Values and Strategies:
Curiosity: From where did that screenshot came from?
 
I love this article. It succinctly codifies the reason I left my last, secure, profitable, stable job for my new, potentially insecure, unprofitable, unstable job in words better than I was using to explain it to people.

Well said Reg.
 
very valuable :)

and appreciate.
 
Great Article. After reading many posts/comments on programming language s and software development, I was beginning to think if I am learning anything at all. As soon as somebody says something about a language/framework etc, somebody would contradict it in a blog/comment. But, your post made me realize that different people have different reasons(based on their value/strategy) to say what they say.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /