Hacker News Reader

Comment by dabedee | Hacker News Reader

> Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.

It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.

The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.

View on HN

You're assuming product people don't 'invent' work, which is faaaar from true. The more technical the area, the more nonsense 'product' generates, that engineering then has to either redo, clean up or fight. The 'product' people on 'product-led' teams also generally own the internal comms and marketing (internal) side of things, which often has the effect of silencing engineering (and many other negative side effects). (Not always but often imo)

Engineers should understand their customers and their product (whether internal or external), should understand their metrics, and should be able to make intelligent, informed decisions. Sticking a non-technical 'product' (aka marketing) person into the mix is generally net-negative imo.

I don't think they're making any claims about non-platform teams never having similar work-invention problems.

They're just saying a good platform team engineer cares about their users.

Which is fairly at-odds in spirit with the quoted idea of "there's no market to lose."

The original article does say "talk to your users" but it also de-emphasizes this by having it among an apparent laundry list of other signals: crashes, costs

Focus on cost without talking to your users - aka the people who care about the spend? You might spend a lot of time reducing a number that isn't very important right now. Focus on crashes but don't talk to your users? You might address some things with easy workarounds ("i hit retry") while ignoring much more painful toil. This is captured in the details for those sections, but not in the headlines.

There's also some interesting stuff in there in some of the bullets, like overloaded use-cases and partner-to-prototype, but again, that's just more specifics on how to talk to your users.

I think the article would be a lot more helpful to a lot more people if it was a "Guide to Talking to Your Users" and then framed each of those specifically as: user discovery, and how to talk about the given part.

I think the problem is one of management and prioritization and decision making - when multiple engineering teams disagree, how do you decide? Management consistently hires people that solve management problems, and mediating disagreements or picking product direction are core management functions that have been completely left behind as managers become purely MBA number people.

product lead doesnt mean lead by 'product people'

Previously I worked at a very large company, my team was mostly isolated form the rest of the tech stack of that company.

Suddenly came a mandate to try to integrate our systems together, the first goal was to use their authorization system (which involved, I kid you not, setting up 3 separate EKS clusters that talked to each other and if the main one goes down, all go down) that the core Platform team of the company was setting up.

Worse even, the plan was to use us as "guinea" pigs for their new systems before rolling out to the rest of the company because our team was smaller and therefor wouldn't be as impacted by problems on their side.

I was vehemently opposed to this, all our other experiences with their stuff was just a huge amount of pain. I remember clearly a meeting we had where I said: "Why would I use your stuff that is not well documented and that I don't understand when I can use open source stuff that is documented and that I can understand". Their only argument was that said they would have internal support for us.

I came up with this concept that I tried to push on to them, that their stuff shouldn't be this monolithic tower of babel monster, but instead should be a buffet where I can pick and choose what to use. Our requirements were very different from their stuff and I didn't want to run into problems because of stuff that had 0 benefit to us.

I ended up leaving that job mostly because of this.

I've had similar fights over the years, on both sides of the discussion.

"If our internal design system is barely half as well documented than Bootstrap then teams will still use Bootstrap. We should take a page from Bootstrap's documentation and include as much detail as we can, on everything."

"As a platform team, your product is this API my app calls. My beta environment should be pointing to your Production, never your beta environment. If that means you need to support better multi-tenant from the same 'app', then you need better multi-tenant. Your outage impacts my testing, which impacts my velocity, which impacts my deadlines. Your backwards incompatible updates need to be planned and scheduled and rolled out like a Production update, every time."

Product mentality is still very useful in platform development. If you can't sell your platform on its documentation and its stability and you must sell your platform on mandate and top-down control, you probably aren't doing as much to help your engineering culture as you think you are.

Yeah, you get what I was trying to get at. It also helps to think about open source (and even paid) alternatives as competition.

Although my main problem was that they were designing these very generic solutions (that were both super complex and very brittle) that can fit every scenario when my _actual_ scenario was very simple. I couldn't get my point across that I didn't want to buy-into their full platform because of risks and complexity on my side, but that I would be open to buy-into small solutions if I saw the need for them in our product.

In any case this company platform team had this mentality that the company should operate like google, trying to build these massive all-in-one solutions that everyone under the company should use. When in practice it would never work because of the sheer amount of people required on their side to pull that kind of initiative off (on top of other considerations like ROI, downtime-risk, etc).

This sucks. Our team strategy in these situations was to just wait and hope the mandate goes away. Or I'd personally de-prioritize that stuff. Meanwhile a couple of us supported our smaller team's platform.

Things never got too bad for us, but they easily could've, and it'd probably be like your scenario where I quit. Was lucky enough that a couple of big layoff waves didn't impact us but did drastically reduce the amount of bogus technical mandates coming in.

Somewhat true. Platform teams have to be engineering & product led. I run a platform team and we work very closely with our customers to understand what problems they are facing and identify platform level solutions for those problems. But we are still hampered by the team not using the platform for their everyday work, reducing the empathy they have towards its papercuts. However, being purely product focused can lead you astray of your users. Our PMs invent capabilities that no one really asked for ignoring the rather large backlog of capabilities that they already need. That's also bad.

