This message was deleted.

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 😞