CTOs and Chief Architects are busy people. Because it’s a demanding job, they are generally looking for information and advice, but are also keen managers of their time. Given that many vendors are being attracted by the size of the customer’s IT budget, if you want to have a chance to speak to them, you need to stand out from the crowd.

In a recent conversation, a colleague lamented that one of his customers doesn’t have time to meet. Based on my 5 years spent as chief architect on the buying side, I shared my pretty cut-and-dried view on this:

  1. Everyone’s day has 24 hours, so it’s never about time, but about priorities.
  2. If you bring value, people will prioritize meeting with you, and make the time.

This conversation encouraged me to write down what I expected from vendor meetings during my time as a chief architect. Personal preferences are bound to vary slightly, but I expect there to also be quite a few commonalities.

Talking to a CTO or Chief Architect

When I was a chief architect, I was generally “busy”, especially when asked for a meeting with a vendor. Too often such meetings just ended up me being asked for my “pain points” or product demos in (slight) disguise. On the other hand, I also very much enjoyed and learned from many other vendor meetings. What makes the difference? Here is a rough outline of what I expected in order to “make time”:

Tell me something I don’t know

While it’s good to ask questions, just asking for “pain points” and invariably mapping these back to the vendor’s latest product isn’t likely to be the conversation a CTO is going to make time for. I expected my counterpart to bring me new insights into industry trends or show me different ways to think about my problems. Or, for a complete change, tell me what didn’t work.

Now that I changed sides my ambition is to present decision makers with new mental models or different ways of looking at ways to address their problems. When talking to a CTO, assume they are well-read and well-informed, so rehashing the latest conference headlines (“Are you using DevOps?”) isn’t likely to get them excited. Bring them something new and original, even if it’s not perfect, and you’ll likely trigger an interesting conversation.

You may wonder how you can bring new things all the time. First, you don’t need a new idea for every meeting (see below). Second, you are unlikely to want to build a relationship with 100 CTOs. So, have a few good ideas and go with those. You will soon get new ideas from your discussions.

Tell me what you do for me

I have sat through countless meetings where the introduction round consists mostly of titles and past companies that people worked for. I sometimes counter this by stating that I am the only person who never worked for another cloud provider, making me “Google native” in a way.

All jokes aside, as a customer it’s not very helpful to me to hear that you worked for brand-name company X, Y, or Z and held such-and-such title. After all, I don’t think that having lived in, let’s say NYC, guarantees you to be a hipster (living in Portland raises the chances you are a pothead, though).

Instead of your past associations I want to hear what you have done for other people and even more importantly what you will do for me. Sorry, I am a little selfish^H^H^Hvalue-oriented and am interested in capabilities, not ingredients, both for systems and people.

Make it an eye-level conversation

A CTO is going to want to talk to someone at his or her level of experience. That’s not arrogance, but simply optimizes the ROI on the time invested in the meeting. Take note that title doesn’t denote level of experience - most customer facing roles have serious title inflation anyway (I am a “Technical Director” - always makes me think I am George Lucas). It’s mainly about talking to someone who has spent sufficient time solving the kind of problems the customer is facing.

Interestingly, many of the vendor’s customer-facing staff haven’t actually spent much time working on the IT side. While its helpful to see what other customers have done, they know the IT environment largely from the outside. I compare this to having read all the travel magazines and maybe having taken a guided tour, but never having actually lived in a place.

Bring the right people (and no one else)

Nothing is more annoying for a senior client than being vastly outnumbered by the vendor (we sometimes joked the “XYZ bus is here”). Not only is it awkward and ends up wasting 10 minutes with introductions, it also makes it nearly impossible to have an actual conversation (see below). The absolute worst case is if each person is vying for air time, segmenting the meeting into 3-4 minute mini-monologues (or presentations) that start resembling a karaoke session. This usually happens when the vendor is more concerned with their internal structures (e.g. every person gets a point for having met the client), than with the customer’s needs. I once even had a manager tell me that when a colleague asks to attend one of my customer meetings, I should always agree because it’s the “right” thing to do. Maybe it’s right for the manager’s status report, but surely not for the customer.

The best sessions I had were with a senior person accompanied by the account manager (sales) who would do brief introductions and make sure action items are noted. Actually, I am sure these sessions were hugely beneficial for the account manager as well even though they stayed fairly quiet.

Let’s think together

Too often vendors come to tell the customer something. That’s actually well intended – I just said I expected to be told something I didn’t know. But the conversation doesn’t end there, it just starts. Bringing me a new idea or a new way to look at my problems is like tossing the ball into the court: it’s a great start, but then you need to play!

I am one of those people who has their best ideas when talking to other smart people. That’s why I regularly pilgrimage to Anguilla and other far-away places (someone’s gotta do it!) to have conversations with my peers. Likewise, having an actual conversation, playing off each other’s ideas and insights is the ultimate bliss of a vendor meeting. Most importantly, having a discussion doesn’t mean having to agree on everything. Most CTOs like to hear different points of views and opinions, as long as they are delivered with precision and integrity.

From my years as chief architect at Allianz I fondly remember two such conversations , one with Uli Homann from Microsoft and another with Bhaskar Sunkara from AppDynamics (later acquired by Cisco).

Don’t tell me how to run my business

It’s natural for a vendor or consultant to want to help the customer. Sometimes, though, they get carried away a little bit and present the customer with their elaborate view of where the customer should be headed, naturally involving ample use of the preferred products. As a CTO’s conversation partner, you should assume they know how to run (or more likely support) a successful business. It’s great to inject new ideas but those have to be based on the customer’s current state and strategy, not some abstract industry blueprint.

Leave me with some thought

SketchAs a customer, after the conversation I want to be left with something I can take and apply to my systems or problems. This can be a concept or an actual take-away. After having switched to the vendor side I often draw sketches during the conversation (flip top touch screen PCs or tablets are great for that) and share them with my clients afterwards. This can look like the sketch on the right. It’s unique, makes a great leave-behind to remind your conversation partner of the discussion, and is infinitely more useful than another memory stick or notebook.

Make it a relationship

Lastly, and this is the one where I occasionally fail, is that if I like talking to a vendor representative, I very much like them to come back. The reason this happens too rarely is that the people who deliver on all of the above are extremely rare, so sales staff is tempted to shuttle them around from one meeting to the next.

Looking at the conversation as the beginning of a relationship implies two things:

  1. Start on a high note - put your best foot forward. That’s how you leave a good impression.
  2. Don’t rush things on your first date. If you build a trusted relationship, opportunity will come.

Being on the vendor side I once stated a very simple goal for my meeting with a CTO: after the meeting he should ask for the next meeting. And he did. And it was the start of a great relationship.

Conclusion

Naturally, none of these points are huge surprises. Nevertheless, it’s easy to get carried away and forget what your conversation partners are expecting. The upside is that if you roughly follow these guidelines, CTOs and chief architects will generally reward you with their most precious assets: time and trust.


Thanks to Manlio Grillo, Michael Plöd, and Michele Danieli for providing input! (and, yes, I prefer to take input from people whose first names begin with M….)

Learn 37 More Things About IT Transformation

37 Things

You can find more real-life stories in my book 37 Things One Architect Knows About IT Transformation:

Categories:

Updated: