3 ms·

I believe the differentiation between product and platform engineers are creating an unnecessary divide: A platform engineer builds something for a customer, j

I believe the differentiation between product and platform engineers are creating an unnecessary divide: A platform engineer builds something for a customer, just that in this case the customer is a developer, usually within the same organisation. If anything applying product thinking to the problem helps the platform engineer: They have a clearer persona for their customers. They can more easily speak to their customers (if internally). They want to deliver value to their customers and fix their problems. Why create this artificial divide and silo thinking? If your customers are not happy with your work you're doing a bad job and your product sucks.

hayst4ck 5y ago
> A platform engineer builds something for a customer, just that in this case the customer is a developer, usually within the same organisation. > Why create this artificial divide and silo thinking? If your customers are not happy with your work you're doing a bad job and your product sucks. The problem is that most companies don't start out with a platform team. They grow and grow until there are a set of problems that are ignored because there is no direct owner until they can't be ignored any more. A team gets created devoted to these problems and ultimately becomes a platform team, because it's an easy way to allocate work. It's one thing to design a "product" from the ground up. It's entirely another to be trying to build a building that is simultaneously crumbling and growing around you at every moment. Platform teams generally don't get the headcount allocation to get ahead of their work either, this results in having to make prioritization choices. When a platform engineer makes a prioritization choice, that means a product engineer is hearing "no." The problem then becomes the product engineer might do something to circumvent you or any other number of failure modes, when platform is circumvented or battled, this creates animosity. If a product team is told no, that likely means platform has to explain it, which is yet another time investment/context switch that is not building a platform "product". I assure you most platform developers are also "product" developers and see the platform as a product. The fundamental organizational difference between a platform developer and a product developer is that a platform developer is a "cost" and a product developer is seen as "income." Which ignores that platform teams are a product multiplier. A correct measurement of platform teams is aggregate product creation. When viewed this way it's pretty easy to see that a 5% boost across all teams might be a better investment than a 30% boost to 1 team. Unfortunately this is something that is very hard if not impossible to measure, so its a matter of leaderships gut feeling/the platform teams ability to market work that could be seen as fruitful.
narwally 5y ago
If ALL of your customers are not happy, then you're doing a bad job. But if only a small subset of your customers are not happy, then that's just par for the course. You can't please all of your customers all of the time because they all have slightly different needs, so you have to make difficult decisions on how you want to optimize overall customer happiness.
- hayst4ck 5y ago
  I think it's more like a team that works on roads or power. Platform teams are usually monopolies and they usually work on critical infrastructure. They are almost a kind of utility. When a power company has failed, you see blackouts, when a city fails to plan for public transportation or load on roads, everyone gets stuck in traffic. A lot of the time all of a platform teams customers are unhappy because there are very systemic problems with the platform (slow tests, hard/slow release, brittle services, slow feature production) that result in an overall bad experience. In addition, just like a freeway that's run out of capacity, adding capacity will often involve even worse traffic while the situation is being improved. Now if a lot of people are experiencing black/brown outs and a lot of people are stuck in traffic, who is to blame? Is it the power companies? Is it the road construction companies? No. It's city hall. It's the people who make prioritization choices. More lanes on a highway is a major investment and building a rail system is a major strategic choice. Those choices are not made by construction companies, they just build. Those decisions are made by city hall. If you are experiencing traffic it's because someone in an authority position looked at the opportunity cost of the tax dollars that might be spent on solving traffic and said, it's too high. Similarly, a platform that has too much traffic (dev experience sucks), probably indicates a CTO that said "we need features more than we need a stable platform." An even more apt similarity is that infrastructure projects often fail because term limits/vote cycle mean that people can make short term decisions they benefit from with long term consequences they are not responsible for. The model of platform as a product breaks down when you understand that the platform is a both a monopoly and a cost center. Platform is much closer to a government (trying to keep people as happy as they can with as low taxes as possible), than a business (able to charge as much as the market will bear/doesn't have to serve any particular customer or use case). The difference between pleasing everyone enough, and pleasing some specific people a lot is quite a large paradigm difference. Platform is a product in the same way that Comcast is a product. Platform is a product in the same way that the Flint Michigan water company is a product. Blaming a platform team is almost always wrong. The right people to blame is leadership.

hayst4ck 5y ago

> A platform engineer builds something for a customer, just that in this case the customer is a developer, usually within the same organisation. > Why create this artificial divide and silo thinking? If your customers are not happy with your work you're doing a bad job and your product sucks. The problem is that most companies don't start out with a platform team. They grow and grow until there are a set of problems that are ignored because there is no direct owner until they can't be ignored any more. A team gets created devoted to these problems and ultimately becomes a platform team, because it's an easy way to allocate work. It's one thing to design a "product" from the ground up. It's entirely another to be trying to build a building that is simultaneously crumbling and growing around you at every moment. Platform teams generally don't get the headcount allocation to get ahead of their work either, this results in having to make prioritization choices. When a platform engineer makes a prioritization choice, that means a product engineer is hearing "no." The problem then becomes the product engineer might do something to circumvent you or any other number of failure modes, when platform is circumvented or battled, this creates animosity. If a product team is told no, that likely means platform has to explain it, which is yet another time investment/context switch that is not building a platform "product". I assure you most platform developers are also "product" developers and see the platform as a product. The fundamental organizational difference between a platform developer and a product developer is that a platform developer is a "cost" and a product developer is seen as "income." Which ignores that platform teams are a product multiplier. A correct measurement of platform teams is aggregate product creation. When viewed this way it's pretty easy to see that a 5% boost across all teams might be a better investment than a 30% boost to 1 team. Unfortunately this is something that is very hard if not impossible to measure, so its a matter of leaderships gut feeling/the platform teams ability to market work that could be seen as fruitful.

narwally 5y ago

If ALL of your customers are not happy, then you're doing a bad job. But if only a small subset of your customers are not happy, then that's just par for the course. You can't please all of your customers all of the time because they all have slightly different needs, so you have to make difficult decisions on how you want to optimize overall customer happiness.

hayst4ck 5y ago
I think it's more like a team that works on roads or power. Platform teams are usually monopolies and they usually work on critical infrastructure. They are almost a kind of utility. When a power company has failed, you see blackouts, when a city fails to plan for public transportation or load on roads, everyone gets stuck in traffic. A lot of the time all of a platform teams customers are unhappy because there are very systemic problems with the platform (slow tests, hard/slow release, brittle services, slow feature production) that result in an overall bad experience. In addition, just like a freeway that's run out of capacity, adding capacity will often involve even worse traffic while the situation is being improved. Now if a lot of people are experiencing black/brown outs and a lot of people are stuck in traffic, who is to blame? Is it the power companies? Is it the road construction companies? No. It's city hall. It's the people who make prioritization choices. More lanes on a highway is a major investment and building a rail system is a major strategic choice. Those choices are not made by construction companies, they just build. Those decisions are made by city hall. If you are experiencing traffic it's because someone in an authority position looked at the opportunity cost of the tax dollars that might be spent on solving traffic and said, it's too high. Similarly, a platform that has too much traffic (dev experience sucks), probably indicates a CTO that said "we need features more than we need a stable platform." An even more apt similarity is that infrastructure projects often fail because term limits/vote cycle mean that people can make short term decisions they benefit from with long term consequences they are not responsible for. The model of platform as a product breaks down when you understand that the platform is a both a monopoly and a cost center. Platform is much closer to a government (trying to keep people as happy as they can with as low taxes as possible), than a business (able to charge as much as the market will bear/doesn't have to serve any particular customer or use case). The difference between pleasing everyone enough, and pleasing some specific people a lot is quite a large paradigm difference. Platform is a product in the same way that Comcast is a product. Platform is a product in the same way that the Flint Michigan water company is a product. Blaming a platform team is almost always wrong. The right people to blame is leadership.