So there you are, a sales person in a high-pressure sales meeting, demonstrating to the customer all of the awesome features of the system, and showing them stunning presentations about ROI and scalability. Everything is cooking right along, and you can almost smell the big fat commission coming from this sale. After you're done, the customer takes it all in, leans back in their chair and asks, "Can it do...."?
Can it do...? The moment of truth arrives. If you say "no", you risk losing the sale and your commission. If you say "yes", then your development team is going to have some work to do. So, you take the easy and profitable path and say "Yes, we can make it do that by..." The customer is thrilled and signs the deal. Your business has made another sale, acquired another prestigious customer and you get paid. Awesome!!
But not so fast. I'm NOT pleased.
You did what?!? You told them we could do that? Are you out of your freakin' mind? Don't you have any clue how hard that will be? Don't you have any idea how crappy the quality will be if we deliver in the time frame you promised? You just single-handedly created a nightmare support situation, and made getting the sale much worse than not. I would have been toasting with you, but now I just want to strangle you. Why can't you sales people sell what we have? You're not a sales person, because they actually sell something that is real. You, my friend, are a promise maker, counting on someone else to deliver. That takes no skill. Want to impress me: use sales skills to sell something, instead of throwing my nights and weekends under the bus so you can pocket the coin. Anyone can make a promise you jack wagon.
(Calming down now.. Deep breaths.. Finding my happy place..)
Two terrible mistakes were made in this scenario. First, the sales person made a promise that assumes the development team has the ability to deliver the desired feature. How does the sales person know that the developers have the knowledge and skill needed to "pull it off"?
(WARNING: If you are a sales person, and ever find yourself thinking or speaking the phrase "pull it off", then you are entering very risky territory. Good software is never "pulled off".)
Second, the sales person gave the customer a time-frame for delivery. Once again, how does the sales person know that the feature can be done in the time promised? Does the sales person have the knowledge, skills and clairvoyance to know all of these things? If not, then who does? Who IS qualified to address these issues? Why... the architect, of course.
So, I want to tweak the sales process a little here, and introduce the one party that can reliably speak to feature requests and time-frames. The next time a customer asks "Can it do.....", before answering, contact your architect and run it by them. Give them a little time to determine what to do and how to do it. (If you really want to impress me, you'll make an architect a member of your sales team.) After they've had a chance to determine the best way to deliver, only then provide an answer to the customer. First, the answer will be one with some actual delivery power behind it. Second, it will be done in a way as to not create bigger problems in the future. Third, the solution will be designed in a way to add to your company's list of leveraged assets.
At one place I worked (which will remain nameless to protect the guilty) the promissory sales technique was a really big problem, and I had my fill of it. I used to get angry in management meetings because the executives continued to allow it. One day I proposed what I believed was an equitable plan.
It went something like this.. Each time a salesman sold something our products did not do, that their sales commission be split with the developers. I saw this as a way to incent the sales team to sell what we had, thus keeping 100% of their commission; but also a way to make sure the developers enjoyed the fruits of constantly delivering under the gun, keeping their growing malcontent at bay. The idea got tossed around some, but never enacted, which is a shame. Over time, my developers grew more and more discontent as their nights and weekends became more of a distant memory, and the quality of their work and commitment diminished right along with it.
In conclusion, I hope you understand that there are very real dangers in not involving an architect in the sales process. Only the architect can speak to your ability to deliver a desired function. Only the architect has any business estimating a date for that delivery. And only the architect has the vision to make sure the function is done in a way that adds to your strategic assets, allowing it to be leveraged over time. By not involving the architect, you may very well end up with a one-off implementation that cannot be reused, a significant and costly support headache, an unhappy and less productive development team, and ultimately unhappy customers.
Here! Here!
ReplyDelete