5 ms·

My experience with platform teams is, once they are formed, they suck up the best people. Doing k8s/technical stuff. People that should have been working on bu

My experience with platform teams is, once they are formed, they suck up the best people. Doing k8s/technical stuff. People that should have been working on building products.

zactato 2y ago
If those people were unhappy in their previous product engineering roles wouldn't they have left he company?
- fifilura 2y ago
  It is not black and white. In my experience, what people want is heavily influenced by the company culture. If building platforms is cool then everyone wants to be there. But if building products is the thing then people want to work with this.
anonzzzies 2y ago
Many technical people find platforms far more interesting than trying to convert an excel sheet to a user viable product. We mixed up platform with product again after a few years as platform not only got the best people but also started to slow down the product team by taking decisions they saw as better (objectively they were) which the product team didn't agree andor didn't have experience with.
- fifilura 2y ago
  You describe the toxicity I have experienced working in the product team vs a platform team. If you don't find it interesting to build products with whatever tool is most adequate (excel some times) maybe you should not work at a company building products. At least you should understand that you are part of the support team not the main guy. And yes, moving to GitHub from Jenkins is maybe objectively a good choice. But if it stalls product development for 6 months, is that objectively-objectively a smart move? It could of course be, but it requires more situational awareness than "is this tool better".
  - bogota 2y ago
    Platform teams also need to make calls where the experience might be worse for some but collectively better for the company. This is normally where you see the product engineers start to freak out.
    - SerCe 2y ago
      That's the point I was trying to highlight in the "Treating product engineers as customers" sin section – the duality goes both ways. Sometimes the best thing for the company is to make the lives of product engineers better, sometimes it's to make them worse. You do whatever is best for the company, not for the product engineers.
      - tuananh 2y ago
        but platform engineers are so far down the chain, it's hard for them to associate their work value to actual customer's benefits.
        fifilura 2y ago
        This is what we are discussing. A company can also choose to organize it some other way.
  - anonzzzies 2y ago
    Yes, I agree. It was more decided to go from Product Team -> [Product Team, Platform Team] and then everyone deep tech wanted to leave the Product Team, so it reversed again later. Guess if it's from the start, you can say indeed you should not work for a company building products. Anything thing is; platforms in themselves don't really sell. The products built with them sell, so what do you work for if you want to just build platforms (want to build game engines, not games as a comparison these days).
- TeMPOraL 2y ago
  > Many technical people find platforms far more interesting than trying to convert an excel sheet to a user viable product. Perhaps in part because they feel, deep down, that an Excel sheet is superior in terms of user-friendliness, capabilities and ergonomics, to whatever the "user viable product" company is trying to sell? A platform may serve different purposes, so the technical challenges, even if self-inflicted, don't seem pointless.
  - oldandboring 2y ago
    > Perhaps in part because they feel, deep down, that an Excel sheet is superior In my experience these folks are the exception rather than the rule. To recognize when, and when not, to use Excel vs. buying/building/subscribing to specialized software, takes a certain kind of real-world experience as a user and/or stakeholder that many engineers surprisingly lack, even long into their career.
discreteevent 2y ago
"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans

My experience with platform teams is, once they are formed, they suck up the best people. Doing k8s/technical stuff. People that should have been working on building products.

zactato 2y ago

If those people were unhappy in their previous product engineering roles wouldn't they have left he company?

fifilura 2y ago
It is not black and white. In my experience, what people want is heavily influenced by the company culture. If building platforms is cool then everyone wants to be there. But if building products is the thing then people want to work with this.

anonzzzies 2y ago

Many technical people find platforms far more interesting than trying to convert an excel sheet to a user viable product. We mixed up platform with product again after a few years as platform not only got the best people but also started to slow down the product team by taking decisions they saw as better (objectively they were) which the product team didn't agree andor didn't have experience with.

fifilura 2y ago
You describe the toxicity I have experienced working in the product team vs a platform team. If you don't find it interesting to build products with whatever tool is most adequate (excel some times) maybe you should not work at a company building products. At least you should understand that you are part of the support team not the main guy. And yes, moving to GitHub from Jenkins is maybe objectively a good choice. But if it stalls product development for 6 months, is that objectively-objectively a smart move? It could of course be, but it requires more situational awareness than "is this tool better".
- bogota 2y ago
  Platform teams also need to make calls where the experience might be worse for some but collectively better for the company. This is normally where you see the product engineers start to freak out.
  - SerCe 2y ago
    That's the point I was trying to highlight in the "Treating product engineers as customers" sin section – the duality goes both ways. Sometimes the best thing for the company is to make the lives of product engineers better, sometimes it's to make them worse. You do whatever is best for the company, not for the product engineers.
    - tuananh 2y ago
      but platform engineers are so far down the chain, it's hard for them to associate their work value to actual customer's benefits.
      - fifilura 2y ago
        This is what we are discussing. A company can also choose to organize it some other way.
- anonzzzies 2y ago
  Yes, I agree. It was more decided to go from Product Team -> [Product Team, Platform Team] and then everyone deep tech wanted to leave the Product Team, so it reversed again later. Guess if it's from the start, you can say indeed you should not work for a company building products. Anything thing is; platforms in themselves don't really sell. The products built with them sell, so what do you work for if you want to just build platforms (want to build game engines, not games as a comparison these days).
TeMPOraL 2y ago
> Many technical people find platforms far more interesting than trying to convert an excel sheet to a user viable product. Perhaps in part because they feel, deep down, that an Excel sheet is superior in terms of user-friendliness, capabilities and ergonomics, to whatever the "user viable product" company is trying to sell? A platform may serve different purposes, so the technical challenges, even if self-inflicted, don't seem pointless.
- oldandboring 2y ago
  > Perhaps in part because they feel, deep down, that an Excel sheet is superior In my experience these folks are the exception rather than the rule. To recognize when, and when not, to use Excel vs. buying/building/subscribing to specialized software, takes a certain kind of real-world experience as a user and/or stakeholder that many engineers surprisingly lack, even long into their career.

discreteevent 2y ago

"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans