Here's where I suspect things go wrong. I see a combination of two ideas at the core of a lot of corporate dysfunction.
The former is obviously true. Wanting is cheap, instantaneous, and unencumbered. I want a car with a 500K mile all-inclusive warranty, Maserati looks and performance, moped operating costs, and a Hot Wheels sticker price. And I want it to drive itself. I am betting that the average reader had at least three improvements they would make to my wish list. None of us expect to see such a thing, of course. The engineering and design costs and material costs make this impossible.
Wanting is cheap, but invention and production are expensive. There are material costs, costs of design, costs of errors and rework, costs of research, time and materials. There are human beings who do design, and they like to be paid. It takes them longer to work out the requirements than it does for me to decide I would like a new kind of car, or desk lamp, or smart phone. Again, it is the very nature of work that invention is generally much more expensive than desire.
Now, an astute reader will see the first statement as an axiom. I should adjust my desires and decide which things I really, really want first. I should realize that all the things I want will take time, and perhaps more time than one would expect. I should not be surprised that I will want many more things before the first thing I desired is complete and delivered. I should realize that many of the things I want are beyond the capacity of the market to provide (at least for now). I should realize that I may have to sacrifice some less important desires (however achievable) to achieve some greater ones. I should expect to be disappointed if I do not adjust my expectations.
On the other hand, the less-astute reader will take this as a problem statement:
That sounds quite reasonable, but it isn't. The second statement (that trying harder always gets more done) is false.
That second statement rephrases technical issues as motivational issues.
It takes a problem from a context in which it can be managed (quality, technique, capacity, and priority) and into a context in which it cannot be solved but can be easily worsened (motivation).
It amplifies a misunderstanding of the first statement in a particularly bad and quite synergistic way.
Inventors and designers have frequently worked themselves past a point of diminishing returns. A tired, cranky, unfulfilled, pressurized worker does not become better by trying harder. Trying harder only works a little bit, and only for a little while, and only if the developer was not really trying hard to begin with. After the frustration sets in, trying harder just makes it worse.
Sometimes you need a more orderly approach and not a more passionate one.
Sometimes you need some new skills and techniques, not a greater display of sacrificial devotion.
If a team can not achieve more by working harder, or will not produce as well, then heaping on more pressure is a poor choice.
My colleague in practice, Darrin, brought up Taylorism and Anti-Taylorism over at Agile In A Flash. Of course, a large number of talks at Agile 2009 are on managing backlogs, improving quality, and dealing with productivity. The meme is in the air (as it has been since before Mythical Man Month). I wonder how many development problems we can solve if we can just accept the first statement as an axiom and recognize the second as a falsehood? How can we bring this about?
I suspect we will need to develop some kind of "desire management" discipline. What would its tools be?
The secret, we're told, is to:
- I can want things faster than you can build them.
- I believe that you can always do more if you really try.
The former is obviously true. Wanting is cheap, instantaneous, and unencumbered. I want a car with a 500K mile all-inclusive warranty, Maserati looks and performance, moped operating costs, and a Hot Wheels sticker price. And I want it to drive itself. I am betting that the average reader had at least three improvements they would make to my wish list. None of us expect to see such a thing, of course. The engineering and design costs and material costs make this impossible.
Wanting is cheap, but invention and production are expensive. There are material costs, costs of design, costs of errors and rework, costs of research, time and materials. There are human beings who do design, and they like to be paid. It takes them longer to work out the requirements than it does for me to decide I would like a new kind of car, or desk lamp, or smart phone. Again, it is the very nature of work that invention is generally much more expensive than desire.
Now, an astute reader will see the first statement as an axiom. I should adjust my desires and decide which things I really, really want first. I should realize that all the things I want will take time, and perhaps more time than one would expect. I should not be surprised that I will want many more things before the first thing I desired is complete and delivered. I should realize that many of the things I want are beyond the capacity of the market to provide (at least for now). I should realize that I may have to sacrifice some less important desires (however achievable) to achieve some greater ones. I should expect to be disappointed if I do not adjust my expectations.
On the other hand, the less-astute reader will take this as a problem statement:
- the team is, for some reason, not delivering the things we want fast enough.
- yet people can always get more done by trying harder
- they aren't really trying
- they don't care enough
That sounds quite reasonable, but it isn't. The second statement (that trying harder always gets more done) is false.
That second statement rephrases technical issues as motivational issues.
It takes a problem from a context in which it can be managed (quality, technique, capacity, and priority) and into a context in which it cannot be solved but can be easily worsened (motivation).
It amplifies a misunderstanding of the first statement in a particularly bad and quite synergistic way.
Inventors and designers have frequently worked themselves past a point of diminishing returns. A tired, cranky, unfulfilled, pressurized worker does not become better by trying harder. Trying harder only works a little bit, and only for a little while, and only if the developer was not really trying hard to begin with. After the frustration sets in, trying harder just makes it worse.
Sometimes you need a more orderly approach and not a more passionate one.
Sometimes you need some new skills and techniques, not a greater display of sacrificial devotion.
If a team can not achieve more by working harder, or will not produce as well, then heaping on more pressure is a poor choice.
My colleague in practice, Darrin, brought up Taylorism and Anti-Taylorism over at Agile In A Flash. Of course, a large number of talks at Agile 2009 are on managing backlogs, improving quality, and dealing with productivity. The meme is in the air (as it has been since before Mythical Man Month). I wonder how many development problems we can solve if we can just accept the first statement as an axiom and recognize the second as a falsehood? How can we bring this about?
I suspect we will need to develop some kind of "desire management" discipline. What would its tools be?
- Value assessment. We should get past "want" and "contract" and into issues of value. What features will most improve our standing in the market? What features will most improve our reputation? Which features will cheapen us? Which yield little or no ongoing improvement? Which features will never really be used (AKA "checklist features")? Which should we farm out? Which should we partner out? Which should we forget about? and which should we really be spending our time implementing?
- Value Alignment. In particular, we need to be more interested in what our customers value. The backlog has to stop being a way that our sales/product/management staff compete against each other and become a way that we improve the value of our company and our product in the market. We need to want better things.
- Cost assessment. We need to quit trying to drive estimates downward, and take them under advisement. Even today, most estimates are ambitious and not conservative (more likely to go long than fall short) and yet we try to push them down to a cost we want rather than adjusting our desires to be within our budgets. That needs a rethink.
- Expectation management. We need to get the truth about capacity, WIP to the decision-makers in our organizations. None of our companies have unlimited capacity, and lean concepts are the only way we know to really get the best out of our people. The system has limits, and we need to respect them first and adjust them second. We cannot simply ignore them.
- Controlled disappointment. We need to stop stringing our customers along. Sales, marketing, and developers alike have a nasty habit of wishful thinking. They put things on the backlog that are not realistically going to be completed in the next month, the next year, or the next three years. I might suggest honesty instead of delay tactics. This work is not going to be done any time soon. Will your customers be happier and respect you more if you keep telling them it will? I think they'll be disappointed to find the work won't be done, but moreso if they find out after a series of false assurances to the contrary. Controlled disappointment might be a good policy.
- Operational cost assessment. Maybe we should not consider a $2M contract a win if it will take $1M to build the feature, and will increase operating costs by $10K per month for the indefinite future, and implementing the feature will cause us to lose $3M in opportunities as other features are delayed. ROI is not all about the money we can make on a contract, and development efforts go into the red more often than anyone wants to admit.
The secret, we're told, is to:
- do less
- do it better, and
- do it more often.
You've said it better than I could. Maybe someday I'll be good at this like you. :-)
ReplyDeleteCould I add bullets to your list of do's at the end?
(*) Assume you cannot ever truly understand your process.
(*) Run little experiments to confirm or disprove your suspicions about your process.
(*) Find simpler ways to do everything.
(*) Study to gain sophistication for handling times when your experiments neither prove nor disprove your expectations. These are tricky.
Those aren't as pithy as yours.
Interesting theme...
ReplyDeleteI might however point out that having known people who actually owned Fiats, I can assure you that you DO NOT want a car with Fiat operating costs. ;-)
Another issue with the concept of "desire management" is what do you do when the "unreasonable" desires are the primary reason that your employer was awarded a particular project?
You know that I fully understand the concept of opportunity costs, so let's skip the discussion for now. If you really NEED a particular project, for whatever reason, and that project comes with expectations that you know you will cause major issues in the development process, what do you do? Do you refuse the project, and then go looking for a new employer?
If you know that they only hope you have of getting an order that you truly need is to make promises that my be nearly impossible to keep, then what?
Working as I do now at a much smaller company, where I am much closer to the actual sales situation, I have come to realize that the no-win scenario is much more common place than I used to imagine.
I am not intentionally being negative here. I guess I could say that perhaps the "desire management" might at times need to be internal to the development team. Managing the desire to have simpler choices than the situation actually requires.
Wally: point well taken. My expectations are no more important than others. We all need a dose of Kregognizing the world we live inK I guess.
ReplyDeleteSome thoughts:
ReplyDelete- These same issues impact IT operations as well. In fact, as I noted on Twitter, there is often a cascading effect.
- The nature of the urgency here means there is no time to improve process, which leads to an inability to provide longer term solutions that could improve velocity without impact on the engineers involved. For instance, it's hard to build automated DevOps and CI/CD at the same time you have to get that thing out "yesterday".
- While the argument that teams that are burned out perform less is both accurate and that is most likely to resonate with leadership, I think it's important to frame this as a moral question too: it is morally wrong to demand too much effort/time from your employees. This is something I think we, as workers, need to defend sacredly.
- Much of what gets discussed to solve this dilemma is actually trying to work around fundamental issues in corporate mindset. They don't want to hire enough people. They don't want to accept the reality that they need to add more time, and/or be flexible about, the time features take to build. Conversely they don't want to accept less features in the time given.
I'm not saying "they" are bad here. I'm saying "they", or rather we at perhaps at even a societal level, need to rethink our core beliefs, because clearly a subtext here is "in order to maintain position in a capitalist framework, we don't want to have to treat human workers humanely".
And that's not anti-capitalist either - I'm saying we need to rethink the some basic precepts around the relation of labor and it's role/value in capitalist endeavors.
So, to me it's not "How do we fix this in our org?", what you write is true about almost every org. It's about how do we change how we think about what we expect out of labor as a society?