In a previous thread, @Angel Barrera Sanchez said:

IMHO: even with the right tech skills, is up to the middle management the success of implementing an IDP.

And later @Scott Collins added:

the challenge comes in the form of leaders who have worked at large orgs with silo’d platform or devops teams who view that particular pattern as the solution to all their problems, when in fact it can result in “platform stuff” being everybody’s and nobody’s responsibility at the same time

I’ve been doing this sort of work for a long time, and the most difficult challenges for me have consistently been successful collaborations with management, mostly middle. I’ve been in small orgs where “throw it over the wall to devops — it’s their job to handle it” was the position. I’ve been in larger orgs with mostly siloed “platform” teams pursuing efforts that weren’t taking the real needs of all the dev teams into account and had turned almost into “tail wagging dog” situations. I’m not bad at winning over other devs… I’m a dev myself, and with a little effort, I can gain their trust by making their lives easier through solving technical challenges. But as an Individual Contributor (IC), bringing managers onboard with a collaborative platform effort has proven to be much harder for me. Their incentives are different, and adding value for them can be more subtle. I’d appreciate hearing some “war stories” from ICs who have successfully forged collaborations with management to launch platform efforts. And I’d love to hear from managers who were themselves won over to such efforts. What approaches worked? What didn’t?

This really hit close to home, would love to get a proper article on this!

Actually, my plan once upon a time was to crack this nut, write a how-to book, then go on the lecture circuit and make tons of $$$$. 😉 From my experience talking to colleagues, this is one of the Really Hard Problems in this field. Buuuuuut… I’ve got to figure it out myself first, and so far my track record isn’t great. I suspect there’s no one-size-fits-all solution here, as — in my experience at least — the situation tends to turn on individual personalities.

Hi Ron, I am a manger, and building a platform team at my company. Your question piqued my curiosity: what do you think a good collaboration model with Devs should look like?

Even if you are asking Ron, I'll give you my pov: • While developing a platform, you have to know your clients (KYC) (mostly, developers) • So it makes a lot of sense to sit with them, understand their work, how they do stuff, and what are their pain points... • Then, pick a few developers (if the company allows it) and make them core contributors to the platform. If they develop the platform, they will use it • Also, spreading the word internally is key for success, the developers mentioned above are a good opportunity for spreading the platform knowledge, but is not enough. You will need to create internal "meetups", "demos", or "blog posts". • There is no silver bullet, every company should drive the implementation in its own way. TL;DR: Develop the platform as a product of your own. You have a huge benefit, you already have clients without developing a line of code... Take advantage of this situation and fill their needs, not "only" yours.

Hi, Olga… @Angel Barrera Sanchez stole some of my thunder. I’ll echo what he said, and add a bit more. Two concepts that companies would probably say they understand but may not act like they do: • most software products these days aren’t applications — they are environments running applications. We don’t get paid unless the applications run successfully in their environments. So if you want to continuously integrate/deploy/test your product, you have to be doing that with an environment, and not just an application. • the shape of the platform on which a product is built necessarily affects the shape of the product itself. One easy example of this is how changes in version control historically changed workflow. In principle you could implement the same workflow and cadence on ClearCase, subversion, and git… but in history that’s not what happened — as each new VCS gained traction, teams changed how they built the product. (And this is in addition to the technology that has changed the products directly, i.e. cloud, containerization, etc.). To me, a successful collaboration requires that all the levels of engineering management have internalized these concepts, and that objectives and incentives are aligned accordingly. Application architecture decisions may have implications for the deployment environment — the product — and by extension the dev platform. Those implications have to be taken into consideration from the beginning. Conversely, dev platform decisions and objectives have implications for product development. Conversations between “dev” and “platform” management (and I don’t even like siloing that way) must be early, often, and always, always with the priority of the product (application + environment) in mind. I’ve seen this go wrong more often that right. I’ve seen dev managers refuse to allocate resources to help address significant dev platform issues because they were chasing feature release schedules (making the platform issues worse in the process) and sacrificing stability for short-sighted delivery goals. I’ve seen platform teams launch efforts that would benefit the platform itself, while leaving higher-priority problems with real product implications unaddressed. I’ve seen “platforms” that weren’t so much platforms as an aggregation of platform technologies, each run by a team focused on its own thing and not coordinating effectively with other teams. I think this all comes down to a coordination/orchestration problem. Orchestration of applications is tricky, but orchestrating people (let alone teams) is downright hard. Orchestrating people involves artful arrangement of incentives to keep everyone “on mission”, and happens at hierarchical levels that ICs don’t always have access to. I’m not a manager, nor do I desire to be. But lacking an “M” on my org chart panel tends to cut me out of the conversations where this orchestration needs to happen. Hence my original question. ;-)

I’ve seen “platforms” that weren’t so much platforms as an aggregation of platform technologies, each run by a team focused on its own thing and not coordinating effectively with other teams.

Here I am 😞