... was a saying Ohioan and I used to use when we worked together on a business development team. Once a customer has decided to purchase your product, the only thing you can do from there on out is screw up the deal. Keep your mouth shut and let the customer do all of the talking.
I've had the occasion to use this advice myself twice recently. At work, there is a major program that has been instructed by their sponsors to integrate with my work. In fact, integrating with my stuff is their #1 priority right now. Their system is built on a rigid and brittle Oracle database with a clumsy front end, typical of such creatures. The database does some really good things, but it's being forced to perform tasks unsuited for databases.
I'm working in Jira which is tailor-made for workflows and project management. The other team must be 20 or so people. My team is me plus the SMEs from my customers. The comparison in agility between the two sides becomes dramatically obvious when we have integration meetings. Those are usually me and a dozen of them.
Since they have been told to integrate with me, I don't have to make a sale. Because their product is so fragile, they're realizing that this integration is going to break various aspects of their tool, requiring them to disable certain event triggers. I don't envy their task and I actually like and respect that team.
As I recalled the "don't talk" maxim, I began to think about what I was listening to as the other side tumbled through the implications of our integration. They were emotionally coming to grips with just what the integration meant. In addition, they had expected the first 3 months of our integration to be meetings and documents. Instead, they discovered they will be expected to produce a working product.
I have no problems with this integration. On my side, the work will take about a week, followed by live testing. On their side, just getting the team all going in the same direction will be a chore. By not talking past the point of sale, I wasn't getting in the way of their evolution of thought. My role now is to remove every impediment I possibly can and make myself available for consultations.
They're on an emotional journey as much as a technical one and such things cannot be rushed.
In my personal life, I've been looking at vacation property in Alabama for about a year. I'm in Foley right now on a 5-day jaunt. Working with a realtor here in Baldwin County, I think I've found the place. It's absolutely stellar, right on the river, in a good neighborhood with all the features I was hoping to find. It's got some quirks, but they're manageable.
Wife kitteh has been supportive, but has pulled up short when I've found good candidates. This is my dream, not hers. We missed out on a superb property about 9 months ago because she couldn't bring herself to pull the trigger. This time, she got cold feet when I told her about it over the phone. The next day, we talked and she was down with the purchase. I didn't press her because I love and respect her too much to do that. I let her describe her reservations and how she had overcome them. They weren't major, but she needed time to work through them in her head.
This was another case of not talking past the point of sale. When your customer or your wife makes a major decision, the emotional evolution can't be rushed. If you try to push people in these circumstances, chances are good they will get their backs up and scotch the whole thing.
By not talking and simply being supportive and understanding, you are giving them the space they need to process what is happening. They may never know you did that or appreciate it, but it will make a big difference in your relationship going forward.
This is the view from the back porch of one of the properties I saw. |
2 comments:
In college, I had a terrible professor for database. And as a result, I've always hated databases. That's my excuse of course.
I've been sucked into Oracle, MSSQL, postgres, MySQL, Sybase, etc for years.
Our product is a hospital management, scheduling, oncall, paging, etc, all wrapped around Oracle. It is a huge beast of a thing, and works really well. Java, APEX, C++, etc. Also, installing and linking MSSQL to the Oracle DB.
I'm the integrator, I write the stuff that installs everything, from installing RedHat to installing the database (primary and standby), and all the 30 or so in house programs that do all the things needed. 8 ISOs with 50-60GB of stuff. Half of that is as much current RedHat patches as I can get, in the event the customer doesn't allow connecting to the internet. Which is becoming increasingly unrealistic.
My biggest frustration is Oracle patching. Every 3 months, I have to package up new ISOs that will patch Oracle DB and Weblogic. The rules are simple, the database can't be down. Requiring that the database have few interactions is ok, but patch switch the primary, patch, and switch back.
Patching has becoming increasingly difficult in the past year. Adding new patch files for new bugs they've introduced, having to remove old patches before installing the new ones because the new version of the patch can't deal with the old one being there. Patching time was growning past 4 hours. Had to find how to remove inactive patches, that sped up patching by more than double.
My opinion of database hasn't changed.
I'm thinking in my free time/retirement of rewriting a badly formed MySQL database I wrote for myself in MSSQL. Being who I am, that MSSQL will run on a Linux machine.
I think I used Jira for a short time at my previous job. We'd converted from Rally to Jira. This job is in Rally. It's all the same to me, overhead for management to try to understand if I've done any work.
Hmm, I'm not anonymous. Why did it do that?
Post a Comment