Hacker News Reader

Comment by Gareth321 | Hacker News Reader

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.

View on HN

> 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.

Presumably the TL has a manager. This whole I need to justify what I’m working on to my manager and my other manager is wild to me.

Getting double teamed by managers is wild.

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

Reply on news.ycombinator.com