In the bustle of a cafe in the Excel Centre at KubeCon in a conversation about platform trends I said: “platform leaders should be mandating far more than they currently are”. The conversation was with Daniel Bryant.

I remember his face staring at me as if to say: “That’s very bold”.

And he’d be right (or at least his facial reaction was). It is bold.

In the platform space we’ve been repeating mantras to each other like "our developers should choose their tools" and "we shouldn't mandate". But with such soft conviction all it takes is one or two vocal developers to complain and our platform project is halted or even derailed.

And it’s these cautious platitudes that are likely undermining your platform success.

Conviction is the fuel that drives meaningful progress. I've seen this first-hand in my own transition from engineering to product, and I’d like to take this newsletter to make my case.

Hopefully you (and Daniel) will not think I’ve entirely lost my mind by the end!

Top-down versus bottoms-up is a ‘moot point’

It’s long been a topic of conversation that adoption of platform tooling is a huge problem. We all know it by now. Conversations usually centre on a dichotomy where it’s either:

1. Top-down - We are ‘forcing’ developers to use hideous enterprise tools leadership chose after a round of golf with a charismatic sales rep. We see top-down mostly as “selling out” where our fellow developers will never forgive us for such heresy.
2. Bottoms-up - Is the more romantic view of the world that good tools merely emerge and developers will merely adopt them. We all want this to be true, but in reality it either rarely happens or is just not repeatable nor strategic to ‘build it and they will come’.

But this false dichotomy hides a hard truth that most platform leaders don’t like to face:

If you've done your homework and have deep conviction in your gut and data that the developer tool you’re building or adopting will significantly improve your developer productivity then leaving adoption to chance constitutes organizational malpractice.

Less ‘Engineering Manager’, more ‘Product Manager’

Being a successful platform leader means taking high-stakes, high-conviction decisions that demand not only storytelling and charisma but a healthy dose of bravery. And a lot of inspiration can be taken from the field of product management, which is often alien to platform leaders more comfortable in the world of delivery and process optimization.

Let’s look at the definition of a PM from Lenny’s newsletter: “Your job as a PM is to deliver business impact by marshaling the resources of your team to identify and solve the most impactful customer problems.”

For platform leaders that means building conviction in two key directions:

1. Understanding and quantifying developer pain
2. Understanding if we’re solving a real and urgent business need.

If you’re having adoption problems you’re likely out of alignment with at least one. You’re either not solving a real problem for your developers or your leadership are unaware or unconvinced of the benefit of what you’re building.

Know thy developers and know thy leadership

Conviction doesn't emerge from thin air, it's built methodically.

Start by deeply understanding your developers by asking them: What tools do you use? Can you show me how you’d fix a bug? Can you show me your process for setting up your development environment? Surveys are great, but physically sitting with developers gives the richest insight. To champion on their behalf you must know their workflows inside/out.

Simultaneously you must understand the strategic direction of the business and how your platform can accelerate those goals. Ask your leaders: what keeps you up at night? What metrics are you dying to move? What type of engineering culture do you want to create?

How can you convince your boss to use a tool?

Aligning solutions to business needs is something I’ve learned a lot about working closely with platform teams in my role in product at Gitpod. Gitpod is very popular with developers and so I’m commonly asked at conferences ‘How can I convince my boss to use Gitpod at work?’.

As I know developers like Gitpod it’s usually a question of whether Gitpod is a good fit for the needs of the business. At Gitpod we work mostly with highly regulated customers like banks and pharmaceutical companies because of the security benefits and the likelihood they have existing but poor performing development environment solutions like a virtual desktop.

My first response is usually to slow down as I mentioned we need to understand if we’re solving a real and urgent business need. For us, that’s usually done by:

1. Running a survey - With developers to understand how many hours their developers spend on broken development environments.
2. Gathering quotes - From developers about that pain (bonus points if these quotes come from well respected and long-tenured developers!)
3. Understanding business priorities - Does the company see it as a problem? Do they want to solve it? Are they willing to invest to solve the problem?

Whilst this is a more ‘commercial’ way of investing in a developer tool, I’d use the exact same process to assess platform investments. When you do your homework you end up with a deep sense of conviction into the decisions you’re making as a platform team, you have support from your leadership and from your developers.

Some developers will complain, someone always complains no matter what you do. But whatever you do, don’t let mantras like "our developers should choose their tools" and "we shouldn't mandate" get in the way of doing your job as a platform leader.