:movie_camera:Product Management for Internal Deve...
# general
m
šŸŽ„Product Management for Internal Developer Platform implementation is

live on YouTubeā–¾

! thanks@Aaron Erickson it was a blast! 15 questions and we keep rolling to answer everything. Let's continue the Q&A in the threadšŸ‘‡
ā€¢ Do you deal with "platform" scope creep, how do you handle? We were successful and went from CICD, k8s and some Security to identity and access management platform and now managing API's ...etc ā€¢ how does your platform team handle tools created by developers on other teams that could potentially be used outside of their team? Do you ignore them? Take ownership of them? Something in between?
a
a,) Platform scope creep: There is a difference between virtuous scope creep and wasteful scope creep. I would ask, is the scope going to make a developer workflow simpler? Whose job does this additional scope make easier? What customer or stakeholder is asking for it, and why? These can all be valuable and useful things to invest in. If you have an identified customer and a clear path to ROI, you can then make a business case to make it allowed scope. The answer, however, may be a.) it doesn't actually do much impact or b.) it could matter, but there are some even better investments that come ahead of those. In those cases, the answer isn't no, but it's "later", when other business conditions dictate that the scope that someone wants can be added within whatever budget envelope you have.
b.) on platform tools, funny enough, I had an initiative at one company literally code named Armada, which was combining the efforts of several tools (think, Armada of ships) to become a united "best of all" experience. We were the biggest initiative, so we ended up being in charge of unification. But did so in a manner where everyone could share the "credit and glory" so that it wasn't seen as a competitive thing. The other business units that had similar initiates were happy to offload the work in our case, as they knew their business objectives wasn't really about building platforms, rather, it was seen as a "necessary evil" over very manual alternatives.