> The continuous struggle is to find ways to increase the value our platform provides to the users of the system.
IME as a staff+ platform engineer*, it is dead obvious what increases user value. What is truly challenging is building a story around why anything should be worked on at all, when platform sits the furthest from customers.
I previously worked with a seasoned PM from FAANG who had low technical chops but somehow placed themself in the final decision maker seat for platform work.
They relentlessly blocked work that I described repeatedly in details: data quality was hurting, latency was dog shit, etc. But “bad data model? What do our customers care about our data model and pipelines that are confusing to maintain?”
It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident. At that point, we finally had the same understanding of the problem at the highest level and I was granted (lol) approval.
This admittedly took me almost a year to figure out. Others just trusted my judgement. The takeaway for me was really good tho. Even technical people probably don’t know wtf is going on in your domain, and metrics gets everyone on the same page, because numbers and charts are easy to understand.
* Platform is used too broadly so hard to say what the author exactly means by this.
I'm the PM side of this debate with my TL. I've tried meeting him on every level of understanding. Graphs, story telling, Jira issues, business cases, ITIL, OLAs and SLAs, customer interviews, user interviews, you name it. He strongly resists having to justify the things he wants to work on. His justifications are usually some combination of "it's too complicated to explain," and "this code is a mess." Problem is, I need to account for their hours. I need to explain why we're spending money on that thing - to people who are even less likely understand what my TL is saying.
I say this not to diminish your frustration but to appreciate that you tried to meet him at his level, and provide some context for what the other side can feel like.
dirtbag__dad · · focus · HN ↗
IME as a staff+ platform engineer*, it is dead obvious what increases user value. What is truly challenging is building a story around why anything should be worked on at all, when platform sits the furthest from customers.
I previously worked with a seasoned PM from FAANG who had low technical chops but somehow placed themself in the final decision maker seat for platform work.
They relentlessly blocked work that I described repeatedly in details: data quality was hurting, latency was dog shit, etc. But “bad data model? What do our customers care about our data model and pipelines that are confusing to maintain?”
It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident. At that point, we finally had the same understanding of the problem at the highest level and I was granted (lol) approval.
This admittedly took me almost a year to figure out. Others just trusted my judgement. The takeaway for me was really good tho. Even technical people probably don’t know wtf is going on in your domain, and metrics gets everyone on the same page, because numbers and charts are easy to understand.
* Platform is used too broadly so hard to say what the author exactly means by this.
Gareth321 · · focus · HN ↗
I say this not to diminish your frustration but to appreciate that you tried to meet him at his level, and provide some context for what the other side can feel like.
sarchertech · · focus · HN ↗
sharts · · focus · HN ↗