> 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.
I can validate that is frustrating. An inability to articulate more than the code is bad and it’s complicated is surprising from a TL.
That is probably the case in most companies, and as I said it’s not that hard to identify what is impacted by that dog shit code.
Having a spike/PRD/TRD process, really anything written by a human long form, can help build alignment. This is because you have ample time to ask questions and dive deeper, and it’s not personal it’s just part of the process.
I’m not sure whether the charts I created were themselves the convincing piece of evidence. They just happened to be where I found common ground easier and then maybe the rest just clicked
> 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.
Your concept of "every level of understanding" does embody the PM stereotype. From an engineering perspective, most of your list tends to be 90-95% timewasting fluff and toil. Hopefully with as much as 5-10% valuable content that can help the team to accomplish their mission.
A good PM (IMO) would take responsibility for dealing with the fluff, and engage the TL with the 5-10% useful fraction.
Also, a good PM will strive to learn and understand what the team is doing and why... well enough to act as an advocate for the team, and explain to the many people you interact with throughout the organization.
A team will respect and appreciate a PM's effort to meet them on some technical level of understanding. Being embedded with a team of experts in a particular technology gives you a unique opportunity to raise your understanding of their tools, technology, tasks, challenges, and successes.
A good PM is valued as a colleague contributing to the team's success.
> metrics gets everyone on the same page, because numbers and charts are easy to understand.
Those are just not to convince a manager though, it gives numbers to set KPIs, or at least some benchmark to evaluate the improvements, and at the end of the day solid reasons to justify promoting the team.
From both sides of the fence, fixing problems that only the engineers on the ground can properly value leads to everyone being miserable in the long run.
More or less. I set up DBM on datadog and built a dashboard with common db perf metrics. You can set thresholds as dotted red lines across the y-axis of charts to articulate moments of danger.
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 ↗
dirtbag__dad · · focus · HN ↗
That is probably the case in most companies, and as I said it’s not that hard to identify what is impacted by that dog shit code.
Having a spike/PRD/TRD process, really anything written by a human long form, can help build alignment. This is because you have ample time to ask questions and dive deeper, and it’s not personal it’s just part of the process.
I’m not sure whether the charts I created were themselves the convincing piece of evidence. They just happened to be where I found common ground easier and then maybe the rest just clicked
boisterousness · · focus · HN ↗
Your concept of "every level of understanding" does embody the PM stereotype. From an engineering perspective, most of your list tends to be 90-95% timewasting fluff and toil. Hopefully with as much as 5-10% valuable content that can help the team to accomplish their mission.
A good PM (IMO) would take responsibility for dealing with the fluff, and engage the TL with the 5-10% useful fraction.
Also, a good PM will strive to learn and understand what the team is doing and why... well enough to act as an advocate for the team, and explain to the many people you interact with throughout the organization.
A team will respect and appreciate a PM's effort to meet them on some technical level of understanding. Being embedded with a team of experts in a particular technology gives you a unique opportunity to raise your understanding of their tools, technology, tasks, challenges, and successes.
A good PM is valued as a colleague contributing to the team's success.
makeitdouble · · focus · HN ↗
Those are just not to convince a manager though, it gives numbers to set KPIs, or at least some benchmark to evaluate the improvements, and at the end of the day solid reasons to justify promoting the team.
From both sides of the fence, fixing problems that only the engineers on the ground can properly value leads to everyone being miserable in the long run.
ambicapter · · focus · HN ↗
What were the charts that convinced them? Just high load % on your databases?
dirtbag__dad · · focus · HN ↗