The problem with every platform team is that, impact is hard to nail down. Does X using your platform Y to generate revenue mean your platform Y has indirect impact same as X? Most companies don't think so and end up destaffing their platform teams. Until, the destaffing ends up in much more inefficiency because everyone is inventing their own crooked wheel, spending time on the same capabilities and detracting from product development.

> Platform teams have to be engineering & product led.

No they have to be product led.

> Our PMs invent capabilities

this is not a good reason for it to be not.

The platform is partly a product for the engineers.

I suppose there's the "better type of horse" issue. Maybe the engineering side can come up with something that users wouldn't think to ask for, or whose benefits aren't obvious until it's actually up and running.

definitely wrong. they need to be independent.

> Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning.

And where do product people get ideas for new features? If you're Microsoft you look at what successful competitors are doing. If you're anyone else you look at customer pain points, exactly as described in the article.

>It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.

Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn.

Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside.

If that wasn't possible we built what we needed ourselves.

If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart.

And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.

If you don't have a project-0 to test those assumptions against, you don't need to start that platform.

[0] https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

> And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.

The Rule of Three in Refactoring applies to this scale, too. If you are building a "platform" for one customer project, that's a one-off and quite possibly YAGNI. If you are building a "platform" for two customer projects, that's likely coincidence and still possibly doesn't show company-wide need. If you can build for at least three customer projects, that is a pattern, that provides real guidance on exactly how generic things need to be and better ideas how to abstract it.

Completely agree, but sadly I have seen platform projects with 0 real internal customers. Only an idea.

The more dogfooding projects the better. And yes, rule of three applies.

Yeah, 1 is always better than 0, just that reminder that real "product focus" happens when you have multiple customers, not just doing one-offs for one or two customers.

I've led a number of platform teams over the past decade and we've always treated it like a product with internal and external customers.

Maybe at large orgs. I’ve never found a platform/engineering led teams to engage in work that didn’t amplify the work of other teams.

I have seen it, over and over again, in relatively small orgs (under 500 devs) where the wrong kind of people are handed the job of platform lead. Project after project people don't want to use. The platform jobs in those places were handled by technical skill, but it was attached to disinterest of how others work. So even when they were sent in the general direction of a useful problem to solve, things rarely pan out, because they don't like to talk to their users. Therefore they write the tools they would want to use and are interesting to build instead.

Empathy for other developers, trying to have a mental model of what annoys them about work, and a general product centric mindset are the real requirements, but few people that decide how to staff the team k ow how to measure those skills. And besides, when people have them, they are often sent to talk to the actual customer, not internal customers.

i think that speaks more to the politics of “handed the job of platform lead.”

i’m many orgs the leads of any team are often people that are primarily interested in linkedin bullet points and being gently fondled and groomed by upper management.

this happens in product and dev teams as well. consistently.

I worked at a big company where the actual platform teams were serving the internal users ok, but then there was some middle layer of org-specific platforms that strangled entire projects. Eg some kind of custom database someone invented.

My efforts were often focused on cutting stuff like that out and using the company platforms directly, which was hard because there were reasons people had middle layers. The company platforms weren't bad per se, but they were in-house and hard to find expertise on.

You'd be surprised how VPs love to insert PMs. A famous game platform company, for instance, had two PMs for their storage team, one PM for their data team, one PM for the compute team, one PM for their dev tools team, if I remember correctly (the numbers could be larger, but won't be smaller)

I was at a small company that had as many PMs as engineers. There was also a "director" in a different department with one report.

> The fix for having no market is to act like the teams you serve could leave.

My nomination for this months "clarity of thought and ability to express it eloquently" medal.

I'd rather engineers invent practical work than product make broken promises for things they don't understand.

> Being product-led means caring about your users

Show me a platform team with a full product setup and I'll show you a platform team with over capacity.

Not to mention the average level of PMs will take a team like this down if you can even find one who can understand the type of work that the team is doing.

It mentions toil and postmortems, which are pretty relevant to the teams you work with.

Yes. Which is why I don't really understand how any of it needs inventing. I'd rather read about how to find out what those teams actually need; and also how to tell when the answer is to build nothing new at all.

by "inventing" they mean that no one higher up in the org is going to tell you what your team needs to be working on, you need to do user research and discover the issues for yourself, and then come up with the right set of features that will solve those issues.

As a platform team member:

"almost never a product manager handing you roadmap"

Oh well wake me up from my dream vacation.

> It's precisely because of this framing and mentality that platform teams don't actually serve people

I agree. When I was on the platform team (despite it not being called that at the time) our thinking was that feature developers were our customers. And our production was the tools they used. This meant not necessarily aligning production being only what was in production for customers of the company, but also in any service we provided to developers. This mentality had to be instilled into the team, and we had to remind people of this frequently, but it worked well.

Reply on news.ycombinator.com