This is Part 2 of our two-part interview series with Jalal Iftikhar, Global Director of Business Systems at Intercom. Read Part 1.

Salto: Any advice for working with business stakeholders?

Jalal Iftikhar: The human element is really important. That’s a huge aspect. If you go and ask for something without building the relationship nor having the camaraderie, people may not believe you at first, and you have to justify a lot more. For instance, if you say the new CPQ will take nine months, and you don’t have a relationship, they may say that’s impossible.
‍
One way we account for this, aside from cultivating relationships, is we have two workstreams: Fast and slow. The first is quick and reactive, the second slow and for big architectural stuff. Our team gets to decide if something is quick and they can handle it right away, or whether we have to pause and fit it into the roadmap. If it takes longer than two weeks, we go back to our sales team and say, “Do you want to put it on the roadmap? What do you want to take off to make it fit?”
‍
When you do good work, you build credibility that allows you to occasionally pause and deal with all the long-term maintenance projects that get missed. That’s when you can go back to your CRO and say, “We’ve delivered on a lot of things this quarter. Now I need a quarter.” If you have a good relationship, they’ll know it’s for them as well.

What challenges do business systems teams face?

I will say, you cannot fall into the role of just doing—that’s a bad place to be. If you act as a doer, the relationship changes. Nobody values your time. You’re just the implementation team.
‍
Me personally, I’ve never been a fan of people bringing solutions to me. That doesn’t work for me. There could be hundreds of solutions. But what’s the problem? If you don’t ask questions and qualify, people will always be bringing you solutions. Those lead to technical debt, and you build yourself into a corner.

I would always rather reply, "What is the problem? How are we tackling it? Let’s have a workshop with the team and hear them out." In that workshop, you don’t just listen. It’s also about educating. You don’t have to get too technical, but you do have to help them see the full picture.
‍

What’s one thing that helps you drive internal adoption?

We launched an internal champions program which is sort of like identifying influencers on each team. Every team has someone who’s boisterous who others listen to. We bring them into the loop before we build any major projects and ask them how they want it, what the UX needs to be, and we take that into account.
‍
If they’re on board, and we actually build it, they’re happy to sell it back to their teams. Nobody will do a better job, because they speak that team’s language. They’ll also tell you what’s happening in the trenches, and help you communicate feedback.
‍

If you had extra time, where would you devote it?

Data cleanliness, for sure. It’s the easiest thing to avoid and seems like the least productive thing to do, cleaning up Marketo, Salesforce, and the finance systems. They’re all collecting these small duplicates across objects and fields over time. Those become blockers. Suddenly someone announces you need to do a cleanup. Why do we need to do a cleanup? Because someone asked for a field or we have this account which is a duplicate, so now the ABM program won’t work. Lead routing won’t work.
‍
I believe both Salesforce and Marketo don’t do a good enough job of combatting data duplication. If I could request one thing, it’d be automatic cleanup that keeps data duplication from ever happening. It’ll probably never happen. But that’d be my feature request.

What’s a question you often ask yourself?

I want to know how other business systems organizations measure the success of their teams. I’ve always been curious. We haven’t implemented it yet, but our process is knowing and defining our help status for each system in a way that measures fungibility, flexibility, and stability, which is based on what tickets arise. Then, the other thing would be to measure stability by the number of releases and tickets associated with said releases. If it breaks a certain threshold, then we must not have built it well enough, or thought through the requirements.
‍
But also, how do you measure the health of your systems? I would love to know how others are doing that. I haven’t seen much openly written about. It seems that everyone will tell you their systems are really good or really bad, but what’s the benchmark? What is a good Salesforce instance? What’s a bad one? How do you measure whether it’s able to do what you need it to do in the future? How do you think about the future?
‍
You can’t let the future be the future. You really have to think about the future as an element of your current-term success.

Yoni Argaman · “Oh yeah our systems are good. But how do you define that?”

Jalal Iftikhar is Global Director of Business Systems at Intercom, a rapidly growing company that’s making internet business personal. They’re hiring.