Tres Leches - The Apache Corp Story
WMMM #017 - A story of team selling and a creative way of using one’s background to build trust.
Cardinal Initiatives Newsletter May 20 2023 4 min read
This week I share a story about how to use an Executive Sponsor to help you win business.
Tres Leches - The Apache Corp. Story
The technology supplier was Oracle Corporation.
The customer was Apache Corp., a Fortune 500 company in the energy sector specializing in hydrocarbon exploration. Apache’s headquarters were in Houston, TX.
The characters:
Matt - the Oracle Account Manager
Kenyon - Matt’s Regional Sales Director
John - our Oracle Sales Consulting Manager
Aaron - the CIO for Apache
Apache was relatively new to our sales org, and we had assigned it to Matt, a newly-hired Account Manager. Matt was an excellent example of the kind of talent that Kenyon was bringing into the Company. He was a highly motivated sales professional with a ton of experience.
In an otherwise IBM and Microsoft account, Oracle had secured an important data warehouse in Apache’s IT department. An oil and gas industry application, written on the Oracle database, was the operational source for the data residing in this data warehouse.
Along with some contact names and a small amount of account transition information, Matt went to work on his plan of attack for Apache.
A QBR helps a sales strategy
I had just hosted a QBR for our team, and Matt had some fresh material to work with. His big takeaway was the team-selling concept. Identify the individuals in your account with the most significant influence over your success and map them to Oracle counterparts. The mapping exercise isn’t always as straightforward as you might think. The strategy often involves taking into account personality traits, outside interests, and location in addition to the role in the company.
One suggestion, in particular, caught Matt’s attention. Map the management and executive sponsors as soon as possible. It is best to have an introductory meeting when there isn’t a sales transaction. Doing it this way allows the relationship to be built naturally, not because either party wants something from the other.
Aaron, the CIO, was an important stakeholder. Although he wasn’t generally known to be an Oracle fan in this IBM and Microsoft shop, he had found favor with the performance of their data warehouse. In fact, Matt learned of an outside consultant that had helped Apache with its data warehouse design. A conversation with him provided us with more color on the account. We learned why Aaron viewed the data warehouse as a success. The outside consultant used an Oracle feature called “materialized views” in the design.
Going Deep
Kenyon recalled that I had a technical background and knew a thing or two about database management systems. He suggested that Matt ask me to be his executive sponsor, mapped to Aaron.
I do know a little about DBMS and development tools, but Kenyon may have been influenced (Halo Effect courtesy of behavioral psychology) by a technique I use to establish credibility.
When selling technology, it pays to go a mile wide with your knowledge base to give yourself the broadest reach. Know a little about as much as you can. You need not go a mile deep in your role as a salesperson. An inch or two is plenty. Most enterprise technology companies pair their salespeople with pre-sales engineers who possess the depth of knowledge that is required for customer-facing sales roles.
The mile-wide approach works well for awareness, but when you need to establish trust to build a relationship with certain types of individuals, “Go Deep.” By that, I mean pick one or two features of your technology and learn as much as possible about them.
My technical days ended long ago. My first role with Oracle was as a first-line sales manager. I encountered situations where my sales team would need me to establish a relationship with someone with a technical background. I developed this technique back then and kept using it throughout my career.
Row-level Locking
The first step in my process is identifying a feature that differentiates your technology. Row-level locking was the feature that helped Oracle win the database wars of the 1990s. SAP had emerged as the #1 ERP applications vendor, and Oracle became the preferred database under SAP due in part to the row-level locking feature. Reach out to your technical pre-sales counterpart for help identifying a feature.
Data must be locked for three of the basic persistent storage operations: create, read, update, and delete (CRUD). If you want to create, update, or delete data, the DBMS must “lock” that data to prevent another user from trying to access it before your operation is completed.
Row-level locking locks the data at the smallest, most granular level, the row in a relational table. The smaller the “lock,” the smaller the number of users prevented from accessing data. Database management systems began using memory rather than disk storage to “cache” data for those three CRUD operations. IBM’s DB2 would lock at the memory page level - page-level locking. A memory page can hold multiple rows of data, so it is a larger and less-granular locking technique - one page uses 4000 bytes of IBM memory.
So if you only wanted to change the “address” field in a customer record, which was only 30 characters (aka bytes), DB2 would lock 4000 bytes of customer records for the duration of the “update” transaction. The implication to the business is time:
More time waiting on a response from the system
Less time that data is available to you
Less time means fewer users with access
More time waiting means more extended periods where data isn’t current
Longer periods mean less accurate information.
You get the picture. Speed and efficiency are always better.
A Brief History Lesson
For perspective, SQL Server locked at the page level with a page size of 8000 bytes. Sybase originally developed SQL Server. Microsoft subsequently licensed Sybase’s technology and rebranded it as “SQL Server.”
Sybase was the strongest competitor to Oracle at the time that SAP needed to choose a preferred database for running its ERP applications. Row-level locking, with its advantages in performance and scale, helped Oracle become the standard for SAP. Sales of SAP’s ERP system running catapulted Oracle to a dominant market share (>40%) in the relational database market.
Mastering my row-level locking talk track had earned me credibility many times, and I was hoping it would work with Aaron.
Tres Leches
Matt and Kenyon wanted to use my title and technology background with Aaron. Matt arranged for a lunch meeting for the introduction. They asked me if I had a favorite place in Houston. I did. I had a few of them. One was Churrascos which served Latin food. They had a chimichurri marinated tenderloin and plantains which I loved. A fan favorite for my clients was this famous dessert called “Tres Leches Cake.” It was off-the-charts delicious.
Tres Leches literally means “three milks,” and this light vanilla cake was soaked in a sweet milk and cream mixture. Customers I had taken there unanimously loved this restaurant and this dessert. Unfortunately, Churrascos was located in River Oaks, a little too far away from Apache for a lunch meeting. Matt came to the rescue, finding a nearby Latin place, possibly inspired by Churrascos, with a similar menu and a Tres Leches dessert.
Materialized Views
My assignment was to build a relationship with Aaron, and I needed to learn about materialized views to do that. I turned to John for help.
John and I went to a conference room with a whiteboard in our Frisco, Texas offices. John grabbed a marker and explained materialized views and why a customer would want to use them. Excellent! Materialized views were a technique where “expensive” queries were cached in memory for better performance. This is very beneficial for high-frequency access but infrequent updates.
John did not stop there. Since we were discussing data warehouse design, he gave me a crash course on “Star Schemas” for good measure. Now I had three “Go Deep” areas to pull from if needed for my conversation with Aaron.
Conclusion
The lunch was perfect. You could almost walk from Apache’s office to the restaurant. The food was great, and Tres Leches was a hit once again. Aaron and his lieutenant appreciated my talk track, and I executed on row-level locking and materialized views. They assigned me more credibility than I personally deserved. There is no “I” in “team,” and my team earned the technical “cred,” especially John. We achieved our desired outcome and then some.
Aaron and I began a professional relationship without a transaction in play. The row-level locking discussion helped establish credibility and positioned Oracle in a more favorable light over both IBM and Microsoft.
One year later, Matt won a contract with Aaron and Apache that gave them unlimited use rights to the Oracle database and allowed them to replace SQL Server.
Summary & Lessons Learned:
1) Mile wide and an inch deep is a good strategy for awareness.
2) Going Deep on one or two features produces a “Halo Effect.”
3) Map your Executive Sponsor before a transaction is in play.
4) Never underestimate the influence of a great dessert.
Thank you for reading,
Jeff
If you like what you read, please share this with a friend.
I offer my help to sales leaders and their teams.
In my weekly newsletter, “Win More, Make More”, I provide tips, techniques, best practices, and real-life stories to help you improve your craft. Don’t miss an edition by subscribing here for free.
