6 min read

You Should Do It My Way

You Should Do It My Way
Old blue eyes. Not the best person, but he was really good at crooning and I can respect that

The value provided by any software platform is entirely dependent on who is using it and how it helps those people to achieve their own goals.

It doesn't matter how pretty or elegant or fast or whatever the platform is, if no-one is using it to deliver some other benefit, all of the time and effort that went into creating it was wasted.

Which is why it can be a very painful experience when you see someone who should have used your platform, but didn't.

And Now, The End Is Near

Software platforms are multipliers.

By themselves they are functionally worthless, but they allow other people and teams to deliver functionality faster, or with more maturity or just generally better than if they tried to do it by themselves.

This multiplication factor is the entire value proposition for why organisations invest in platforms. They are a long-term investment that is entirely dependent on adoption to create a return.

So, whenever a situation arises where a platform could have been used, but wasn't, it's bad for everyone involved.

It's bad for the people that could have used the platform because they probably spent a bunch of time and effort on building something superfluous, when they could have invested that money into something more meaningful.

It's bad for the business because not only was there wasted effort, but now the business also has to deal with fragmented architecture, which if left unchecked can quickly grow into a meaningful amount of technical debt that is difficult to pay back.

It's bad for the platform owners as well, because their value to the business is weakened, and they have lost an opportunity to extend and mature the platform to make it more valuable for other people and teams.

Obviously no sane person would consciously choose a path that is bad for everyone involved.

But that doesn't mean it doesn't happen anyway.

And So I Face The Final Curtain

The first completely valid reason for why people choose to not use a platform is because it's just not ready for them.

That doesn't necessarily mean that the platform is immature or incomplete, it just means that for whatever their specific use case is, the platform is not attractive enough to pay the price of adopting.

Sometimes you can work around this and negotiate for the people who want the additional functionality to just build it into the platform instead of going their own way. That implies that your platform is set up for contributions though, which isn't always the case, and even if it is, you still need to monitor them fairly closely to make sure they are still aligned with the platform vision and strategy.

The second completely valid reason for why people chose to not use a platform is because they don't even know it exists.

This is particularly a problem for larger organisations (cough Atlassian cough) which have difficulty ensuring that every software delivery team understands all of the options available to help them deliver more effectively.

This one is actually pretty easy to deal with if you catch it though, because all you need to do is educate the people about what the platform is and how it can help them. If you're lucky, this could be as simple as just linking them your extensive and effective documentation (which you have, right?) or it might be as complex as going on an internal roadshow to build your platform's brand.

The last reason for not adopting the platform, which in my mind isn't particularly valid, but which I've still seen anyway, is differences of opinions.

Sometimes you just get someone who wants to go their own way. They want to build their own thing, and they have enough organisational clout to make it happen.

This one is probably the hardest to deal with because it's difficult to change someone's mind. Obviously, you can try to convince them that the platform is the right thing for both their use case and for the business, but in my experience, even that isn't enough sometimes.

In which case, having tried the carrot, you may need to use a stick, aka get alignment from the people above them in their management chain and force the adoption of the platform that way. You probably won't make a lifelong friend in the process, but sometimes sacrifices must be made.

All of the paths above assume that you arrive before the damage is done, which isn't always the case.

My Friend, I'll Say It Clear

If you arrive late to a situation and the people involved have already made the decision to not adopt the platform for whatever reason, you're in for a much rougher ride.

If you're lucky, the decision they made was a conscious one, choosing to trade platform adoption off against some other factor that was important to them. This can happen when the platform is missing capabilities, when the roadmap for the platform doesn't line up with the timelines for the team in question or when the cost of adopting is too high for what the team is trying to accomplish.

The good thing about a conscious decision to not adopt is that it probably came with a plan to walk it back, which you should do everything in your power to support so that it actually happens. If there wasn't a plan for eventual adoption, you should start that conversation as quickly as possible.

The more difficult situation to deal with is when the decision was made to not adopt the platform, things have already been built and the team has no real desire to do anything about it because it's working for them.

In this case you have to attack from multiple angles.

The first angle is to create pressure from above, finding alignment with senior stakeholders in the area in question and making a case for consistent platform adoption across the board as a way to achieve overarching goals. If you really want you can point specifically at the team which chose not to adopt the platform and doesn't even want to consider it in your argument, but that's not a great way to make friends.

Still, sometimes you don't need to make friends.

The second angle is to create pressure from within. Find a trusted partner in the area and make them an advocate for platform adoption. This could be as simple as educating them about the benefits of the platform or as complex as actually helping them to spike out an example of adoption in their area to prove your case.

The more people you can do this with, the more internal pressure you're going to create, which combines nicely with the pressure from above to help push through that inertia that is preventing platform adoption.

The last angle you can use is to leverage cross-cutting programs of work. It's common for individual teams to be responsible for a specific area of the business or a product, but there are almost always large, cross-cutting programs of work that require those teams to comply to some standard or make some common feature set available.

Depending on the program of work, if you can position your platform as being the method of choice for delivering that common feature set, then it will create a large amount of pressure on any team that chose not to adopt to either build something equivalent themselves (which will be very expensive and time consuming) or to rethink their previous decision.

I'll State My Case, Of Which I'm Certain

Pretty much everything I've written above assumes that you honestly believe that consistent adoption of your platform is going to be beneficial to the business. I assume that you have a good heart, but technically there is nothing stopping you from using these hints and tips for evil.

Don't do that though. I don't want to have to kill again.

In all seriousness, this is another one of those blog posts that came from a few lived experiences at Atlassian. I'm not going to name names because that would be beside the point and a bit of a dick move, but I've dealt with pretty much everything in this blog post over the last couple of years.

The hardest one was definitely having to convince a team to get on to the platform after they had built something of their own and had become emotionally attached to it.

At the end of the day people and teams won't always do what you want them to do, and sometimes they will go their own way. Your job is to try and minimise the number of times that happens and to ensure that not only is their return to the fold inevitable, but that you welcome them with open arms when it does eventually happen.

And resist the urge to say I told you so.