Delivering value
It’s quite the rage today to talk about “delivering value” as opposed to “delivering software”. That scares me.
Consider the contractor who had our house in chaos for what seems like forever. We now have more counter space in the two upstairs bathrooms. I think you could make a strong argument that he would have delivered more value to us if he’d taught us–two of us in particular–how to more efficiently use the space we already had. And yet I’m glad he didn’t. I preferred him to deliver what we wanted to pay him to deliver.
On the other hand, my dad built houses. I remember him once telling a prospective client that the architect’s plans they had were wrong. Given the man’s job, he’d come home dirty every day, so he’d probably want to go directly to the shower. The plans had him tromping all through the house. Instead, he needed a doorway from the garage to a little hall with a bathroom one step away. I think they let him redraw the plans, thereby delivering more value.
So there’s a tricky balance here. Are we up to it?
As my wife put it the first time she met my friends, “You software people have really strong opinions… about everything!” The average software person is more likely than, say, the average veterinarian to talk to someone briefly about her job and immediately come up with ten ways she ought to do it better. Telling such a jumper-to-conclusions that the team should look beyond what the business wants to what it needs is… maybe tempting them to play to their weaknesses.
I would instead tell a team they must, over the course of many months, prove to the business that they are worthy of being invited to the larger conversation about what the business needs. And to do that, they must–first and foremost–deliver what the business wants, while also acting as a humble student of that business.
January 25th, 2010 at 11:16 pm
I don’t remember when nor why, but I stopped talking about “delivering value to customers” and began talking about “helping customers deliver value for themselves”. I emphasize this in my training and coaching work. I invite others to make the same mental shift.
January 26th, 2010 at 7:35 am
[…] Delivering value (Brian Marick) […]
January 26th, 2010 at 8:27 am
I think I used to fall prey to this temptation when doing work for customers. The change occurred when I had a project and needed to retain consultants. All the second guessing definitely brought attention to the plank in my eye.
You brought up an interesting point about humility of the consultant, but the humility of the customer was also a factor. Your father’s advice may have fallen on deaf ears were it not for the humility (or something) of his prospective clients in hearing what a builder had to say. Perhaps your father sensed something in the customers and that is why he offered the advice. It makes sense to take into account specific customers, and determine what sort of relationship they want.
January 26th, 2010 at 5:58 pm
“humble student of the business” strikes me as the most important aspect of this message. By assuming that role, perhaps we’ll be less likely to force our perception of value onto the business and accept that the business may better understand what is valuable to them than we.
We also need to be sufficiently expert in /our/ business, of creating software, that we can actually deliver something valuable.
January 28th, 2010 at 4:12 pm
Delivering value strikes me as one of what I’m coming to think of as the “ergodic issues” (in the kind of borrowing of vocabulary that I used to get quite angry about)—that is, the longer one thinks about it the more thinly and evenly the amount of thinking one can do gets spread over all the things there are think about. Until the starting point is both lost and irrelevant.
Are we up to it? Probably not.
What would it be like to be up to it? We have in the folklore plenty of horror stories about the business stating their problem in the form of the absence of some very unsuitable solution which it happens they can imagine. But I’m not sure that’s what you mean. In the example of your dad and the ill–designed house his critique seems to have been of a poor solution suggested by some other professional rather than an inappropriate requirement from the client. Did the guy with the messy job *ask* for the bathroom to be far away from the door?
Meanwhile, some of my folks are working on a project to produce custom CAD/CAM tools for a heavy engineering firm. We have carefully structured the contract so that whether or not the outputs the tools give are correct is very much the client’s concern. If one of the gadgets they design with these tools blew up it would be national news and the liability would sink us. But that the tools give the outputs that the client expects them to, as specified, is our responsibility.
Is suspect that “delivering value” is a passing fad. I tell my consulting clients to be highly suspicious of arguments to do with value, particularly scheduling work by “highest value first”.
Then again, I meet teams who have been trained by quite brutal operant conditioning to deliver only and exactly the imagined solution that the business asks for. The business has learned to do this because if they don’t they infer form past experience that otherwise the team are likely to deliver any random thing (including nothing). And on yet another hand I see quite expensive projects do a very technically competent job of delivering good quality sophisticated solutions that it turns out no-one ever wanted. And this turns out not to be a problem for the business because no–one cares about the outcome of the project anyway. Someone on the receiving end of that sort of thing could well come to pine for “value”.
And now my thinking is spread too thin.
March 25th, 2010 at 4:01 am
Indeed, I can agree with the sentiment.
At one gig I worked, the customer would say “we want an Oracle report”, and the devs would say “that’s he solution, bring me the problem. The best solution might be a web app, or a SQL query you run from MS Access. Just bring me the problem.”
Of course, if you try on the project level, the customer could ask you to develop a new product or service, but you say “Wait, the real problem is you want more money, right? So the solution might be that we do a PR campaign …”
For engineers, for some reason, the first example is perfectly valid but it’s obvious that the 2nd is a problem. I’m not sure where the line between the two is.
A good point well made.