Making promises
I have a hard time making promises. You see, I'm an engineer. I deal with inanimate objects, laws of physics, software. These things are notoriously unmoved by persuasion, argument, anger, cajoling, threat, incentive or contract terms. We engineers live at that distinctly difficult place where the elastic rubber of human expectation meets the hard road of reality. In other words, we have to fulfill what the salesman promised.
In the world of software, making any kind of estimate is risky business. There have been books written on why this is so, so I'll not trouble you with my own explanation. It must suffice to say that anyone who doesn't accept that this is true and inescapable is not living in the same world that I am. But that doesn't stop bosses and salesmen from selling unimplemented features and promising delivery dates, usually without asking the people who have to make it happen. In fact, this is the conventional management approach for getting engineering to produce.
The former CEO of the company I used to work for used this technique all the time to "take business off the table" as he put it. In other words, promise the customer a feature set or delivery date to get them to sign the contract. Often, he wouldn't even tell Engineering until a few weeks before the actual delivery. Then, we'd have to hack something together in crisis mode. To be fair, he would always take the heat from the customer when we didn't make the date, but it sure didn't do a lot for my blood pressure, or the quality of the work, or my estimation of him, or after a time, the company's reputation. I found this technique of promising and then "managing" failed expectations abominable.
In my experience, it is far better to be completely transparent and not yield to the great temptation to promise, or even suggest that something can "probably" be done.
What do you think?
In the world of software, making any kind of estimate is risky business. There have been books written on why this is so, so I'll not trouble you with my own explanation. It must suffice to say that anyone who doesn't accept that this is true and inescapable is not living in the same world that I am. But that doesn't stop bosses and salesmen from selling unimplemented features and promising delivery dates, usually without asking the people who have to make it happen. In fact, this is the conventional management approach for getting engineering to produce.
The former CEO of the company I used to work for used this technique all the time to "take business off the table" as he put it. In other words, promise the customer a feature set or delivery date to get them to sign the contract. Often, he wouldn't even tell Engineering until a few weeks before the actual delivery. Then, we'd have to hack something together in crisis mode. To be fair, he would always take the heat from the customer when we didn't make the date, but it sure didn't do a lot for my blood pressure, or the quality of the work, or my estimation of him, or after a time, the company's reputation. I found this technique of promising and then "managing" failed expectations abominable.
In my experience, it is far better to be completely transparent and not yield to the great temptation to promise, or even suggest that something can "probably" be done.
What do you think?
posted by Joe C at 7:41 AM
Rss Feed
2 Comments:
Great minds do indeed think alike, Joe! (see the link on my name for the reference)
I had a similar experience with a previous business partner. In the early days it was just he and I. We would both meet with the client and hash out the details and features of the project. As we grew, his task became to meet with the client while I moved behind the scenes and managed the business and our growing team of programmers.
I took control of the company and parted ways with that partner when we realized he had been making promises to the client for features and functionality that wasn't covered in the contract. Just to get them to sign our proposals and so they would "love him" and be excited about all the things he promised that we'd "just throw in" that they wouldn't have to pay for.
I think it's really helpful when management and the sales team has a better understanding of how engineering works and why sometimes the things that seem to be small and simple can often times be the most time consuming and difficult to implement.
i too am up for transparency, and yet, having a due date can be very orienting for a person like me with so many interests. That said, the *energy* of a promise is so dfferent from that of a due date in my world. It often has the undertones of manipulation.
Post a Comment
<< Home