Friends On The Other Side

If I've learned anything from my time at Atlassian it's how different it is to be part of a platform team, in comparison to basically any other sort of team that builds software.

That's not to say it's harder or easier or anything like that, it's just...different.

For one thing, you find yourself in the middle of a lot of conversations, and that's a place where there are many opportunities to actually make things happen.

If you know how to make the most of them.

You Were Messing With The Shadow Man?

When you're a part of a platform team, you sometimes get other parts of the business coming to you asking for help delivering some big thing that they want to do.

This is great!

It is from these sorts of asks that you will discover different ways in which you can expand and mature your platform, which in turn leads to more engagement and more adoption, which in turn leads to more opportunities to expand and mature.

It's a positive feedback loop.

So, as a leader within a platform team, it's important to build and maintain positive relationships with those other areas of the business, so that you know sooner rather than later what they are planning and how you can possibly help.

This can be as simple as regular synchronous catchups with key players, or as complicated as doing things like going on internal roadshows to build awareness of what it is that your platform can do, why that matters and how people can get in touch with you.

I've followed both of these approaches, and basically everything in between, and I can say that while the time invested in those sorts of activities can initially feel like a waste, it's not.

It's a classic long-term investment strategy.

Of course, the best way to build a positive relationship with those sorts of internal customers is to be able to deliver on whatever it is that they want, within the timeframes that they want it in.

That's not always easy, especially when you are often situated in the middle of so many different (and potentially competing) programs of work, so you may have to pick and choose your allies.

After all, you can't make everyone happy all the time.

He Was Very Charismatic!

The areas of the business that exist outside your platform, the ones with grand dreams that can only be accomplished in partnership with you, are just one part of the equation.

The other part is the people and teams who actually need to adopt your platform capabilities in order to deliver on the requirements being asked of them from the large-scale programs.

These teams are less concerned about the bigger picture and more concerned on whether or not your platform will make it easier for them to deliver on whatever it is that they've been asked to do, along with how much effort it's going to take them to maintain an appropriate level of operational support.

You also need to build and maintain relationships with these groups, though the approach that you take should be different.

These sorts of groups typically outnumber the larger business units mentioned above, so it's less effective to follow that sort of door-to-door salesman model.

You can still spend time connecting with key players directly, but it should be targeted connection, probably around a specific ask or requirement. Let them know that you are here to help them do what they need to do and then actually follow through on that.

In comparison, doing a roadshow and literally visiting every single team that might use your platform for some reason is probably going to be an inefficient use of time and effort, as the return on investment is likely to be low.

Instead, invest in cohesive and coherent documentation, and ensure that the platform is actually easy to use and effective at helping them to move more quickly than they would without it.

The more people and teams that build solutions successfully on top of your platform, the more you will generate passive reputation and the less likely it will be that a single team will just peel off and try to do things their own way.

Which is bad for everyone involved.

You're In My World Now

The reality is that both sides of the relationship equation need to be kept in balance.

If you overfocus on the people driving the large programs of work that require your platform to succeed, you will probably fail to engage with and keep the end-users happy. In turn, this causes a cascade failure, with the people who thought they could rely on your platform to achieve their wildest dreams reconsidering that engagement.

But the same thing happens if you lean too far in the other direction.

Prioritising only the experience of the end-user, of the people and teams that need to actually adopt and onboard to your platform en masse, will mean that you don't get the engagement from the wider business, nor the pressure that can come from that to encourage adoption even if the individual teams don't feel like it.

The good news is that you don't have to be perfectly balanced at all times.

Like everything in life, the situation will ebb and flow depending on the needs of the business.

Sometimes you might be focusing intently on engaging with the large programs of work to build awareness and foster trust in your platform, other times you might be completely immersed in the intricacies of helping individual teams do what they need to do.

Knowing when to shift the balance from one side to the other is the most important part.

I Promise I'll Pay Y'all Back...

For once, the content in this blog post is based on a real-life experience.

I can't really say what the initiative was, but it was kicked off by a large department within Atlassian and it required the addition of new capabilities to our platform in order to succeed.

We could have easily just delivered what they wanted and moved on with our lives, leaving the actual pushing for adoption of individual service teams up to them, well after we had somewhat washed our hands of the situation.

Instead, I built relationships with those service teams well ahead of when the platform was actually ready for them to adopt, incorporating their requirements into the new capabilities of the platform that we were building and mitigating a few nasty risks that would have derailed everything nice and early.

Which was worth its weight in gold.

The most important thing that I realised during this whole adventure was that when you're in this sort of role, a TPM responsible for a platform of some sort, you are, ultimately, a connector.

You help people and teams to achieve more together than they could achieve on their own.

Or, if you prefer, you are the spider that sits in the centre of the web, watching carefully to know which thread needs the most attention.

It depends on how you want to look at it I suppose.