Hoping someone has done something similar and can ...
# product-management
o
Hoping someone has done something similar and can provide some guidance 🙂 I'm an advocate of having a platform PM, but at my current role we're not in a position to get such a role approved. Other constraints are that engineering managers are not in a position to play the role, we have insufficient TPMs to step into the gap, and everybody in a platform leadership position generally not having the capacity to lean in. We're proposing putting together a tiger team, what we're looking to call a "Developer Relations" virtual team, with an engineer representing each of the 8 platform teams, who as a group would collectively be responsible for discovery, prioritisation and advocacy of the entire platform (basically a bit of a distributed product management model, doing this work maybe 40% of the time and the remainder continuing with project work and BAU) with an engineering manager as acting "lead PM" for this group. Does this make sense given the challenges? Has anyone tried such a model when staffing and skills were constrained but the need for product management in some way was required? Really not ideal, but thinking this could be a way to get interested engineers driving things and setting up the scene for proper product management down the line once the value has been shown.
a
Tactically sure. Anything can work given the right conviction from people. You can also descope - tbh when i hear there’s no staffing then the business needs are probably not what you’re actually outlining otherwise it becomes a p0. So another model is to think like a startup and decide what is the one thing that NEEDS to get done. I also like to ask myself “why are there these constraints” - engineering is problem solving with constraints so challenge your beliefs of the constraints and other solutions emerge.
o
Interesting points! In terms of the staffing, this isn't an engineering problem, it's a socio-economic-political problem related to headcount allocation across a quite large organisation. The need for a PM is seen by the people at the coalface, but translating that into company strategy and selling people on the idea of product management for platform teams is a slow process - a startup we're not, and there's a wider organisational context in which we operate. I'd also say that it's not a binary, it's nuanced - the teams are not ineffective, they are producing results, so it's not a P0. But if you haven't experienced firsthand the potential step change in outcomes that can be produced by having effective product management, and teams seem to be "delivering something", then something is needed to start changing that worldview.
a
I would start small, I used to manage an extremely large platform/infra org and what I found was trying to accomplish things like this in one step never worked
Another strategy is to pick someone and develop them and find a smaller goal and grow them into the role
Also I hear you on the “we’re not a startup” but you can still run projects like one 🙂
a
I agree with @Andrew Fong, I see the PM as a critical role in a platform team and I would look to one of the existing team members to take on this role, even if it is unofficially. Baselining some KPI metrics for the platform team before, and after the unofficial PM took on the role is a great way to demonstrate the impact such a role has on the performance of the platform team. Once the business can see the demonstrated value of the role, it might be easier to get this role prioritised and recruited. Having led a platform engineering team for many years, as well as working in DevRel I think your approach is a great tactical measure. I would combine this with having an unofficial PM. Prioritisation is super important for platform teams and having one person able to make a call will help move things forward.
b
Continuing on from what @Andrew Fong said about identifying the constraints, I assume the underlying issue is budget. A common problem I see is that platforms don’t have any cross-charge / charge-back - so they (and the staff that buid/support them) are just a drain on the P&L. It doesn’t fix your immediate problem (and I think your proposal is good), but perhaps look at other ways of helping to fund the platform. Chargeback is ideal, as most costs are opex. Cross-charged “capacity pools” work well in capex orientated companies. If you can’t do something direct, then perhaps work with your PMO team to agree a “tax” that can be applied across all projects in return for accelerating development. Of course, you’ll need some metrics to show how you’re saving everyone time and money - hint, focus on business opportunity like time to market.
o
Thanks @Andrew Boyagi, really like the idea of the KPI metrics. Been trying to think of what we could use, and not sure I've identified the best way forwards. At the end of the day the promise of having a PM is that we will be able to identify and prioritise the most impactful work - we therefore need to have a metric that tracks the impact of the work provided by the platform team. But is that any different from any of the other metrics we use generally across the team to measure impact on developer experience? I imagine the pitch would be something like "the team is already driving an upwards trend on these metrics i.e. 10% YoY improvement (for the sake of argument only) but with a PM we'll see a 20% YoY improvement".
And thanks @Bryan Ross, you're entirely right - chargeback is best, but can be hard to calculate sometimes across all platform services, so at a previous place we used a percentage of cloud spend to fund the platform team. It always goes back to the metrics, and being able to translate metrics to money. Cost of delay (time to market) is a good one, but even that implies the product organisation can provide that information, and I very strongly doubt they can do so reliably, and I've unfortunately never worked in an organisation where they could. I've never really found a way to directly translate platform or DX metrics into equivalent money amounts in a way that's acceptable to finance AND that's convincing to myself, it's always an argument based on very flawed and shaky assumptions. That's the nature of the field and I doubt it's possible to do rigorously, but would be great to have a standard approach to these things. I usually fall back to things like cost of downtime which I think most organisations have a good handle on, and also rely on estimates of engineer-days saved (by the people who would have been doing the work) when improving efficiency to highlight cost avoidance. Given for the latter everyone is often just guessing more or less, it becomes an interesting exercise in story-telling 🙂
a
@Olivier Kouame given one of the major benefits of a PM is focussing on the most impactful work, a good way of measuring the impact of the PM is to keep a list of the work that was de-prioritised and not worked on. A main challenge of platform engineering teams is maintaining focus on what’s important, demonstrating how you’ve done that by intentionally not doing less important/impactful work/requests is a good way to illustrate this to your management.
o
Thanks @Andrew Boyagi, great advice! I'll give that approach a try as it absolutely makes sense to me, will report back later in the year 👍🏾