Slumlord Enterpise Vendors — Are They Holding Back Your Transformation?

It’s always difficult to watch a friend suffer. Here’s a story I hear a lot lately:

A company is undergoing a transformation and have reached a place where they’re thinking about end-to-end service design. That’s when they remember that they’ve outsourced a lot of operational systems, meaning key bits of data that are required to run a responsive, agile business are owned by an outside vendor. When they go to the vendor to retrieve this data, little information is forthcoming free of charge, and it’s expensive just to get an estimate for data retrieval. Eventually, it turns out to be too expensive to move forward, so nothing is done. The transformation limps along wounded, and leadership blames “the agile” instead of taking a hard look at the vendor.

This story reminds me of those stories you hear about slumlords who take advantage of their tenants’ inability to “just leave” instead of actually doing the job of a proper landlord. Vendors do as little as they need to meet their contractual obligation, knowing the price of pushing back is too great for their customers.

So what’s happening?

In order to understand what’s happening with these vendors, we need to step back and look at what’s happened with transformations to date.

Transformation efforts have tended to concentrate on an organisation’s own delivery capability, which works fine for those that control their entire estate. However, in addition to building in-house, large organisations outsource projects because they lack the skills, capacity or desire to do the work themselves. They’ve largely relied on outside companies to manage various aspects of their business that seemed tangential, especially operations and customer service. If your transformation has hit the point where you’re dealing with the outsourced bits of your enterprise, you’re probably finding that the transformation playbook is missing a chapter.

This next part of the story may sound familiar:

The vendor says a lot of agile-sounding things, but what you actually encounter are outdated and poorly documented APIs (or none at all), and promises of functionality that turn out to be half-baked. Engagement during development is costly, coming in the form of oxygen-wasting “engagement managers” instead of knowledgeable technicians, and trying to code and test against their services is a nightmare.

What’s happening is that many of these vendors don’t follow modern practices in their own development, they’re just beginning to, or worse, they pay lip service to your new world view during the sales process only to fall short once they’ve made the sale. Change, as you know, can be costly. So instead of retooling their own technology and business practices to meet customer needs, vendors choose a strategy of entrenchment and “sweating assets.”

Should we expect better?

In 2018, the answer is yes. Good vendors recognise the need for change and recognise that change is now constant. However, slumlord enterprise vendors who maximise their profits by sweating their assets and minimising the effort they expend on your engagement need to go.

The security that comes with a brand name might look good up front, but they may be costing you in the long run, if they’re not able to follow through. As you transform, it’s time to start demanding more, and taking the opportunity to really change your organisation by looking for vendors that will help you meet not just today’s needs, but also the challenges ahead.

How do you spot a slumlord enterprise vendor?

Here’s a handy list of signs that you may be dealing with a slumlord vendor:

There are a couple of options when you run into these issues with third parties.

The first is preferable, and I’ve seen it work– bring them along on your journey by showing them that improving development practices is about moving forward, not moving on. A good and useful vendor will work to actively achieve your goals with you.

Unfortunately, the preferable option isn’t always possible with some vendors. The reality is you may not need them, or they may not want to change, and if your partner isn’t willing to grow and change with you, as in life, it may be time to move on. Re-thinking the rules of engagement with vendors may seem costly, but the price of ignoring this need will be even more costly in the long run. The greater cost will inevitably come along when your competitors, who’ve already done the work of re-thinking the rules of engagement get ahead, while you flounder in the old world.


If you’re re-thinking your vendor, getting a bad feeling about them, or looking at a new one, here are some considerations that can help you figure out your next steps. These considerations are by no means comprehensive — figure out what works for your organisation with your dev team, and watch your transformation flourish:

Accessing your data
What works What doesn’t
No hassles. Always available, no hidden charges, no exceptions. No APIs, Poorly documented APIs, just anything that’s not 100% automated.

Paying to get your own data

Paying to get information about your data

APIs & Customisation
What works What doesn’t
Verify all claims; a technical lead who will work with the product on your side has positively assessed claims about functionality.

Opennes to this process

Documentation is online and fresh.

Non-technical representatives during this process

Sparse documentation

PDFs are a sign of outdated practices.

Testability
What works What doesn’t
Your team should be able to write tests independent of the vendor’s production environment

Your technical lead has assessed the effort required to stand up a test environment.

The vendor is working with you to make things easier, like providing sandbox environments, testing stubs, and generally being helpful.

Your vendor is insisting on “end-to-end” testing that really means testing their product.

Monolithic architectures that make testing difficult

Monitoring & Alerting
What works What doesn’t
You understand what’s going on with the service you’re paying for at all times.

Your team has access to monitoring and alerting for service, availability, usage, etc.

If your vendor doesn’t already provide it, they’re working toward it, and not giving you the feeling that there’s something to hide.

Opaque/coded error messages when things go wrong

You have to contact them to find out what’s going on.

No monitoring or alerting, no plans to provide it.

Development Support
What works What doesn’t
A named, technical, point of contact is be available throughout development.

You have a name, a face, and can talk to this person over Slack, Skype, hangouts, what-have-you. This person isn’t a middle-man, can write code, and explain why things are the way they are.

Non-technical “engagement managers” as your team’s main point of contact.

Charging you to find out how much it will cost to answer a question

Performance
What works What doesn’t
Specifications should be available to inform projects of limitations and scalability, and verifiable

Your team is comfortable that they are able to test for production against upper performance limits without interfering with the production environment.

They work with you on problems that may not be their own.

Your vendor’s response to this one isn’t “trust me” and an appeal to an SLA in a document somewhere.

When you’re having problems, you have to prove the problems are yours, not theirs.