Hi folks, I would love to get feedback on this scenario, which unfortunately happens quite frequently in my company. A "public interest" tool is often tested/introduced by a pilot team without involving the platform team, and then the tool itself is handed over to the platform team. Since the platform team needs to understand its functionality in terms of multitenancy and scalability, it is then perceived as a blocker for the company's adoption of the tool. Apart from introducing an effective tech governance process—which we currently lack—do you have any other suggestions for addressing this issue at its root or any mindset we should adopt?

So I have some ideas but it kinda depends on the size of your company

Agreed about the tech governance piece. It sounds like "handover" is a one way, top down process, which seems incorrect to me. A more sustainable model would be one in which the engineering department can do PoCs with new technology without involving the platform team, but at the point of doing anything serious with it, there needs to be a discovery phase (whether done by the platform team or by the original team working to a template) as you describe. Only on completion of that discovery phase can the tool be added to the suite of tools in the platform offering. If the tool doesn't pass, or if the original team doesn't have the bandwidth to take it through that process, the tool is either discontinued, or run for that one team but not added to the platform as a general offering.

I’d embed a liaison from the platform team into the teams doing the POC. That way you can essentially upstream some guidance, work on the POC, build relationships and help socialize how the team thinks about new software adoption Being reactive or telling people to essentially RTFM is likely to cause a lot of friction on both sides.

The problem in this scenario that you are pitching is that platform team is brought late into the process that’s why it is perceived like they are holding this off. If the tool is being handed over to platform team, I am assuming the tool proved it’s value to the organization and use cases were thoughtfully tested that’s why the platform team has this pressure.

Love this topic! I have a lot of thoughts A few questions: • Do you have a PM? ◦ My assumption is no, or else they don’t have the necessary muscle needed to push back where they should be, and need to build that muscle rapid, or they and your team will continue to be steamrolled • Do you have a roadmap and a list of priorities? • Is that roadmap public (internally) and easily understood • Are you working in an outcome oriented manner (or at least pretending to) • Does your company have pillars/north stars/overall outcomes • Do you use Jira? (my instructions will be easier with jira) To me (and I don’t know much about governance processes - so I’ll leave that to the other responders), this screams to me that your team doesn’t know your own roadmap, so you are unable to defend it from last minute projects when requests like this comes along. Instead of you being called the blocker for projects, if you had a roadmap, these last minute projects could be called blockers for your roadmap, especially if your roadmap objects are tied to company pillars/outcomes etc, and the requests coming in last minute don’t fall as high on the priority list. What I would suggest - and all of these things can technically be done individually. Don’t try to change it all at once, that will end badly (from my own experience 😄 ) 1. Create a roadmap, make it easy to share and make what projects easy to understand a. If you want help with this, and can turn on jira product discovery, I have 2 guides here that would get you set up in about an hour following them. Its free for 3 users, so if you are the first to enable it in your company, even better - it will be novel and people will pay attention. b. this is your main article for saying, OK if we do that, this has to go, and this is prioritised higher for stakeholder B - go talk to them and see if they are OK with their stuff being delayed. c. Getting other people to fight your pushback for you is a nice trick, but don’t do this too often or the other people will get annoyed too and nobody will be happy. Use as a last resort or with people you have a good rep with 2. Implement 6 week cycles (attached is a visualisation of what that looks like). My guides above build JPD with this in mind a. Planning for the next 6 weeks happens in the last 2 weeks of the previous cycle. You can make a rule that anything that comes into your team must come no later than these last 2 weeks, or else they’ll have to wait for the next cycle. You can only do discovery on work that comes during a 6 week cycle, but no dev work can begin 3. Create 2 outcomes your team are going to focus on for this half (3 is too much if you haven’t done outcomes before, and in general, 3 leaves too much room for ambiguity) a. I have a workshop guide here that you can use with your team to create outcomes b. Verbalise these outcomes with leadership and say “These are our outcomes” instead of asking. Even better if they have pillars for the company and you are tied directly to the pillars. Use ChatPRD for this to refine your outcomes. Send in a screenshot of your miro board from the above step and ask for ideas 4. Turn everything into an opportunity (all your epics) and Prioritise all your different opportunities towards your outcomes. Reach X impact is plenty. You are using this as a way of pushing back requests initially, but after a while your team will build a bit of a muscle for improving your reach/impact scores and will get better at prioritising stuff a. I have a template miro board here that will help with that. Look at the notes for explanations etc. 5. Implement epic champions on your team, and make sure every ticket that comes into your board has an epic. a. This works nicely with 6 week cycles, as the champions can be the key communicator between your team and the company team asking you for stuff. The next time the team has a project in the pipeline, they may reach out to the champion earlier, avoiding this problem in the first place. This all becomes your intake process, and should be clearly represented by a document (like this) that is kept current and shared with anyone who asks for you to build stuff. Happy to chat more on this if you find this useful. I love this stuff and platform teams seem to be the ones who need it the most (having built all of this structure managing platform teams)

Thanks @John Conneely, yes I should be the PM of the platform group but I haven't built the muscle yet 😓 . You're right about the platform roadmap priority and seeing other requests like this a blocker for us instead of the other way around. About 6 weeks cycle, we're adopting Shape Up that is very similar apart the cycle length (6 weeks for building & shaping + 2 weeks of cool-down)

Have you product ops people/scrum masters who are implementing the shape up process? It's very similar yep, I just had never heard of it when I was coming up with my way of doing it and I'm not changing now 😁 The 6 weeks are the important part, it's a lovely cadence that frees you up for deeper discovery work. Lean into following the new process and get friendly with the people who can fix your boards and workflows when introducing the new process breaks stuff. Offer to give feedback to help them solve the problems with the rollout and they'll solve your problems fast Those things can make things a slog and you end up context switching loads because of it!

Have you product ops people/scrum masters who are implementing the shape up process

yes, and it's still me. I see the problem by myself here 😓